For almost a decade, major software vendors have been marketing the concept of Application Lifecycle Management as a way to coordinate software development activities, and the result has been mixed. According to Forrester, three quarters of software and services decision makers at American and European enterprises are aware of this emerging discipline.
Nearly 29 percent of IT shops are using ALM, and only 23 percent are not aware of it. Of the companies that are not using ALM, almost 60 percent are either interested in using it or are in the process of starting a pilot in the next 12 months. However, despite strong awareness and interest, Forrester also found that the understanding level of ALM is low and the vendor offerings have been slow to hit the market.
One expert's definition of a portfolio turns the bottom-up concept on its head, defining a portfolio as “the vehicle by which an organization achieves its goals and objectives.” In other words, the portfolio comes first, and the programs and projects are broken out from it. Let’s walk through it in a little more detail...
In Part 1, you committed to getting in shape for the CAPM/PMP exam. Now you’re back and ready to start getting a little more serious. This second article of the series will show that the tough work doesn’t have to hurt as we ease in with a look at process groups.
The advocates for the implementation of portfolio management are dissatisfied with how decisions are currently being made. They wish to bring about a change to this decision process. They are not, therefore, likely to have much influence in how decisions are currently being made. What to do about this conundrum?
Old Wine in New Bottle or a Useful Approach An application lifecycle is the continuum of activities required to support an enterprise application from its initial inception through its deployment and system optimization. According to Butler Group, a European IT research company, the management of an application lifecycle as opposed to its development is more effective and concerns much broader issues than those of project processes and methodology. It covers a variety of software lifecycle activities including project management, project tracking, development processes, configuration management, quality control, IT governance, IT portfolio management and release management.
The coordination of development lifecycle activities, including requirements, modeling, development, build, and testing, through: 1) enforcement of processes that span these activities; 2) management of relationships between development artifacts used or produced by these activities; and 3) reporting on progress of the development effort as a whole.
March Toward Integration
Over the years, ALM has emerged as a discipline and a product category. It is gaining recognition and adoption not only because of the push from vendors and analysts, but also due to its benefits. ALM significantly improves project success rates, improves the quality of software delivered, reduces development time and makes software development more visible to higher business management.
Even though there are significant benefits of the management of application development as an end-to-end business process, there are many barriers to adoption of this perspective.
As ALM is gaining acceptance, its commercial potential is increasing and more vendors are trying to fill the market gap by providing solutions for it. Many vendors like Borland, IBM, Microsoft, Serena, Telelogic etc. are rolling out products that inter-relate many lifecycle phases and make application development a repeatable business process. These solutions allow development teams to define and execute consistent lifecycle processes. They provide real-time visibility into the application portfolio, enabling management to make investment decisions and determine the status of projects. They provide quick and easy access to all lifecycle information and enhance the communication between various teams.
Today’s ALM solutions have gradually evolved through accumulation of individual tools rather than through a focused design. One reason for this accretion is that products and tools automating and supporting lifecycle phases were introduced when needed without a master plan for a complete ALM solution. Once these tools demonstrated their usefulness to development teams, then a new demand arose for interaction amongst them. The business opportunity became obvious, and vendors started to put together an effective solution by integrating these tools.
Forrester calls today’s solutions to be ALM 1.0. Their major characteristic is that there is a single tool for each role. These tools may not be uniform and vary by company, business units, teams and individuals. They have redundant features in areas like workflow, collaboration, reporting, analytics and security, which maintain functional silos eliminating cross-lifecycle transparency. They have micro-processes (workflows in quality management tools) embedded in each practitioner tools and macro-processes (connectors between two tools), embedded in tool integrations that increase the effort spent in building and maintaining synchronizations.
More on the Horizon: ALM 2.0
Despite many inherent limitations in today’s ALM solutions, the market for them is growing. Forrester estimates that enterprises spend more than $5 billion on new licenses for ALM tools ever year. This is bound to go up as vendors graduate to ALM 2.0 from a collection of lifecycle tools to a platform for coordination of development activities.
Industry experts say that the newer versions of ALM solutions will offer tools assembled out of plug-ins, and customers will pay for only the features that they need. Common services like collaboration, workflow, security, reporting and analytics will be available across tools and built into the platform. ALM 2.0 will be repository neutral with no need to migrate old assets unlike today’s solutions, which require the use of the same vendor’s SCM solution for storage of all lifecycle assets. The new generation of solutions will use open integration standards, allowing for deeper integration with third part tools. They will have processes as versionable assets and share common components.
There is no vendor who is providing these features today, but many are working toward it. Butler Group thinks that product offerings from Borland, Compuware, IBM and Telelogic are a cut above the competition. Microsoft, Mercury and Serena also offer products with strong functionality and performance. Most of these solutions are proprietary, which improves integration between tools by the same vendor but not with competing vendors. On the one hand, it improves the operations and support for ALM solutions. But on the other hand, it increases users’ dependence upon one vendor. Still, there is no doubt that the market for ALM solutions is fragmented, but emerging and more exciting products will be offered that will enable IT teams deliver faster-to-market, high quality software products.
"The good die young, because they see it's no use living if you have got to be good."