Any article dealing with Application Lifecycle Management (ALM) must first define the term. In the David Chappell & Associates definition, ALM is presented as a series of overlapping timelines from Governance through Development and then into Operations. If you use Keane’s definition, it goes: Development > Management > Rationalization. With both systems, there is a cycling back through the phases of development and management/operations multiple times as the application is upgraded or released in a new version. Governance arcs over the entire lifecycle while Rationalization occurs only at the end point.
For our purposes, we’ll consider the ALM cycle as beginning from the time it’s a tiny twinkle in the software designer’s eye and continuing to the time it’s decommissioned, dead and buried. ALM is often thought of as a set of tools or solutions rather than a methodology (this is a conflation that serves vendors of said solutions well). However, it is simply a set of principles that takes a ‘zoomed out’ view of applications – taking into account all the ways its management impacts an organization.
Benefits and Pitfalls of ALM
ALM is definitely a holistic IT approach. There are no externalities in this system. The design team is responsible to the development team and the development team to operations, maintenance, support, and so forth. IT as a whole is responsible to the organization for designing, developing, delivering, maintaining and finally retiring the application in the way that best supports business objectives.
Unfortunately, the ALM concept doesn’t always perform up to the organization’s expectations. There are often places along the ALM timeline (or repeatedly in certain areas of the cycle) where effectiveness is lost and performance issues arise. The project may grind to a halt, the application may fall short of user expectations, or it may not delivery business value. We’ll look at a few of these problems and consider ways to improve performance of IT and of the application itself throughout the ALM process.
Governance: The Stage of Conception
This stage is typically thought of as starting with the idea to create an application. But it may, in fact begin before that point. Ideas don’t just spring forth from nowhere. In a reactive organization, ideas about what types of applications are needed come from examining current problems. There’s nothing wrong with assessing and diagnosing an organization’s shortcomings and using that information to kick things off. However, if you find that your applications are no longer as useful as you thought they would be by the time they get deployed, you may need to rethink this approach.
High-performing and strategic organizations and IT firms consider what applications they will need to take advantage of future opportunities rather than just those that will resolve current issues. One advantage of this forward looking approach is that it allows IT to plan ahead for provisioning infrastructure and equipment to support applications once it is time for deployment. It also forces business partners and IT partners to work together in the planning stages to define the right deliverables. Business stakeholders can’t just point to a problem and say, “Give us something that fixes this!”
Plan for Complexity in Development
One significant hurdle that IT departments face in delivering applications that perform well is that it usually takes far more time and money to get the job done than anyone anticipates (or admits). Scope creep damages the relationship between IT and the business stakeholder before the application even gets off the ground. IT ends up looking incompetent or dishonest when it consistently fails to stay within budget and produce working applications on time. However, cutting corners to stay on track typically means sacrificing quality and the performance of the final application.
IT can help make the business case for providing more resources (time, money, tools) during the planning and development phases by shining a light on where the real costs of an application come into play. According to Keane, the highest annual spend on any given application does occur in its initial development year. However, maintenance and operations actually end up representing 70% of the total effort IT puts into the application during its serviceable lifetime. The annual costs go up more and more as the application reaches the end of its lifecycle and becomes more difficult to maintain.
Put plainly, business stakeholders must understand that they are going to spend the resources on the application anyway – when they do it is up to them. They might as well budget up front and give IT the chance to produce a quality application that performs well over the long term. The right ALM tools can, of course, be reused, allowing IT to increase its ROI over time.
Automate the Transition to Operations
Develop, Deploy, Manage, Repeat. That’s the dance that applications go through over and over throughout their lifecycle. This is even more true in today’s Agile development environment. Just as the most dangerous parts of an airplane trip occur during takeoff and landing, the risk posed by applications is greatest during deployment of new versions or upgrades. There’s always the fear that some “unknown” factor could rear up and take down the whole network.
Operations may have a long checklist of things to do to ensure the application is really ready. At the same time, there’s often a push to just get the darn thing live so IT can move on to the next task. Deployment is very often an area of poor performance in the ALM timeline. Automation in both pre-deployment testing and actual installation of the applications is one of the most useful remedies for such bottlenecks.
Be Logical in Rationalizing Your Applications
The end of the application’s lifecycle is an area that may go largely unnoticed, but it can greatly impact the performance of IT’s infrastructure. Having a server network littered with the ghosts of defunct or legacy applications takes up resources that could be better used elsewhere. A periodic review of the entire application portfolio is needed to determine if any applications are redundant or costing the company more to maintain than the ROI they offer. If an application is not quite ready to be completely retired (and it is somewhat modern), it may be possible to move it into the cloud and let it sit idle until instances are needed. Or, it may be fed back into the design and development cycle to be revamped in a form that delivers greater performance and higher business value.