Frameworks, frameworks, everywhere... ITIL, CMM, COBIT, etc., etc., ... and yet none of them satisfy. All have nagging gaps and flaws:
- ITIL's weakness with respect to production applications, the primary "service" offered by the modern IT organization...
- CMM's level of abstraction and disregard for operations...
- COBIT's narrow focus on governance and audit...
And all are process based. They focus on activities, not on things. And while activities are indeed important, I have to confess my data centricity. I've always leaned a bit more to nouns than verbs.
The concept of portfolio management is a better fit for me, and indeed ITIL calls for Service Portfolio Management, as an evolution of the original service catalog concept and co-optation of Application Portfolio Management.
However, it is clear the Service Portfolio is one among several. And furthermore, the portfolio management literature does not focus enough on the fact that all elements in a portfolio go through a common lifecycle. In fact, that would be one of the defining characteristics of a portfolio: all elements in it go through largely the same stages from acquisition through disposition.
Here is a candidate list of the lifecycles requiring portfolio management by the IT organization: some will be familiar, and some may surprise.
- Service lifecycle management (from demand through retirement)
- Technology product lifecycle management
- Asset lifecycle management
- Human resource lifecycle management
- Information lifecycle management
I increasingly have been seeing these lifecycles as distinct yet interrelated; each has their own logic and none can be subsumed under another. In terms of the IT value chain, the essentials of the service lifecycle are primary, and the rest are supporting. But the supporting lifecycles are independent of the primary value chain in terms of timing and, often, initiating events.
Definitions:
Service lifecycle management is first among equals; without the need for services, none of the rest have any meaning. And, as I've established in previous writings, the service lifecycle is a value chain, the core of "ERP for IT" and essentially idenfical to ITIL v3. So, the concept of an "IT value chain" still has utility. The other lifecycles support it.
Technology product lifecycle management. As a practicing enterprise architect, I am often called on to assist in the evaluation of new and novel products purporting to solve many problems. New products require functional and non-functional evaluation, definition of acceptable configurations, and ongoing control against policy and baseline configuration. Sets or "patterns" of product combinations may be defined, in the interest of greater consistency and provisioning speed. All products require upgrades and patches, are challenged by new competitors and disruptive forces, eventually lose vendor support, and ultimately must be euthanized and removed from the environment. This entire lifecycle is too often managed as a set of functional silos, even crossing multiple functions such as vendor, configuration, and security management.
Note that this lifecycle is often decoupled from the service lifecycle. Technology products are often introduced with the assumption that they will support multiple services, and of course any one service may depend on multiple technology products. In the case of such fundamental computing platforms as OS/390, CICS, MQ, and TCP/IP, the technology product may well outlive multiple services platformed on it, themselves long-lived.
Technology products generally subtype into hardware and software (the boundaries are not crisp and some products include both).
The service lifecycle often drives the technology product lifecycle. Typical anti-pattern: the project team tasked with implementing the service determines that a new technology product (perhaps specifically optimized for the service) is required, and push to have this new product's approval accelerated, perhaps encountering reluctance from those responsible for the technology product portfolio, who may point to redundancy or non-functional issues.
Asset lifecycle management. Assets are not the same as technology products, which are types, not instances. "Compaq DL360" is a type, while a specific device with a distinct serial # is an asset. "Oracle 11" is a type, while a particular license is an asset.
The management and especially the timely provisioning of assets for the large data center operation is a particularly challenging topic, requiring careful timing and coordinated forecasting. While vendor solutions for application-centric demand management are mature, solutions for infrastructure demand management are not. The discipline of capacity planning is an essential input, but the lifecycle also requires attention to vendor management, purchasing, logistics, asset control, power and cooling capacity, physical security, and other disciplines.
As assets are instances of technology products, the asset lifecycle is dependent on the technology product lifecycle - one does (or should) not generally acquire an asset without considering whether the product is suitable. However, once the product is deemed suitable, many repeated cycles of acquiring particular instances and managing them through dispositon may ensue.
As with technology products, the asset lifecycle is strongly influenced by the service lifecycle. This may seem obvious - why would we buy the assets if we didn't have a service to platform upon them? However, just as project teams may run into challenges when they seek technology products that are not well aligned with the current portfolio, so too their needs for immediate provisioning of computing capacity may challenge the overall asset portfolio management strategy. This is one of the business drivers for virtualization.
Human resource lifecycle management. This is a well known lifecycle; not as much to be said. The management of appropriate skills in the employee base is where this lifecycle intersects both the technology product and service lifecycles. However, I think there is much work to be done in better managing skill sets; current approaches focus too much on particular products and not enough on the core skills needed to quickly pick up new product competency.
Digressive case in point: I had to hire a software engineer a couple of years back, who was going to program in .Net. Given a choice between three candidates, two with .Net experience and one with only Java and C++, I still chose the candidate with no .Net experience. Why? In addition to solid industrial experience, he had done graduate work in computing theory, so I surmised that he would learn .Net quickly (it took him about three days) and, once having climbed this curve, would be more productive than the other candidates (he was terrifically effective, turning around complex solutions in hours and days, not weeks). The problem is that usually hiring managers are constrained from making these kinds of decisions by HR policies, which tend to rely on over-specifying the product skills being sought.
Information lifecycle management. This is probably the topic of a whole new posting. Currently, this term has been co-opted by the storage management vendors for the purposes of selling more storage. My view would be broader, starting (per COBIT PO2) with defining the information architecture, entity lifecycles, and also (yes) the capacity consequences of those entity lifecycles. Much more to be said on this...
-----------------------
I debated whether supplier/vendor management was its own lifecycle. While it is certainly an important function, I am less sure that it should be seen as a unitary lifecycle. We have suppliers of services, hardware, software, and labor, and while all need to be managed from a legal contract point of view, the skills, techniques, and interactions for managing software versus hardware versus labor sourcing are notably different in my observation. Any vendor "lifecycle" would be heavily dependent on the major class of "thing" provided by the vendor. (Yes, some vendors provide two or three - notably HP and IBM...)
Thoughts?
