IT development and deployment in the early 2000s remains a patchwork of incompatible systems and seat-of-the-pants management, difficult to control and nearly impossible to audit. It is unlike other corporate business functions such as admin and sales, where systems like ERP and CRM provide reasonable control and tracking solutions. The term Application Lifecycle Management (ALM) began to gain mind share in the early 2000s as the accepted term for efforts to coordinate and control the disparate activities of software application management. It is a different beast entirely than Asset Liability Management, the other ALM, which is used by accountants and actuaries to plan their world.
Planning, development, validation, deployment, maintenance, and monitoring are recognized as major elements of the software application lifecycle. Each of these efforts may employ multiple tools, involve multiple teams, and report to multiple managers. As software systems become more complex and more deeply interdependent, it becomes critical for organizations to control and coordinate these efforts. That's where Application Lifecycle Management enters the picture.
What's my motivation?
Central coordination and control has always been desirable, but it always seemed like too much effort, effort that could be better spent on coding the next hot system. What changed in the early 2000s that made it become urgent?
The key driver was and is "IT Governance". There's enough complexity there to warrant a separate in-depth discussion, but in brief, "IT Governance" is a push for process controls in IT. It is the result of numerous legislative initiatives in various jurisdictions that followed scandals at companies like Enron and Hollinger International Inc. Most notably, the U.S. Sarbanes-Oxley Act drove businesses in or doing business in the United States (that is, almost everybody) to examine their ability to audit practices in all areas of their business. As almost nowhere else in the organization, IT's standard mode of frenetic chaos seemed to call out for better control.
Of course, the increasing complexity of large, multi-tiered applications plays a part too. Software initiatives in large companies are typically huge investments of time and money, which slide right off the rails with alarming frequency. It's too much for even the most hotshot manager to hold in her head. Increasing use of offshore and distributed development teams put paid to what was left of the classic Management by Walking Around approach to gathering status. Management needs some way to see what's happening in all locations and phases, so they know what parts are on plan and where the speed wobbles are.
New, enabling technologies are drivers as well. New IT buzzwords such as SOA and web services hold the promise of "seamless integration" for disparate software parts. After years of holding out like Star Trek's Scotty down in Engineering, proclaiming that "We're barely holding things together down here, sir" IT is finally going to have to submit to the yoke of management oversight, just like the rest of the working world. Drat.
What's ALM all about?
Application Lifecycle Management means different things to different people, and a precise definition depends on which vendor is trying to sell you their canned solution. However, certain common themes emerge. ALM should:
- ... ensure that decisions about software support overall business objectives
- ... reduce overall IT / development costs. ALM should help managers to efficiently deploy resources and reduce software rework, ensuring that project teams build the right solution the first time.
- ... provide control. ALM helps to define and enforce an auditable, repeatable process for software development and deployment. ALM provides auditable tracking of all changes, and should help to provide predictability on project delivery.
- ... enable communication. An ALM system should notify all key stakeholders of all changes and key developments in their project areas.
- ... enable validation, ensuring that an acceptable and dependable level of quality and security is achieved, and monitoring deployed systems to ensure that Service Level Agreements (SLAs) are met.
A complete ALM solution covers all major stages of an IT project. It starts with project initiation and evaluation, and the gathering of requirements. ALM establishes the business needs and parameters of any project before approval, and then manages and records the approval process itself. Next, with approvals in hand, ALM controls and reports on project execution from design through development and validation (testing, security audit, etc.). Finally, ALM tracks the operational aspects of the software application, managing and reporting on system deployment and on application monitoring.
Elements of ALM
Requirements Management (RM)
Before starting a major IT initiative, ALM requires that all relevant inputs be captured, collected, cataloged, enumerated, folded, spindled, and otherwise subjected to process. An ALM system will normally collect key inputs such as business, technical, operational requirements; change requests; and incident reports. The ALM system tracks and reports on authorization and approvals for changes, as well as incident escalation and problem resolution. All these steps take place to ensure that IT efforts, once approved, will be aligned with the original business needs. All stakeholders will be able to see what change requests are, and are not, approved and scheduled for implementation. Most ALM solutions also place modeling activities into this category. Once enough inputs are in place, they are associated with a project which itself goes through approval and authorization.
Project portfolio management (PPM)
Another post-Enron buzzword, PPM treats ongoing and proposed IT projects like a stock portfolio, with management choosing a mix of projects to provide the best return on their investment. This doesn't necessarily mean only the safest — a few high-risk, high return projects may be selected to leaven the mix. ALM interfaces with PPM to provide continuous updates on the status of all efforts, so that strategic adjustments and resource reallocations may be made as frequently as needed by the business, rather than only when a project ends in delivery or outright failure. This effort may also include IT resource management, including but not limited to physical assets like lab hardware, source code assets, software tools and licenses, and scheduling and cost-allocating IT personnel.
Software change management (SCM) and Software configuration management (SCM)
Once the approvals are in hand, the schedule has been set and the contract written, it's time for the nuts-and-bolts project management. Software change management generally refers to this part of the project lifecycle. Elements include automation, application builds, source and application version control, quality assurance testing, and audits for standards and security compliance. Another related process, confusingly also called SCM, is software configuration management, which primarily deals with application deployment to test, pre-production, and production systems.
ALM interfaces with the first SCM to track progress and report events and milestones to the business stakeholders. ALM interfaces with the second SCM to inventory the applications, components, and configurations in active deployment, and to provide version and release management for them.
ALM players
Microsoft's Visual Studio Team System provides the leading solution for the .NET development space. If you control the tools and the APIs, it's comparatively easy to build an integrated command and control solution! In the Java world, Borland hopes to achieve something similar, having decided to jettison their traditional developer-tool business and focus on ALM. IBM, is of course in the game too, with elements of their Tivoli and Rational solutions taking part. Other companies in the ALM provider game in mid-2006 included Mercury Interactive, Aldon, Rally, and MKS.
Many smaller independent software vendors (ISVs) also see ALM as the next gravy train. With a Gartner group estimate that the ALM business will be worth over $3 billion by 2009, ISVs are rushing to fit their offerings into the ALM picture. One way of doing that is by participating in a multi-vendor alliance to create a common standard. The Eclipse project's Application Lifecycle Framework initiative (http://www.eclipse.org/alf) is one such effort, where tool providers wishing to participate must implement certain web-based services and raise events back to the ALF framework. Whether this approach can enable the small vendors to compete effectively with the big fish remains to be seen.
Disclaimer: This is the corporate version of Node your homework, wherein I try to catch up to my colleagues in product management and decipher their "slide decks". It's quite likely that I've misapprehended some of this, and I would welcome comments and corrections.