Application Lifecycle Management and Architecture
While discussing system retirement in the post It’s a system, not a family member, I touched on the subject of Application Lifecycle Management (ALM) from the end of life point of view. It’s an extremely important topic that deserves a fuller treatment, both in terms of its definition and the role of the architect in the process.
David Chappell, in his paper “What is Application Lifecycle Management?”, provides an excellent definition of ALM. He points out that it goes beyond the development process, to include both governance and operations. Chappell defines and scopes these components as follows:
Governance, which encompasses all of the decision making and project management for this application, extends over this entire time. Development, the process of actually creating the application, happens first between idea and deployment. For most applications, the development process reappears again several more times in the application’s lifetime, both for upgrades and for wholly new versions. Operations, the work required to run and manage the application, typically begins shortly before deployment, then runs continuously until the application is removed from service.
According to Chappell, the purpose of governance is to ensure that the application is providing business value and Application portfolio management (APM), is a key tool to provide metrics to validate that value. Regular evaluation is likewise critical to ensure that the costs attendant to maintaining an application do not exceed the value provided. This is where the architect can influence the process.
One of the factors leading to IT landscape complexity in Capgemini’s Application Landscape Report 2011 Edition was “Custom legacy applications are becoming obsolete and are difficult to maintain, support, and integrate into the new, modern IT infrastructure”. This is particularly troubling when you consider that, per those surveyed, approximately half of their application portfolios consisted of custom applications. It does, however, identify some areas where architectural practices can help.
Many tend to think “mainframe” when they see or hear the word “legacy”. It’s naive to think that applications developed relatively recently can’t turn into legacy applications as well. Operating systems, database software, and operating environments (.Net Framework/JVM, web servers, middleware, etc.) are all constantly evolving. While it’s not a crime if your application isn’t on the bleeding edge (it may even be a virtue that it’s not), it is vital that the architect is aware of where those components of the solution stand and has a roadmap for moving the application forward in order to avoid obsolescence. The roadmap should include costs, benefits, and risk of upgrading the various components, along with the risks of deferring the upgrade. This information allows stakeholders to make informed decisions about maintaining the application. Keeping the application technologically current allows an organization to avoid one of the key barriers to application retirement identified in the report:
Lack of qualified developers to migrate retired application data and functions. This is especially true for custom-designed systems. The people who were involved in building them are no longer with the company, and nobody fully understands the underlying processes and complex relationships between application components to successfully migrate the data and safely decommission an application.
When applications are allowed to deteriorate in this manner they are not only difficult to retire, but also nearly impossible to support or enhance. Essentially, they’re dead apps running.
Maintainability and supportability of an application are also areas where the architecture can contribute to or detract from the value provided. Stakeholders should be made aware that these aspects are not just for the convenience of the development and support teams, but are factors which affect the costs of these activities. Time (i.e. money) invested in maintainability should result in shorter development times for both enhancements and fixes. Likewise, investments in supportability should yield fewer and shorter outages as administrators are given the tools to predict and avoid issues and support staff is given more information to diagnose those that do occur.
The architect is also uniquely positioned to influence the interoperability of an application. Use of techniques such as layering and message orientation as well as tools such as messaging middleware can enhance the ability of an application to integrate with other applications while continuing to evolve internally in a controlled manner. Obviously this is most cost effective when built in from the ground up, but even refactoring an application to promote interoperability may be feasible for high value systems.
The report noted that “Companies continue to support applications that no longer deliver full business value and do not support current business processes”. The goal of ALM is to prevent that from happening. One way to avoid supporting applications that no longer provide value is to insure that all your applications continue evolving to avoid both technical and functional obsolescence. Obviously this is a team effort, but maintaining architectural oversight throughout the application’s lifecycle insures that the decision makers have the technical information needed to keep the system relevant and valuable for as long as possible.
Originally published at genehughson.wordpress.com on February 11, 2012.
