One of the major sections in my book is the development of a unified process framework.
The reader might well ask: with such breadth and depth available in COBIT, CMMI, and ITIL, why spend any time developing a new framework? As Jeff Kaplan notes in his excellent Strategic IT Portfolio Management,
The last thing the IT industry needs is another proprietary framework. The best thing that could happen would be if all the disparate IT associations (ITIL, SEI, COBIT, etc.), as well as academics who study and teach IT management, were to consolidate their frameworks into one definitive, comprehensive, public-domain reference model that would align industry terminology and create a single blueprint for IT managers.
Well stated. However, the primary reason for YAFW (Yet Another Framework) is that, even though all these frameworks are (to varying degrees) seen as process-oriented, none have a true value chain orientation. They do not define what the core value-add process is for the IT organization, and it is very easy in reading them in all their detail to lose perspective as to what is primary and what is supporting in enterprise IT.
This is in part due to the fact that IT has been somewhat weak in understanding and leveraging supporting processes. Enterprise architecture, project management office, capacity planning, data administration, quality assurance, and other such teams are perpetually at risk in many organizations where they are viewed as bureaucratic distractions. The core imperative is :
Build the thing and deploy it!
The COBIT/CMM/ITIL frameworks recognize this mentality as a problem, but overcompensate through exhaustive coverage of supporting processes to the point that the reader starts to wonder, “where’s the beef”? For example, in CMMI, Engineering is only one of the four process area categories, and within Engineering, the Technical Solution process area (“design, develop, and implement solutions to requirements”) is only one of six process areas.
This de-emphasis of the basic construction activity is deliberate, as much mischief has occurred in software engineering in the name of “build the thing and deploy it.” However, there is a reason that the software construction activity is seen as “real” work by many practitioners: it is a primary value chain activity. Without actually doing software construction, activities such as configuration management, verification and validation, and process and product quality assurance have no meaning. The core activity has become de-emphasized to the point where bureaucracy swamps it:
Newcomers to CMMI thus examine the framework and are baffled at how actually writing code seems marginalized, seemingly no more important on a process level than secondary activities such as Risk Management or Decision Analysis and Resolution. The Agile movement is in some senses a response: “Working software is the primary measure of progress.”
The same is true of both COBIT and ITIL. Each are comprehensive in their way (if one considers all ITIL volumes), but both mix primary and secondary IT activities into what might be called laundry-list frameworks. Capacity Management is a high profile activity in ITIL, but would probably not be identified by the end IT customer as value-add, while Incident Management probably would be. The entire system design and build activity is seen as one small part of the Release process area, itself a subsidiary of the Change process. COBIT (the most holistic framework) similarly has “Develop and maintain procedures” (clearly a supporting process) as a peer process to “Install and accredit systems” (clearly core value chain).
The solution is not “either-or,” but “both-and”:
The supporting processes take their rightful place as enablers, but the central priority of delivery remains. The value chain is that sequence of activities which directly add value to the customer’s end experience. (The concept of value chain originates with theorist Michael Porter, from his book Competitive Advantage.)
The concept of “ERP for IT” is a driver for this book, and the salient characteristic of ERP systems is that they enable value chains. Without a value chain perspective on IT, we have no basis for using “ERP” as an architectural concept.
Here is one representation of an IT value chain concept.
There are others – see especially John Gibert’s IT Physicial Heal Thyself.
I am very interested in any other work along these lines – if you have any references please send them along.
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.
