Don't underestimate the benefits of managing applications throughout their use
There are changes taking place in application lifecycle management (ALM), with increases in the range of tools available to support application development and in the scope of ALM. The scope changes are particularly pertinent in the climate of low project productivity that bedevils software creation.
There is a consensus that something needs to be done about the management of large and complex projects: too many have serious deficiencies, overshoot schedules and costs, do not meet user expectations, or fail completely and are scrapped.
ALM can alleviate these problems and to meet the challenge is reaching vertically into the business layer, to better meet business needs and make IT visible as a business unit to higher management.
Activities such as project portfolio management and requirements management are now integrated into ALM and can feed information to executives, for example providing concise indicators and reports to alert management to the status of projects.
When many millions of pounds are at stake, this type of awareness is essential and helps to bridge the culture gap that still exists between IT and the rest of the business. The increasing visibility of IT to the business also works in reverse: application developers can better understand how their applications are affecting business and feel that their work is appreciated.
The applications that are covered by ALM are no longer exclusively those produced in custom in-house development, which can still account for as much as 50% of applications in large enterprises. It now includes commercial, off-the-shelf applications, integration software, third party applications and components, as well as offshore and outsourced applications and modules.
All applications need to be managed, whether in development or during maintenance and support in production.
Project portfolio management plays a number of crucial roles in helping to manage application development and application usage as a business activity, such as:
lRationalising the number of applications within an organisation. This is especially important where mergers and acquisitions have taken place and in providing a global view of application use
lAligning IT with business needs and ensuring that projects in the pipeline meet them, ensuring that business cases are made for new applications to meet business needs, and prioritising projects in the pipeline that are urgent for the business
lManaging manpower resources to fit business needs
lRunning quality assurance software metrics on applications and making cost-benefit decisions on maintenance and support
lManaging application delivery
lProviding business intelligence about application development.
Another addition to the ALM suite relates to requirements management. For too long this has simply been a paper-based gathering process or an activity that occurs only at the beginning of a project. The fault in this approach is all too evident when people dig deeper to better understand application development and how to improve it. Requirements engineering, a mature practice in the defence and aerospace industry, has been re-branded requirements management and is being applied to IT in other vertical markets.
It matters - possibly more so than any other aspect of application development. You can draw a parallel between data and requirements. The old adage "garbage in, garbage out" applies equally to requirements. But getting requirements right is not an easy task. For a start business users think in terms of solutions, whereas IT thinks of requirements. To cross that divide we need business users who understand technology, and IT people who understand the business.
In requirements management the first step is to build a business case for a proposed application and gather the requirements. This process must identify all the stakeholders - all too often an application is built and only then is it discovered that a class of user has been overlooked.
Modern tools, such as those offered by Telelogic, Borland, and IBM, keep the requirements traced to code development. This ensures that the correct application is being built.
But the power of modern tools is to keep requirements in a central repository, so that any change in requirements is instantly propagated to all the project team - crucially developers and testers - ensuring the latter are testing against the latest requirements.
Managing change is often where projects fall down. Project schedules seldom cater for change, whereas in practice change is the norm not the exception. But the story does not end there because once the application is released the user experience needs to be fed back into the next release cycle of the application. Requirements management provides the feedback mechanism for retaining this information and linking it into the next cycle of requirements.
Another factor these tools can help with is the increasing use of offshore development, where distributed teams operate in separate time zones. They can assist efforts to keep requirements synchronised, aid collaboration - with comments attached to requirement, and easily retrieved - and help to ensure that developers and testers make fewer assumptions
ALM's extension to encompass project portfolio management and requirements management now also extends beyond deployment into application performance management. This automates the monitoring of applications' performance and helps to reduce the costs of maintenance and support. The latest generation of ALM suites has also targeted core development activity by providing role-centric tools, typically based on analyst, architect, developer, tester, and project manager.
Over and above these changes in ALM is the notion that applications do not have a simple beginning and end - rather they evolve. Managing the evolution of an application through release cycles, particularly in large projects, requires tools to make the process easier.
ALM is the technology, but the most difficult aspect of application development remains: people management. Here there are also changes taking place, with a wider adoption of methodologies and process practices. In combination, these changes provide a more robust and repeatable development experience.
Michael Azoff is a senior research analyst at Butler Group.
The Butler Group Application Development Strategies conference takes place in London on 27-28 April
This was first published in April 2005