Fogbeam Labs The FogBlog

If you have not yet heard of "Capability Cases" and you are in the software business, run, don't walk, to capabilitycases.org or your favourite on-line / physical book retailer and pick up the book "Capability Cases: A Solution Envisioning Approach" by Irene Polikoff, Robert Coyne and Ralph Hodgson. Capability Cases are a must for any professional involved in defining, proposing, building, selling or creating software systems in 2013.

"Why", you might ask, "are Capability Cases so bloody important, and if they were actually all that, why haven't I heard of them before"? Glad you asked. In short, Capability Cases solve the problem of bridging between the worlds of the hardcore technologist - who appreciates technology for it's own sake, and values technical elegance first and foremost - and the business executive who is more concerned with solving business problems and defining solutions that will help the business address market challenges, operational deficiencies, and improve internal processes.

As to why you haven't heard of them already, well, that's harder to explain. They are a new'ish idea, and the word about Capability Cases seems to have been drowned out by all the noise being generated in the technology world. Perhaps because a proper appreciation of the value of the Capability Case requires a rare breed of individual, someone who can walk in both the world of the technologist and the world of the business executive. In any case, this approach is a significant step forward in terms of defining software systems to solve business problems, and will soon be all but required in any organization which wants to do more than pay lip service to generating competitive advantage from information technology.

"But wait," you might protest, "Nicholas Carr has already said that IT doesn't matter and can't represent a source of competitive advantage. You must not know what you're talking about."[1] Well, it could be that I don't know what I'm talking about, but, to put it simply, Nicholas Carr is wrong. Information Technology absolutely still represents a means to achieve competitive advantage. The important point to realize, is that "IT for IT's sake" is not a means to achieve competitive advantage... a modern, enlightened organization must instead focus on understanding the capabilities which Information Technology can provide, and must understand how those capabilities enable aspects of their business strategy. In other words, competitive advantage is not a simple as "whoever has the best algorithms wins" but instead is derived at the intersection of strategy and technology.

And this is where Capability Cases come into play. By beginning with the forces affecting the business, and driving through to solutions and the capabilities needed to enable those solutions, the Capability Case is exactly the means to understand how to leverage technology to achieve a strategic / competitive advantage. However, to gain the maximum benefit from Capability Cases, an organization is going to need people who can - to at least a minimal degree - speak both the language of business and the language of technology. If you are a technologist who speaks "Relational database" and "NoSQL graph database" and "CORBA" and "RMI" and "distributed / replicated cache" but does not know anything about "Porter's Five Forces" or "SWOT analysis" or the meaning of "Value Chain" or "Balanced Scorecard", you will not be properly equipped to serve in that "gap bridging" role. Likewise, if you are a business executive who believes "I don't need to know anything about technology, I'll leave that to the geeks in IT" and you don't know the difference between a database and a web browser, your days are numbered. The most valuable members of the most effective organizations going forward, will be those who can serve in this role of defining solutions using Capability Cases.

So, are we saying that IT people need to go get an MBA, or that business execs need to go get a Computer Science degree? Not at all, but regardless of where you currently fall in this dichotomy, you will need to make a conscious effort to gain a minimal level of skills and knowledge from the "other" domain. If you are a technologist and you don't know the name "Michael Porter" and have no idea what "SWOT analysis" is, then go buy a textbook on Strategic Planning and dig in. If you are a business executive who has no idea how a "relational database" differs from an "application server" then go to http://www.codecademy.com/ and start programming, or go sign up for a course at Coursera. Do it now, or you will probably find yourself unemployed sooner than later.

Likewise, if you are an ISV or other vendor of software solutions, if you are not able to articulate the capabilities of your software in terms of Capability Cases, you will struggle to communicate the value of your products to the people who control the purse-strings and make buying decisions. Influenced by Nicholas Carr and his "IT doesn't matter" mantra, executives have become more sceptical of proposed technology initiatives and want a better map to show how the initiative leads to an actual business benefit. That map consits of one or more Capability Cases, especially when the Capability Case is tailored to the specifics of the customer in question.

Capability Cases are also an excellent tool for Lean Startups who are taking advantage of the "Customer Development" methodology developed by Steve Blank. Use the tools from the Capability Case methodology to help zone in on the important business forces affecting your customers, and you'll do a much better job of identifying high value needs, and developing solutions to those needs.

To summarize: Capability Cases are a methodology for defining and specifying software solutions, which operate at the boundary between the business world and the technology world. They map from the forces affecting the business, to the solutions needed to address those forces, and to the capabilities which enable those solutions. They are the current state of the art in solving the problem of communicating between the business domain and the technology domain and are essential for turning technology into competitive advantage.

Join the Hacker News discussion.

If you've read this far, you should probably follow us on Twitter.