Foreword
Like every young industry, the information technology (IT) business is rife with confusing, competitive, and cockamamie terms and acronyms. I have often wondered at the industrywide propensity to invent and promulgate TLAs (three-letter acronyms, of course!). It seems almost refreshing when a new acronym sports four or five letters, or better yet, eschews compressed forms altogether. But no, the favored approach to technology innovation remains confusing acronyms.
This is not an invention of the 21st or even the 20th century. Electric lamps and the internal-combustion powered automobile, both introduced in the late 19th century, were young technology industries that thrived on spurious differentiation. And youth lasts a long time in a technical industry: The battle royal fought between the Edison group of companies and the Westinghouse company over the electrical standard for the United States was at its peak when Nikola Tesla plied his trade in Westinghouse's workshops (after leaving Edison's employ) in the late 1880s; it had already been a decade since the invention of the light bulb and would be some two decades more before the war was over and Westinghouse's embrace of Tesla's polyphase alternating current had succeeded.
It is unlikely, however, that more than a few consumers of electric lamp technology had any idea what the direct current vs. alternating current debate was about. The level of complexity was obviously far too high for the average buyer; the same can be said about the technical choices in the automobile purchases by the vast majority of car buyers, prompting automotive marketing departments to simply train us that fuel injectors are good and carburetors are bad.
Unfortunately, the same technology complexity and resulting market simplification continue to plague our young IT industry. The resulting apparent “speed of innovation” that worries chief information officers might or might not reference true technical innovation, but it certainly pertains to the innovation in new terminology! Certainly there is constantly changing technology in corners of the IT industry, but much of it is simply new wine in old bottles.
The good news is that old bottles form a strong, solid container for that new wine, and the smart consumer of “new technology” can see through the terminology, the acronyms and the labels, to the real business problems and the ways technology can have a positive effect on operations along the only axes that really count: better, cheaper, and faster. That's where the “agile enterprise” comes in—an “agile” organization reacts quickly to change, recognizes both internal and external (customer and supplier change) quickly, perceives the need for change in the future, and accepts that need as a cost of doing business.
The next step is the hard one and in fact the reason for the book you are holding (and the nexus of the TLAs on the cover). The hard part of IT integration isn't the technology per se; the reason we can see further is that we stand on the shoulders of giants. The complex chemistry and optics used to create our integrated circuits are far below our level of detail; we can depend on others to solve those problems. No, the hard part of IT has always been, and remains today, the enormous gap between management of operations and technology that supports those operations.
How can this be? After more than 50 years of computing, well over 30 years of computing in large organizations, and some 20 years into the pervasive (personal) computing revolution, why should it still be difficult to recognize business challenges in a way that technical solutions clearly address those challenges? The answer is simple: Like other young technology fields, from the marine architecture field a half a millennium ago to the century-old technologies just mentioned, shared languages are just coming into use.
By “shared languages” I do not mean the languages of management (natural languages such as English or abstract but unstructured languages such as spreadsheets and presentations); nor do I mean the languages of computer technologists (such as Java, LISP, and C++). I mean languages that are readable from both sides of that divide: modeling languages. This isn't a new idea, of course; in marine and building architecture we use blueprints. Blueprints speak to the buyer, the seller, the builder, even the makers of parts and the builders that use those parts. Blueprints can be turned, relatively directly, into three-dimensional models for the home buyer as well as parts lists for the electrician. Blueprints are standardized, structured, and well accepted. What we need to do is take that broad step in the IT industry.
Though this book starts off with three TLAs on the cover, you'll find that the real coverage is both more and less. “More” in the sense that you will find more acronyms and ideas inside, but connected together in a way that makes sense; and “less” in the sense that all these ideas sum to one basic idea: If modeling works in other engineering fields, it will work in the IT field. Agility in the enterprise—better, faster, cheaper—comes from being able to structure organizations to take advantage of reusable business capabilities; from the ability to recognize, precisely capture, store, and retrieve the definitions of those capabilities; and from the ability to capture all that information in a shared, widely understandable model of the enterprise.
Those are, respectively, service-oriented architecture (SOA), business process management (BPM), and model-based management (MBM)—thus the title and contents of this book.
You will find herein a wealth of knowledge about how models change the way a business can, should, and will operate. Though there are technology underpinnings to these ideas, don't miss the fact that these innovations are about organizational management more than about IT. Some of the ideas surely are new wine in old bottles; have a sip, though, because those old bottles definitely add flavor!