Capabilities vs Solutions

On our “About” page, we claim to focus on delivering capabilities over solutions, and I’d like to take a minute to clarify this distinction.

A solution is just anything that solves a problem. For any technical problem, there are hundreds of possible solutions—and at least a dozen workable ones—but workable solutions are incomplete because they still require work and require you to think in the context of that problem.

The most important feature of a capability is that once you have it, the issue it addresses is no longer a challenge, and this frees you to view the world differently. As Douglas Adams put it:

The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why, and Where phases. For instance, the first phase is characterized by the question ‘How can we eat?’ the second by the question ‘Why do we eat?’ and the third by the question ‘Where shall we have lunch?’

The “why” phase is where the solution matures into a capability, and once you reach the “where” phase, you can take the earlier parts for granted to some extent. Here, higher-level problems of sociality supersede the problem of hunger. In DevOps, supporting developer experience and improving scalability and reliability replace the more straightforward work of building, testing, and deployment.

If you are a company that develops software, how you build, test, deploy, and operate it is critical to the success of your business, but none of these are likely to be a core part of your value proposition. Once these become capabilities, they only require maintenance, and your DevOps engineers can focus on other problems you certainly have: cost control, expanding to other regions, regulatory compliance, etc. Building on the foundations of the existing platform, these, too, can become capabilities. This iterative process is the true secret to running lean IT.