The Alignment of IT and Business

Its 8:45am, two weeks after the outage of our "minor IT system" at First Class Glass' Denver data center and IT Manager John Brown is finishing up his monthly metrics presentation to FCG's business leaders. Amped on too much coffee and not enough sleep, John reminds himself why he hates these end-of-the-month presentations.

"There're just too many manual steps in putting together these reports," he thinks to himself for what seems the hundredth time since late last night. "Every month, the FCG executive leadership wants all this statistical and trend line data so that they can see that our systems remain as operational as they always have," he thinks, "Yea, I know we sometimes run out of disk space on some of the servers, and rarely our critical applications may slow down or go down for a short period of time. But we've thrown so much money at this application and network, adding clustering and redundancy, disaster recovery, and everything else that we rarely have major problems anymore."

What I really wish we had was a way to pull these metrics automatically. Then, once a month my senior staff and I wouldn't have to spend the night here pulling together statistics for this marginally-useful 30-minute presentation."

John adds the finishing touches to his PowerPoint slide deck, entering in some last-minute figures he received from his Help desk manager on work order closing metrics. He saves the completed file to the network and heads off to the boardroom for his presentation.

If you've ever pulled together these kinds of metrics for your company's monthly executive update meeting, you've probably had the same series of thoughts at the 11th hour. Figuring out what kinds of metrics the leadership wants to know is only part of the trouble. Compiling those metrics from dozens of separate and un-automated systems can have the effect of shutting down the department for a day as people scramble to gather the end-of-the-month statistics. Often, the presentation goes by with nary a question when senior leadership doesn't understand the statistics you're providing them.

Contrary to what the IT people in the trenches often believe, this data is critical to the smooth and continued operations of the business network. Executive leadership needs these statistics so that they can prove to themselves that the money they've "thrown at the network" is actually providing value and measurable return.

Business leaders by nature have to look at the world through statistics, trend lines, and return on investment (ROI). IT by nature tends to look at the world in terms of technology. Merging these two schools of thought into a common language—or at least a common interface—is one of the tenants of Business Service Management (BSM).

Where the difficulty often presents itself in these situations is in translating what is important to IT into information that is digestible to executive leadership. If business leaders can't understand the kind of data they're being presented at the monthly metrics meeting, they can't make good decisions on what to do with that data. This chapter talks about the dissonances between what IT believes is important and what the business leaders want to see.

When these two groups speak the same language and share the same priorities, we say that they have achieved alignment. This chapter will discuss the alignment issue as well as common failures in alignment. We'll talk about why misalignment occurs and what IT can do to develop itself both culturally and technologically to resolve the problem. Throughout the discussion, we'll incorporate what we've learned so far from Chapter 1 to show how the implementation of BSM into the operating environment helps enable the alignment of IT and the business.

The Chasm Between IT and the Business

Remember our "minor IT outage" from Chapter 1? It was not considered all that problematic an event by the IT department. The team of server administrators resolved the issue within a reasonable amount of time, and the system was listed as Tier III, putting it in the same category as low-priority backup and systems management systems. But that system wasn't as low priority as the IT department thought, causing a slight outage to a major system but incurring a large cost to the company. Let's return back to the story to see how our monthly metrics meeting plays out:

"…and as you can see in this slide, IT met their Service Level Agreement (SLA) for this month, showing no appreciable network outages for the month period."

"John, can I stop you there," interrupts Dan Bishop, First Class Glass COO, "why does this report not include the problem we had with the B2B site back two weeks ago? That outage has been keeping our accounting people here late nights for the last two weeks cleaning up the mess. The cost in overtime alone is killing our Q3 budgetary numbers."

John nervously continues, "Well sir, that system is categorized as a Tier III Priority system. Our SLA for Tier III systems states that we have eight hours to get these systems back online, which we did. In any case, that system is only a minor player in the B2B system anyway. And, the problem happened at 2:15a, when many of our business customers weren't even awake."

What you should see in this example is a conversation you may have had before in your business. Both parties are perfectly within their rights to believe they're correct. IT brought the system back online within its agreed-upon timeframe, but the business has recognized a higherthan-expected cost. When it comes to the total impact, what we have here is an example of the chasm between IT and the business.

Responsibilities and Priorities

In many businesses, the IT department is run by the techies. Purchase decisions are based on easing the management responsibilities of those in charge of server care and feeding. Description of service outages are constrained by the devices taking part in the outage. Those individual devices—database, network, application servers, infrastructure servers—and the services hosted by those devices are reported up the chain in the parlance of the responsible engineer for the service. Let's start our analysis by taking a look at the responsibility matrix for a typical business network.

