I'm begining a new series on Integration. Five parts. Clear up some of the noise on SOA. This series will refer to the set of four Operating Models described in the excellent book, "Enterprise Architecture as Strategy" from the great minds at MIT's Center for Information Systems Research (CISR), Jeanne Ross and Peter Weill. If you have not read the book, that's OK. Working Paper 359 on the CISR site will provide the right level of depth (there is a free registration on the site).
To quote from the working paper:
Companies make two important choices in the design of their operations: (1) How standardized their business processes should be across operational units (business units, region, function, market segment) and (2) how integrated their business processes should be across those units.
That's two variables. Assuming each has two values: Low and High, and you get four possible combinations. Ross gave these four types of models different names.
- Low Integration, Low Standardization - the Diversification Operating Model
- High Integration, Low Standardization - the Coordination Operating Model
- Low Integration, High Standardization - the Replication Operating Model
- High Integration, High Standardization - the Unification Operating Model
I've illustrated these models in this way.
The book I mentioned above goes into excellent detail on the implications of these models, and what kinds of companies are well suited to each model. Using success as a guide, you can quickly see how these two choices: Integration, and Standardization, drive huge effects across the organizations of these companies. They also drive the kind of "Big Picture" Enterprise Architecture models that the organization should produce, because each one benefits differently from EA.
Many folks now believe that SOA and EA will gradually combine, so that they are two parts of the same message. That story is interesting when you consider these four models, because SOA is radically different in each one. I believe it is true, because the four models each benefit from both EA and SOA, but in different ways. I believe there will be four types of Enterprise Architecture organization, and for each one, there will be a different set of methods, artifacts, and outputs... and a different SOA for each one.
And that is what this series will be about: the effects of the operating model on SOA. I will cover each of the operating models and describe the effect on a high level SOA reference architecture for that type of business, as well as the technical implications with respect to governance, catalogs, standardized schema, and mechanisms for gaining unity.
Here are a list of links to follow-up blog posts that discuss the different aspects of SOA in each of the business operating models described by CISR.
Why do this?
I see arguments every day, in the blogosphere and in books and white papers, where thinkers disagree about the value of a catalog or the need for standards or the future of SOA in general. The problem with these arguments is that most of the speakers are (a) correct, from their viewpoint, and (b) not changing their minds. We have a set of entrenched voices saying different things. So how can all of them be right?
I believe that there is more than one right answer, and that it depends on the operating model of the company. In other words, the tools, standards, and approach that is useful for a Unification model are simply not optimal when applied to a company with a Coordination model. That doesn't mean that you won't get progress, but you won't get as much as you could without considering the operating model first.
For years, the IT thinkers have been saying "let's get closer to the business... then IT becomes more useful." Guess what, folks! There is no "THE" in business! There are ten thousand ways to make money, and we need to serve all of them. One size, or one approach, or one toolset, will not suit all businesses. But chaos and cacaphony won't suit our ability to be effective.
By using simple models like the Operating Model concept from CISR, we can create reference architectures that can be reused in different organizations to base not only their Enterprise Architecture program, but their SOA implementation, and with it, the toolset that they need to build an agile, responsive, efficient, and highly valuable IT organization.
Once the SOA leaders realize that there is more than one right answer, we can begin to have productive conversations, not about whether a catalog is needed, or not, for everyone, but what role a service catalog plays in a Coordination operating model SOA, and how that role is different in a Diversification model. (it is, wildly). Consensus can be reached if we understand the scope of the problems that we are trying to solve.
That is my goal.