Understanding tools strategy in a devops world

The recent explosion of software delivery tools needs to be paired with a discipline for managing them

Tools on wood table
Thinkstock

Tools play a pivotal role in the creation of any product, whether it’s a consumer good built through a manufacturing process or an app developed through a software delivery life cycle. The tools you use to build and create our products shape the overall value that they deliver to customers. In fact, the evolution of all product-development disciplines is marked by the introduction of new tools and practices for using them effectively.  

For traditional retail products, inventions like the assembly line and automation have transformed the development process. But those inventions were not in themselves enough. The technology needed to be paired with discipline like Lean to realize true value. Lean introduced a number of important techniques that allowed people and their processes to align with the new technology, techniques like the 5S methodology, which creates a visual workplace that is invariably safer and more efficient.  

Clearly tools and the practices around their use are a critical part of any product delivery supply chain, and software products are no exception. 

There is an explosion of digital tools that help you design, build, and deliver software products. Dozens of functional categories have emerged or crystalized over just the last five years in areas like issue tracking, application performance management, monitoring, logging, release engineering, QA/test, and security. Some of the factors that are influencing the growth follow.

SaaS

The effectiveness of SaaS in hands of startups has impacted this category of application just like every other category of business tools. Cloud platforms provides the conduit for disrupting the heavyweight enterprise applications. Categories that were previously dominated by large vendors like IBM and CA are being deconstructed and disrupted by SaaS startups. A tool backed by Series A funding and 50 engineers is now a serious contender to replace pieces of IBM’s Rational suite or HP’s test management curmudgeons.

Specialization

As you get more clarity about the boundaries of each process involved in software development, you can create role specializations and purpose-built tools for them. As an industry, we have been decomposing our technical problems into pieces we can solve through software tools. The result is a wider spectrum of shallow tool categories, rather than heavy and deep catch-all tools.

Commoditization

The universal need for software delivery in every industry means there is an active market for commercially supported tools that previously did not have enough demand to sustain a business. In the past an organization may have simply suffered by building and maintained their own tools, contributed to feature-lacking open source projects, or, most commonly, simply compensated for the lack of good tooling by using manual process and procedure. But now there is now a broad enough market to commercialize and monetize every tool category that you can dream up.  

While this market saturation has many upsides, the growth has been met with a lack of maturity in the methodologies of these tools are used and deployed. We haven’t quite developed the maturity of practices needed to support them. Key aspects that need to be anticipated and accounted for:  

  • Tools store organizational knowledge: Issue tracking tools like Atlassian Jira and ServiceNow have become the ivory towers of cognitive work. They are the sanctified assemblage of information, recording everything about what is going on in the business. The artifacts of those tools—plans, epics, stories, and issues—form islands on the uncharted maps of our knowledge. These artifacts have replaced documents as the primary means of capturing information, yet they often live in neglect or isolation. While each department within organizations to build their own collection of process and knowledge, there is little thinking about how to connect them with everything else.
  • Tools guide process: Tools have become proxies for process. We capture our workflows and management methodologies in purpose-built applications that guide and facilitate our actions. This has strong implications for how you run your business—achieving flow across processes in a life cycle means you need to think about where and how you use our tools to facilitate change, what level of rigor you should use for capturing processes and their states in our tools, and how you can connect the processes that are captured in separate tools.
  • Tools generate information: Each application you use creates a sustained stream of information about its life cycle, which is useful at various other stages and in overall business reporting. But only if it can be captured; data needs to be actively collected and reported back to other processes and people to be made useful. So what information is important? What metrics do you need to collect information on? The software industry is still at odds with itself about how to track success—should we look at manufacturing metrics like cycle time and lead time, or do we need to invent a new framework that takes into account the peculiarities of cognitive-creative work? This is all currently unsettled and up in the air. 

The result of all this is that is technical organizations need to think carefully about how they approach their tools strategy. High-performing organizations need to study and even fund new research in the emerging delivery disciplines, expanding on agile and devops to meet the meet the depth and breadth of the same supply chain and value stream analysis that has been led in other disciplines.

The practice of Lean opened the world’s eyes to using systems thinking to guide decisions about seemingly low or local impact decisions about how to use and deploy tools. Such decisions are just as easy to ignore in software, but even more serious, because we don’t just rely tools to get work done—tools are the argosies of information needed for us to function at all.

Cognitive organizations rely on tools for much more: to guide you, inform you, and shape your understanding. The next stage in software delivery maturity is therefore to develop our own “Lean” for the software supply chain to generate strategies and disciplines that will help contain the explosion of tools, vendors, services, and technologies that are already revolutionizing the way we all work and bring system-level discipline across the software delivery supply chain.

This article is published as part of the IDG Contributor Network. Want to Join?