What is an ALM Governance Framework?

An ALM framework is essentially a set of guidelines, tools and processes that manage how you develop, deploy and manage your solutions. As discussed in our previous post, the Governance component of ALM consists of various factors within itself. Depending on an organisations needs, your governance framework will differ. For instance, with regards to project change requests, some companies require a basic form to be completed with the request, whereas another company may have a change request process linked to a DevOps board and user stories. This is why its crucial to have some direction as to how you want your ALM governance framework to work.

The Components

Understanding each component of the framework will assist with finding what suits your specific requirements. Lets break down a few priority components:

• Development Standards: Governs how we develop solutions such as having naming conventions, error handling and code structure.
• Peer Reviews and Testing: Also known as Quality Assurance (QA). Ensures a fresh set of eyes have reviewed your code ensuring your solution runs effectively, efficiently and meets its requirements.
• Security: Defines how our solutions should be secured. This includes who has access to the solution, securing backend data, encrypting the data, and being compliant with data regulations etc.
• Monitoring: Keeping an eye on our solutions performance, resources and capacity.
• Change Requests: Do we have a structured process to deal with change requests? How are they logged? Who approves them? Does this change impact delivery times? etc
• Maintenance: A streamlined process to maintain our solutions and data, such as archives and backups.
• Environments: Where do our solutions get built, where do they get tested? Where does the completed solution live?
• Resource Management: Identifying what projects are priority vs the capacity your team has available to build.

All of these components work in coherence with each other. Let’s break down a simple ALM Governance Framework.

An Average Day In Johns Shoes

Resource Management

Waking up to a well needed coffee, John goes to work and opens up his email. He’s got multiple emails asking his thoughts on various Internal Projects his CEO thinks will benefit the company’s internal processes. John knows that balancing client projects is priority, but he also needs to priorities some internal development. John needs to manage his resources efficiently by presenting what Internal Projects are viable against difficulty, duration and priority. This gives John the necessary tools to manage his developers capacity whilst taking on priority projects. John can now also present a budget based on capacity to take on these Internal Projects.

Development Standards

With the go ahead, John assigns the project to 3 developers who crack on. Following the company’s strict development standards, the developers are getting on just fine knowing they all following the same process. Even when Johns developer, Steve, got sick, Anthony was able to continue his work without having to spend hours trying to understand Steve’s code.

Environments

Being that the company has many other solutions already in use, John ensures he separates active development from production solutions. To keep this structure simple, John has his devs working in a Developer environment. When they ready to progress, they’ll deploy to QA, UAT, then finally to Prod.

Source Control

Because John has 3 devs working on this project, he wants to ensure that no one’s code gets over written and that there’s always one true code of truth. He therefore creates a DevOps repository with appropriate branches in the DevOps project.

Peer Review

The team have successfully deployed to QA. John gets Sarah to come and have a look at the solution with a fresh set of eyes. She reviews the code, naming convention, comments and other standards that should be adhered to.

Testing

Sarah approved the solution and the team continued with their deployment to UAT where the finance team will start testing the solution. A few bugs were found and fixed relatively quickly, allowing for the team begin preparations for a production deployment.

Monitoring

During testing, the team monitor the solutions performance to ensure that the solution is not lagging or slow, and that there’s no storage leaks.

Version Control

The team finally cross the finish line and deploy to prod. At the same time, they mark the solution as version 1.0 so they can safely enhance features and fix bugs without effecting production.

Change Requests

Three weeks go by. John gets a call… The stakeholder wants a few changes made. No problem. John gets out his change request process and captures the requirements. He then links the requirements to the DevOps board and begins the phase two development of version 2.0 back in the developer environment. Our cycle then starts again.

John was able to manage the entire project on a daily basis by utilising all the ALM Governance processes already in place.

The Framework

Now although Johns framework worked for him, your framework may not need to be as complex. Figuring out what parts of ALM you need vs what you don’t need is extremely useful. Having unnecessary processes in place sometimes causes headaches you don’t need. Stick with what works for you!