Select a strategic toolset

Define a tools strategy based on five criteria

Many organizations choose tools to automate aspects of the development and delivery process, based on a tactical, project-specific, need. This approach to tool selection is fraught with business challenges, such as the cost to maintain a disparate toolset; and technical challenges, such as the lack of integration between tools acquired in different parts of the organization. This article describes five key characteristics to consider when selecting a strategic toolset.


Peter Eeles (, Financial Services Sector Industry Lead, IBM Rational, IBM

Peter EelesPeter Eeles is the industry lead for the Financial Services Sector at IBM, where he helps organizations improve their ability to develop and deliver software. Peter offers in-depth knowledge of architecture-based initiatives such as Service Oriented Architecture (SOA) or strategic reuse. Previously, Peter served as the Chief IT Architect of the worldwide solution delivery organization at IBM Rational. He is a co-author of the books The Process of Software Architecting (2009), Building J2EE Applications with the Rational Unified Process (2002), and Building Business Objects (1998).

04 February 2014

Also available in Chinese Spanish


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.

Think "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
Various development disciplines with integrations

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
Business, development and operations disciplines

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
Integrating products from several vendors

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
The elements of a development environment

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.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Select a strategic toolset