SOA in the Unification Model

  • Article

This is third in a series on the impact of the business operating model on Service Oriented Architecture.  (see overview)

What can you get from this series?

My prior post raised a bit of ire with one of my readers, a fellow whom I respect.  He felt that my posts were not telling a positive story about SOA. 

I believe that SOA is a highly valuable paradigm for enterprise integration.  I also believe that the ability to apply SOA to a problem is not uniform.  Some problems can be solved with SOA.  Others cannot.  There is no magic bullet. 

I am hopeful that this series helps folks to

  1. identify which situations they are in,
  2. understand the challenges they will face when applying SOA to their situation, and
  3. improve their odds of successfully providing value to their business.

I am not attempting to sell SOA to anyone.  I make no money from "Selling SOA."  I have no personal or professional stake in the success of the SOA paradigm.  That said, I believe strongly that SOA has a value, and if we do a good job of avoiding mistakes, we can demonstrate that value to our respective businesses.

The Unification Operating Model

"When organizational units are tightly integrated around a standardized set of processes, companies benefit from a Unification model.  Companies applying this model find little benefit in business unit autonomy.  They maximize efficiencies and customer services by presenting integrated data and driving variability out of business processes." (Enterprise Architecture As Strategy, by Ross, Weill, and Robertson)

I illustrate this model as follows.  (I described how to read these images in a prior post).

operational models - Unification

Companies that use a Unification model work very hard to wring out every drop of waste from often-complex processes.   Some attributes:

  1. Highly centralized management environment
  2. Company grows through leveraging economies of scale
  3. Process standardization seen as a key element of corporate success
  4. Frequently found in commodity businesses

One example that Ross uses is the core chemicals manufacturing business of Dow Chemical. 

IT in the Unification Operating model

As I said before, the operating model is the single largest driver of decisions in your SOA.  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 unification model, the following situations are typical:

  • Shared enterprise systems - Large IT systems are often used to reinforce the centralized nature of these companies.  It is not uncommon to see an ERP system managing a wide array of core functions, including HR, manufacturing, customer relationship management, and financial management.  It is also common to see a best-of-breed approach, where large systems from different vendors are implemented to support each function separately.  Integration is key to success.  However, the data models for the information typically is defined by these applications themselves.
  • Process owners - In order to get process consistency among the various operating units, a single person is identified to own each key process and they, along with their team, is responsible for insuring that the process is efficient, cost-effective, and productive. 
  • Central IT decision making - Decisions in the IT organization are central.  Systems are purchased, and deployed, with the goal of improving the cost effectiveness and efficiency of the company's core business processes.  These companies tend to have very tight IT budgets, as IT is frequently not seen as a core contributor to process innovation.  Data masters are often centrally mandated.

Note that, in the unification model, variation between business units is kept to a minimum.  It is common to see the CIO report to the Finance Director or Chief Financial Officer. 

SOA and BPM in the Unification Model

The Unification Model is interesting because (a) SOA is expensive and may take years to reap full benefits, and (b) this IT environment is very cost conscious.  That said, the environment is already familiar with purchasing large software systems and taking a long period of time to implement them.  If you work in an environment like this one, and there is no SOA in place, you may make some traction by framing SOA as a single software package.  (Not as large as ERP, but larger than a shipping management system, for example.)  On the other hand, you could also get traction by tying SOA to a large system upgrade (see below).

The common data model

Once again, the key to implementing Enterprise SOA is the common data model.  While the cost of creating a common data model is far less in this model, the benefit may be difficult to explain.  That is because the data model is driven by the central systems that produce or consume the data.  The urgency for creating a common data model may not be high.

In this model, SOA provides two benefits.  Both require the common data model:

1) Protection from Vendor Lock-in: If the company has taken a "best of breed" approach to technology acquisition, then they have likely purchased different systems from different vendors for key business functions.  Integrating these systems is expensive, and there are scars to prove it.  This creates a "high barrier to entry and high barrier to exit" for these companies.  It costs a lot to put in a system, but even more to leave.  SOA can help lower those barriers by creating an abstract layer that processes abstract transactions in a standardized way. 

This allows a company to purchase a new Financial system (Microsoft Dynamics AX, for example), and instead of integrating each of the other systems to it, the IT department would simply write adapters to connect the new system to the abstract services layer.  Other systems can now directly consume the new system without substantial modification  (in theory, anyway.  Nothing is perfect.)

2) Process Composition across systems:  It can be difficult to track a single transaction, through a complex process, across many systems.  The customer doesn't care.  You can directly impact customer satisfaction if it is difficult to figure out which system has the information that your customer needs to know, or to make it difficult to retrieve that information readily. 

So, if customer satisfaction is important, process composition across many systems is a key capability of your IT infrastructure.  To solve for this problem, you need four things: SOA as an integration mechanism, a common information model as a unifier, an enterprise identifier scheme to allow the transaction to be traced from start to finish, and tools to inspect each system for the information related to a unique transaction (using SOA, of course).

Funding SOA

If you get your information model in place, you could implement SOA as a combination of a package install and software adapters that is tied to a larger project, like an ERP replacement.  On the other hand, with this operating model, it is possible to build a bottom-up SOA, where the services are produced as part of IT projects without architectural coordination, primarily in areas where the information model is well-understood. 

Direct Impacts of the Unification Model on SOA Operations

The following effects would be typical for SOA+BPM in a Coordination model:

Centralized Process Management - Process owners manage a subset of the processes.  Processes are often coordinated.  Using the same BPM tool and repository is a best-practice, and one that will make immediate sense to the business.  The tool must be able to support a wide array of BPM needs, and must leverage standards.  

Centralized Governance Model - SOA Governance tools are quite useful in this model, and they should be used.  (SOA Software and Amberpoint are two Microsoft partners that I would suggest, for readers interested in this space.) 

SOA Service Adoption - Due to centralized decision-making, the decision to consume a service can be tied to project funding.  This bit of overhead should pay for itself quite easily, since you would end up with a greater amount of service reuse, and therefore, less code to maintain in the long run.  Some organizations have even gone all out, and implemented a set of core SOA services as a single project, then turning to governance to require all new projects to adopt them.  (Top-down SOA). 

Cross-system process concerns - Getting SOA benefits out of processes that look to a single enterprise system is a fairly quick win.  I like quick-wins.  You can build credibility for SOA by rolling out a few of these "low-hanging fruit" projects.  However, to get real enterprise benefit out of SOA, you need to be able to compose a process across many systems.  This can be easy, or this can be hard. 

To make it simple, repeatable, and adaptable, you need to create your common information model.  That model must contain not only information entities, but also a notion of what business documents you will communicate with, and what events occur on each document. 

SOA Readiness - While a central group may decide to implement SOA, each of the IT teams that surround the major systems will have different levels of understanding of the concept of event-driven services.  You will need to build a common understanding, and common standards, to make sure that these different groups, using different technologies, can reduce the friction that could occur when a process consumes many different services.

Centralized Service Catalog - You are likely to end up with a single catalog, but it may be a good idea to consider splitting the catalog into layers, with the upper layer of services oriented towards the business process areas that the organization cares about, and the lower layer of services to makes the information available.  Services in the upper layer consume services in the lower one. By separating services in this manner, you can simplify the SOA composition process. 

Conclusion

The Service Oriented Architecture for the unification operating model should take a cost-focused approach to delivering business value, orienting the services towards both process and information.