Foreword

Professor Fred Brooks refers to “thinkers,” “do-ers,” and “thinker-doers.” This book is written by some of the most energetic “thinker-doers” in the business. They are amazingly well-versed in current academic research and leading edge technology. They also get their hands dirty and deliver specifications, designs, and operational software for their customers.

The book adds an important term to our already large catalog of terms that we system builders routinely use—Capability Cases. The essence of the book is that just as we need reusable components to improve our productivity while developing systems, we also need a reusable library of Capability Cases to help explain to our customers what is possible and to comfort them by knowing that “what already exists cannot be impossible.”

An envisioned solution—achieved through some suitable activities, such as those defined as the “Solution Envisioning” aspect of the book—then is a collection of Capability Cases. Just like reusable patterns, Capability Cases describe something which already exists from a user's perspective, not a developer's perspective. By combining a collection of Capability Cases a set of users and stakeholders can get a more precise notion of what could be built and what business value that particular solution would provide.

Why is this book important? It is important because far too many business people in the world are simply catatonic at the thought of being responsible for “delivering a custom application.” It need not be so. A custom application can be described using a set of reusable Capability Cases; those Capability Cases can be implemented with a set of reusable frameworks or components; and everything is held together with a modest amount of “glue code,” which is not very risky to implement. With such a strategy businesses can finally get the applications and systems that they want instead of the systems they are being sold which always require the business to change to accommodate the application or system.

Years ago I had the privilege of managing a collection of remarkable “thinker-doers” at ITT Corporation. We were asked to develop a 10 year projection of software development technologies. We constrained ourselves in our projections by only considering capabilities which already existed, even in a high technology research group. Surprisingly we did a great job of predicting where hardware technology was going and we were a decade optimistic in our view of software technology. So constraining ourselves to think about solutions composed only of Capability Cases is not very restrictive!

If we restrict our thinking about new systems to existing Capability Cases, does this ensure that we will not have failed projects? Of course not. The project may still fail because we attempt to do too much too quickly or with too few developers or with inexperienced developers.

What if we're a startup company and really want to develop something that is substantially different from anything that has ever been built before? It certainly can be done, but some cautions apply. One or two major innovations are all that a single project can accommodate. I have seen companies fail when they try to develop too many fundamental innovations in parallel. But there is nothing wrong with a series of innovations happening in sequence. Companies like Apple and NeXT have demonstrated their ability to do just this. Microsoft has demonstrated spectacular prowess in taking innovations developed elsewhere and commercializing them—with or without the cooperation of the original developer!

Ralph (one of the authors of this book who has been working on software projects as long as I have) and I remember when companies would spend millions of dollars writing meaningless specification documents filled with conflicting vague notions of what some set of stakeholders thought they wanted in a new system. Designers and developers would ponder for days and weeks and sometimes even months trying to figure out what on earth the customer really wanted. Until the solution is completely described in a form that designers and developers can unambiguously understand what It^[1] is, no one can provide an accurate estimate of the time and effort to construct It (using whatever technology).

^[1] It is a pronoun and refers to the envisioned solution; IT is an acronym for Information Technology.

Capability Cases, in conjunction with the Solution Envisioning process, provide for a more precise way to define It. With such precision, IT organizations can finally start delivering the business value that their stakeholders demand but rarely have received. Irene, Ralph, and Robert have made a fundamental contribution to software engineering. I look forward to seeing a virtual bookshelf full of books describing available Capability Cases. It will happen soon, I predict.

Next will come the tools to assemble Capability Cases with their associated object-oriented components. This is not an easy project and would be quite hard to express using existing Capability Cases. So be prepared to wait a decade or so before our often described building blocks solution can be assembled from Capability Cases.

Tom Love, co-founder and CEO, Shoulders Corporation