Genus classifications allow us to subdivide the Family of IT into subcultures based on their commonality to each other, while the Species definition enables us to highlight sometimes subtle differences, such as color, range or specific habits.   Therefore, in order to round out our Taxonomy, Genus will refer to how IT is physically architected, while Species will expose what that architecture may hide.

The physical architecture of an IT environment used to fall into only a couple of categories.  Most organizations built their platforms to address immediate needs, distributing systems based on the location of their primary users.  An inventory database would be housed at the warehouse facility, while financials would sit on systems at corporate.  This required the building and maintenance of complex links, both at the physical transport layer and also at the data level.  Because of the limits of access technology, people traveled to where the “data” was kept.

Twenty years ago, we began the transition of moving the data to where the users can consume it.  A new Genus evolved that enabled data to be moved to where it could be consumed.  It’s vastly more efficient to ship a 5MB spreadsheet halfway across the country than it is to ship a 170lb accountant.  In this architecture, the enablers were increases in available bandwidth, more efficient protocols, and better end-node processing power.

As we move forward in time, we are continuing to push the efficiency envelope.  Now, we don’t even have to move that spreadsheet, we just have to move an image of that spreadsheet.  And we don’t care where it needs to go, or even what route it takes to get there.  We are all about lowest cost routing of information from storage to consumption and back.

So, Genus is a way for us to gauge how far down that arc of advancement our customers have traveled.  Think in terms of a timeline of alignment with industry trends and capabilities.

Species, on the other hand, can be used to uncover the “gaps” between where in the timeline the customer is and what they have missed (intentionally or not) in terms of best practices.  Did they advance their security in line with their technology?  Have they established usage policies?  Can their storage sustain the transition?  What have they sacrificed to get where they are today, and what lies beneath the surface?

Using Genus and Species classifications, we can round out the taxonomy of any particular IT environment.  The combination of factors from each of the seven layers completes a picture that will allow us to guide our customers through the turbulent waters of today’s IT world.

To recap the seven layers:

Kingdom: How IT is viewed by the business

Phylum: IT’s general operating philosophy

Class: How IT is managed on a daily basis

Order: How IT is consumed, and why

Family: The structure of data flow within IT systems

Genus: How IT is physically architected

Species: What that architecture may hide

It would be quite the undertaking to build out individual groupings in each of these categories.  That is not what is important (although I did enjoy creating the pseudo-Latin neologisms in earlier parts of the series).  What is key is that we consider all of these categories when creating an overall approach for our customers.  It’s not all about the physical architecture, nor all about management.  It’s about how the collection of characteristics that flow from the top level all the way down to the bottom converge into a single picture.

In my opinion, it is a fatal mistake to apply technology and solutions across any of these levels with impunity.  Assuming that because a customer fits into a specific category they “have” to leverage a specific technology or solution is to blind yourself (and ultimately your customer) to what may be more appropriate to their specific situation.

Each environment is as unique as our own strands of DNA, and as such even those that make it to the Species with commonality will branch onto different future paths.  Perhaps there should be an eighth level, one that trumps all above it.  It could be called “Individuality.”

In Part1 and Part2, I have begun to map the classification of IT using the biological taxonomy framework.  Each of the first two articles identified the top levels of IT classification.  The Class level is the last of the major distinctions, and begins to show us where our services and value statements will have the greatest impact.

At the Kingdom level, I identified three business/IT classifications that focused on how IT is viewed by the business.  These were Cost Center, Operational Enabler, and Profit Generator.  At the Phylum level, I divided IT by its general operating philosophy.  Each Kingdom was sub-divided into 3 phyla which demonstrate how they arrived at where they are today.

If we continued down this path, each layer would grow exponentially.  There would be 27 Class definitions, and 81 Orders, and so on.  That would make for the longest blog post in history.  Instead, for the rest of this series, I’ll focus on what each level brings to the overall definition of a particular IT environment, and provide some examples so as not to turn the reader into an extra on The Walking Dead. 

Class

Going back to biological taxonomy, the Class level groups organisms by major physical components.  Our Honey Badger friend is in Class Mammalia, which tells us it has hair, teeth, breathes through lungs, and has a well-developed hormonal system.  It is the Class category that separates mammals from reptiles and birds.

