The disciplines of Application Lifecycle Management (ALM) are evolving to meet the changing requirements of business. Not only are old disciplines evolving, but new disciplines such as project and portfolio management (PPM) are emerging to bring application development organizations closer to the business. These disciplines need to be supported by a new generation of ALM tools that break down functional silos and promote collaboration and role-focused views of the application lifecycle.
What is ALM?
ALM is a set of disciplines that together govern the process of turning business ideas into software. Issue and defect management, build management, modeling and simulation, requirements management and deployment management are all disciplines within ALM.
Figure 1: ALM is a set of related disciplines used to turn business ideas into software.
Some disciplines, such as build management, operate in relative isolation. Some disciplines, such as requirements management and PPM, operate across the entire lifecycle, touching and being touched by every other discipline.
These disciplines are brought together by foundational elements such as reporting, traceability, collaboration and process that, when well implemented, meld all the disciplines into a cohesive whole. When implemented poorly, the disciplines are fragmented and relegated to silos.
Challenges facing ALM today
Why do we need a new generation of tools to support evolving ALM disciplines? A cynic might say the reason we need a new generation of tools is that vendors need an excuse to sell us more software. The cynic would be wrong. Globalization and multi-shoring make application development much more challenging today than it was even 10 years ago. Geographically distributed teams working on both sides of the corporate firewall must work collaboratively and seamlessly across functional, technical and even language and cultural silos.
Besides these technical difficulties, custom application development is becoming more important to the business. According to the February 2007 Forrester Research report "The State of Application Development in Enterprises and SMBs," in 2007, enterprise IT will spend 25% of budget on new software development. This is an astounding number when you consider that IT usually spends 75% of its entire budget, not just its software budget, keeping the current infrastructure running.
This increase in spending is not just about the financials. Custom software has become a strategic asset for many organizations. Recent studies show that companies willing to invest in compelling and innovative software see rewards both to the bottom line through increased efficiency and to the top line as customers are drawn to these applications.
ALM practitioners have had to adapt to meet the challenges presented by these environmental changes. They have learned to collaborate across silos, work across large geographic distances and work more effectively and efficiently with resources on both sides of the firewall. Yet while development organizations have evolved, ALM tools have not changed so rapidly.
Older ALM tools are discipline-centric, with internal processes that don't integrate across the entire application lifecycle. They have silos of information that makes it difficult, if not impossible, to implement ALM-wide reporting and traceability. Even when ALM tools are integrated, the integrations tend to be point-to-point, fragile and incomplete.
Introduction to ALM 2.0
ALM vendors are already moving to address these problems. Vendors are moving towards a new set of features that will help ALM practitioners bring their processes and tools together to meet the challenges in the new application development environment. Forrester's Carey Schwaber calls this movement ALM 2.0.
"Tomorrow's ALM is a platform for the coordination and management of development activities, not a collection of lifecycle tools with locked-in and limited ALM features. These platforms are the result of purposeful design rather than rework following acquisitions," according to Forrester's August 2006 report "The Changing Face of Application Life-cycle Management."
ALM 2.0 is about transforming tools from being discipline-centric to being role-focused and process-centric. ALM 2.0 will give practitioners the ability to pick and choose the features they need from each tool, mixing them and combining them in a common interface customized for each stakeholder. Integration and automation within ALM 2.0 will be a customization task rather than a design task. As an ALM practitioner, I should be able to use ALM 2.0 tools to build an integrated process, define a portal view of my assigned work and collaborate with my peers -- all without expensive integration programming.
This level of integration isn't magic. Vendors need to provide Web services that break down monolithic applications into a set of features that can be aligned along role boundaries. Vendors also need to adopt interoperability frameworks to facilitate process-centric and role-focused stakeholder interactions.
While some vendors are promoting proprietary interoperability frameworks, others are taking the open source approach. Open source frameworks are vendor neutral, standards-based and are supported by community involvement. For example, Eclipse has an ALM interoperability framework under construction. The Application Lifecycle Framework (ALF) is based on industry-recognized service-oriented architecture (SOA) standards and uses events and a BPEL engine to automate ALM processes.
Implementing ALM 2.0
How do you get started with ALM 2.0? First, determine whether you have a need. If you are a small, co-located development team, you may not be a good candidate for moving to ALM 2.0. However, if you have a globally distributed team, complex processes, or experience a lot of frustration from inefficient ALM practices, you should see significant benefits from moving to ALM 2.0.
Interview your ALM stakeholders and learn about their pain points. Where are the development bottlenecks? Does it take weeks rather than days or hours to get changes approved? Do build failures regularly interfere with your release process? If you get an avalanche of complaints, you are a good candidate to spend the time and resources necessary to make the move to ALM 2.0.
Next, decide which of your problem areas to tackle first, and promote it internally as a pilot. Make sure your initial project is one that will have a significant positive impact, but don't tackle too much in your first project. Take a clue from the Agile community and deliver small sets of improvements early. Then iterate, building on your earlier success.
Build process automation is a good candidate for an ALM 2.0 pilot because build failures often disrupt the application development process. Although most development organizations have automated build scripts, they don't really automate the entire build process, which has scope reaching all the way back to the PMO and all the way forward to IT operations. You should also take inventory of your existing ALM tools. Look for a subset of your candidate process that is highly problematic and is supported by ALM tools that expose Web services.
Once you've decided on a problem to solve, you need to select an interoperability framework. If you already have a standards-based framework provided by one of your ALM vendors, go ahead and use it to get started. But be wary. If the vendor framework requires you to write code or scripts to define your process, then you aren't implementing ALM 2.0 at all. Just walk away and get one of the open source frameworks that provides a visual design tool. If you don't already have an interoperability framework, consider using an open source framework such as ALF.
Next, create any Web services you need to wrap your existing tool set. In a perfect world these services would be provided by your vendor. Not all vendors support ALM 2.0 today, however, so you may need to write a few services yourself while actively pushing your vendors to support SOA standards.
Finally, automate the small process you've selected for your pilot. Don't just throw it over the wall to the stakeholders, but work with them to get the process right. With ALM 2.0 you can modify processes easily. Unlike first-generation ALM, your integrations won't be brittle. You can modify them to meet the needs of your stakeholders rather than requiring your stakeholders to adapt to static and inconvenient integrations.
Once you move beyond your pilot project, you will need a long-term plan for building on your initial success. Not only will you need to automate other parts of your application lifecycle, but you will need to do some serious vendor management. ALM 2.0 shouldn't require an expensive rip-and-replace strategy, but if you have unsupported tools, or tools where the vendor isn't planning to implement standards-based Web services, you should consider replacing these vendors or tools over time. Encourage your vendors to move towards role and process-centric features. Pressure them to adopt SOA standards. Arm-twist to get them involved in open source projects promoting common infrastructure, vocabularies and data structures. Over time these vendors will either support ALM 2.0, or you will find other vendors.
ALM 2.0 holds great promise for helping development organizations streamline practices and procedures, taking the managerial grunt-work out of the business of writing software. Moving to ALM 2.0 doesn't need to be expensive or time-consuming. Neither is ALM 2.0 some pipe dream you can only get sometime in the future. Some ALM vendors are supporting Web services already, so you can get started today.
About the author: Dr. Kelly Shaw has been in software development for over 20 years. She has been a developer, an operations manager, a development manager, an architect, a product manager and, most recently, a strategic analyst and chair of the Eclipse ALF Requirements Committee. She has worked in academia, the Department of Defense, the pollution monitoring and compliance industry, the space business and currently works in the ALM software business. Dr. Shaw joined TeamShare in 1999 and remained with Serena Software after TeamShare was acquired in 2003. She is a member of the IEEE and a lifetime member of HKN.