Figure 2.1: An example org chart for an IT organization. Those individuals above the dotted line are typically responsible for the overall business strategy, while those below the dotted line typically deal with daily operational issues.

Figure 2.1 shows a typical organizational chart for an IT department. This chart shows the IT Director reporting to a CIO, who ultimately reports to the CEO. The IT Director's direct reports are the managers responsible for their portion of the network. Co-equals at this fourth tier in the organization are each of the managers who lead their team of administrators. Those administrators are typically identified as responsible engineers for specific portions of the network: Bill the Windows Administrator is ultimately responsible for the functionality of Windows Active Directory (AD). Jane the Network Administrator specifically manages the network gear in the company's DMZ to the Internet. Bob in Applications really only manages the B2B sales application.

Also shown in Figure 2.1 is a dotted line representing the line of demarcation between those individuals typically responsible for overall business strategy and those that handle daily operations. Notice the bottom-heavy nature of the org chart in relation to that dotted line. Due to the high positioning of the dotted line, it is here where we see the biggest chasm between the goals of IT and those of the business.

Unlike individuals in sales and marketing who work with business-level goals as part of their daily operational tasking, individuals in IT are often insulated from business decisions. The summation of this insulation, along with the vocabulary created and used by IT, is a large contributor to our chasm.

Why this chasm? Principally, due to an individual's scope of responsibility. As an individuals' position in the organization gets further and further away from the money-making decisions in a business, their priorities—both formal and intrinsic—grow less aligned with the overall goals of business. Adding to that situation is the fact that the responsible engineer for systems monitoring is often an administrator in the Applications or the Network group.

The applications or network administrator is given the task of installing, configuring, and maintaining the systems monitoring tool for the network. He or she is a techie. Thus, the decisions they make in terms of what to monitor and when to alert are based on their priorities and experience as a techie. Their fifth-tier knowledge of the overall business strategy inhibits them from enabling notifications that align with the needs of the business. Let's deconstruct our discussion on alignment a little further and talk about how the culture of the IT organization as a whole affects its alignment with the business.

Early IT

In the beginning, there were just a few computers. Then some very intelligent people figured out ways to connect those computers. Since then, those computers' interconnectedness has had a tendency to beget ever more computers. Early IT organizations tend to react to the business need for additional services and the hardware to host those services rather than plan for and expect their arrival.

This reaction to the need for service expansion happens due to the reactive nature of Early IT organizations. Later, this chapter will discuss the IT Maturity Model in great detail; but for this section, it is important to note that Early IT organizations tend to operate more or less independently from the rest of the business.

Table 2.1: The goals of Early IT are often the least aligned with those of the business. As the business attempts to grow itself, IT finds itself struggling to manage the existing infrastructure.

This independence predominantly occurs because early networks can be quickly thrown together to support the needs of the burgeoning business. The details of redundancy, service resiliency, and manageability are swept to the side as the priority is to simply get the service operational. The initial network hypergrowth combined with the hypergrowth of the early business often means plenty of firefighting for IT.

It's worth stating here that firefighting and otherwise reactive modes associated with Early IT should not be considered a black mark on IT itself. Reactive-mode IT is a necessary evil of any new business endeavor. This firefighting is more an indication of the sheer magnitude of effort necessary to build and manage a modern business network.

"Users" Become "Customers"

As the business matures, the network tends to mature with it. The initial network that was quickly thrown together eventually gets a much-needed facelift with an eye towards resiliency and single point of failure elimination. At some point through this period, the IT department begins to see improved mean-time between failures for services. This reduction in firefighting for core services earns IT the ability to stand back from the network and begin looking at the network as an integrated unit rather than the summation of its individual parts.

The change in mentality associated with greater "building" and less "fixing" also tends to drive a change in how IT sees the employees who use the network. At some point, the IT department begins to see the users of its network less as "the people causing the problems" and more as "the people using the services." The negative connotation of "users" disappears, and the network residents become in effect the "customers" of IT. It is this mindset change that signals the movement of IT away from its initial firefighting days.

Proactive IT

Once that change begins, the move to Proactive IT occurs rather rapidly. Proactive IT incorporates solid change control into network configurations and incorporates necessary systems documentation into every task. Most importantly, those change control mechanisms are agreed upon by all members of IT, are followed, and align with the needs of the business.

Be wary of moving to formalized change control too early. Formalized change control rapidly matures IT, but at the same time tends to reduce its agility. If the business is still in a startup mode, formalized change control can inhibit that business' agility as well.

