This is second in a series on the impact of the business operating model on Service Oriented Architecture. (see overview)
Quick note about the CISR models
Before I go into a lot of detail about the operating models, I want to make one thing clear: The operating models from CISR follow the same laws as any other reference model. To whit: "All models are wrong. Some models are useful."
In other words, most enterprises will exhibit behaviors of each of the four CISR models in one aspect or another. That said, most businesses will exhibit the behaviors of one model more than the rest. This is usually apparent in the financial filings of the company (annual report, 10-Q) because it is difficult to hide the operating model of a company when you have to tell investors how you plan to deliver value in the coming year.
Also, as with all models, before you assume that your business is a Coordination model, make sure that you ask the business, not the IT team. Best case: ask the executive leadership (CxO level) to debate the point. It does no good for IT to have one view and the business to have another (path of pain).
"The Coordination model provides integrated service to each key customer group. The integration results from sharing key data across the business units to present a common fact to the customer." (Enterprise Architecture As Strategy, by Ross, Weill, and Robertson)
The illustration that I use is above. I have similar illustrations for the other models in the overview page.
How to read this image: a single gray horizontal box represents commonality across business units. In this case, a coordination model company will share customers and partners, even though each of the business units are managed seperately. The business processes are distinct by each business, as is the operational data, but it is all brought together in the business intelligence as a way of understanding the customer from a 360-degree view.
The example provided by Ross for a Coordination model company is Metlife, a financial products company that provides insurance and other financial services to millions of customers. The customers themselves may qualify for, and should benefit from, the products of many different business groups. However, each group may have their own "view" of the customer that is pertinent to their business.
The business model is the single largest driver of decisions in your SOA, whether you know it or not. The impact of the model starts with the business, extends through business funding of IT, and into the architecture, design, and complexity of the IT ecosystem. In a company based on the coordination model, the following situations are typical:
Note that, in the coordinated model, each of the business units is managed separately. This allows business leaders a great deal of flexibility (and accountability) for making their part of the business successful. It also means that the IT group tends to be divided up so that there are separate funding or reporting models to each of the different business units. Centralization is infrequent, and coordination (of funding, of architecture, of standards) requires consensus.
The Coordination Model is interesting because (a) SOA can provide real benefits, and (b) this is the most difficult of the four models in which to create a SOA. That is because of the impact of separate business management on IT funding, especially of a shared infrastructure like "common data models" or "common messaging standards" or even "common OS platforms." Anything 'common' is difficult, because the business units do not typically provide an incentive for their IT teams to create common models, and yet commonality is the key to getting value out of SOA.
The following effects would be typical for SOA+BPM in a Coordination model:
Distributed / Federated Process Management - Each business unit manages its own processes, using its own tools. Processes are rarely coordinated across business units. This is a fact of life for the BPM tools, and frequently there is little business value behind forcing all business units to use the same BPM tool, since they cannot share the primary value chain processes anyway. Common corporate processes (like HR and Finance) are typically the only exception to this independent spirit.
Distributed / Federated Governance Model - A favorite topic among SOA folks is governance. Governance has many meanings. SOA Governance tools may prove ineffective if you use the tool to find a service, because you may not be able to tell which of your businesses paid for that service. This is important because the businesses themselves are quite likely to affect the amount of governance they want to occur, and therefore the governance rules that "their" services are to be judged against.
Semantic dissonance in the data - Making a service that is useful is nice. Make a service that is reusable is great. Getting two or more business units to adopt the service is darn near impossible. That is because, in this model, you are expected to integrate the data, but not the business processes. This usually creates a situation where the "semantic understanding" of the data is quite different between businesses.
For example, in one business, a purchase order may be created by anyone but is followed by an approval process if it exceeds a threshold. In another business, the purchase order cannot be created until the approvals have occurred, and perhaps, all purchase orders require approval.
So, if you look in a database and you see a purchase order... has it been approved or not? The answer depends on the business unit that created it. While this example is overly simplistic, the goal is to show that, for some core business entities, there will inevitably be places where the underlying states for the information cannot easily be aligned. This is semantic dissonance, and it makes Enterprise SOA a distant fantasy for those enterprises who are unprepared or unable to muster the consensus needed to find the commonalities in the various business processes.
To bring together the full benefits of SOA will require a costly process to align the events that create your business documents and to create a shared understanding of "when the purchase order becomes a purchase order." That says nothing about "what data is in a purchase order" or "what system does a purchase order live in." All of these variables create complicating effects on Service Oriented Architecture.
Consensus processes for designing and deploying SOA - the decision to deploy Service Oriented Architecture cannot be made by one central group. It must be made by many people, working together. In a "coordination model" company, centralized groups are rare and often quite small. They don't have the clout to bring about the kind of change needed to deliver truly reusable services. That requires "virtual teams" or "steering committees" that are often difficult to manage and can seriously delay deployments.
Service consumption is voluntary - Ever heard this fantasy: "If you build it, they will come." In a Coordination model, this idea, far fetched in any model, is downright silly. IT projects, especially ones funded by different business units, are going to have a difficult time explaining to their business why they created a service that another business can use... especially if they don't get some benefit out of it. Reusable services are more expensive than point-solution services.
Plus, reusable services force the IT team writing the consumer service to take a dependency on another team for delivery. That nearly always causes problems. Therefore, the only services you can easily reuse are services that (a) developed by the same business unit, or (b) are dictated from executive management, or (c) are so "thin" that they provide no real processing, and therefore, no real value.
Federated Service Catalog - Since processes may be different in each business unit, but some data elements are expected to be shared, it is typical to see one of two effects on the service catalog. Either (a) each business unit has it's own catalog, or (b) one common catalog exists, but each service is flagged with whether that services is "core" or if it is provided by a particular business. The assumption is that non-core services will only be consumed by applications that are part of the same business unit as the service publisher.
The Service Oriented Architecture for each of the business operating models will be quite different. Those differences can determine not only how difficult it is to create a SOA in that business environment, and the amount of business value that can be generated by doing so.
PingBack from http://blogs.msdn.com/nickmalik/archive/2007/10/12/soa-and-the-cisr-operating-models.aspx
So many things to do, so little time, this is what we call a catch-up post SOA Nick starts a new series
These are all good points however given that most companies are in the "Coordination Operating Model" category, are there any ways to solve the issues which are raised here? Do they need to move to a different model to make SOA work?
Interesting question. Do companies change their business model to make a software solution, however elegant, function. I've never heard of that happening, not would I bet money on it.
Forgive me, but the notion sounds like: Gee, we have a hammer and the expensive electronics we own all use small screws... can we change the screws into nails so that we can make the hammer work?
I didn't actually say that SOA wouldn't work. I said that SOA, in these models, holds the most promise for business benefit, and the most difficulty. The key, and this bears repeating, the key to making Enterprise SOA work in the coordination model is to create a stable and consistent Information Model, and govern folks to it.
I know that is difficult, but the payoff is huge.
The answer is in the information model. That single, difficult, incredibly important item is what turns the hammer into a set of fine screwdrivers, appropriate for the use you need.
Excellent stuff Nick
Now I just have to get my business people to work out what we are!
I assume that if different parts of a business run on different models I could treat them seperately re SOA?
Yes. Typically, if different parts of your business "run differently" then you either have a coordination model or a diversification model. I will put up a comparison of the two as part of the series.
If you have a coordination model, then you need common data models. If you have a diversification model, then you will have a different SOA for each business unit.
Companies combine these models in some pretty creative ways, so that 'advice' is general at best. I hope it is helpful nonetheless.
This is third in a series on the impact of the business operating model on Service Oriented Architecture.
This is fourth in a series on the impact of the business operating model on Service Oriented Architecture.
This is fifth in a series on the impact of the business operating model on Service Oriented Architecture.
So many things to do, so little time, this is what we call a catch-up post SOA Nick starts a new series on Integration with SOA and the CISR Operating Models and adds SOA in the Coordination Models Nick also on a Tale of Two Visions Both Arnon and Nick