A value chain approach to IT

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 …

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.

-Charlie

Comments

[kmanoj]

I was surprised to see another topic on a similar note - movement to a higher level (framework in this case)
I was reading about the graduation from CMMI to ITIL in this blog

[Rick]

Your article is spot on. As we all know, IT Service Management (ITSM) is more than just the processes described within the IT Infrastructure Library (ITIL®). The successful delivery and management of IT Services require the integration of several well accepted standards, best practice frameworks and methods in order to align IT Services with the needs of the enterprise. itSM Solutions LLC (www.itsmsolutions.com) has created Open ITSM Solutions™ a unique and effective approach for the integration and operation of well accepted ITSM frameworks, methods and standards as part of the enterprise or mission value chain. The Open itSM Solutions™ suite of training, certification, mentoring and staffing solutions provide a prescriptive approach for the adoption of ITSM best practices by helping organizations adopt a systemic structure for thinking about the planning, development, delivery and support of IT Services and the skills and staffing to operate as an IT service provider integrated into the enterprise value chain

[KK]

Agree with your thought and it is Hitting the Nail in the Head!!!

Enough talks have been happening across the IT Industry on the challenge of “Aligning IT to Business”. Every CIO is being plagued with myriad questions on this front from Analysts/Vendors/Business Units alike and the pressure is piling to achieve this state of excellence. .

I feel that the show-stoppers are perhaps two myths that continue to prosper in most boardrooms, one that most organizations continue to believe that IT is a cost center and two, that every function of IT has to be business aligned and even if they start to think about IT Business Alignment, It is more on Statement of Intent rather than real action.

With those basic truths in place, I feel that the fundamental tenet of decomposing the IT Business is in the four fundamental pillars
1. People (Human Capital)
2. Processes (IT Processes & Foundation)
3. Technology (Every Piece of Technology which hosts the Business Services)
4. Tools (Used to Manage the Techology and Enable IT Processes)

The key to success lies in defining the linkages between the Four Key Pillars (P2T2) and drive the Integration between these entities and any ERP4IT platform has to be designed keeping the above pillars in mind.