Seven Reasons You Need a Data-Driven Approach to Application Lifecycle Management
Info-Tech has reviewed the application lifecycle management (ALM) toolsets of more than 100 organizations in the recent update to our ALM Vendor Landscape. We found over 50 financial services organizations had changed how they use their ALM toolset dramatically. Once upon a time, application delivery leaders would have implemented a single ALM solution to drive local efficiencies in stages of the lifecycle. Today financial services organizations are on the leading edge of efforts to integrate and automate a data-driven ALM toolchain from ideation to operational support.
An integrated toolchain ensures business and application development leaders have the insights they need to ensure:
- The applications they build and maintain deliver the value the business expects.
- Each step of the software delivery lifecycle can be measured and improved.
- There are no gaps in the applications they develop.
- Frequent changes in regulations, requirements, and design are easy to manage.
- They can audit-proof compliance with regulations and policy.
The greatest challenge organizations face in achieving these goals is a cultural shift from a waterfall, document, and project-driven approach to application development. Organizations have begun embracing an adaptive or iterative, data-driven, product-based approach to application development to drive throughput.
The Code Is Not the Only Source of Truth
Undisciplined and project-based Agile implementations have also presented a cultural challenge. Their focus on development has resulted in lost knowledge of the whole product. Requirements, design, and development decisions driven by business goals are essential to maintain, support, and enhance applications. This loss of insight has resulted in “some of the biggest project failures” the Boston Consulting Group has seen. Info-Tech’s research also found these failures have cost CIOs their jobs, particularly on legacy replacement projects. A majority of the organizations we studied have selected or already implemented one or more ALM tools as a central repository to avoid these challenges.
MS Office Is Losing Ground As the #1 ALM Tool
We looked across the main use cases in the ALM toolchain, namely:
- Portfolio and Project Management
- Requirements, Analysis, and Design
- Development Work Management
- Test Execution and Management
- Build and Deploy
- Incident Management
And we found that Microsoft Office (including Microsoft Project and Visio) is still the primary tool more than 50% of the time. However, MS Office may be the default tool of choice simply because it is on everybody’s computer. Office is also an increasing cause of frustration and inefficiency. Software engineers became so frustrated they founded a political party in Switzerland whose sole goal is to eliminate PowerPoint. Critical activities such as traceability, automation, and change management are effort intensive in Office tools. Organizations of all sizes have selected and implemented one or more ALM tools in the past five years as a result.
You Need to Stop Using Word as an ALM Tool Right Now!
The use of Word for project documents is rampant. It is also the greatest barrier to an end-to-end, data-driven ALM lifecycle. Our research has shown that the massive, manual conversions required cost several times the price of implementing an ALM tool. You cannot measure, trace, or use content in Word systematically as well. Make a break. Organizations that have shifted to Excel-based documentation have found it is easier to manage traceability, ensure completeness, and measure practices and projects when they decompose their ALM artifacts into a standard structure in Excel. Tools like SharePoint and PowerPivot also give you the ability to manage and report on your project and product content. Excel-based documentation is also much easier to migrate into an ALM if you decide to implement a tool.
Development Work Management Tools Have Expanded Into Portfolio and Project Management
The shift to product-based methods such as Agile and Lean has seen an explosion of tools such as Jira, CA Agile Central (formerly Rally), and VersionOne for development work management. The feature sets that support backlog and burndown management have also proven useful for program management. This has led to the branding of Agile lifecycle management as a critical capability by key vendors such Collabnet, IBM, Atlassian, CA, and Microsoft. The workflow and task management capabilities of these tools are the most used features. The shift from project-based to product-based delivery has also highlighted that these tools do not have the version control, traceability, design, and automation features to manage a product holistically from ideation to implementation. As a result, integrations between these tools and requirements, analysis, and design (RAD) tools is a critical step.
The Requirements, Analysis, and Design Management Tool Market Is Exploding
Virtually every organization we explored has implemented or is selecting one or more tools to support requirements, analysis, and design. For example, two organizations we explored implemented Blueprint for requirements, business process, and use-case analysis and then integrated it with iRise for simulations. Financial services and other highly regulated industries have made the investment to:
- Audit-proof their organizations through end-to-end traceability across the lifecycle.
- Visualize requirements with built-in modeling features
- Automate manual activities such as test case, acceptance criteria, and user story generation.
A key driver is also the increasing maturity of product management discipline. Tools that support visualization and management of complex relationships artifacts such as capability models, stakeholder context, process, and detailed design across a whole product support the move away from project-based delivery to true enterprise product-based delivery and management. Over two-thirds of the organizations we studied have implemented a RAD tool over the past three years.
Customers Only Use the Core Capabilities of Swiss-Army-Knife ALMs
HP QC had the most significant implementation base in the organizations we studied. Its breadth of capabilities led HP to rebrand HP QC as a full-lifecycle support tool, HP ALM, in 2011. However, customers use features such as ALM’s requirements module solely for requirements traceability to tests, not requirements analysis and management. Many organizations continue to use Word and Excel to document requirements and then manually copy them into HP ALM. Usability and limited features outside the core testing capability were the main reasons identified. Customers are looking elsewhere for more fully featured solutions to manage other aspects of the application lifecycle. Every HP ALM shop reported using one or more complementary ALM tools as well.
Getting Users to Adopt the Tool Is the Key Challenge
Office is still on everyone’s desktop and most of the participants and stakeholders in your ALM lifecycle are completely comfortable with it. Over 40% of the financial services organizations studied have implemented enterprise-wide toolchains. While IAG found that tools could provide value, that value was only significant when organizations invested in people and practice maturity as well. The organizations we studied have made significant investments in ALM process and practice development and education to drive adoption of the toolchain as a result. Vendors are increasingly being engaged to develop people, process, and adoption programs for clients, and not just implement a tool.
Recommendations
Take small steps to move from your current practice to one or more ALM tools:
- Assess the whole SDLC to identify where a tool might provide the greatest benefit.
- Consider culture, people, and process before you dive into tools.
- Create structure with a data model and glossary for the artifacts that support your vision.
- Shift your documentation practices from Word and PowerPoint to Excel to support metrics, governance, and migration.
- Select and implement a tool based on the lessons learned from this approach.
Bottom Line
It will be a significant investment in time, effort, and money to implement one or more ALM tools. You must consider all aspects of your ALM and SDLC practices to be successful. The impact on each IT discipline and how they work together is critical, particularly when if you are changing to methods such as Agile and DevOps. With all of the hype today, it is tempting to leap into a tool-driven DevOps and Agile method. A disciplined approach that starts with people and then process is required to shift from a document to a data-driven ALM practice supported by a tool.
Want to Know More?
Create a Horizontally Optimized SDLC to Better Meet Business Demands
Build a Strong Approach to Business Requirements Gathering
Implement Agile Practices That Work
Structure Your DevOps Adoption Using a Metrics-Driven Approach