What is the highest priority in enterprise IT?
- Increasing success in project management?
- Improving service levels?
- Aligning IT with business objectives?
It’s dangerous to generalize, and any one of those priorities might be the primary goal in a given IT environment. But there is one more:
- Prevent operational costs from overtaking the entire IT budget
This could be re-stated as “drive down operational costs,” but it’s important to understand the consequence of failure: the loss of all innovative capability.
Click to enlarge
What are the drivers of higher operational and maintenance costs?
- No project plan for steady state: was TCO analyzed and defined? Were the resulting FTEs for operations and maintenance agreed to as incremental to the current base spend?
- Poor systems quality – even when the project is deemed a “success.” What is the incident rate? Unplanned maintenance releases?
- Complexity – even when the system “works.” Does it take 8 hours FTE on average every week (or night!) to get the overnight batch to completion? Did the last team working on a maintenance release spend half their time re-analyzing the system’s current state?
- Obsolescence – are knowledgeable staff more and more expensive? Is the hardware beyond a TCO “sweet spot”?
- Vendor/product issues – did your RDBMS vendor force you into a new version, imposing new maintenance releases across 25% of the applications in your portfolio? Did you understand the impact of this sufficiently in advance?
How do we start mitigating these cost drivers? “What gets measured, gets managed.” And we cannot measure until we name, normalize, classify, and/or enumerate. Without an accurate inventory count, the retailer does not know their net worth – and there is simply no substitute for walking the aisles and counting.
The analogous requirement for enterprise IT is the alignment of configuration management and portfolio management.
Configuration management has several levels of granularity, and several overlapping objectives. However, one characteristic of mature configuration management is leveraging the application concept as an organizing structure. Applications are assigned application IDs, which serve as the default naming standard for a large percentage of all configuration items in a given IT operation. This is often done by an operational team without reference to higher level considerations of enterprise architecture or portfolio management. However, much of the information required for application portfolio management derives directly from configuration management:
- How complex is this application?
- How many interfaces does it have?
- How many servers is it dependent on?
- What depends on it?
- How many batch jobs does it have? How long do they run every night?
- What databases is it dependent on? Do they have high-criticality data in them?
- How many incidents on average does it have a month? What are their first-call resolutions? What is the overall trend?
- What is the capacity trending in terms of CPU, memory, and disk for a system? For a family of system? For the entire application portfolio?
- What vendor products were used to build a given system? What systems are dependent on vendor product X?
And so forth. These numbers are primarily summary aggregations of information that at a granular level should be in the configuration management database (CMDB) and related systems. They are needed in portfolio and architecture discussions, as essential information for higher order questions such as:
- What is the overall technical profile of System A? Is it well-managed, technically sound, and at a reasonable TCO? (Of course, portfolio management would also want a business profile, but that isn’t something configuration management can help with.)
- If we propose a replacement for System B, what are the downstream impacts and a first-order approximation of their costs?
- If vendor product X is going off support, do we understand the impact of that? If we wish to switch our Java application server vendor, how feasible is this?
- Is there an opportunity to move System C to a virtualized or grid architecture? Where in our portfolio of 100 applications is the best opportunity to do this?
- What servers are due for lease refresh and what are the impacted applications?
- What application teams are directly responsible for handling customer data, and do they have sufficient training?
And so forth.
However, today we have a gap with shortcomings on both sides. Configuration management (and by extension IT Service Management and ITIL) tooling today seems focused on reducing operational impacts (although there are signs of attention at least to capacity), and does little in terms of portfolio management.
On the other side, many portfolio management products seem to assume that a) portfolio management is all about managing projects; b) if it is about applications, the data needs to be manually re-harvested and re-analyzed – there is little or no assumption of integration with the operational ITSM space.
From a process perspective, an ideal state would be:
Click to enlarge
There are clearly opportunities for innovation here for creative vendors and consultants able to think outside their boxes.
Add to 
Bookmark murdok:
Charles Betz is a Senior Enterprise Architect, and chief architect for IT
Service Management strategy for a US-based Fortune 50 enterprise. He is author of the forthcoming Architecture and Patterns for IT Service
Management, Resource Planning, and Governance: Making Shoes for the Cobbler’s Children (Morgan Kaufman/Elsevier, 2006, ISBN 0123705932). He is the sole author of the popular www.erp4it.com weblog.
