For my public sector clients whom I work with, I like to include the concept of application lifecycle management. ALM should be defined for the people involved in the project, i.e. supplying the application, the business that requires the application and the support folks caring and maintaining the solution. Get them all on the same page, so to speak of what ALM means for them. Secondly, processes used to support SDLC+Operations, are part of the overall support and solution to ALM. These processes improved with a tool such as JIRA, (other mentioned int he comments). One example per this public sector client is that they are using new software as services in a "low code" design and architecture. They are already using JIRA and some other Atlassian products to manage the development of the new applications. Thus in my role as an agile enterprise architect, I am helping them define their ALM goals and support and achieve these goals with tools such as JIRA, the SaaS platform. The project includes the transition from heavy code on legacy platforms to a new lighter and business-centric approach. ALM+Tools+SDLC has opened up new capabilities such as automation, agile, and DevOps ways of working, however, the mindset and awareness of using ALM and tools like JIRA to improve their SDLC are vital as it also opens up an improved help desk, release management and other operational support work. Your question requires more context to say yes to JIRA; however, I absolutely support an ALM approach using a modern toolset that supports agility, automation, monitoring, release management, ticketing and troubleshooting. Each of these is essential services that form the value stream of the business concept to an application in production. Thus the lifecycle of the value of an application and solution.
Search for a product comparison in Application Lifecycle Management (ALM) Suites
Director of Agile Development Solutions at a consultancy with 1,001-5,000 employees
MSP
Apr 14, 2020
Can you clarify what you mean by ALM? ALM typically stands for Agile Lifecycle Management and JIRA is one of many ALM tools on the market so I am not clear on what you are asking. You say your doing both software development and operations/production support so I assume you may be using Scrum and Kanban. In my experience JIRA is fine for small single team use and primarily for Scrum. You can use it for Kanban but if you are looking for the typical metrics we track with production/operations teams vs SDLC teams then JIRA may not be the right answer for your production teams. If you are just looking for the visibility offered by Kanban then JIRA may provide sufficient ability.
ALM is a good tool for SDLC management and Jira is the ideal tool for Agile and DevOps practices.
Usually, it is a combination of a good SDLC tool and an Agile/DevOps tool is that creates the best outcome for an organization.
My recent implementation of Jira with another SDLC tool (QMetry) at one of the government departments helped them adopt Agile/DevOps processes in a very cost-effective manner.
Depending on your needs I would recommend doing a thorough PoC with either tool and deciding on the right fit for your needs. Also, to keep in mind that ALM and Jira integration is not robust and requires additional tools/efforts to create end-to-end traceability.
Manager, Technology at a computer software company with 201-500 employees
MSP
Oct 25, 2021
If you start with Jira in the Atlassian cloud, your team will have access to both team-managed projects and company-managed projects.
Company managed projects usually have one of the following: * consolidated/shared set of schemes and entities * customized workflows (by Jira Administrators) that have conditions, validators, and/or post functions set.
Team-managed projects are independent projects where the team members determine the fields on the screens, the workflows, etc. These projects are limited to user-installed apps which can be utilized and do not have the full scope of standard entities available to the team.
Team-managed projects are a good way for various teams to work out the items that they want to have in their project and then migrate to company-managed projects when their customizations are available for company-managed projects. In Company managed projects, the project administrators can still alter the simple workflows which have not had conditions, validators, or post functions added by Jira administrators.
Since it is easy to create cloud instances, a company could create test instances for trying out specific items and then release them after the work has been adopted in their production instance or deemed to be discarded.
Atlassian provides several templates for various types of projects - projects could be created on text instances to determine which items are best for a team, department or for the entire company.
Basically, it depends on the requirement you have what is your end goal. If you have to manage only tasks like, current state or status, who is working on which task, then JIRA is enough.
If you want to manage the entire application lifecycle, like Code Management, CI/CD, and other capabilities then you use ALM tools like Gitlab, Azure DevOps, or a combination of the toolset to create you ALM setup.
Hi
It is depending on the case
If you using Agile as development framework
ALM octane is coverage in one single tool while JIRA need many integration [such as requirement: confluence, test: Zephyr, defect: core JIRA]
If you using Waterfall and focus on testing process, classic ALM is best suit on the solution
in other cases
1. if you don't want ot host the environment, JIRA and its integrations is better for on cloud.
2. if you have budget limit, may be JIRA is better choice. It's more cheaper
However, if you don't have budget constrain, ALM octane for Agile development and ALM classic for requirement and test management are the best choice.
Find out what your peers are saying about Atlassian, Microsoft, Nutanix and others in Application Lifecycle Management (ALM) Suites. Updated: December 2025.
A real ALM does not require a ticket/activity tracking in addition. A real ALM includes all you need to manage the demand, your activities, your (agile) projets, your code, your continuous integration, your continuous testing, your validation, the traceability, the collaboration, etc.. If it does not provide all this, it is not complete. If it requires many plugins to work... well, evaluate carefully.
Director, Pre-Sales and Architecture with 51-200 employees
Real User
Apr 15, 2020
I would recommend Jira, not ALM. ALM is big, very hard to implement, costly and at the end of its life (hence being now supported by Micro Focus). If I were to start from scratch, I would pick a cloud solution like Azure DevOps or GitLab, even if you don't do cloud-based applications. These are the two we use ourselves.
We use both simply because historically our Java dev teams were all Git and our .Net dev teams were using MS Team Foundation Services (TFS). Our pipeline also integrates our own test platform Askida CT for all testing except unit tests. Jira remains our Agile comms tool because it has been integrated into our ERP for billing (we use the Tempo plug-in).
So when counseling our clients, the choice we recommend is based on what they already know, the expertise of their dev team and the technologies their products use.
My own preference is Azure because of the breadth of tools well-integrated services.
CEO at a program development consultancy with 11-50 employees
User
Apr 14, 2020
Neither – nor, to manage SDLC I prefer MS Project to have fully integrated toolbox incl. controlling EVM day by day, multiple(!!!) resources per task, dynamic cycles for agile sprints, all based on a unique vector-net-plan algorithm with force & back simulation, multiple critical chains, etc. etc. others are dreaming of.
You can always use JIRA with an alternate tool. The point is whether it is efficient or not for you case. Though in my experience most integrated agile development tools replace Jira and are more efficient, especially when dealing with code (in addition to just managing activities and tasks). Steven proposed one; I propose to give a try to Tuleap.
ALM - Application Lifecycle Management -
Micro Focus has two ALM solutions,
ALM .Net is for traditional waterfall software efforts
ALM Octane is for Agile software efforts.
I would recommend the use of Micro Focus ALM Octane for any Agile, DevSecOps projects. ALM Octane can integrate with many open source and third-party solutions, out of the box. Octane gives your organization a Single Pane of glass to monitor and manage the entire SDLC!
Application Lifecycle Management (ALM) Suites streamline the software development process by integrating project management, development, and quality assurance tools in a single platform.Many organizations leverage ALM Suites to ensure a consistent and efficient development cycle from conception to deployment. These suites offer comprehensive solutions for tracking requirements, code changes, testing processes, and team collaboration. By providing real-time analytics and reporting, they...
For my public sector clients whom I work with, I like to include the concept of application lifecycle management. ALM should be defined for the people involved in the project, i.e. supplying the application, the business that requires the application and the support folks caring and maintaining the solution. Get them all on the same page, so to speak of what ALM means for them. Secondly, processes used to support SDLC+Operations, are part of the overall support and solution to ALM. These processes improved with a tool such as JIRA, (other mentioned int he comments). One example per this public sector client is that they are using new software as services in a "low code" design and architecture. They are already using JIRA and some other Atlassian products to manage the development of the new applications. Thus in my role as an agile enterprise architect, I am helping them define their ALM goals and support and achieve these goals with tools such as JIRA, the SaaS platform. The project includes the transition from heavy code on legacy platforms to a new lighter and business-centric approach. ALM+Tools+SDLC has opened up new capabilities such as automation, agile, and DevOps ways of working, however, the mindset and awareness of using ALM and tools like JIRA to improve their SDLC are vital as it also opens up an improved help desk, release management and other operational support work. Your question requires more context to say yes to JIRA; however, I absolutely support an ALM approach using a modern toolset that supports agility, automation, monitoring, release management, ticketing and troubleshooting. Each of these is essential services that form the value stream of the business concept to an application in production. Thus the lifecycle of the value of an application and solution.
Can you clarify what you mean by ALM? ALM typically stands for Agile Lifecycle Management and JIRA is one of many ALM tools on the market so I am not clear on what you are asking. You say your doing both software development and operations/production support so I assume you may be using Scrum and Kanban. In my experience JIRA is fine for small single team use and primarily for Scrum. You can use it for Kanban but if you are looking for the typical metrics we track with production/operations teams vs SDLC teams then JIRA may not be the right answer for your production teams. If you are just looking for the visibility offered by Kanban then JIRA may provide sufficient ability.
Hi Therese,
ALM is a good tool for SDLC management and Jira is the ideal tool for Agile and DevOps practices.
Usually, it is a combination of a good SDLC tool and an Agile/DevOps tool is that creates the best outcome for an organization.
My recent implementation of Jira with another SDLC tool (QMetry) at one of the government departments helped them adopt Agile/DevOps processes in a very cost-effective manner.
Depending on your needs I would recommend doing a thorough PoC with either tool and deciding on the right fit for your needs. Also, to keep in mind that ALM and Jira integration is not robust and requires additional tools/efforts to create end-to-end traceability.
Hope this helps!
If you start with Jira in the Atlassian cloud, your team will have access to both team-managed projects and company-managed projects.
Company managed projects usually have one of the following:
* consolidated/shared set of schemes and entities
* customized workflows (by Jira Administrators) that have conditions, validators, and/or post functions set.
Team-managed projects are independent projects where the team members determine the fields on the screens, the workflows, etc. These projects are limited to user-installed apps which can be utilized and do not have the full scope of standard entities available to the team.
Team-managed projects are a good way for various teams to work out the items that they want to have in their project and then migrate to company-managed projects when their customizations are available for company-managed projects. In Company managed projects, the project administrators can still alter the simple workflows which have not had conditions, validators, or post functions added by Jira administrators.
Since it is easy to create cloud instances, a company could create test instances for trying out specific items and then release them after the work has been adopted in their production instance or deemed to be discarded.
Atlassian provides several templates for various types of projects - projects could be created on text instances to determine which items are best for a team, department or for the entire company.
HI Therese Divita
I use both.
Basically, it depends on the requirement you have what is your end goal. If you have to manage only tasks like, current state or status, who is working on which task, then JIRA is enough.
If you want to manage the entire application lifecycle, like Code Management, CI/CD, and other capabilities then you use ALM tools like Gitlab, Azure DevOps, or a combination of the toolset to create you ALM setup.
Hi
It is depending on the case
If you using Agile as development framework
ALM octane is coverage in one single tool while JIRA need many integration [such as requirement: confluence, test: Zephyr, defect: core JIRA]
If you using Waterfall and focus on testing process, classic ALM is best suit on the solution
in other cases
1. if you don't want ot host the environment, JIRA and its integrations is better for on cloud.
2. if you have budget limit, may be JIRA is better choice. It's more cheaper
However, if you don't have budget constrain, ALM octane for Agile development and ALM classic for requirement and test management are the best choice.
A real ALM does not require a ticket/activity tracking in addition. A real ALM includes all you need to manage the demand, your activities, your (agile) projets, your code, your continuous integration, your continuous testing, your validation, the traceability, the collaboration, etc.. If it does not provide all this, it is not complete. If it requires many plugins to work... well, evaluate carefully.
I would recommend Jira, not ALM. ALM is big, very hard to implement, costly and at the end of its life (hence being now supported by Micro Focus). If I were to start from scratch, I would pick a cloud solution like Azure DevOps or GitLab, even if you don't do cloud-based applications. These are the two we use ourselves.
We use both simply because historically our Java dev teams were all Git and our .Net dev teams were using MS Team Foundation Services (TFS). Our pipeline also integrates our own test platform Askida CT for all testing except unit tests. Jira remains our Agile comms tool because it has been integrated into our ERP for billing (we use the Tempo plug-in).
So when counseling our clients, the choice we recommend is based on what they already know, the expertise of their dev team and the technologies their products use.
My own preference is Azure because of the breadth of tools well-integrated services.
Neither – nor, to manage SDLC I prefer MS Project to have fully integrated toolbox incl. controlling EVM day by day, multiple(!!!) resources per task, dynamic cycles for agile sprints, all based on a unique vector-net-plan algorithm with force & back simulation, multiple critical chains, etc. etc. others are dreaming of.
You can always use JIRA with an alternate tool. The point is whether it is efficient or not for you case. Though in my experience most integrated agile development tools replace Jira and are more efficient, especially when dealing with code (in addition to just managing activities and tasks). Steven proposed one; I propose to give a try to Tuleap.
I would recommend both of them, JIRA for Agile/non-agile projects/requests tracking. and ALM for Testing/Staging and Production stages,
Both and you can replace them by only azure devops as a project management ,bug tracking,testcase management and devops
ALM - Application Lifecycle Management -
Micro Focus has two ALM solutions,
ALM .Net is for traditional waterfall software efforts
ALM Octane is for Agile software efforts.
I would recommend the use of Micro Focus ALM Octane for any Agile, DevSecOps projects. ALM Octane can integrate with many open source and third-party solutions, out of the box. Octane gives your organization a Single Pane of glass to monitor and manage the entire SDLC!