The following scenario is typical in organizations where decision makers choose tools based on an immediate tactical need:
We're going to deploy the Acme Inc. configuration management tool because one of our flagship projects desperately needs to address some immediate issues with version control. Although there are more comprehensive tools on the market, the Acme product is cheaper and it will perform the job. By morning, the problem will be solved.
Although this approach satisfies a short-term need, it often leads organizations to amass tools that overlap in capability, that fail to integrate, and that place a burden on the IT department to maintain, as new tool versions become available.
This article highlights five themes to help you select a strategic toolset, rather than a collection of tools that present challenges such as overlapping functionality or lack of integration.
IT professionals use tools to automate manual processes at various points within a typical software supply chain. Tools might be business-relevant (such as enterprise architecture and portfolio management tools), development-relevant (such as requirements management, design management, coding and test management tools) and operations-relevant (such as release management and monitoring tools).
Typically, teams select a toolset according to criteria such as the features available, the platforms supported, the ability to address scalability and security, and the flexibility to support different development lifecycle approaches; for example, waterfall, iterative, agile development, and disciplined agile development. However, when different departments in an organization choose the tools they need and do not consider the bigger picture, silos of capability develop. It becomes inefficient or impossible to transfer tools and work between departments. Although individual tools can add value, consider the possibility that an integrated toolset offers more value.
Consider the tool integrations shown in Figure 1. The integration between test management and requirements management can make it possible to link a test case to a requirement. This information can be used to determine the level of test coverage against the defined requirements and can help identify a need for additional resources if the coverage is less than adequate.
Figure 1. Integration examples
Another example is the integration between design management and configuration and change management, where designs are version-controlled in the configuration and change management solution. A large number of design changes can indicate areas of instability in the designs and can highlight the need to focus on these areas accordingly.
An integrated, strategic toolset can provide a level of visibility and transparency of project progress, and can lay the foundation for an effective approach to governance. In many cases, the ability to report management information is enabled through an integrated toolset.
Many organizations also view the toolset as the key component of an integrated supply chain, as shown in Figure 2. This view has become commonplace given the increased interest in agile development, DevOps (the processes that link development and operations tasks), and continuous delivery.
Figure 2. An integrated supply chain
An integrated supply chain is an effective way to look at the landscape, because it reveals two gaps that are often present:
- The gap between the business and IT (the business-IT gap). To address this gap, look at the following areas:
- Consider the integration between "above project" tools (such as those used to support enterprise architecture and portfolio management) and "project-specific" tools such as those used to support requirements management and design management.
- Consider the use of agile methods (where, for example, an IT project includes a business representative directly in project development) and the associated tools that provide support for agile development, in addition to traditional development lifecycle approaches.
- The gap between development and operations (the IT-IT gap). To address this gap, look at typical DevOps solutions, such as processes and tools to support continuous testing, continuous release, and continuous monitoring and optimization.
This supply chain thinking and the implied integrations can support strategic decision-making. For example, an organization in a regulated environment (such as those in the financial or pharmaceuticals sectors) needs to determine the effect of a new mandate. To determine the cost of the changes required by the mandate and to take appropriate action, the organization needs to look at the links between the current requirements, the designs derived from these requirements, the codebase derived from the designs and so on, all the way through the supply chain.
Without ready access to this information, the organization has to rely on some form of "software archaeology" to manually search documents and other data sources, and to interview practitioners who might have insight. An integrated view of the toolset makes it easy to trace requirements to the elements that implement them and ensures that IT is aligned with product strategy, portfolio decisions, and enterprise architecture principles and standards.
Recognize that heterogeneity is the norm
In most cases, the tools environment used in day-to-day work is heterogeneous – a suite of tools from several different vendors. For example, the tools for word processing, spreadsheets, presentations, email, web browsing, and other purposes typically come from a variety of vendors.
The situation is similar for the integrated development tools environment. Typically, these environments consist of tools from many different vendors. Figure 3 illustrates products from six different vendors (A, B, C, D, E, and R).
Figure 3. A heterogeneous environment
When you select a strategic toolset, remember to consider the tools and the integrations available. If you have to build or buy missing integrations, the cost of the overall strategic tools architecture can increase substantially.
Open platforms and standards foster an ecosystem in which IBM products, partner products, open source products, and products from other vendors can work harmoniously. The Jazz platform, an integration platform for software development tools, transforms software and systems delivery and makes it more collaborative, productive, and transparent, through integration of information and tasks across the phases of the lifecycle. Another example is the Open Service for Lifecycle Collaboration (OSLC) standard, which provides specifications to integrate tools from different vendors.
Consider the total cost of ownership
When you select a strategic toolset, remember that the successful introduction of any toolset goes beyond the cost of the tools. Consider this simple example: a team decides to use an open source tool because the cost of purchase, when compared with commercial tools, is negligible. Or is it?
Although some open source tools are quite excellent, others require additional investment that is not immediately obvious. Several elements, in addition to initial purchase costs, affect the total cost of ownership.
The framework shown in Figure 4 provides a comprehensive view of a development environment. The developerWorks article Define the scope of your development environment includes more details.
Figure 4. Development environment definition
This framework considers six key elements of a development environment: method, tools, infrastructure, organization, enablement, and adoption. Each element adds cost to the total cost of ownership.
For example, in addition to the cost of any tools, consider the cost of the following tasks:
- Create method content.
- Configure the tools to accommodate the defined method.
- Provision the infrastructure required by the tools.
- Perform any data migration from an existing toolset.
- Create and provision enablement (training and mentoring).
- Provide resources to act as the first-level support for the development environment.
Look for a transformation partner, not simply a technology provider
When you acquire a tool, you enter into a relationship with the vendor. For example, you are dependent on the vendor's support channels and dependent on any product fix packs and future releases.
When you make strategic tool decisions, think of the tool vendor as a transformation partner, rather than only a technology provider. You are, in essence, choosing both a tool and a vendor.
Consider whether the vendor organization is solvent and stable. Does it have a global presence with local support? Does it have an active user community? Does it provide a developer network?
Other areas to consider are less obvious. Does the vendor provide you with a toolset and leave you to implement it, or do they also have a services organization that can accelerate the time-to-value from the investment made in tools? Do they have proven frameworks and approaches to help you transform your capabilities? Do they emphasize how to make the change meaningful to practitioners? Do they have the case studies and references that you expect?
Take a value-driven approach
The cost to acquire a strategic toolset has to be balanced against the value to be gained. The cost and value contribute to the return-on-investment element of a business case for any investment in tools.
At the highest level, value statements are often aligned with faster, cheaper, better objectives, such as improved practitioner productivity (faster), reduced development cost (cheaper) and higher quality solutions (better). However, the adoption of any toolset can stall if some simple elements are not in place. A simple framework that focuses on these elements is provided by John Kotter, in his book Leading Change. Two of the steps in the Kotter framework are directly focused on value.
The first step is to establish a sense of urgency (in this case, an urgency to invest in tools). Make it clear that when the organization addresses the urgency, it receives tangible business value. Any compelling reason to act often comes about as the result of a crisis, potential crisis, or significant opportunity. The goal is to remove the complacency of the organization to stay with the current state of things. Most organizational change initiatives fail at this step and the adoption of a strategic toolset is no different.
The second value-focused step is to generate short-term wins. Belief in a vision does not last forever; evidence that the introduction of a strategic toolset delivers tangible results is the only way to ensure that people stay committed to make the changes.
Deploy changes to capabilities in incremental stages. Each increment adds value and can be implemented in a reasonable amount of time. Plan to deploy incremental changes according to the priorities of the organization and the value to be gained.
When you choose a strategic toolset, apply the five themes described in this article. If you consider all these factors, your tool selection is more likely to result in a fit-for-purpose environment that maintains its strategic value in the long term.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, anytime, and many of the Getting Started ones are free.
Get products and technologies
- Download a free trial version of Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, or use it in a cloud environment.
- Check the Rational software forums to ask questions and participate in discussions.
- Get connected with your peers and keep up on the latest information in the Rational community.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.