Showing posts with label CMMi. Show all posts
Showing posts with label CMMi. Show all posts

May 23, 2008

Frameworks and Enterprise Architecture

One of the issues facing IT professionals these days isn’t a scarcity of IT frameworks, but rather many good frameworks that can be in conflict if we do not sort them out.

Usually each framework is focused on a certain lifecycle, which on one hand helps align it to a certain view on things, but on the other hand complicates things further, because each framework attempts to be all things to all people, by covering an entire lifecycle.

Here are some examples of the frameworks and their associated lifecycles:

  • Enterprise architecture – the IT investment life cycle (Capital Planning and Investment Control, CPIC)
  • SDLC—the Systems Development Life Cycle
  • ITIL –the service lifecycle
  • PMBOK—the project lifecycle
  • CMMi—the process lifecycle
  • Configuration Management—the asset lifecycle

Each framework has plans that need to be developed, processes to be followed, reviews that get conducted, and go/no-go decisions issued.

If an organization attempts to introduce and utilize all these frameworks then there can result a major overlap of structures, processes, and reviews that can literally drive a project manager or program sponsor nuts!

The organization could grind to a standstill trying to comply with all these frameworks.

I believe that each framework has useful information and guidance for the organization to follow and that the key to implementing these is to determine which is the PRIMARY framework at various stages of IT. The other frameworks may overlap in the stages, but it is the primary framework that guides that each stage.

Here’s an example using a few of these:

  1. Enterprise architecture is the decision making framework for IT systems. It has a core function in influencing IT investment decisions based on the target architecture and transition plan and EA reviews of proposed new IT projects, products, and standards. Therefore, EA is the primary or dominant framework in the planning stage of IT (up to the IT investment decision).
  2. SDLC is the development framework for IT systems. SDLC has a core function is guiding the software development process. As such, SDLC is the primary framework for the development phase of the system (which comes after the IT investment decision and before operations and maintenance). Of course, SDLC has planning phases and O&M and disposition phases as well, but SDLC is the primary framework only in the development stage.
  3. ITIL is the service framework. It has a core function in determining how service will be delivered and supported. ITIL is the primary framework for the O&M stage of the system (this comes after the development and before the disposition of the system), since that is when the system needs service delivery and support. Again, ITIL has other stages that overlap with other frameworks, for example planning and configuration management, but ITIL is the dominant framework only in the O&M phase.

The other frameworks should conceptually also assume a primary role for specific phases of IT and then pass off that role to the next framework that is dominant in that particular area.

4. For example, maybe PMBOK would have a dominant framework role also in the planning phase, looking at cost, schedule, performance, resources, risks, and so on (this would be after the IT investment decision of EA and before the development or acquisition phases). Again that is not to say that PMBOK doesn’t shed light and provide requirements for other stages of IT—it does—but it just is not the primary framework for those other stages.

I believe it is only by developing a unified lifecycle and assigning primary framework “ownership” to each stage will we be able to develop a truly workable IT structure and process for our organizations. As the saying goes: ”Two kings cannot sit on one throne.” So too, two frameworks cannot be simultaneously guiding our project managers and program sponsors nor taking up valuable IT resources.

The end goal is a single, simple, step-by-step process for our projects to follow with clear actions, milestones, and reviews, rather than a web of confusion and siloed, redundant governance processes in play.


Share/Save/Bookmark