Thursday, November 6, 2008

People, Process, Technology - Process Frameworks

In an earlier post, I made a point that people, process, and technology are all pre-requisites for achieving success in enterprise application projects. I am going to focus today's post on processes, specifically process frameworks around application lifecycle management.

Application Lifecycle Management is not a new thing, as there exists not just one, but many process frameworks that address its various aspects. Examples include:

- Information Technology Infrastructure Library (ITIL)
- Control Objectives for Information and Related Technology (COBIT)
- Oracle Unified Method (OUM)
- Oracle Application Implementation Method (AIM)
- Siebel Results Roadmap
- PeopleSoft Compass
- Microsoft Operations Framework (MOF)
- Rational Unified Process

You probably notice that Oracle alone has several methodologies, so there is no shortage of process to follow. By the way, in case you are wondering, the various Oracle methodologies eventually are supposed to get merged into the Oracle Unified Method. That can be a subject of a whole different discussion.

I am not sure if there is such a thing as the perfect methodology. Some of these methodologies are more development focused, while others are more operations focused, but I think there is increasing realization that an application project's complete lifecycle starts from the moment when the project is kicked off and ends when the application is retired, so a comprehensive application lifecycle management process framework needs to address both development as well as operational needs.

Take ITIL as an example. In ITIL v2, much of the focus was on operational management. The two core books of Service Delivery and Service Support addressed the processes of:

- Service Level Management
- Capacity Management
- Availability Management
- Continuity Management
- Financial Management
- Change Management
- Configuration Management
- Release Management
- Incident Management
- Problem Management

Infrastructure Management, Security Management, Asset Management and Application Management were in separate books. Except for the Application Management book, which depicted an application management lifecycle, ITIL v2 did not point out explicitly that many of the Service Management processes really need to start before the application goes into production.

In fact, in the Application Management book, it separated the pre-production activities in the first three phases as Application Development activities, while the activities in last three phases were classified as Service Management activities. That to me was a bit weird as it implied that the work to come up with a service level agreement do not take place until the application is ready to go into production. In reality, many of the considerations for defining service level goals should be done as part of overall planning in an application project.

In ITIL v3, which was released in May 2007, the lifecycle aspect of application projects took center stage. All the existing ITIL functional processes were re-oriented into five lifecycle phases, which include:

- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement

These five phases cover everything from initial planning to on-going postmortem analysis needed to drive continual improvements. To me, this makes a lot more sense. If someone needs to manage capacity, or ensure availability of the application, which traditionally are seen as more of operational activities, the planning aspects of these really need to be carried out by the operations team up front as the functionalities of the application are getting implemented in parallel by the developers. Even something as “operations centric” as monitoring has a pre-production component – one needs to plan what needs to be monitored and instrument the application accordingly.

As the ITIL v3 evolution illustrates, a comprehensive framework that provides holistic recommendation to application lifecycle management best practices needs to cover all phases of the lifecycle and addresses both development and operational activities. As an added bonus, ITIL also provides a common vendor-neutral language to talk about various issues. Many terminologies are so overloaded, especially with vendors (Oracle included) all using them to suit their needs, that it can be difficult to talk about many issues without re-defining the terminologies at the beginning of the discussions first. ITIL pretty much eliminates this confusion. Therefore, I am going to make reference to it in my future blog posts.


Ibrahim Levent said...

I think Application Lifecycle Management is different from methodologies; it is only related with application-side, not the people or process side. Development and implementation is very differenet processes and I think should be approached with different process methodologies.

Let me try to border process lines:
1- Development: RUP,Agile,XP,Software Factory etc.
2- Project(Implementation): Oracle AIM,SAP ASAP,MS RIM etc.
3- System Management: ITIL, MOF,COBIT etc.
4- Quality: CMMI,ISO etc.

I am not sure about that one methodology for all aspects is possible or needed.

Chung Wu said...

Thanks for your feedback.

I am not sure why application lifecycle management is unrelated from methodologies. Methodology, as defined by the Webster dictionary, is a body of methods, rules, and postulates employed by a discipline : a particular procedure or a set of procedures. Since Application Lifecycle Management is a discipline, Application Lifecycle Management methodologies would be the body of methods, rules, and postulates to carry out application management.

Application Lifecycle Management definitely has people and process elements. Someone has to carry out the tasks steps by steps in order to accomplish various objectives afterall.

As to whether development processes are different from operational processes. They are different, but should be related. For example, requirement analysis is one of the earlier phases of most application development processes. In addition to defining functional requirements, service level requirements should be considered at around the same time. I have seen too many application development projects not taking operational requirements into account during development phases, and end up with software that's not very manageable.

The processes that you mentioned are not exclusive of each other. Some of these processes are stronger in one domain, while others are stronger in other domains. They can be used in conjunction. With that said, I feel that ITIL v3 is probably one of the more comprehensive process frameworks out there today.