Comprehensive software reviews to make better IT decisions
Justify Your Approach to Structuring Your ALM Environment
Teams want an open and integrated application lifecycle management (ALM) environment. Teams are now empowered to adopt the tools they need to address complexities and frequent changes while ensuring end-to-end artifact traceability. ALM vendors are positioning their products as open solutions with out-of-the-box integrations and marketplaces to allow teams to create a tightly integrated and flexible tool environment. However, given the wide landscape of delivery tools out there and preferential treatment some vendors give to each other, creating an integrated ALM environment with you preferred choice of tools may not be possible through your current vendors. ALM integration hubs provide out-of-the-box connections when product delivery tools do not.
As much as ALM vendors would like to advertise, there is no one vendor who offers comprehensive coverage for each software development lifecycle (SDLC) stage so every vendor relies on its integration capabilities to fill those gaps. Get a firm understanding of what you require from your ALM tools so that you can make an inform decision whether a comprehensive solution (e.g. Microsoft) or a functionally specific platform (e.g. Atlassian) is good enough to meet your needs.See our Choose the Right ALM Solutions to Manage Product Delivery note for more information.
It is common to see organizations adopt a certain ALM platform and having a mixed bag of third-party, proprietary, and open source tools that plug into this platform to enable end-to-end traceability and holistic visibility of release progress. However, you will have to integrate the various tools together and address each vendor separately which can be difficult to manage. The benefit is that it can give you the opportunity to be flexible to changing environments, empower your teams to select their own tools, and select specific tools that fit specific development needs rather than obtaining a comprehensive suite from a single vendor which may be overkill.
Much like any comprehensive development suite like Microsoft and IBM, you will be paying for features that you may or may not need. However, all of the features you do need come out of the box with these suites. Having a fragmented tooling environment gives you the opportunity to select specific tools to meet specific capabilities and allows you to focus your spending on only the tools that you need. However, as your development needs expand, the management of your ALM environment may become expensive which can require you to acquire hubs like Tasktop, OpsHub, and Kovair to manage the integration among your tools if the out-of-the-box plugins and customizable REST APIs are not provided by your current vendors.
- Holistically review your SDLC to identify what you need to deliver your products and changes from intake to deployment and maintenance. View your SDLC from people, process, and technology perspectives. See Info-Tech’s Modernize Your SDLC.
- Select and implement your ALM solutions. Review the ALM SoftwareReviews Category Reports to assist in your vendor selection and our Implement a Proactive and Consistent Vendor Selection Process blueprint for more information about procurement best practices (including RFP templates).
- Select the tools that are needed to supplement the gaps of your selected ALM solutions. Decide how to integrate your tools together whether that be using the integration features provided by your ALM solutions or using an ALM integration hub.
ALM solutions are leveraged as platforms to centrally enforce and monitor delivery processes and standards. Vendors are positioning themselves as open platforms by allowing integration with other delivery tools and ALM solutions with out-of-the-box plugins and REST APIs. However, the wide landscape of delivery tools and restricted vendor partnership agreements may make the integration of some tools difficult with vendor-provided integration features. ALM integration hubs help address these integration gaps.
Want to Know More?
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.
Aha! introduces scenario planning to give product owners the ability to create and compare multiple release approaches based on team capacity and backlog priority.