Within IT, we can apply Class to the fundamental thing that separates each of the previously defined phylum – how IT is managed on a daily basis.  IT can be managed in a myriad of ways, from internal to external, as a unified platform or by technology silo, and by variable of fixed cost approaches.  In any of these variations, the importance of this classification cannot be mistaken.  No matter what the decision making process has been that resulted in the current state of affairs for IT, it is that ecosystem’s management constructs that will determine the course of IT.

70% of IT resources are consumed managing the current environment.  So, by defining Class at this level, we are grouping IT by the majority of time and effort expended.  Providing ways to re-balance IT resources, while at the same time reducing errors and downtime, will provide great value within any of the IT Kingdoms.

Within the Cost Center Kingdom, you will find Classes and Orders such as:

Within the Operational Enabler, you will find Classes such as:

Within the Profit Generators, you will find Classes such as:

By Michael Halperin

In the first and second installments of this series, we introduced the idea of Quality of Experience (QoE) Management and explored how traditional IT Monitoring tools are excellent at providing visibility into an IT environment, but lack context – the critical difference between traditional IT monitoring and QoE Management.  We explored exactly what constitutes context and broke it down into three components: Business Services, Infrastructure Mapping, and Benchmarking. So the question becomes, why isn’t everyone doing this?

The answer lies within the complexity of those three components of context. To implement QoE Management, the first thing we must do is answer the question “what are our Business Services?”  This would require an intensive investigation and analysis that would be extremely time consuming.  Mapping those Business Services would be even more difficult and time-consuming. In fact, this task would be impossible in most IT environments because of the rapid rate of change characteristic of most IT environments – by the time the map is complete, it would be out of date.  In other words, QoE Management using manual methods is essentially impossible.

However, emerging tools bring QoE monitoring into the realm of the possible.  New auto-discovery tools not only identify infrastructure components but also can identify specific data flows – Business Services – that run on the infrastructure.  These tools are unobtrusive and therefore can run all the time, making our Infrastructure Mapping a real-time function. It also enables Benchmarking, ongoing monitoring, and identification of impacted users when an event occurs.

With the right tools in place, Quality of Experience Management becomes possible.  Ironically, it doesn’t necessarily require a dramatic change in traditional monitoring. Today, many IT shops carefully watch the discrete components of the IT environment. But with monitor sets driven by Benchmarking, IT can act, not just when things break, but also when performance goes out of normal parameters just enough for  users to notice.  Because of Infrastructure Mapping, IT can quickly identify which Business Services are impacted, and act to protect users accordingly.   The power of this approach is apparent, and we predict that QoE Management will soon emerge as the new Holy Grail of IT Management.

So what should organizations who are interested in QoE Management do next?   Stay tuned….

In the article, author David Goldman states that one reason for the “spectrum crunch” is the tremendous increase in data requirements for newer wireless devices.  He references a Federal FCC agency report that indicates that the iPhone consumes 24 times more spectrum than a traditional cell phone, and the iPad 122 times.

There is a finite amount of spectrum, so as the percentage of these types of devices increases in the market, the quicker we will become spectrum constrained.  And as these devices become lower in cost, and WiFi becomes the standard for consuming other forms of entertainment (ie books, movies, news), the impact will escalate exponentially.

Think about it this way.  We have in large part moved from a paper-based society to electronic, and from hard wired to wireless.  We feel free, able to consume what we want, when we want it, from anywhere we like.  And what is the one constant and required resource for this new societal shift?  Wireless spectrum.

In a few years, we may see a conservation movement to preserve spectrum, similar to that we have seen for other “natural” resources.  The normal course of events generally starts with an impact to our lives, either in cost or availability of that resource.  Think of the energy crisis in 1973 and its impact on the auto market.  Prior to that, cars were not built with any consideration toward fuel consumption.  A 1970’s Chevy Impala had a 6.5 liter V8 and got less than 15 miles to the gallon.  In ’74, people lined up to buy the VW Rabbit, a car that provided between 30-40 mpg.

Could this happen in the wireless market?  Sure it could, if the impact of higher spectrum usage results in higher costs to the consumer.  For example, if you own an iPad, maybe you pay a spectrum surcharge, similar to the gas guzzler tax (started in 1978, a direct result of the ’73 energy crisis), levied against people who purchased less fuel efficient vehicles.  And what if the owners of those spectra decide to further consolidate, and the carrier costs for those devices skyrockets?   Will that stop people from buying spectrum-guzzling devices?  Not all of them, but a portion would probably reconsider.

