Application Lifecycle Management (ALM)

Revision as of 18:51, 21 November 2022 by User (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Application lifecycle management (ALM) is an integrated system of people, tools, and processes that supervise a software application from its initial planning and development, through testing and maintenance, and into decommissioning and retirement. By combining and organizing the elements of an application's lifecycle, ALM improves product quality, optimizes productivity, and eases the management and maintenance burden for related products and services.[1]

The principal role of Application Lifecycle Management (ALM) is to manage the life of a software application from concept to delivery throughout the entire development process. To be effective ALM solutions must include requirements management, software change and configuration management, system model management, and test management in a single, integral solution. ALM provides visibility into product release readiness, supports variant complexity, automates development processes, and ensures complete lifecycle traceability. Directly, ALM offers significant value to a company, but ALM also enhances other enterprise systems, such as product lifecycle management (PLM), by enabling the sharing of product information across engineering disciplines.[2]

The different interpretations of application lifecycle management[3]
Application lifecycle management is interpreted differently by different ALM providers. Basically, it comprises the whole period in which an organization invests both time and money into a solution, from the needs of the stakeholders to the development of ideas, the definition of a business case, the planning and development of a solution right up to the preparation, implementation, service and discontinuation of the solution. The following disciplines or tasks come into effect:

  • Stakeholder identification, stakeholder analysis, and stakeholder communication
  • Idea management
  • Business case
  • Requirements engineering
  • Design, draft solutions and architecture, for example with mediums like SysML and UML
  • Project management – agile, classic, or hybrid
  • Resource management
  • Change management
  • Issue management
  • Configuration management
  • Version management
  • Code generation
  • Quality assurance and testing
  • Reporting
  • Build management, release management, and deployment
  • Customer support including maintenance and software maintenance
  • Benefits management i.e., solution evaluation
  • Discontinuation, if necessary, replacement through another solution

The structure for these disciplines and tasks forms project management, process optimization, and workflow management. For these disciplines and tasks, there are different ALM tools – from isolated solutions to integrated tools.

ALM is Different from SDLC[4]
ALM is much more than SDLC. Software Development Life Cycle (SDLC), as we all know is limited to the phases of software development, i.e. requirements, design, coding, testing, configuration, and project management. ALM, on the other hand, deals with a broader perspective of applications. It does not finish at the end of development, but when the application is no longer used by the business i.e. primarily many years after the initial development. To simplify, ALM is the superset that includes one or more SDLCs that may appear in the entire lifecycle.

The Need for an ALM Framework[5]
A conceptual framework explains, either graphically or in narrative form, the main things to be studied – the key factors, constructs, or variables – and the presumed relationship among them. In a conceptual framework, you put the concepts together as in a jigsaw puzzle. You work out how all the concepts fit together and relate to one another. The first stage of theorizing identifies and clarifies concepts; the second stage concentrates on the connections and relationships between the concepts. The ALM framework was used as an evolving insight into the concept of ALM to help with data collection, analysis, and documentation during the case studies. Second, the main result of the research process was a proposal for the ALM framework that was constructed and demonstrated iteratively during the series of case studies. The ALM framework provides the means for scientists and practitioners to understand the complexity of ALM from an ALM solutions perspective, i.e., what the principal elements of ALM are. In addition, according to our case experiences, the framework can be used to document, analyze and find improvement ideas for an organization’s ALM solution. The need for the ALM framework arose from the lack of clarity on document and analyzing the organization’s ALM solution.

The Three Aspects of ALM[6]
ALM can be divided into three distinct areas: governance, development, and operations (see figure below) The three aspects of ALM are tightly connected to one another. Doing all three well is a requirement for any organization that aspires to maximize the business value of custom software. But this isn’t an easy goal to achieve. Each of the three is challenging to get right on its own, so getting the combination right is even more challenging.

  • Governance: In ALM, the purpose of governance is to make sure the application always provides what the business needs. Governance is the only thing that extends throughout the entire ALM time span. In many ways, it’s the most important aspect of ALM. Get it wrong, and you won’t come close to maximizing the application’s business value.
  • Development: While equating ALM with the software development process isn’t accurate, development certainly is a fundamental part of every custom application’s lifecycle. Development occurs in the first part of an application’s lifecycle, then happens periodically as the application is updated.
  • Operations: Every deployed application must be monitored and managed. Operations begin shortly before an application is deployed, then continue until the application is removed from service.

Application Lifecycle Management (ALM)
source: David Chappell Associates

5 Benefits of ALM[7]

  • Agility — Through the collaboration and application of "just enough" processes
  • Predictability — Through better estimation, better communication, and more repeatable processes
  • Auditability — Traceability of work back to a business need, accountability for each change or decision made, and the ability to separate concerns
  • Quality — Through more-effective management of requirements, design, and quality processes
  • Productivity — Through the continuous improvement of processes and practices, and more effective utilization of resources

These benefits result in better control of costs and risks in development projects across the spectrum of applications that run the business, grow the business or transform the business.

11 steps that can help you achieve successful Application Lifecycle Management[8]

  1. Define the roles that should be part of the ALM. Define who is responsible for each role in information technology, software technology, quality assurance, software testing, the lines of business, and on the customer's side.
  2. Define the goals and objectives of each role. If this step isn't followed through, then the details of each role will not be understood and the question of "what do I do?" will never be clear. This step helps to avoid the "he-said/she said" and finger-pointing.
  3. Anticipate a certain amount of internal-process dependency. Outline and illustrate what work and which roles will depend upon your actions and deliverables. If this is not clearly documented, other people working on the project may assume that time is not important, or deliverables can be delayed or covered up if done incorrectly. A proper ALM process ensures that all levels of work are done correctly and follow quality standards.
  4. Develop a risk and contingency plan. Every role and each step in the process has the potential to make waves if something goes wrong. Make sure you think about how a missed deadline or objective could be rectified without a major disruption to the overall ALM process. If the risks are not understood from the beginning of the project, then you will be constantly working in a "ticking time bomb" environment. Problems affecting time, functionality, quality, outputs, security, performance, schedule, and cost can all add to the risk to the end product, the application, and the customers. Thus, it is always better to be proactive with a constructive, reusable lifecycle.
  5. Prepare a process. It is important that you outline a flowing pathway of communication and documentation. This is where the SDLC comes into play and defines how a company and/or department will operate.
  6. Foresee each individual's potential output. Understand the capabilities of each person on your team and set expectations accordingly.
  7. Plan … plan again … and plan some more! If you couldn't already tell, detailed planning is a must for ALM to be successful. Each role must be defined so that when a project is started each role's objectives, dependencies and needs are known.
  8. Know how communication affects your clients and other external stakeholders. When you interface with a client and that client expects something in return, how will you involve them in the process? Communication between you and your customers is crucial since the earlier your clients are involved the more they will feel a part of the process; they will be more likely to accept your thoughts and ideas.
  9. Set up quality assurance checkpoints to ensure your ALM process is working. This step is usually conducted by a quality analyst, whose job is to ensure that all processes are running like clockwork. (A quality analyst is not to be confused with a software tester whose role should have already been defined in step number one.) When a project is being run by a project manager, they often want to also manage ALM – but if this occurs it is difficult to provide good quality assurance since there is little or no opportunity for outside evaluation. Quality checkpoints by a quality analyst help create balance within the process.
  10. Work toward continual improvement. At the end of the first lifecycle attempt, it is QA's responsibility to delineate what went right and what went wrong in order to correct any bumps in the process. A "lessons learned" document should be prepared and presented to all of the key stakeholders, internally and externally, and discussion should ensue about how to improve the process for the next attempt. If not, then a process truly does not exist. This tends to happen if one person or team is "running the show" rather than a collective group.
  11. Provide governance. After a constructive baseline is set, all process changes must go through a formal procedure to ensure new rules and changes within the company's adoption of the ALM process. This is why step number nine (quality assurance checkpoints) is so important. QA monitors the processes that are put into place. Governance then works hand-in-hand with regulatory in-house and external audits for standards and assurance.

See Also

Application Performance Management (APM)
Application Portfolio Management (APM)


Further Reading