In the 20 years since I wrote my paper the advances in IT have been astonishing. If you had met me in 1991 and described the technology I would use to write this blog I wouldn't have believed you. If you had also told me that a product approach to applications would still make conference headlines 20 years later I would have known for sure that you were crazy. But, 20 years on, a product life-cycle approach to applications is still the exception rather than the norm. What have we been doing all this time?
Make sure you have a map before setting out on a long journey
If you have ever gone on a long journey you will easily grasp the idea of a product life-cycle approach to applications. At each step of a journey you are faced with choices. There is not always a clear route which leads directly to your destination and, even when it appears that there is, it can turn into a dead end. For example, Vancouver is a few thousand miles to the west of where I live but if you drive west you will find the Atlantic Ocean blocks your way. The best way for me to get to Vancouver is to travel east to my nearest international airport and catch a plane which will set off north and take a route across the edge of the Arctic Circle.
The project approach to applications is like taking a bus to the western edge of my home town and then deciding how to proceed. The product life-cycle approach is like planning out the whole end-to-end journey including making reservations, buying travel insurance and packing the right clothes. It is also wise to check that your passport and vaccinations are up to date, you have the right currency and you have made allowance for possible delays.
For applications a life-cycle approach takes account of the on-going pace of change in business processes, regular patches and upgrades, infrastructure refreshes, data cleansing and eventual decommissioning. Even though there are uncertainties, none of these potentially expensive and disruptive factors need come as a complete surprise. However, when organisations take a project-based approach to managing their applications, almost everything beyond the immediate project work is ignored. At best, some allowance is made for a routine maintenance service contract. When the next project is initiated, perhaps to perform a significant upgrade, the timescales are probably already very tight and the right financial, human and other resources are unlikely to be in place.
We can sort it out tomorrow
One reason that so many organisations adopt a project approach to their applications is the long timescales involved. Business planning and financial allocation are usually performed on an annual basis. The horizon for business strategy might be between 3 and 5 years which is similar to equipment replacement cycles and turn-over in management roles. In contrast many applications will continue in operation for 10 years and some to 25 or 30 years. Few organisations have the management frameworks required to deal with such long-term commitments.
Another reason is that managers, including IT professionals, do not realise that applications have a number of characteristics which set them apart from other types of information technology. Applications embody the way an organisation works and software changes have to be carefully coordinated with process and organisation changes. Applications are also much more complex and fragile than other categories of IT and it is often difficult to accurately predict the impact of changes.
Unfortunately the omissions of the project approach build up over time and eventually a technical, financial or functional crisis will trigger more drastic action.
We can go no further on land - let's swim
Many organisations look to application portfolio management as a solution and initiate modernisation or rationalisation programmes to help shift their applications back in line with their technical and business strategies. The success rates of these kinds of initiative are very low because the process change implications are considered too late or a black swan technical issue destroys the cost-benefit case. To return to my travel analogy these sorts of programmes equate to trying to reach Vancouver by swimming across the Atlantic.
Treat proposals for these kinds of initiative with extreme care. There are people who can swim great distances and perhaps one will cross an ocean but most will need to be rescued or will drown.
Application Product Management
A better alternative is to develop the practice of product management for your portfolio of applications. This has three main components.
- Implement good practice enterprise and technical architecture processes to maintain the target architecture for applications and, over time, influence change projects to converge on the target.
- Recognise applications in the governance structure by identifying and empowering product owners, and where appropriate product teams, to maintain continuity across projects, build expert capability and act as commissioners for specific project work.
- Support whole life-cycle planning and gradually integrate this with more conventional business planning and budgeting.
Hopefully it won't take another 20 years to establish a product life-cycle approach for applications and everyone involved can then have a much more pleasant journey.