IT that begins to operate proactively begins to "see the forest for the trees." They begin understanding the metrics necessary to identify the health of the network. They start to recognize the natural cycle of IT purchasing and plan more carefully for those purchases. And they begin to recognize their role in the greater business, providing calculated support for the necessary business services as they're needed. The best Proactive IT teams align seamlessly with the business and its goals.

Figure 2.2: As IT grows, key indicators as to its maturity become apparent.

Let's take a look now at a more formalized model of IT Maturity, presented by Gartner. This model expands upon what we've discussed in this section to talk about the key indicators associated with the maturity level of an IT organization. The intent here is to highlight how the organization's maturity parallels with its alignment to business. In all of this, we'll discuss how the tenants of BSM are a catalyst for solidifying that alignment.

Alignment Inhibitors

No conversation on alignment is complete without a discussion of the behaviors that tend to prevent that alignment from occurring. We've already discussed alignment inhibitors throughout the earlier text, but for completeness, let's discuss each in turn. As we consider the roadblocks to getting IT and the business on the same page, think about where these elements are present in your organization. Is your IT team a cohesive part of the business' strategy or do they sit in their own part of the building walled off from the rest of the employee base? Among the following items, alignment between IT and the business principally means that IT and the business know each other and say "hi" in the hallways as they pass by.

No Common Dialog

Our "conversation in the hallway" analogy rings true perhaps most specifically in terms of vocabulary. If IT and the business are utterly incapable of communicating with a common dialog, IT will forever be relegated to the left half of our maturity curve. Furthermore, when IT and the business are incapable of talking, the business itself suffers. Others who figure out the role of their own IT infrastructures don't get left behind in terms of competitive advantage.

Two things must happen for the common dialog to occur. First, IT needs to figure out mechanisms for reducing the technical complexity in their communication. Like any good college speech communication class, IT must learn to tune the conversation to the listener. From a metrics approach, the understanding of how finance is realized in each business process is a key component. For a BSM implementation, this component is critical as one of the major steps in BSM is the identification of granular business processes and the assignment of dollar values to each. Thus, it can be argued that the common dialog is really the first step in incorporating BSM.

The second element that must occur—though business leaders may not agree—is the need for them to understand IT. If the business strictly sees IT as a cost center full of techies, alignment can never occur. Business leaders need to see the value in IT-branded metrics as well. It is as difficult for IT to derive service quality metrics based solely on business metrics as it is solely on technology-based ones. The commonality of quantification goes both ways.

Mismatched Expectations

As was explained in the chapter example, the availability expectations of FCG's IT department didn't match what really happened. Knowing of a service outage and responding to it needs to be augmented with the knowledge of how that outage affects the business. This is the central tenant of BSM. Once each service is granularized and analyzed with an eye towards business impact, those expectations begin to align. Interestingly enough, though the lack of a common dialog is arguably the biggest inhibitor to alignment, the impact of mismatched expectations often causes the most impact to the business.

Technology-Focused Metrics

The idea of mismatched expectations feeds directly into the issues surrounding technologyfocused metrics. When metrics are created as technology-centric, they lose the total realization of the customer's experience with the environment.

Consider our example critical B2B system. FCG's technology-focused metrics identified only a very small outage to the environment, although that very small outage actually caused—from the user's perspective—a huge problem. The loss of a single system may sound inconsequential on paper, but the total impact to the business is large.

Only by flipping the metrics 180 degrees can we illustrate the system from the perspective of the system's users. Ultimately those users are the reason for that system's creation in the first place, so logically it only seems rational that that system's measurement of success is based on the satisfaction of its users.

Chapter 3 will incorporate a detailed discussion about the maturation of monitoring tools and techniques that ultimately culminates with BSM. Through BSM's framework and tools, we can flip upside-down our traditional ways of thinking about monitoring data and enable metrics that more closely align to the needs of the business.

Siloing

Siloing is the concept of individual toolsets or teams working in insulated environments where their activities may not necessarily be communicated elsewhere. In siloed environments, the activities can be unnecessarily replicated elsewhere in the environment, wasting resources on the duplication.

