When we talk about ALM, we often only talk about the automation part. Even though this is an essential part of it, there is more to ALM than that. ALM is a complex system of tools, people, and processes to control the complete cycle of an application, from planning and development, testing, and maintenance to retirement. It is important to know that all of these are integral parts of holistic ALM.

The following diagram illustrates the different stages of an ALM process and that it is an ever-repeating cycle:

Figure 1.1 – Stages of ALM

Whenever we have completed one cycle by starting from the Maintain stage, we start over with the planning of the next iteration. After the first iteration, the Maintain stage continues while the other stages are executed to support and maintain the current version in production while the next version is prepared. This goes on until the application is finally retired.

As you can see in Figure 1.1, the ALM cycle contains five stages:

1. Plan
2. Develop
3. Test
4. Deploy
5. Maintain

The following sections will explain these five stages.

Plan

First, an application must be planned. Therefore, this is the first stage of the ALM process. This will include requirement gathering from all stakeholders to collect all their needs for the application to support their business cases in the best way possible. Business requirements are not the only requirements we have to take into consideration. Within this stage, gathering compliance and governance requirements is as important as gathering business requirements. Usually, we differentiate between functional and non-functional requirements, where business requirements are often functional and the others mentioned are often non-functional.

With all this input and requirements, a design of the application will be created.

Since the ALM process is a cycle and can repeat itself, it can support an Agile development approach. In this case, the requirements gathered in the Plan stage of one iteration can change the requirements and design of an earlier iteration.

Develop

After the plan for the application (or the next iteration) is completed, the team starts implementing it. The development team must break down given requirements into small pieces to be able to implement them.

Within this stage, the team could use different development approaches. The most known ones are either a Waterfall or an Agile approach. Since the whole ALM process is a circle and repeats itself, this would mean that the chosen development approach is a sub-approach.

Test

Usually, the Test stage and the Develop stage are very tightly related to each other and even overlap. Testers start their work of defining test cases and setting up test environments while the application is still in development. They send features back to development whenever they find parts that are not working as expected, which should happen in close communication between the test team and the development team.

In addition to the often-manual tests of dedicated test teams, it is recommended that the development team also creates unit tests as well as integration tests for the software they are writing. In addition to that, there might be the need for automated UI tests, performance tests, load tests, and a bunch of other tests.

The formal purpose of this stage is to verify that the created application meets the requirements defined in the planning stage of the ALM process. Until this is the case, the team will do mini-iterations between the Develop and Test stages.

Deploy

This stage defines the release of the product to production or the end user. There is no direct definition of how this stage should be done. It very much depends on the kind of software developed, the target audience, the prerequisites within the organization, and a lot of other factors.

Maintain

The last stage is to maintain your application, as the name says. It includes monitoring and managing the application. This stage is usually the longest in an ALM process.

As soon as an application is in this stage, it stays there until it gets retired, even though new iterations (a.k.a., new versions) are usually started as soon as one version goes to production and therefore enters the Maintain stage.

As mentioned earlier, a flowless process to develop custom software is crucial to the success of an implementation. In the upcoming sections, we will analyze the following key advantages of ALM:

• Boosting communication and strengthening visibility
• Sharpening testing
• Increasing quality
• Improving development and deployment speed

Boosting communication and strengthening visibility

A good ALM strategy provides your team with the tools needed to deliver high-quality software. This includes proper team communication and planning platform(s). All of the tools in an ALM strategy should be as integrated as they can be to improve collaboration.

When those tools and platforms are in place, all stakeholders, and the development team in particular, will get better insights into the current project status and what has been achieved already, as well as what lies ahead.

Sharpening testing

Another part of a sophisticated ALM strategy should be guidelines, best practices, and tools when it comes to testing. This includes manual tests such as regression tests by the test team, as well as automated tests such as, for example, unit tests or integration tests.

When those guidelines, best practices, and tools are in place, the development team can easily create automated tests, which should be run on a regular basis, at least before the software is deployed to the downstream environments.

Increasing quality

The first two key advantages together will lead to increased software quality. Since all stakeholders are able to communicate better and more frequently and get better insights into the current project status, and the development team can create automated tests, the overall quality of your delivered software will be increased, mainly because the identification of issues can be done a lot earlier in the process.

Through source code management and proper branching, the quality of the delivery can be increased even more.

Improving development and deployment speed

All of the aforementioned will, in the end, improve development and deployment speed. Since issues can be identified earlier in the process, the development team needs less time to fix them and respond to the input of the testers. Therefore, the cognitive shift between tasks becomes less for both developers and testers, which leads to more efficiency and thus improved productivity.

The deployment process that should be set up during the establishment of an ALM strategy should optimize and automate the current deployment process. Through iterations of improvements, it will be optimized even further. This means that the deployment speed will be increased over time.

ALM tools are usually a collection of project management tools. How sophisticated those tools are depends on a lot of factors, one of which is how mature the current organization is in relation to application development. It could range from a very simple document or wiki to a “full-blown” ALM product.

It is also important to mention that there are usually several tools that are combined to achieve a holistic ALM tool landscape.

The following list gives you an idea of the features your ALM tool landscape should (at least) cover:

• Communication: The team implementing the solution needs to communicate with various stakeholders. Since communication is a crucial part of developing an application, it should be part of the ALM planning. It should be clear to the entire implementation team which communication channels they should use.
• Requirement planning: Requirements are necessary so that the development team implements the correct functionalities according to the needs of the business. Therefore, clear structure and tooling in regard to requirements (including gathering, defining, estimation, and tracking) are important.
• Test management: Every implementation should be tested. An automated approach is preferable, but a manual approach in most cases is also feasible. Both approaches are often combined, depending on which area of the application is currently being tested. Either way, a good ALM approach should define where the tests are managed. This includes defining new tests, scheduling test execution, and tracking test results.
• Source code management: Since a usual application implementation project includes writing code, an ALM process has to include a tool to manage the project’s source code. This includes different branches, commit tracking, and pull requests.
• Automated deployment: An optimized ALM process will execute deployments to downstream environments in an automated fashion. This optimizes quality since all the necessary steps are always executed in the same order and in the same way. To be able to handle this, an ALM process should define which deployment automation tool to use.

Here are some examples of ALM tools:

• Microsoft Azure DevOps
• GitHub Actions
• Atlassian Software Suite (Jira, Confluence, Trello, Bitbucket, Bamboo)
• Jama Software
• Tuleap
• Visure

In this chapter, we learned about the key ideas behind ALM. We learned that an ALM process contains five steps: plan, develop, test, deploy, and maintain.

This chapter also describes why ALM is important to a successful implementation project and the advantages it brings. They are as follows:

• Boosting communication and strengthening visibility
• Sharpening testing
• Increasing quality
• Improving development and deployment speed

You now understand the stages of ALM and some of the tools used to implement it.

The next chapter looks more deeply into the need for ALM when working with the Microsoft Power Platform.

1. Which of the following is a benefit of ALM?
   1. Code works the first time without errors
   2. Qualify of code is improved
   3. Code is easier to maintain
   4. Telemetry is automatically captured
2. Which two of the following ALM tools are provided by Microsoft?
   1. Azure DevOps
   2. GitHub
   3. Jira
   4. Tuleap

For more details on the topics covered in this chapter, reference the following resources:

• Application lifecycle management: https://learn.microsoft.com/dynamics365/guidance/implementation-guide/application-lifecycle-management
• DevOps solutions on Azure: https://azure.microsoft.com/solutions/devops/