While Application Lifecycle Management (ALM) has become a
topic of great discussion for middle-management, especially in Development organizations, it has largely remained a discussion on application/ software
development and tool-chains. Advantages
to Developers and Development managers have been highlighted; however, the
crucial business benefits that ALM has the promise to deliver to the
organizations have yet to be clearly understood and espoused, so that these can
become the very basis for effective ALM to be established and for the business
benefits to accrue.
2012 has seen significant strides in ALM. With the advent of Lean/ Kanban, the idea of
Lean ALM or Lean/ Agile ALM is getting some attention. ALM itself has expanded continuously since
the early days to include not just the software development activity but also supporting
business/ management process governance, project/ program portfolio management,
resource management and others. The
latest Forrester ALM Wave Report for Q4 2012 defines the ALM boundaries to
include all of these activities in the context of ALM.
So, what does ALM mean to you – and what benefits do you
seek from it? If you are considering (re)defining your ALM strategy, here are 7 resolutions that might work for you!
1. I will understand
exactly what ALM means - especially in my context.
ALM has broadly focused primarily on software development
and too-chains to enable that. However, development is just one part of IT's ALM activity. Many IT organizations outsource a lot of application development work but still need to manage their outsourced vendor's work. Or they buy and implement 3rd
party tools to meet their application needs.
A large part of IT budgets is spent on maintaining existing applications. In many cases, a lot of "hidden
resources" are spent building applications/ tools/ utilities that
potentially never see the light of the day and may not provide the business
benefits they were meant to. All of these activities comprise "ALM" for the organization and should ideally be managed accordingly.
An Application’s “lifecycle” begins from the time someone in
Business comes up with an idea or a request to fulfill a need (or a new technology solution is identified that might greatly help business) - to the time an app is delivered (through
either a build or buy approach) to service that request - to its ongoing
maintenance and enhancements – and typically to its retirement.
Figure 2 Application Cost/ Effort and Benefit over Time |
Today, IT must manage all of the activities that support
this lifecycle. ALM's real promise is that it can bring these myriad activities under a single "Application Lifecycle
Management" framework and streamline them, since all of this work
contributes to the application portfolio of the organization and one way or
another, impacts IT budgets, cost and contribution to the organization's
business success.
2. I will understand
the specific benefits that ALM can accrue to my organization.
ALM’s benefits from a “tool-chain” perspective to the
software team itself has been discussed extensively. However, it is at the organization level that
Application Lifecycle Management can really shine! It can provide visibility (via traceability and end-to-end coverage) to all of the
work being done towards building, implementing or maintaining the various apps
that support the organization's business.
ALM can provide a good idea of the overall money being spent across the various stages of the application lifecycle. A key thing ALM can enable IT to do is
measure itself on how rapidly it is able
to respond to Business Requests, execute those that must be executed and
those that cannot or should not be. And it
can help IT respond to changes to Business
Requirements on a continuous basis - and help demonstrate to Management exactly
how it has been able to do that. Finally, ALM can enable an organizational dashboard that provides
management a unified picture of the quality, cost and responsiveness of the IT
organization while delivering real business benefits.
3. I will (put
together an ALM team or charter my existing ALM team to) define our overall ALM
strategy, objectives and processes.
While ALM can certainly provide benefits at individual team
levels, it's real promise and benefit is at the organization level. If teams are to work towards a common set of
goals, they need to have some minimum common process that defines the overall Application
Lifecycle, irrespective of whether it is developed using traditional, Agile or
hybrid methods.
![]() Figure 3 ALM Framework |
A typical IT organization today is working in a mixed or
Hybrid Agile environment where legacy apps may follow traditional dev and maintenance
processes while newer apps built on technologies that enable real-time and
continuous build, integration and deployment.
Irrespective of the development method, ALM has the potential to consolidate
and roll-up application development/ maintenance data and provide critical
business measures of IT's responsiveness to Business needs. This can only be done with an overall
objectives and process framework under which all ALM (and PPM) tools are
deployed and used.
4. I will (empower my
team to) put together the necessary ALM Tools framework to ensure our ALM
Strategy can be successfully executed.
Whether you have existing tools that you want to integrate
into a seamless ALM solution or you decide to get an integrated ALM suite, you
want to be able to automate your ALM processes, measures and metrics for an
end-to-end view of your applications related assets and projects. You need to be able to look at incoming
demand for new functionality and tools, you need to monitor existing
development and implementation projects and you need to keep an eye on existing
applications' maintenance and support activity.
![]() Figure 4 Comprehensive ALM Tools Framework |
You should be able to conduct a 'portfolio analysis' of new
requests, in-flight and proposed projects as well as existing applications to help
Business understand and clearly define what is of real priority to them,
especially changes in priority due to shifting business demands; balance your
resources against these often conflicting demands and provide clear direction
to your application/ project teams about what they need to do to ensure
business is being served on time and with quality!
5. I will (ask the
team to) catalog our existing Business Requests, Application Dev/
Implementation Projects and existing Applications to understand the current
state of Applications in the organization.
One of the key challenges all medium and large IT
organization execs deal with are "sandbox" projects and tools;
activity and assets that stay under the covers and typically may not even see
the light of the day. Even if they do,
and get deployed, the cost of keeping them updated escapes the official
reporting of IT costs or gets incorrectly captured. Added up, they can represent significant
drain on IT budgets! Lack of an
integrated system such as an ALM tool/ platform and managing with spreadsheets
and Sharepoint documents further exacerbates this problem. ALM tools can help get a cohesive ALM
strategy off to a great start by simply helping catalog and maintain all of the
work and resources being spent on all these applications in a central
repository. More importantly, it can
help highlight cost and effort "leakage" in the organization and help
identify these pockets of 'hidden investments'!
6. I will define an
overall Application Roadmap for this year and the next, collaboratively with
the Business.
Once the basic ALM framework is in place, then comes the fun
part - getting together with Business and defining the overall Application
Strategy and an Application Roadmap.
Armed with current business requests backlog, and catalogs of projects
and applications, you can engage meaningfully with Business peers on an annual,
quarterly and monthly basis to review the priority of new and existing initiatives,
prioritize the new requests backlog and existing applications’ performance in
terms of SLAs and costs.
Figure 5 - Periodic Prioritization is Key |
Based on this
discussion, you can start to define what needs to be taken up next week, next
month, quarter or year – and you have a well-defined Application Roadmap that
everyone can see and collaborate on to keep it current!
7. I will regularly
monitor the Implementation and Success of our Application Portfolio and ALM Strategy.
If you are able to go through and implement the first 6
resolutions, the 7th should be a breeze! Admittedly, it will take some
work to do it. The key issues to be discussed
and resolved are always business, policy or process related. But they NEED to be dealt with for effective
Service Levels from IT to business! And an
effective and integrated ALM process and tool strategy will help immensely
in making the transition from just building software and applications to
managing your Applications well throughout their Lifecycle.
I hope you find these resolutions useful. Please do recommend others that you believe
are critical as well. I wish you a
successful New Year, especially in your Lean/ Agile ALM initiatives!
Mahesh Singh
Co-founder, Digite/ Swift-Kanban






Excellent post - very much in line with the way we have thought of managing our Apps portfolio. One thing that has helped us is to regularly capture and report the head-count/ effort and cost for all our major apps and compare that to the value it provides to business (based on user surveys) - and do a year-on-year comparison of that ratio. Only when the ratio dips below a threshold do we consider retiring an application.
ReplyDeleteRyan O'meara
Cinci Power
Hi Ryan - thanks for the comment. Sounds like you have your ALM approach well covered!
DeleteInteresting Post! i believe what is worth analyzing is linking the requirements with earned value in an economic scale. a quantitative analysis of the value of each requirement.
ReplyDeleteHi Raghda - interesting point! It should certainly be possible to analyze each requirement's 'earned value' in the conventional sense - which is more of a cost measure rather than (business) value; using traceability or other types of links between requirements and the associated tasks and other work items used to track the work done to build those requirements. A good ALM system (such as Digite!) should certainly be able to provide such information.
Delete