ALM
The actual goal of Application Lifecycle Management (ALM) is to transform a business idea into working software as efficiently as possible. The requirements need to be aligned with development to build applications that drive business objectives.
Your ALM processes should be managed as actual business processes because they create the predictability that the business is requesting.
In reality they are still considered to be an IT internal concern.
Pain patterns
Do you recognize any of the following pain patterns?
- The complete application landscape needs refactoring due to a company merging program. How will we facilitate the integration in parallel with our current legacy changes?
- We cannot change that (shared) component because we do not know what the effect will be.
- Bugs in production are extremely hard to fix because we do not have an environment to simulate the symptoms accurately.
- Since the release of V2.0 we have that old bug again. Didn’t we fix that in V1.2?
- For the deployment of an application we need to deploy a number of services. It fails over and over again because we always seem to miss something.
- The new release was not working properly although our QA testing resulted in a GO.
- Our production deployments always take 2 weeks to complete. They have to be planned carefully because the operations team is really understaffed.
- We have a corporate release calendar but miss the agreed deadlines. We are not able to deliver the business changes that we have promised.
- Why are you developing new functionality while there are still critical bugs open?
- Some artefacts in production were changed without the appropriate approvals. This seriously distorted our daily business.
If you recognize these pain patterns, I invite you to stay tuned and read my next post on how to eliminate them. You can get more predictability in your software delivery by improving the maturity of your ALM processes.
