Newsletters:

Hype or Help? An ALM Reality Check - Page 1

Nov 26, 2007
By

Bob Doyle






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?

Page 1 of 3


 

0 Comments (click to add your comment)
Comment and Contribute

Your comment has been submitted and is pending approval.

Author:

Comment:

 (click to add your comment)

Comment and Contribute

Your name/nickname

Your email

Comment:

(Maximum characters: 1200). You have characters left.