In the end, Application Lifecycle Management helps you to transform business ideas in an efficient and predictable way. You, as an IT department, will be able to deliver what the business needs. Moreover, you will be able to do this on time and within the estimated budget. The ALM maturity assessment discussed in my previous post results in a clear overview of the current maturity level (per discipline) and a phased plan to increase the maturity of you ALM processes. In this post we will discuss the possible benefits of executing an ALM maturity increase plan (by using a concrete customer case).
Benefits
When you reach a good ALM maturity level, you can expect to see (among other things):
- Stronger collaboration between business and IT, resulting in better alignment of IT and business goals
- Improved project management, including better estimation, tracking and reporting through a single, unified view of the project
- Quality improvements, in such a way that the final application meets the business and technical requirements
- Shorter development cycles and improved productivity through better tool and process integration, reducing the time and effort wasted with disparate tools, duplicated data and manual processes.
- Increased agility, allowing the IT department to rapidly build and adapt applications to support changing business requirements.
Customer business case
With the correct ALM ecosystem in place you can automate your processes making them repeatable and less error-prone. To illustrate this I would like to give a concrete example.
The customer in this example was very traditional in software development: one application = one team = one server. Every server was installed manually and every deployment was done by hand. To increase the agility in the software development we slowly moved from the traditional approach to a Service-Oriented organization. This actually put a huge burden on the operations department. Suddenly one application spans multiple teams and the deployment involves multiple services instead of one big artefact.
Main pain patterns at this stage
- Deployments had to be carefully planned because they take a lot of time. The operations department was a real bottleneck to ship working software to our customers.
- Deployments were very error-prone because of the manual nature. If one out of 10 service deployments fail, the entire application can be broken. This resulted in escalations within the department and fire-fighting as a consequence.
- After deployment, we usually had strange and unreproducible errors. This was caused by poor information and settings that were very specific to that particular server environment. The development team had to invest a lot of time to solve these bugs and the business was annoyed that it took us so long to solve these issues.
What did we do?
- Standardization of the configuration management (Devops effort)
- Automation of the server installation in such a way that every server environment is identical.
- Automation of the application deployments via Puppet
What value did we deliver?
- Because of the automation the deployment time was decreased from 1 or 2 days to 5 minutes (and this included a dry-run). The operations team was no longer a bottleneck. One of the consequences was that we managed to reduce theoperations team by 1 FTE. This is a sustainable cost reduction of about 2.5% on the IT departments (personnel) budget.
- Automation of both the server installations and the application deployments reduced the errors after deployments drastically. The software was delivered as promised to our customers (on time and with the right quality level).
- The development team could focus on delivering new features instead of fire-fighting or investing time in solving strange unreproducible bugs. Analysis has shown that every developer usually spent 5% of his time (on average) on this. Multiply this by 30 developers and you get a time saving action of 1.5 FTE. Instead of downsizing the team we choose to use this capacity for delivering more features to our customers.
Conclusion
Based on the initial pain patterns we decided that an ALM maturity assessment was appropriate for this customer. By using the ALM maturity roadmap & radar we got an objective overview and could focus on improving the maturity of the disciplines that delivered us the most value.
In the end we got predictability in our software delivery with a substantial IT cost reduction and happy customers as a result.