In my previous post I have shown a number of possible pain patterns that you can experience if the maturity of your ALM processes is not adequate. In this post we will discuss a method that can be used to assess these processes and increase the ALM maturity in the areas where this is needed.
ALM disciplines
ALM is an ecosystem that combines people, processes and tools which are needed to transform a business idea into working software (see my previous post). In order to increase the predictability you have to increase the maturity of your Application Lifecycle Management (ALM) processes.
Application Lifecycle management is about finding the right balance between “building the right thing”, “building the thing right” and “building (or releasing) it fast”.
As such, we would like to divide ALM into 6 disciplines:
- Requirements Management: in order to build the right thing, your input needs to reflect what the business really needs.
- Software Change, Configuration and Release Management, containing
- Change Management: “there is nothing permanent except change”, so be prepared.
- Version Management: centralized management of multiple product versions with standardized and secured access for your team.
- Build Management: builds should be continuous and automated.
- Release Management: release & deploy software artefacts on different environments.
- Quality Management: you need to verify that the working software actually reflects the requirements (in order to deliver what the business needs)
ALM maturity roadmap
We have put these disciplines and mapped them in our “ALM maturity roadmap”. This generic framework allow us to perform an objective ALM assessment for each project or organization. As a result it provides the the required information that can be used to improve the ALM processes to a whole new level of maturity. The outline of this framework and the positioning of these 6 disciplines is shown below. 
The ALM maturity roadmap is used as a tool to perform assessments. Every topic is discussed with the relevant stakeholder(s) within the project or organization. Maturity increases from left to right in 5 different levels. Not all disciplines have the same maturity levels because they are linked to each other. In order to release your software efficiently you need a certain maturity in version and build management. If you want to build and test what the business really wants, you need good requirements as input.
ALM maturity assessment
An ALM maturity assessment leads to a report that describes the current situation and recommendations per discipline. Each topic is scored and visualized on the “ALM Maturity Radar”. This shows the scores per discipline but it is also a great instrument to get an overview of the overall maturity of the ALM processes.
All disciplines depend on each other. They need each other’s strengths, but also suffer from each other’s weaknesses. That is why they need to be balanced. In the example maturity radar, you can see that build management scores lower than the other disciplines. Therefore, it will be our first focus to increase the maturity in this area. In a second phase we should also work on other disciplines. The recommendations that were identified during the ALM assessment are prioritized (based on cost, benefit, risk and urgency) and estimated. This leads to an “ALM maturity increase plan” which is a phased plan with a clear scope for every phase. We make a prediction of the maturity if the plan gets executed. These predictions are verified regularly when the plan gets executed.
Where’s the value?
If the ALM maturity increases, your processes will get more predictable and you will be able to deliver your software to your customer more efficiently. This can result in a reduction of cost, time-to-market, better quality or increased agility. I invite you to read next week's post on ALM benefits if you are interested to know why you should invest in ALM maturity.
