Hype or Help? An ALM Reality Check

By Bob Doyle

(Back to article)

In order to reach the holy grail of full lifecycle visibility -– the ability to integrate, coordinate and manage all the different phases of the software delivery process -- Application Lifecycle Management (ALM) was born.

A category of development solutions, ALM emerged to help CIOs manage the complexities of software delivery, from development to deployment. However, because CIOs by and large are reluctant to throw out years of investments in favor of a single monolithic platform, this goal has not been realized. In essence, the first generation of ALM has failed.

What went wrong

When ALM was introduced, it was touted -– and held much promise -- as the saving grace for the software delivery world. The truth, however, is that while ALM vendors had the right idea -– reduce the complexity of development -– ALM solutions have shown mixed results in transforming software delivery into a manageable and predictable process that provides better business value.

The cause for this can be traced to the vendor approach to ALM, which was to aggressively promote restrictive, end-to-end offerings that locked customers into proprietary IT platforms. From the perspective of IT organizations, this was viewed as a proverbial “fork in the road.” They were forced to choose between two options:

1. Manage their delivery process using disparate tools for different roles/platforms with little integration and no ability to track the overall progress of the project, or

2. Start from scratch — by ripping out their existing tools and replacing them with a monolithic platform (perhaps abandoning any established best practices), and put trust (and professional reputation) in the hands of a single vendor whose agenda may or may not align with your own.

And here is where we get to the crux of the ALM challenge. As enterprise development has organically evolved from small groups of developers writing software for the mainframe in the basement, to vast multi-functioned teams working on enormous applications designed to run on highly complex, distributed systems, developers and their team members have adopted and created a mix of disparate tools and methodologies to get the job done. The result is an enterprise development potpourri of “mix-and-match” lifecycle tools with questionable functionality and limited (if any) integration. And this is the state of the typical enterprise development organization today.

Every IT organization is different. Each has a mix of platforms, business applications and tools. Heterogeneity is the norm, and this is unlikely to change. According to a survey of more than 300 ALM customers published by Borland Software in August 2007, nearly 90 percent of organizations rely on multiple ALM from several different vendors. Sixty-nine percent support two or more development platforms, with nearly half deploying to both Java and .NET environments.

Recipe for disaster

The survey also revealed that half of respondents are using four or more ALM tools, and that 33 percent of them have tools from more than three different vendors. That's a lot of tools. To further complicate things, 44 percent of the survey’s respondents indicated that they use two or more software development processes, with agile methodologies and custom processes being the preferred solution sets.

The idea that developers should dispose of their old methods and tools in favor of a new proprietary environment was a recipe for disaster. From the CIO perspective, there’s just too much at stake.

First, the time that is spent to learn about and master new tools is likely to eat into any promised productivity gains. Secondly, and arguably more importantly, asking a team to toss out all of its old tools and methods is tantamount to telling them that they’ve been going about it all wrong.

Finally, while the urgency for cost-cutting within many IT organizations has eased quite a bit since the post-bust years of the early 2000s, COOs are always looking for ways to extend the life and the value of existing IT assets. Why not leverage these existing assets in a way that bolsters existing options and capabilities?Unfortunately, the biggest cost the failure of ALM has exacted is to the credibility of the CIO. My experience has been similar to what Borland’s survey uncovered -– lots of tools, lots of different methods, very little structure for tracking progress, identifying issues and, ultimately, understanding if all the work that is underway is actually going to result in an application that delivers what the business needs.

What I did have was “management by gut plus experience.” For every project, I would periodically gather together my development managers, sit them down, and ask them how their projects were running. Those I trusted -- those who had excellent track records -- I marked as “green.” I then took a closer look at the projects whose owners didn’t pass my “gut check” -– they were the “yellows” and “reds.”

I could then report to my executive peers based on the overall color dispersion of my gut “dashboard.” Sure, I could periodically ask for reports on lines of code written, hours logged, milestones met, functions delivered, etc. –- but it would take me weeks (and valuable man hours) to gather the data. And, not only was it already outdated, but it often didn’t provide any true understanding of the overall productivity of the team, or whether the project was really on track to deliver the right functionality.

Moving toward a solution

Despite these shortcomings, the core concepts that initially animated the ALM movement remain sound. According to Forrester’s estimates, organizations see the value in the ALM vision and continue to invest in ALM technologies to the tune of more than $5 billion each year.

What has become clear is that an ALM platform that aims to restrict the capabilities of the development team falls short and often fails. Fortunately, I think that the industry is starting to shift in the direction of a real solution. Vendors are recognizing that what CIOs really need is a business application to manage the entire application delivery process as it exists in their environment today -- tools, platforms, chaos and all. Forrester agrees, and the research group has heralded the advent of “ALM 2.0.”

This is the right trend, as long as vendors remember that flexibility and openness are key. An ALM solution should empower CIOs and their organizations to develop systems that cater to their needs — using the tools, processes and investments that they’ve already made.

ALM is not just about tools, its about finding a way to connect, manage and measure all the various activities and assets across the application lifecycle — even in the most heterogeneous environments. At the end of the day, this is perhaps the clearest path to reaching the holy grail of full lifecycle visibility, with business objectives aligned perfectly with development activities to deliver optimum business value.

And how does an executive measure whether their development efforts are “delivering optimum business value”? This is a question every CIO should spend some time answering. Further, the subsequent measurement of this value should be supported by the next generation of ALM solutions. A recent Economist Business Intelligence Unit report on the changing role of IT in the business found that senior executives expect that over the next three years, IT’s primary role will shift from one of improving cost efficiency to one of enabling revenue generation. And the number one way these executives felt IT would contribute to revenue generation was through the development and delivery of new products and services.The application development organization is where the proverbial “rubber hits the road” for the IT executive. And, as my previous “managing by gut” example illustrates, the current state of affairs for measuring, predicting and ensuring the success of delivery projects is the cause of many an ulcer for the CIO.

For this reason, ALM 2.0 should not just be about visibility, coordination and management (though all of these things would be a great leap forward for ALM), but should also be about measurement -– simplifying the process of gathering and analyzing the right data for CIOs and their teams to understand the “state of affairs” of any development project and be able to report back to the business in a meaningful way.

The future of ALM

When the developer has a choice over tools and technologies — and the ability to leverage the knowledge, skills and capabilities not just of other team members but from across the industry — all in the context of process and visibility improvements afforded by ALM, then and only then, will the software delivery process be truly transformed.

ALM can live up to its potential -– the potential to provide an enterprise a workable solution for managing one of the organization’s most important business functions: the delivery of IT applications and services. But this will only be achieved by addressing and embracing the open and tremendously heterogeneous nature of today’s enterprise information systems.

A working consultant, Bob Doyle has more than 30 years' experience as an IT leader. He has served as a Partner at Tatum CIO Partners, LLP; SVP & CIO at Fleming Companies; SVP and CIO of Alliant Foodservice, Inc. (formerly Kraft Foodservice); VP & CIO of Community Mutual Insurance Company (Blue Cross/Blue Shield in Ohio); VP of IS at GTE-Contel; Director of IS and Administrative Services at Avoinic Systems Division of Lear Siegler, Inc.; and various management and technical positions at General Dynamics.