After all, people still bought Hummers when they came to market in the 90s.  However, when prices for gas started to soar in the first years of the new millennium, sales plummeted.  GM tried to keep the brand viable by creating smaller, more efficient versions, but by then the damage was done.  In 2010, after only owning the brand for 11 years, it was eliminated.

So, put yourself 5 years, maybe 10, into the future.  You are looking at your next wireless device purchase.  Your options vary greatly.  All things being equal, you’ll still be flocking to the Apple store for the iPad X.  But that may change, if the iPad X comes with a 50% higher carrier contract because its data consumption was that much higher.

We may have to learn the same valuable lessons taught to us by the VW Rabbit.

By Michael Halperin

In our last installment, we introduced the concept of Quality of Experience (QoE) Management.

In this installment, we explore how QoE Management differs from traditional IT monitoring and how adding just one component can change everything.

Let me first say that the issue isn’t with existing IT monitoring tools and approaches.  For over two decades, IT departments have been relying upon an incrementally improving set of monitoring tools to identify and understand the incidents and events that occur within the IT infrastructure.  These tools provide visibility– the ability to see what’s going on.  Every year, new tools come out to provide better visibility to the ever-changing array of devices, systems and services that comprise the IT environment.

While this ongoing change in visibility tools is evolutionary, the advent of Quality of Experience (QoE) Management will be a revolutionary change.  Yet it requires the addition of just one more component to the traditional monitoring approach. This powerful change – the difference between traditional monitoring and Quality of Experience Management – can be summed up in just one word: context.   That is, a foundational understanding of how each component of the infrastructure is being used.

Context itself has two perspectives.  The first is the usage of the infrastructure over time by users performing various functions.  The second is the usage of the infrastructure at a particular moment in time (specifically, that moment when an event occurs).

But understanding context is the hard part.  Most IT departments will tell you they do understand their users.  But most likely, that knowledge is in the heads of the individuals within the IT department, not within the systems that monitor and manage the IT environment itself. And while that institutional knowledge can be vital to providing a good level of service, the true power of context comes when it is combined with traditional IT monitoring to enable a revolutionary change in how users experience IT.

Definition of context within a systematic framework requires a structured approach, and there are three components that together give us the three-dimensional view required to understand the context of user activity as it relates to the IT infrastructure. These three components are:

• Business
  Services
• Infrastructure
  Mapping
• Benchmarking

We use the term Business Services as an umbrella term that includes a wide variety of end-user facing functions.  It could be an application flow (e.g., all the hops in the transaction when a user accesses an ERP application – and the underlying database structures – from their desktop). It could be a functional protocol like SIP, point-to-point VPN or VoIP. It could be an extensible functionality like remote access, and it could be a combination of all of the above like Unified Communications.

Infrastructure Mapping is just what it sounds like. Every Business Service relies upon one or more components of the IT infrastructure, including end-user devices, WAN, LAN, security, servers, storage, applications and middleware.  Once we know what Business Services we support, we must understand how specific Business Services use the underlying IT infrastructure.  For instance, if our user is accessing an ERP application from home, then their local device, their internet connection, their VPN connection, the WAN link, the LAN, the app server, the database server and all the supporting storage are all links in the end-to-end Business Service, and therefore part of the Infrastructure Map for that Business Service.

Benchmarking is a data collection function that answers the question “what does normal look like?”  By definition, it can’t be a snapshot, but requires monitoring over a period of time to understand the normal ebbs and flows of performance.  Benchmarks include performance of specific individual components (e.g. a server), interfaces between components (e.g. the response time of a database server to an ERP application) and transactions across multiple components (e.g. normal response time of the company portal to a remote user across the VPN).

Traditional IT monitoring tools can measure the performance of specific components of the infrastructure.  But when all three of the components of context are in place, QoE Management compares performance against benchmarks and maps performance to specific Business Services. If a specific infrastructure component begins to behave outside the normal benchmark, a flag is raised and our Infrastructure Map identifies all impacted Business Services. We then have the information we need to warn or re-direct users who are engaged with that Business Service, and therefore most likely to be impacted by the event.

Over time, IT is able to evaluate where variances from benchmarks are most prevalent, then use the Infrastructure Map to identify which of those are most critical to users.  That allows IT to focus resources on those “hot spots” most likely to result in future issues.

The impact of all this on users – and the Lines of Business those users support – is obvious.  Also obvious is the question “why isn’t everybody doing this?” That answer will be provided in the third and final installment of this series.

