Where is ALM in the modern development?

Application Lifecycle Management (ALM) is a framework to manage the whole application’s lifecycle from ideas and concepts, through development, to maintenance and retirement. Traditionally, ALM consists of several separate disciplines like product management, requirements management, software development and configuration management, test and quality management, release and deployment management, variants management, etc. Usually, ALM is a synonymous for a tool or several integrated tools. Integrated toolsets are crucial to achieve effective ALM and support a variety of processes and compliances, but tools are not enough without processes, methods and people, so ALM is much more than just a tool.

What is an appropriate and effective ALM toolset depends on the industry you belong to, regulations and compliances you must fulfill. It could be quite simple and integrated into your software and configuration systems, but on the other side could be very formal and complex for regulated industries like automotive, aerospace and defense, pharmacy, or medical devices. The most important thing to understand is that no matter how you develop your software or systems, ALM is always present.

Software development continuously changes introducing new technologies, practices and tools, which challenge ALM toolsets as well, to keep up and continuously improve. Expectations for modern ALM system is to be modular, adaptable, and extendable platform, to integrate a set of tools to behave as one single system. It is quite normal today that ALM systems support Agile approaches, integrate and use the most popular software configuration and CI/CD tools on the market, integrate popular and domain-specific tools, integrate with test automation tools, and support system development by V-Model considering regulations and compliances.

So far, it is clear, that ALMs are complex systems that must fulfill numerous requirements and functionalities. With continuous improvements, the list of functionalities is constantly increasing, as well as challenges, but some challenges are always present in enterprises, especially in the regulatory industry. In the following, we will focus on exactly those challenges.

Tools usually provide traceability between planning tasks and defects, and code changes. It is supported usually by linking issues to change sets, commits, or merge requests in software configuration. But sometimes, there is a need to trace and control changes in requirements and test cases and then track what changes across disciplines are involved in each delivery.

As a basic traceability we consider:

• links within requirements and design hierarchy, where downstream artifacts link upstream artifacts
• links from tests to requirements

The next level required by compliance is to link requirements to code changes implementing them, and tests to code changes validated by them. Besides, there is a need for impact analyses, whenever an artifact in the system is changed, there should be a warning on dependent artifacts.

In the practice, it is hardly possible that only one tool or system, from one vendor, satisfies all your needs and requirement. There are plenty of reasons for it like legacy tools, company-preferred tools, custom-developed internal tools, and industry-specific tools. Usually, companies invest a lot of effort in software configuration tools, CI/CD solutions and test automation tools, it is mandatory to integrate those tools and replacement is usually not an option. Finally, you would need an ALM system as the single source of truth, so tools should be properly integrated and synchronized.

To achieve an integrated and synchronized system we will probably need to extend the tools and provide automation to synchronize data, e.g., running tests in pipelines could require applying results back to the ALM system to keep it as a single source. Besides, there is often a need for automatic analysis, calculation and update data, e.g. calculating risk assessments, analysis and updating depending on artifacts in the hierarchy.

Systems usually consist of several subsystems. Variants of the system usually reuse those subsystems but even project specific variants of the subsystems. In the end it is quite complicated to track dependencies without tool support. ALM system has to support building systems, reuse subsystems to reduce efforts, manage and track variance and especially be able to track the impact of changes and defects to system variants, e.g. whenever a defect occurs, it is crucial to find out what else variants of subsystems and what systems are affected by the defect.

Companies are often forced by compliance to export data and data dependencies in meaningful documents. It is a quite challenging task when there is a set of tools and there is no sufficient and single data source. When you configure tools, processes, and integrations, it considers that everything that comes in must go out of tools. There are several solutions to achieve common reporting, but with different efficiency.

• Custom application or extension to fetch data and generate a document
• Extending the default reporting solution by adding additional logic to get the document
• Export all required data from the system and use other solutions
• Completely custom DWH and BI solutions that give you full reporting flexibility across integrated systems.

Regulations usually require keeping data for a specific and dedicated amount of time (usually longer than one decade) and being able to restore the data in 24 hours on demand. Tools and platforms evaluate and change over time, which makes it complicated to keep them in sync for so long time. A recommendation is if possible, to keep historical data in the old system and migrate and evaluate only the most recent data. To avoid long-term issues by defining processes and configuring tools, always consider how to migrate, export and import data in the future.

There are plenty of ALM solutions available on the market, which makes selecting the right tool even more complicated. The first step to selecting the proper tool should be an evaluation of current processes and ways of working, especially the reason why is it like that. The common issue is that current processes are driven by legacy processes and tools and could be improved. The following step should be tool evaluation and piloting, do not hesitate to test your improved process in the tools and get feedback. A very common mistake is to expect that everything stays as is and that the new tool will fulfill only existing gaps. Switching and introducing new tools always change usage, and you must adapt yourself to it, changes should always be acceptable until they lead to improvement and better efficiency.

Each tool and each process changes over time, the evolution is expected and normal. During evaluation and piloting, test and consider how will you maintain your systems in the future and consider that you will export and import those data again in the future.

CROZ as consulting company has years of experience in process improvements and tools implementations, with a special focus on software development and DevOps practices, business intelligence, Agile transformation, quality assurance and ALM. For years, Croz experts lead and participate in projects adopting ALM tools and processes across the EU and region, especially in Germany, UK and Denmark. We participated and built our experience and knowledge in many projects mostly for the automotive industry, aerospace and defense, medical devices, telecommunications, and financial sector, by satisfying complex compliance and regulations like Automotive Spice, FDA and GAMP5.

As IBM Platinum Business Partner, we are experts for IBM ELM (Engineering Lifecycle Management), supporting processes and methods on DOORS, DOORS Next Generation, EWM (Engineering Workflow Management), Global Configuration and ETM (Engineering Test Management). It is very important to mention our achievements in system integration and custom reporting. CROZ developed a BI solution for ELM which can capture data from ELM, DOORS and other integrated systems in dedicated DWH and provide common reporting, aligned to regulations.

Besides our IBM experience, we support our customers to use other ALM solutions, as well. We extend our competence with Atlassian tools stack, Jira and Confluence, integrated with Xray and Zephyr Test Management tools and Tricentis Tosca. Our common approach is to introduce agile and DevOps practices as much as possible, especially to integrate ALM systems with CI/CD pipelines.

As a development and consulting company we continuously improve ourselves and search for new ideas and better solutions to improve processes, quality, and efficiency for our customers and us.