Application Management : AB/ITSM

OpEx versus CapEx

adsey007 — Mon, 30 Mar 2009 08:06:00 GMT

Forrester just posted on how the recession is hitting capital budgets (CapEx) and that you should consider using operating expenses (OpEx) to purchase software (http://www.idc.com/getdoc.jsp?containerId=lcUS21765009).

About 18 months ago, we introduced one year term licenses on the Business Availability Center (application and business transaction management) software so that it is more likely to fit within OpEx budgets.

Mike Shaw.

BSM Evolution Paths: Auto Industry Sample

adsey007 — Tue, 24 Feb 2009 10:24:00 GMT

In the last post, Bryan Dean, our research expert in the BSM team, outlined the different ways in which customer evolve towards Business Service Management. In the next few posts, Bryan will give an example of each of the different types of evolution. Over to you Bryan ....
_______About three years ago, the business division managers of a multinational automobile manufacturing company planned a bold transformation of their distribution network to leapfrog the competition. They enthusiastically laid out a roadmap for business process innovation and aggressive customer/dealer satisfaction initiatives.

Only one real problem; the CIO knew that building, rolling-out, and operating the underlying IT for this future business vision exceeded their current capabilities. The CIO eventually had to raise the red flag and explain to the executive committee why IT was the bottleneck. Ouch, not a good day.

In the previous post BSM Evolution Paths: Samples and Observations, we talked about five common evolution paths, the organizational and persona dynamics of an Automated BSM/ITSM journey. In this post we will overview a specific example.

To be fair, the CIO spent years driving significant investment in process, tools and the organization. Let’s look at a subset of key personas and BSM/ITSM foundation:

Director of Infrastructure (reporting to the VP Global IT Ops):

Enterprise-class central event/performance platform and console
WAN/LAN network management platform
Basic, component level performance and availability reporting
Dozens of vendor-specific configuration and admin tools

Director of Service Management (reporting to the VP Global IT Ops):

Global, consolidated helpdesk/service desk
Well defined and automated incident process; basic level problem, configuration, and a manual change process

Director of Applications (development, test & level 3 support. Reports to business divisions):

Suite of pre-production stress-test quality and performance tools
End-user and application performance/diagnostic tools (test environment)

The Key Evolution Steps

Step 1: CIO empowers and holds the VP of Global IT Operations (VPITops) accountable for end-to-end business service responsibility. Imagine the panic on his face! VPITops launches key lieutenants on quick gap analysis.

Step 2: The VPITops needed a quick win. He believed that visually demonstrating and reporting performance and availability from a business service perspective -versus an infrastructure perspective- would be a catalyst for driving “aligned” IT behavior. The current network and infrastructure products didn’t have this capability, so VPITops leveraged the tools already proven by the application test and level 3 support team.

VPITops established a new team within Operations (parallel to infrastructure event management) to own and run the end-to-end business service visibility/accountability solution. Integration was established between the two teams and tools.

Step 3a: VPITops took his new business service visibility/accountability tool (in dashboard/report form) to key business division managers, and established a business relationship management function. This converted the conversation from anecdotal complaints, to measurable service levels. The CIO had tangible proof of progress.

Step 3b: While engineering step 2, the Tools and Process Architect realized they needed a better means of discovering and maintaining the IT/Business service models. Their infrastructure environment was shared, complex and dynamic enough that static service models were not effective, so they brought in an application dependency mapping technology. This success spawned a serendipitous benefit to another team in step 4a.

Step 4a: The application quality/test and release team realized the service model could be utilized in the service transition process. They previously had several very painful episodes of moving complex applications from test into production. With an accurate, up to date service model of the production environment they could better identify dependency issues before roll-out. Speed and accuracy... Happy CIO.

Step 4b: The Director of Service Management and the architect evaluated how to federate the data between the application dependency mapping service model and the CI configuration data in the helpdesk. The software vendor provided a federation / reconciliation adaptor, so the helpdesk was able to leverage the CI relationships and operate off a “single version of the truth” (sounds eerily like an ITIL V3 CMS!).

Near Term Roadmap

· Automate change/configuration workflow and provisioning

· Upgrade/replace enterprise event and performance console to leverage service model for root cause analysis and business impact assessment

· Apply business service relationship management to additional business divisions

· End-to-end visibility of composite MQ application business transactions

The Verdict of the Journey so far

The CIO still has a job, and has a funded roadmap. One might ask why they didn’t start with step 4b, and establish the CMDB and service model first? Well, the CIO was on the hot seat, and they were concerned about getting bogged down in an enterprise-wide CMDB architecture project.

This exemplifies the unpredictable and unique nature of evolution paths. More can be said about the delicate balance between tops-down guidance, and fostering organic innovation from within the ranks of IT. In future posts, I will discuss and analyze this further, as well as introduce other examples.

BSM customer evolution paths: Samples and observations

Michael_Procopio — Thu, 05 Feb 2009 01:41:00 GMT

When developing and marketing products, we often have questions which can only be answered by going out there and seeing what people are doing. We have a guy on the BSM team who does this for us. His name is Bryan Dean. I've worked with Bryan for many years and I've always been impressed by his objectivity and the insight he brings to his analysis (i.e. he doesn't just present a set of figures - he gets behind the figures).

At the end of last year, we asked Bryan to analyze the top 20-odd BSM deals of 2008. He formed a number of conclusions from this research. One set of conclusions concerned how people "get to BSM" - how they evolve towards an integrated BSM solution. I asked Bryan to help me with a series of posts to share what he learnt about evolutions towards BSM because I think that knowing what our other BSM customers are doing may help you.

________

Mike: Bryan, can you give a summary of what you learnt?

Bryan: There is no one evolution path. It's fascinating to me that a hundred different IT organizations can have virtually the same high-level goals, fundamentally agree on the key factors for success, and yet end up with a hundred unique execution paths.

Before I answer your question, can I create a definition? The term "BSM" is very poorly defined within the IT industry - different vendors have different versions, and so do the industry analysts (in fact, some other research I did last year concluded that very few people had a clear idea of what BSM means). So, I'd like to introduce the term "Automated Business/IT Service Management" or AB/ITSM.

Back to your question, I think I can group all the different evolution paths into five key types:

ITSM incident, problem change & configuration: this evolution is driven out of the need for process-driven IT service management with the service desk as a key component
Consolidated infrastructure event, performance and availability: this is driven by a recognition that having a whole ton of event management and performance monitoring systems is not an efficient way to run IT, and so there is a drive to consolidate them into one console.
Business service visibility & accountability: this is more of a top-down approach - start with monitoring the customer's quality of experience and then figure out what needs to happen underneath. This is popular in industries where the "web customer experience" is everything - if it's not good, you lose your business
Service discovery & model: this is where evolution towards integration is driven from the need for a central model (the CMDB). Often, the main driver for such a central model is the need to control change
Business transaction management: today, this is the rarest starting point. It's driven by a need to monitor and diagnose complex composite transactions. We see this need most strongly in the financial services sector

Mike: How about the politics of such AB/ITSM projects? (I don't see the AB/ITSM term taking hold, by the way :-) )

Bryan: Politics (or, most specifically, the motivational side) is important. I think many heavy thinkers in our industry have the mistaken assumption that that there is a single evolution path, controlled from the top on down by the CIO following a master plan. Trying to manage such a serialized, mega project is a huge challenge and too slow, not to mention that 99% of CIO’s are not in the habit of forcing tactical execution edicts on their lieutenants (I know I’ll get some argument on that one :-) ).

What I see from my research is that the most successful IT organizations are those who have figured out how to balance between discrete doable projects, and an overall AB/ITSM end-goal context and roadmap. Typically, the CIO lays down a high-level vision that ties to specific business results, and then allows key lieutenants to assess and drive a prioritized set of federated, manageable projects that independently drive incremental ROI. Some IT organizations may have a well-defined integrated roadmap, but the majority of IT run federated projects in a fairly disjointed fashion.

These parallel paths are owned by many independent personas within IT, each trying to solve the specific set of issues at hand. For them, being bogged down in how their federated project aligns and integrates with all the other AB/ITSM projects is daunting… if not fatal.

And on reflection this makes sense to me - the human side of things plays a large role in such endeavors.

Mike: What do you mean?

Bryan: IT organizations of all shapes and sizes have goals to reduce costs, increase efficiency, improve business/IT service quality, and mitigate risk all while applying technology in an agile way to boost business performance. What I find interesting is how specific, funded initiatives are created by specific personas to achieve the goals.

In future posts, I will share some specific examples of how customers evolved through these paths, the key driver personas, the core motivations and how these paths come together.