From the perspective of misalignment, siloing can also represent the lack of communication and mismatched goals between departments in an organization (Source: http://en.wikipedia.org/wiki/Silo_effect). When IT-internal goals are siloed away from the rest of the business as a whole, they lose the necessary collaboration that drives alignment.

Exacerbating this issue is the fact the there are significant silos within IT as well. The network , the servers, and the applications are all managed within separate silos, leading to metrics being technology-focused, rather than business-focused. IT goals must be a component of business goals and worked on in collaboration with the business if the two are to effectively merge.

Reactive Mode IT

Our last inhibitor is one we've discussed at length in this chapter. When IT is operating at or above 100% capacity with just the daily care and feeding of the network, it is impossible for strategic thinking to occur. Though the process involves an initial cost, in order to elevate IT out of strictly reactive mode, some team members must be permanently or quasi-permanently set aside for the tasks of strategic thinking and long-term planning.

There's an old IT joke that goes something like, "I don't have the time to automate this process. I'm too busy doing it manually!"

The Gartner IT Maturity Curve

The Gartner model for IT maturity expands on the concepts we discussed in the last section. This model identifies five categories of IT culture. As an IT organization moves from infancy to full maturity, it exhibits a series of identifying characteristics and enjoys certain benefits associated with that level of maturity.

Figure 2.3: In the Gartner model, Proactive IT is only the third step towards maturity. Gartner's model also adds the trigger points and associated benefits enjoyed by organizations that achieve each level in the model.

What drives the rightward movement of an IT culture is its acceptance of planning and automation components. You'll see right off that Gartner identifies Proactive IT as only the third step in the maturity process. With Gartner's model, once an organization gets to the Proactive stage, they're only halfway to fully recognized maturity. The reason for this is the addition of service-oriented thinking to the automation and planning components associated with the Proactive stage. Service-oriented thinking aligns with the business service model that BSM resides upon. Let's take a look at the characteristics associated with each of the stages in the Gartner model with an eye towards how that stage integrates with the tenants of BSM.

Chaotic

Earlier in this chapter, we discussed Early IT and the associated mindset. That mindset integrates well into the Chaotic stage of the Gartner model. In the Chaotic stage, Gartner identifies a few key characteristics (Source: These and all characteristics to follow are from the Gartner IT Management Process Maturity Model, Transforming IT Operations into IT Service Management, Data Center 2003, Deb Curtis and Donna Scott ):

• Ad-hoc
• Undocumented
• Unpredictable
• Multiple Help desks
• Minimal IT operations
• User call notification

These six characteristics identify an IT environment that is highly un-optimized. So much so, in fact, the IT department has no capability of even understanding the underlying environment itself. A problem that occurs in this environment is likely not realized until a user notifies IT that the problem has occurred. Automatic notification capabilities are not established. No documentation of services is available to track linkages between services and service dependencies. The lack of control renders the environment highly unpredictable.

In the Chaotic environment, tools are purchased for tactical reasons and freeware and open source tools are often chosen above enterprise-level tools due to initial cost barriers. However, it's important to note that some IT organizations in the Chaotic state have actually over-invested in tools with the premise that purchasing a tool equates with improving service. And, because they don't have mature processes, every department has their own tool, duplicating cost and effort. Toolsets are siloed as are the personnel who use those toolsets. The culture in Chaotic environments can involve organizational infighting as lines of demarcation are not wellestablished.

Relating the Chaotic environment to our discussion of BSM, it is very difficult—if not impossible—to bootstrap a BSM implementation into an environment that lacks even a modicum of definition. The organization will likely require a shift to the right before it can consider a BSM solution.

Reactive

That first shift to the right for a Chaotic organization is a move to the Reactive stage. Without repeating what we've already discussed about Reactive IT, let's look at a few of the characteristics Gartner identifies with Reactive organizations:

• Best effort
• Fight fires
• Inventory
• Initiate problem management process
• Alert and event management
• Monitor availability

As you can see, the first shift adds a host of benefits to the IT organization. Although service availability is still at a "best effort" stage and SLAs are likely not yet implemented, the organization is at this point beginning the process of understanding its environment through the inventory and availability monitoring process. Inventory and monitoring data—through predominantly up/down monitoring—are feeding management databases even if the data is not being acted upon.

IT within most companies resides in this stage of maturity. And interestingly enough, many ITminded professionals prefer to work in environments at this stage. At this stage, IT is still a bit of the "wild west" but without the complete adhocracy associated with the Chaotic stage. Change control measures are voluntary and unplanned service outages may still occur due to miscommunication between the various components of IT.

With an eye towards BSM, environments in the Reactive mode are fully capable of implementing a BSM solution. However, the implementation of that solution and its associated service model will involve heavy documentation and formalizing of the environment—taking the "wild" out of the "west" if you will. Implementing a BSM solution at this stage will organically shift the organization's maturity another notch to the right. Because of the nature of IT culture at this stage, this shift can be painful for the employees within the organization.

As stated earlier, it is not necessarily bad that an IT organization lies in the Reactive stage. Only that the organization has not invested the time and material into elevating key personnel out of firefighting and into analysis and automation activities. The slow and steady incorporation of automation activities has the tendency to organically drive this move. It need not be a dramatic change from Reactive to Proactive.

Proactive

Our previous discussion ended here with the Proactive stage, but Gartner uses this as a stepping stone to the higher levels of IT service orientation. Proactive stage IT enjoys some very useful benefits, and only here do those benefits begin the process of aligning IT goals with those of the business itself:

• Monitor performance
• Analyze trends
• Set thresholds
• Predict problems
• Automation
• Mature problem, asset, and change management processes

They key determinant in identifying a Proactive stage IT organization is the use and analysis of performance data and how that data relates to the end user experience. Less-mature organizations still don't have a good answer to the questions, "why is the server slow today?," "who is impacted?," and "how long has this been a problem?"

With Proactive stage IT, the organization begins the process of actually using and acting upon the data collected by the inventory and monitoring solutions implemented in previous stages and adds the crucial component of monitoring performance from the end-user's perspective. Here, IT begins the process of understanding the underlying pinning of the network infrastructure and how it impacts service availability. The maturity of internal processes at this stage begin IT's ability to truly fulfill SLA guidelines because an understanding of the actual capability of the network is known.

Very important here is that one major issue still lingers in the Proactive stage: SLA guidelines and upward flow of metrics remain IT-focused and not business-focused. This lack of business focus is the single issue that keeps IT from reaching the next stage of maturity.

Organizations that implement management and monitoring at this phase are making good use of the data, but that use is still IT-centric. Implementing a BSM methodology and solution at this phase will actually provide the greatest return for the business. The general service model is relatively understood, if not used, at this point. It is here that the IT organization has the maturity level to understand the cause and effect associated between availability of the service model and how it affects business operations. A BSM implementation at this phase will rather quickly move IT that critical additional shift to the right and will do so with the greatest return on the initial investment.

Service

Few organizations mature on their own to the Service stage. Here, the IT organization truly understands its role in the daily operations and long-term viability of the business. In Chapter 1, we talked about how BSM helps illuminate the quality of a business service. Here within the Service stage is where the dollars and cents figures associated with that quality of service are actually identified and acted upon. That financial description of a service is the main component of ensuring a successful BSM implementation.

Here in the Service stage, IT enjoys the following benefits:

• Defined services, classes, and pricing
• Understand costs
• Set quality goals
• Guarantee SLAs
• Monitor and report on services
• Capacity planning

This concept of the dollar value associated with service delivery is crucial to the Service stage. Unlike in previous stages where IT dollars are typically "thrown at" products, the Service stage enables the organization to plan the outlay of money towards enhancing the holistic service model. This understanding of the linkage between the business service and its impact on business operations is a key characteristic of the Service stage.

Value

Our final stage is the Value stage. Here, the concepts of utility computing and "IT on-demand" surface as business services arrive just-in-time for their need. Value computing embodies the ability for IT to utilize its metrics gathering and actioning tools to predict and react to real time changes in business demands. Characteristics and benefits of IT organizations in this stage are:

• IT business metric linkage
• IT improves business processes
• Real-time infrastructure
• Business planning

It is generally accepted that no organization has really reached this stage yet, though a fully realized BSM implementation has every capability of launching a willing organization into this stage. Whereas the Service stage is the embodiment of BSM's central tenants, the incorporation of BSM's data into automated business decision-making and real-time service control and management can enable a tightly defined organization to recognize this stage.

BSM's Impact at the Various Maturity Levels

As an organization moves up the maturity chart, there is a logical progression that must be made from basic monitoring of infrastructure metrics to deploying end user experience monitoring to a full implementation of a BSM solution. The benefits derived will differ depending on the capability of the organization to identify and define the service model and its linkages. The maturity of the organization will also have a bearing on the maturity of its developed service model. Table 2.2 discusses each of the levels in the Gartner maturity model and some of the benefits that can be realized by incorporating a BSM solution at that level.

Table 2.2: At each level along the maturity model, an organization can move towards IT and business alignment.

IT Focus Is Changing

Whether your organization chaotically fixes problems as they break or predictively recognizes pre-failure warnings and auto-reconfigures resources to suit, IT in all types of organizations is slowly maturing across the board. As the "science" of IT continues to formalize with business process frameworks like ITIL and others, computing environments need not necessarily always begin at the Chaotic stage.

Moving through the stages of maturity in an initial IT implementation is getting easier as common processes and best practice approaches become more generally available to the public. Along with that automatic maturity comes a slow change in the focus of IT away from the device-centric and product-centric behaviors of the past and towards a service-centric focus.

This industry-wide change means that fewer organizations are spending less time in the Chaotic and Reactive stages. The formalization of IT business processes also makes it much easier to incorporate technologies such as BSM that augment those processes with data and automation.

Four major topics should immediately come to mind when considering how IT's focus is maturing towards an integrated component of business: Its impact on total business revenue, how a well-oiled IT infrastructure is a competitive advantage to business, the ability for agile IT to enhance the agility of business, and how the movement to Proactive IT directly benefits the business bottom line.

Figure 2.4: For organizations at every point in the maturity curve, maturity naturally occurs due to industrywide effects. IT's old focus on cost containment and supporting the business is slowly transforming to a coequal relationship.

Revenue Impact

Traditionally, the IT organization has suffered the business as a loss center. A necessary evil of all modern businesses—even those not recognized as technology companies—IT traditionally centers its budgetary activities around cost containment. If IT can trim costs through process standardization and automation, the resulting giveback to the organization at year's end can be maximized.

This "least worst" way of budgeting for IT expenditures has had the effect over time of reducing IT's ability to service its customers. Organizations that historically incentivized IT upper management through cost containment goals often found themselves hurting in the long run as expensive technology investments age and new mechanisms for access are made available. Exacerbating this problem is the inability for many IT organizations to find effective IT-based metrics that tie into business goals. IT organizations that lack metrics for quantifying the value of IT to the business have the most difficulty in validating justification for new projects and initiatives. Often in these organizations, getting new technology in the door is a measure of the "coolness factor" or the "this-product-is-no-longer-supported factor" rather than any quantified financial benefit.

Contrast this set of behaviors with those in companies who have determined a best-fit set of metrics relating IT value back to the business bottom line. In these organizations, metrics are readily available to justify IT expenditures. Rather than relying on the budgetary handouts of executive leadership, IT serves as co-equal with the business in identifying and exploiting business opportunities.

In many companies, this changeover to a revenue-neutral or revenue-positive environment goes far into rapidly maturing IT and aligning its goals with those of the business. Relating this conversation back to BSM, the technologies and frameworks that comprise BSM assist with the value quantification process. With BSM's concern for the quality of a service comes ready-made metrics for identifying its real business value.

Competitive Advantage

Along with the changeover from a revenue negative to a revenue positive organization, IT gains the ability to drive competitive advantage for business. As an example, look at a widely spread organization with employees working outside the traditional brick-and-mortar office. IT's incorporation of rich, process-aligned remote access tools for non-traditional workers automatically provide a competitive advantage to the business as a whole. Competitors who require field workers to work through inadequate interfaces incur a time cost per field worker per transaction per day for each quantity of data those field workers need to input. That time cost translates into a business advantage.

In our example, mature IT organizations that are able to recognize the business value of correctly implemented remote access solutions often get the approval to implement them. Then, after implementation, correctly defined IT metrics ensure that such a system continues to be valued by the business.

When IT matures to the level at which it is considered a co-equal part of the business that not only enables business but also drives business, the business as a whole will enjoy an advantage over competitors. This elevation doesn't come easily. Through organizational maturity comes the necessary commonality of language and business relation.

Agility

Very similar to the concepts of competitive advantage are the mature IT organization's ability to rapidly reconfigure as necessary for the maximized functionality of business. Businesses, especially SMB and mid-market businesses, require rapid shifts of resources as the market and economy changes. Mature IT will understand the requirements of constantly shifting business and implement technologies and processes that can operate in today's business environments.

IT organizations that constantly find themselves "catching up" as the needs of the business change are not incorporating the tools and technologies necessary for automation and rapid service deployment. The instrumentation data and related logic associated with BSM and its frameworks help identify where automation provides the best value to business. As not all forms of automation provide good return, a mature IT organization will use its monitoring, inventory data, and trend lines to quickly determine the best fit for new tools and services.

Reactive to Proactive IT

Lastly is the key element of long-term planning. Immature IT organizations tend to wade in the daily tasking of system care and feeding with little look towards the future. These organizations often find themselves overwhelmed when a major service upgrade is forced upon them by vendors. IT organizations that find themselves paying extra to use yesterday's technologies are likely not performing the necessary planning. As the focus in IT changes and IT continues to develop a common dialog with the business, these planning issues fall to the side as the business budget entangles itself with the planning activities of IT.

Figure 2.5: Five common behaviors can be inhibitors to alignment.

Why Invest in BSM?

Throughout this chapter, we've talked about the need for alignment between IT and the business. We've discussed why that alignment makes the business stronger and more competitive. And we've talked at length about how misalignment can eventually hurt a business and its abilities to be agile in the marketplace. Throughout our conversation, we've touched on the tenants of BSM as a catalyst for enabling this alignment to occur.

But how exactly does BSM enable that alignment? We're just talking about heads-up dashboards for management types aren't we? In a way, yes. The end result of a successful BSM solution is a heads-up display customized for its consumer. Business leadership sees real-time data on business services and their impact on the bottom line. IT leadership sees asset-centric statistics related to SLA measurements. Even the systems administrators get benefit, using the fully realized service model as a sort of map to quickly guide their troubleshooting processes through fault tree and impact tree analyses.

For these benefits alone, a business may want to consider the incorporation of BSM into their existing management and monitoring suite to help them understand the pain and pleasure their customers are feeling when using their systems. Depending on the tool selected, the BSM framework should augment the existing infrastructure without a "rip-and-replace" of existing tools.

But included with each of these benefits is how the mere process of implementing BSM and its service model into an existing network environment can go far in moving an existing IT culture to the right in terms of maturity. Developing the BSM service model is no trivial task, but the accumulated knowledge gained through developing its granular composition will go far in helping IT understand its own network—and help the business better understand IT. And as we said when we started this chapter, when these two groups understand each other, we have achieved alignment.

Figure 2.6: The data visualizations or "views" created by BSM build upon each other. Each representative consumer is given real-time insight into the answers that make sense to their responsibilities.

Where it Works

There are some obvious places where BSM works best within an organization. Business services as defined by BSM are:

• Revenue generating or revenue/cost impacting
• Critical to the business
• Supported by the infrastructure of IT
• Integrated with business processes
• Provided by a service organization, whether internal or external

Understanding that, BSM really only works when quantitative revenue metrics can be created for the service in question. To fully implement BSM, the service must have some impact on the revenue bottom line and that impact must be able to be quantified into terms of dollars and cents.

So what about infrastructure servers like Domain Name Servers (DNS) and Windows AD servers? Though their outage may not necessarily directly impact a business service, the potential exists that their loss can trace to some loss of service capability.

Most computers rely on DNS for name resolution functionality. So losing that service can have an impact on how your servers talk to each other.

In any case, BSM implementations are the easiest when the business already has an underlying understanding of its internal business processes. The BSM service model should relate more to those processes than the underlying hardware infrastructure. Though for those whose processes are not well-defined, the service model creation process often results in a better understanding of the componentization of those processes.

Relating back to our chapter example where John Brown and his IT team spend hours of time each month on gathering, crunching, and reporting statistics, the real-time component of BSM's data gathering goes far into reducing that process' overall recurring cost. As an example, let's assume that FCG implements a fully recognized BSM implementation that includes the service model and all attached metrics required by the business. In this example, John Brown's process of gathering month-end statistics is reduced from a multi-person, multi-day task involving the compilation of data from numerous systems in multiple data formats to simply printing off the desired dashboard from the BSM system.

Obviously this is an extreme example, because our calculations on return don't include the work involved with setting up the dashboards and configuring data connectors to each disparate system. But what's important here is the concept that the automation components intrinsic to the BSM toolset enable this data to be gathered. Once implemented, organizations that use BSM tools can organically come to understand their data points of interest and incorporate them into the proper visualization as they see fit.

The Dashboard Audience

As you can see in Figure 2.6, the typical organization of our resulting BSM visualization layers data on top of each other. Each of the consumers of data in the business is presented with the information relevant to their level of responsibility. What is critical here to understand is that BSM centralizes visualization data from numerous otherwise segregated systems into a single view. Rather than needing to look through two or three or four separate views using separate tools to get an understanding of the network environment, BSM's data consolidation and business logic rules allow for a one-screen picture of the network.

Technicians and Administrators

Following on with our description of Figure 2.6, the operational metrics typically received from device monitoring systems align with our inventory system data for asset management. These items help IT in the trenches understand the status of device health, location, and composition on the network. Our individuals in the trenches get the information they need to track problems and identify trouble spots on the network. This helps them answer the question: What is the problem's cause?

Managers

Managers, both operational and strategic, also gain the luxury of the same data provided for systems administrators. Adding to that data are the asset metrics that help them determine best-fit for existing asset classes as well as planning data to help with expansions and future purchases. Adding BSM's quality-based logic into the mix, managers can be alerted and react to preconfigured management reaction lines. As the manager, both in IT and elsewhere is typically responsible for the level of customer interaction and customer service associated with the business service under management, they can come to understand the question: What is the problem's effect?

Executives

Elevating our discussion to the level of the executive, their desire for device-based information is typically relatively low. The executive that cares about an individual router's failure in a remote data center is relatively rare. What the typical executive does care about, however, is how that router's failure affects the ability of their company to perform business. BSM's built-in logic capabilities can parse data from numerous management systems to get a holistic understanding of the network's health.

Where it excels over monitoring systems is in that logic's ability to link to a dollars and cents view associated with the outage. As is the case in our chapter example, the FCG leadership would have much more information to work with had they known that the "minor IT system's" outage linked so directly to the ultimate functionality of their critical B2B system. Some examples of Key Performance Indicators (KPIs) that may be of value to the FCG executives are Web site drop rate, number of orders placed or shipped, or customer satisfaction.

Having that information readily in-hand, the executive can take concurrent action with the outage to maintain continuity of business and business relationships. As we show in the earlier figure, the desire of the executive is to understand the question: What is the business impact?

Where It Doesn't Work

We can't talk about where BSM works unless we also talk about where it won't work, though this half of the discussion is really the inverse of our list of potential business services. If your business organization utilizes its network solely for the purposes of internal workflow processing, BSM may not be the best fit for you. As stated numerous times, for BSM to be valuable, a dollar figure must be placed upon a business service (and, therefore, the lack of it). If the business network is used strictly for difficult-to-quantify internal workflow, BSM will not provide the same level of value as to one that impacts the corporate bottom line.

Low Risk Implementation

Because BSM implementations traditionally pull data from disparate management systems rather than attempt to gather data on their own, the risk to daily operations associated with its rollout is relatively light. Though some BSM instrumentation can be implemented as part of end-user experience monitoring—a topic we'll discuss in detail in Chapter 5—much of BSM's instrumentation occurs outside the BSM system.

By segregating the data collection functions (from traditional systems management and monitoring tools) with the data calculating functions (from the BSM tool set), there is no need for a "rip and replace" of existing toolsets within the environment. Typical BSM toolsets include sets of connectors that tie into other networked systems for the purposes of gathering data. The highest risk component of a BSM implementation is usually the implementation of these data connectors.

Figure 2.7: BSM's data typically arrives from other preexisting management systems' data gathering efforts.

Connectors are configured to pull instrumentation data from those systems into BSM for further calculation.

Cost Containment Aspects

BSM has further benefits associated with cost containment activities. As we've learned in our chapter example, the cost of even a single server outage can be high. Thus, increasing our total effective uptime by even a small percentage has far-reaching budgetary implications.

As an example, if we assume that a highly critical customer-facing system has a desired uptime of 99.5%, that equates to slightly more than 3.5 hours of downtime per month. If BSM's service model and the service dependencies that link its elements help us arrive faster to a solution when an outage occurs, we can translate that into a higher uptime. Increasing our uptime percentage from 99.5% to 99.6% buys the organization an additional 45 minutes per month of uptime. With highly competitive, high burn-rate organizations measuring loss at many hundreds of dollars per user per month, this 45 minute gain translates into thousands of dollars of recurring cost containment—merely by having a better visual representation of the problem domain.

Governance and Compliance Aspects

Lastly, the additional costs of maintaining governmental and industry compliance records often overwhelm unprepared IT organizations. The reality of many compliance regulations is that some auditable technical control must be in place to manage and monitor systems for compliance violations. Depending on the compliance regulation, those controls may have different objectives such as preventing the release of Personally Identifiable Information or protecting data of a financial nature. Incorporation of BSM helps aid the regulators in recognizing that due diligence has been done on the part of the organization to understand its security posture and rapidly notify when configurations go out of baseline or security triggers are flagged and noticed by the organization. The historical reports and real-time dashboards of a BSM implementation easily shows the security officer and auditors that those due diligence controls are in place and operational.

The Value of Alignment

As we've shown throughout this chapter, there is value in aligning the goals of IT and the business. Once we've bridged the chasm of vocabulary, mismatched expectations, and technocentric metrics, the business gains competitive advantage not enjoyed by those who view IT merely as a cost center. A BSM solution can link critical business processes to IT services while bringing IT goals back to the business, creating that critical alignment.

---