In the immortal words of Mr T – “Pity the fool who modernizes their applications”  

I’ve been thinking about how much more challenging it is to keep the IT train on the tracks when managing an application lifecycle is no longer a single, independent, perhaps linear process.   This is the first blog of a series designed to address a question I was asked in an earlier comment: 

“What’s the difference between SOA Governance and broader application governance?  

IMO extending SOA governance more broadly to the concept of governance of the modern application lifecycle will be a powerful way for IT to combat the complexity that comes from the move from monolithic apps to modern compositions of shared services.  And composing rather than re-building is a key to lower costs of build and maintenance--which could be important right now in the dark days of reduced budgets.

Let's break our preconceived notions of a single, independent application lifecycle (how many slides have you seen that draw a lifecycle as a linear arrow?) to prove that modern application lifecycles are much more challenging to keep on track without governance and automation.  I’ll describe this phenomenon below and then, follow it with six key challenges (IT headaches of sorts) of application lifecycle management that can be addressed with an ample dose of governance.

What do you think of when you hear “application lifecycle”?  Do you visualize a linear process of delivering an application?  When you hear “application lifecycle management”, do you think of a linear progression of handoffs from driving requirements, to development, testing, staging and delivery of an application?

Now, time to turn off preconceived notions and switch your thoughts to applications that are made up of compositions of shared services and it’s time to make your head hurt.

First, the concept of the monolithic application having a linear lifecycle needs to change.  Modern Applications are compositions of modular and potentially shared services which, in and of themselves, have lifecycles with inherent interdependencies.  The application lifecycle is actually an overlapping set of interdependent lifecycles – the lifecycle of the service and the lifecycle of the composite application which depends on the service. 

 

A change to either side, the service or the composition, impacts both lifecycles – requiring planning, communications between teams, change management, development, testing and re-deployment.  Now, carry this out to the concept of many shared services (represented by M) that are consumed by many composite applications (represented by N) and you quickly have M+N lifecycles with MxN dependencies.  

I suspect your next set of questions will be, why and how?  The next set of blogs will address six reasons why Governance is the right medicine for what ails the modern application lifecycle.