Lifecycle Management, Defined

Like many other aspects of Information Technology over the past 15 to 20 years, Lifecycle Management has evolved quite a bit. In fact, it didn't generally even get referred to as "Lifecycle Management" until about ten years ago. It (both the term and the practice) has become more expansive in nature as time has passed. This is an interesting not just due to the evolution which has occurred to the surrounding practice, it is also the one area in IT where technology and business / management comes closest to being blended into one concern.

Lifecycle Management is also the reason that IT Architecture exists the way it does today - without the driving force of various governance processes and mandates, IT Architecture would have likely never quite crossed the threshold from systems or software engineering and design. We'll return to that in a minute.

So time for definitions - and in this case - a hierarchy.

Lifecycle Management, DefinedLifecycle Management is the practice of coordinating all the related activities for any given selection of IT capability (within or across organizations). There is generally a hierarchy for these activities which falls roughly into the following structure; Portfolio, Program, Project. Generally at the Portfolio level, the capability management spans many systems whereas there may be multiple Projects supporting just one piece of software or one system. In an optimal situation, all Lifecycles should be unified based upon shared methodology, principles, goals and supporting tools. 

Many people have long considered Lifecycle Management to be the province of the manager. However, nothing could be further from the truth. For Lifecycle Management to function as intended there has to be a partnership between management and technology resources. This partnering usually occurs on the tech side through the role of IT Architect.

This view is a more traditional enterprise-focused view (mainly waterfall in nature) 

Why Lifecycle Management isn't just about Management
Let's go over a few things that must have technology input to succeed:

1. System (and project) Scope - While there may be a number of specific expectations from business, the most successful systems (and projects) are those in which the tech side helps to define the boundaries of what can realistically be done. This manifests itself at the highest level in portfolio roadmaps and at lower levels through statements of objectives or similar scope documents for projects (which then get passed through governance processes for approval). 
2. Project Estimation - This is a much more complex process than many realize. Good project estimation requires a precise understanding of the complexity of the technical tasks involved. Whether you're talking about building J2EE-based APIs or deploying a WCMS, the tech experts who have been there / done that are invaluable in helping to define a realistic project estimate. Since much of IT is measured based upon estimated cost versus actual expense - this area is disproportionately important. 
3. Risk Assessments - Sometimes this includes Architecture Assessments, other times it is more of a technology strategy type exercise.
4. Technology Selection - Should we Build or Buy, or if we're going to buy, how do we choose? These are the typical questions that get asked, but who can really answer them? The IT Architect, of course - its part of their job description.
5. Solution Decomposition - This is related to project estimation but more detailed. Generally, somewhere within a planning process, there is a preliminary design exercise which goes as far as determining how best to 'break up' elements of the intended solution into digestible pieces. This also involves prioritization - understanding which parts have to come before or follow others due to various technical dependencies or constraints. 
6. Project Oversight - This is a big topic, one we will dedicate other posts to, but for now we'll just introduce it. IT Architects often play a semi-leadership role within individual projects (as a project or solution architect). This is so technical issues can be tracked, managed and mitigated with continuity across all phases of the individual lifecycle. 
7. Enterprise Integration - This is without a doubt the hardest part of the overall set of potential Lifecycle Management related activities. Now, many think of Enterprise Integration as a purely code focused or networking relating topic - believe me it's not. Enterprise Integration is in reality the intersection of potentially overlapping systems, data and expectations. The most important aspect of Enterprise Integration is inter-operability design  (which comes in many, many forms). It's a study in complexity and not for the faint of heart. 

Let's step back for a moment and explore Lifecycle Management from a different angle. In previous posts we've been talking about methodology a bit; Agile, Waterfall and so on, but what does it all mean? The short answer goes something like this:

An IT methodology quantifies the workflow or lifecycle steps necessary to provide consistent support for system development and management. Most lifecycles share the same common elements; a planning phase, design phase, build phase and implementation phase. And yes even Agile has all of these. Within the common framework, there is a massive amount of variation. So, if you ever had to work with Carnegie Mellon's CMMi (waterfall spiral methodology) and then were put on a Scrum project (Agile variant) it would be like moving from Iowa to Italy - a culture shock to be sure. 

In today's terminology, you often hear the term Application Lifecycle Management (ALM) used - it is essentially the same thing as Software Development Lifecycle (SDLC) except perhaps that today an ALM can encompass both Waterfall and Agile whereas before SDLC was more Waterfall focused. So what are Waterfall and Agile, anyway? 

Waterfall - this refers to both purely linear and 'linear iterative' development methodologies, wherein requirements are more fully defined up front and allocated to segments in a somewhat sequential manner. In some cases, code is completed and tested in iterations - other times no capability is delivered until the very end (traditional waterfall).

Agile - Up front design is minimal, few if any requirements are formally development. The focus is the production of working capability with each (very short) iteration. Design in this model becomes iterative in that core assumptions can be readdressed and correct "in flight" (which is why up front requirements become redundant or unnecessary). 

We will be talking a lot more about 'Agile' and 'Waterfall' as we progress on the blog. 

Lifecycle Management has evolved from a set of competing software development methodologies to become a potentially all encompassing set of technology management processes for the enterprise. And it will continue to evolve with the IT Architect maintaining a key role for some time to come.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc