In this series of articles, I’m going to address Application Lifecycle Management (ALM) as a process, giving a high level overview of the subject for novices and some useful insights for the more experienced out there.
Technology is rapidly pervading every organization in the world. As more and more companies become digital companies, it’s the applications and services, that give them a competitive advantage in the marketplace. Thefore it becomes critical that the development, testing, deployment and maintenance of these applications are completed in such a way that not only meets the business obectives but is also as effecient as possible and constantly improving through feedback loops.
Take too long to develop new functionality and a competitor will steal your business. Don’t test enough, or effectively, and you’ll face issues in your production environment that will be costly to resolve. Don’t deploy your applications into production considering all the factors at play and you’ll find yourself repeating the activity, rolling back or worse pushing code to production and breaking functionality, or integrations, that already function. Once your ERP or CRM soluton is in production it can’t remain static, you need to constantly improve. Monitoring and maintenance become critical for giving information back and making changes that improve your product, service or business process. This is what will allow you to compete in a crowded marketplace.
Well the clue is in the same but what we are interested in is how we manage the actual activities that occur throughout the lifecycle of an enterprise application like SAP or SalesForce.
The topics this series aims to cover are:
The first topic of this series is Release Management. So why do we need to think about Release Management? These days more and more customers cannot afford for their production environments to be out of commission for even 1 minute. As technology becomes ubiquitous and competitive advantage is gained through more efficient and effective enterprise systems it’s critical that customers protect the health and integrity of their production environments, and services, through the use of a series of formal procedures and checks.
So then the goal of Release Management is to take a holistic view of a change to an IT product, or service, and ensure that all aspects of a release, both technical and functional, are taken into consideration when moving code to production.
However, change to an IT landscape introduces risk and risk must be controlled and this is where we introduce process to control the changes.
Typically, the business wants to release more functionality more frequently and the Release Management team’s job is to schedule and execute these releases while mitigating the risk of failure. This must be done by providing guidance and visibility towards management around the risk of releasing functionality and from a process perspective by implementing Quality Gates that aim to ensure no bad code gets shipped to production. You can think of a quality gate as a milestone that determines whether changes can released to the next environment. Only after a quality gate has passed can the release continue.
But what about DevOps I hear you say. Making high speed changes to environment can be risky considering the complexity and importance of ERP sytems like SAP but if companies are going to remain competitive they need to adopt modern development techniques that can afford them speed, automation and stability. So of course DevOps is critical but this article is descibring the steps within the Release Management process and if you can automate as much as possible then all the better.
Throughout this process, stakeholders are usually engaged through go live meetings where debate is had on the benefit of releasing new functionality compared to the risk.
Release Management Teams require a good understanding of the entire project. Planning releases means understanding, and taking into consideration, the overall activities executed throughout the release (analysis, design, build, tests, documentation, knowledge transfer, implementation, early live support).
Release Management teams must also be the bridge between functional, technical, testing, change, business and management teams and are often.
Release Managers are the jack of all trades.
