Application Lifecycle Management: Success in Terms of Business Outcomes

 

IT helps the rest of a business integrate information silos and automate processes.

 

However, when it comes to managing how software is produced, IT often has a hard time making a convincing case for integrating software development silos, because it relies too much on technical arguments. Instead, IT shops – and application lifecycle management or “ALM” vendors – should elevate their approach and take a few lessons from their business counterparts: frame the benefits of ALM in terms of business outcomes, not improved processes. ALM vendors should package and create solutions that map to high-impact processes in the application lifecycle that benefit the business.

 

 

ALM vendors have historically taken a ‘Field of Dreams’ approach: if you build it, they will come. In their case, this meant that if you improved the process of managing requirements, software testing, conducting, and version control or build-scripting, the benefits should sell themselves. However, the CFO’s response is usually “show me the money.”

 

The application lifecycle encompasses the steps that occur from the point when a need for new or changed software is established until the time the software is coded, tested, deployed to production and operated. The dilemma for IT is that the business has long perceived this cycle as a cost centre and therefore has never imagined that there might be business value from improving how the application lifecycle is managed. As technical, engineering-orientated professionals, IT staff members have never been adept at talking the terms of the business.

 

Instead, they hope that C-level management will get the message, or take it on faith that improving software development will improve the business. Stuck in a self-perpetuating cycle, ALM vendors have encountered significant resistance to elevating the message of ALM beyond integrated tooling. Compounding the challenge, vendor account teams remain more comfortable selling tools than solutions. No wonder the ALM market has had a high mortality rate.

 

However, given the importance of software development to the competitive health of an enterprise, it should not be so hard to sell ALM. How IT develops software affects how quickly value is delivered to the business, which in turn affects the business’s ability to adapt to or spark changes in the marketplace. This should be a C-level concern, and if IT adopts a more business-focused approach it will become more closely aligned with the business.

 

The devil is in the details. IT departments and ALM vendors need to identify the software development processes with greatest business impact and frame those impacts in business terms.

 

 

The first hurdle is the misconception that ALM is a product. ALM is the process by which IT organisations manage how they develop and run software. The term emerged when vendors began introducing products that expanded from stand-alone tools to broader solutions managing software development from inception to construction, testing and deployment. However, defining ALM as a product is a losing proposition for both vendors and IT.

 

For IT organisations, the tools focus of ALM has simply reinforced existing work patterns, internal attitudes and perceptions. IT shops measure themselves in technical terms around coding, testing and build-scripting, rather than considering how they could improve the value they deliver to the business. For vendors, perception of ALM as a product leads to the letdown that ALM is a poor step-sister of enterprise packaged software such as ERP.

 

With few exceptions, ALM does not lend itself well to a packaged, umbrella solution approach because the market is so fragmented. Most IT organizations consist of diverse collections of entrenched local tribes that each work off their own platforms, programming languages and methodologies, with some groups more disciplined than others. Not surprisingly, it is easier to sell tools at the tribe level than solutions at the enterprise level.

 

ALM needs a fresh look: IT shops and vendors should apply a business process approach

 

ALM vendors have always boasted that they do not target developers but aim higher in the organisation, at directors or C-level executives. To put real meat to that assertion, ALM vendors must cultivate a discussion focused on business process.

 

The good news is that ALM policies – such as requiring at least 75 percent of code artifacts to be tested before check-in to source code repositories, or mandating test cases for every requirement – are not strictly about finding better ways to develop code. Instead, they are about ensuring that software is developed to tangible business goals and will more likely deliver the right business outcome because it is defect-free. The problem is that such thinking is not instinctive to software development or vendor sales teams.

 

Taking a process approach to implementing such policies forces IT to push for consistency and predictability. Framing those processes in business terms forces it to think in terms of producing the best business outcomes. How could you make such a case? A short list of ‘dos’ and ‘don’ts’ for IT and ALM vendors could include:

 

 

 

 

To drive these points home, the benefits should be targeted to the company’s core business. Examples could include:

 

 

 

 

If ALM is not about tools, how should solutions be packaged by vendors and presented by customers? The answer is not to start with tools. Use an approach that any business process management veteran will recognize.

 

 

 

 

The results will change how ALM vendors package and sell their products. For instance, instead of selling test automation, promote a software warranty solution that ties software quality to actual service levels – and value – delivered to the business. Make the business case by addressing the benefit of more reliable service levels to the company’s core business. The solution would close the loop between traditional software QA and the application’s actual service-level quality, which is conducted before software is deployed, with the track record of the application in production – as monitored through service-level management, performance management, security incident tracking and trouble ticket activity.

 

All of this is not to ignore the core building blocks of any properly managed application lifecycle. They include some form of integrated development environment for coding that is tightly coupled with quality management and defect tracking, source code version control and build automation for managing the software release cycle. However, these tools are only a means to an end. To support the business, ALM should be reinvented as solutions that manage the business processes of delivering software.