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.