Do you remember from high school, how we were all taught to classify biology via the old adage:  “King Philip Came Over For Good Steak?” The adage allowed us daydreaming students to remember the 7 layers of classification, which were Kingdom, Phylum, Class, Order, Family, Genus and Species.  Since this is a new year, and hopefully a year of tremendous technological advances in the world of IT, I thought it would be appropriate to apply this classification to IT.  Besides, the only way to look forward to new IT “species” is to fully understand what we have today, is it not?

Each classification level provided a way to group organisms by shared characteristics, allowing for definition of their key aspects, and eventually enabling relationships to be developed.  For example, The Honey Badger (of recent fame) is of the Kingdom Animalia, Phylum Chordata, Class Mammalia, Order Carnivora, Family Mustelidae, Genus Mellivora, Species Capensis.  Which translates to:  They are an animal with a backbone, which breaths air and gives birth to live young which they nurse, has teeth and claws and primarily eats meat,  has short legs and ears, thick fur and is active year round, is most like a weasel in appearance, and is native to the southern African and Middle Eastern continents.

Now, within IT we can take a similar approach in classification (and, no this is not the OSI model, but interesting how OSI also has seven layers of classification?).  For this exercise, let’s start at the top and work our way down.

At the Kingdom level, IT can be classified in one of three ways:

A Cost Center – where IT may support internal business functions and management needs, but does not directly influence production or revenue.  An example may be a retail organization’s Point of Sale platform, or a manufacturer’s ERM solution.  These are generally seen as cost overlays to the business.

For obvious reasons, if IT is a cost center then the persistent view is that investments in IT will not net a return, but will negatively impact profit levels.  The challenges here are to identify what the business is willing to spend in IT and create the most effective organization possible.  IT is given limited strategic brain-time, and new expenditures are a negative experience.  To be purely in the Cost Center mode, a business would need to be able to survive at sufficient levels without technology in place, which in today’s world is a rare breed indeed.  However, these organizations do exist, even if only in their own perspective.  Some of the largest technology gaps show up in areas such as redundancy, data protection, DR, and security.

Operational Enabler – IT in these organizations has bridged from being considered a Cost Center to an influencing component in the success of the organization in delivering their service or solution to their clients. Firms leverage IT as a differentiator or competitive advantage, and often some level of direct customer delivery is tied to IT.

In these organizations, IT is both a cost of doing business and a key component of a successful business plan.  Investments are made judiciously, with a focus on ROI and lower TCO.  IT may also spend more in critical areas than in underlying infrastructure or platforms.  It’s not uncommon to find state-of-the-art business platforms being supported by legacy networks and lower tier storage devices.  Redundancy is often sacrificed, and upgrades/improvements put off until the next budget cycle.  Within IT there may be different levels of importance defined on different platforms, leading the organization to a front-end/back-end mentality towards investment.

A Profit Generator – where IT directly impacts revenue or profit levels.  eCommerce, software development, and marketing organizations are good examples here.  IT is either the service/solution your customers are purchasing from you or is a critical path in the delivery of your service/solution.

Here you will find financially backed IT environments that are consistently maintained and updated.  The organization realizes that their livelihood is heavily or entirely reliant on IT, and will overfund rather than skimp.  At a platform level, high levels of resiliency, recoverability and scalability are the norm.  IT staffs are larger and better trained.  On the flip side, with the organizational expectations so high, you will also find less margin for error, delay or impact.  External support from partners, managed services providers and other 3rd parties are prevalent here.

At the top level, IT can be classified by the view of the organization in terms of the benefit it provides to the business.  The lines are not completely distinctive, and do rely on individual perspective.  However, this classification level will set the foundational view of IT in the organization, and will likely determine the course of action for most, if not all, IT decision making.   Like the Kingdom level in biology, where distinction is at a cellular level and not always visually apparent, this IT classification level can be deceiving.  The Venus fly trap, which qualifies as a Plantae in most ways, gets its nutrition via consuming other organisms, which is a characteristic of the Kingdom Animalia.  So, if you are dealing with a Cost Center classification, you may find sublevels of the other classes within the organization.

The next level down of classification (Phylum) should build off of these three designations, further defining the business’s approach to IT.  The key characteristics of these deviations are centered on the pace of change and adoption of new technologies and best practices.  In my next blog entry, I’ll look at both the Phylum and Class levels of the taxonomy of IT.