In each issue BrainBox takes one of technology's more impenetrable subject matters and attempts to, well, penetrate it. So if there's a topic you'd like to pick our brains on, let us know and we'll get BrainBox on to it.

This time round we take a trip down the cul de sac of the prosaic that is Application Lifecycle Management.

What?

Application Lifecycle Management.

IT systems have always tended to suffer from three essential flaws: They take longer to develop than expected, they cost more than was budgeted for, and they don't quite do what the business wanted.

Application Lifecycle Management - or ALM - is aimed at helping business to overcome these issues to ease application development.


What about it?

Back when any computer was a welcome step up from a ballpoint pen, IT development didn't matter so much. It was a black box.
You fed your requirements in at one end and waited patiently for something - anything - to pop out of the other.

But now that IT has become vital for competitive advantage and even business survival, owners and managers want to peer inside the black box and see what's going on - to try and speed things up, improve quality, and ensure a better fit with the needs and aims of the business.

To do this, they need to know how efficient each programmer is, how fast they work, how many mistakes they make. They need to ensure the technicians understand exactly what the business is trying to achieve; that they know precisely what each application should do.


Why?

Managers need to be confident that software has been properly tested, that requested changes have been properly made and verified, that all the pieces of the jigsaw fit together faultlessly, and that the live system is running at optimum performance.

They also want to understand the human resources within the IT team. Who's doing what? Do they need outside help? Is the project on budget and on schedule? How will a request for a change impact existing work? (Important new systems are often delayed because programmers are sidetracked by updates to less important existing ones).

It's also important to ensure that quality standards are maintained, that any clever innovations are re-used, that mistakes are learned from, and that any changes in the direction of the business are reflected accurately in its systems.


How?

It's not a question of spying on staff. Everyone involved - analysts, programmers, testers, system administrators, webmasters, project managers, and end users - wants to ensure they're doing their job as efficiently as possible, and that their part of the system lifecycle dovetails seamlessly with the sections before and after it.

What they don't want is to spend hours filling in reports and timesheets: so some measure of automation is highly desirable.

A few years ago this requirement began to crystallise into a formal methodology backed up by an increasingly sophisticated and integrated array of software tools. This came to be called "Application Lifecycle Management" (ALM).

Each stage of the development process, from defining business requirements to deployment and management of the completed system, is formally recorded and measured, and people at all levels can access either detailed information or high-level summaries as appropriate.

When fully implemented, ALM provides a structured, disciplined, repeatable way of developing and maintaining systems.

The larger the organisation and the more people involved in application development, the more vital ALM is likely to be.

But even the smallest firms can benefit. They are however, unlikely to be able to cost-justify the more extensive ALM tool sets.

It doesn't matter if the firm doesn't develop applications in-house, since many aspects of ALM - defining requirements, customisation and configuration, testing, deployment and performance management - are just as applicable to packaged software.

It's also possible to build up ALM in stages rather than implementing it all at once. Some firms begin by formalising the definition and management of user requirements, or the testing process, or the management of change requests, and add other aspects later.


What else?

ALM isn't just, or even primarily, about software tools. It's principally an attitude of mind.

In the smallest businesses, where only a few people are involved in specifying, developing, and maintaining its systems, the software can be added later, or may even be superfluous. ALM can also be outsourced to a third party and can even be used by the client organisation to help manage its outsourcing contracts.

Most ALM implementations require some customisation though, and vendors generally recommend taking consultancy and training in order to get the most from their products.

However, success or failure is in large part down to the user organisation itself. Board-level commitment is essential, as is ongoing communication between the business and its technology function. If everyone can be persuaded to buy into ALM and the culture of communication that underpins it, it's possible to unify the efforts and aims of the business and IT functions as never before.


Where can I get hold of it?

A number of vendors sell ALM solutions including Borland, IBM, Microsoft, Aldon, MKS, Polarion, and Serena. Some offer enough functions to build up into a complete ALM system, others provide a range of specialist tools.

However, by standardising on an open platform such as Eclipse, firms can often mix-and-match ALM tools from different vendors, or even obtain open-source tools for free, and formal interoperability standards - such as the Eclipse Application Lifecycle Framework -
are beginning to be implemented.


Key stages in the application lifecycle

• Business needs definition
• Requirements management
• Specification
• Modelling
• Design
• Development
• Unit testing
• Integration and configuration
• System testing
• Version control
• Deployment
• Live system management
• Change request management
• Project management