SOA in the Diversification Model

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

Artificial Constraints and the SOA Message

In response to another bit of feedback: In these posts, I describe the requirements for a business to adopt SOA.  The question was: am I being careful not to create an artificial constraint by stating that a business must adopt an unnecessary practice in order to succeed at SOA?

In response, let me be clear.  I am talking about Enterprise SOA, not Application SOA. 

• Enterprise SOA is the art of developing services that are specifically engineered to meet the needs of different business units and are developed for the express purpose of collaborating in multiple business processes.  You need business-level involvement to make this work.
• Application SOA is an excellent design practice that you can use when developing your app, leveraging the mechanisms and patterns of SOA to build a system that should be more agile, more maintainable, and hopefully, more scalable than it would have been if the design relied on different architectural principles.  Developers can do this without asking the business, and to be honest, the business should not care.

Answer: yes, I am being careful not to create an artificial constraint on Enterprise SOA, because I'm doing my level best to describe, from my personal experience and analysis, the minimum level of constraints that a business will need to adopt in order to build SOA at an enterprise level. 

We don't do our enterprises any good if we attempt SOA and fail.  If someone tells the business that SOA is easy, or cheap, or simple, and there are good reasons to believe that it will not be, then a false expectation could be set.  It would be a lie.  This false expectation could cause the failure of the SOA project.  If the business needs to be convinced before putting up sufficient funds to bring in SOA, then convince them.  If you cannot, perhaps you should find someone who can. 

The Diversification Operating Model

"Diversification applies to companies whose business units have few common customers, suppliers, or ways of doing business.  Business units in diversified companies offer different products and services to different customers, so central management exercises limited control over those business units." (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).

Companies that use a Diversification model encourage financial performance in their business units with very few constraints at all.   Some attributes:

1. Small centralized management environment
2. Company grows through financial performance within businesses and the acquisition of other businesses (often quite different from one another). 
3. No shared transactions.  Few shared customers. 
4. Diverse product and service offerings with minimal overlap.

One example that Ross uses is the Carlson Companies, a $20B company in the marketing, hospitality, and travel business.  Their portfolio includes Radisson Hotels, T.G.I. Friday's restaurant, Carlson Marketing Group, Carlson Wagonlit travel, Radisson Seven Seas Cruises and the Gold Points rewards network.  These businesses are quite different from one another.

IT in the Diversification Operating model

For those folks new to this series: 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 diversification model, the following situations are typical:

• "Shared Business Function" approach: Different business units may share specific operating functions.  For example, in some cases, the corporation may provide Human Resources, IT, and Financial management as a portfolio of shared operating functions for the different companies.  Each company pays for the right to use these shared operating functions.  Note: these are not SOA services.  We are basically saying that the non-value-chain functions of each company are outsourced to the same firm, a subsidiary of the corporation.   See the example below.
• Customer Data is not shared - Customer data belongs to the business unit.  It is usually not shared with the corporate headquarters.  Roll-up data often is shared, and financial data is nearly always shared, but customer and transactional data is not.  Interestingly enough, in some cases, the information is actually stored in a single enterprise system that is managed for each business. 
• Little or No Process Consistency in the Value Stream - There may be some process consistency in the "outsourced" support processes, but when it comes to the way that these companies make money, they don't bother coordinating across other business units.  What would be the point in creating that dependency?
• Distributed IT decision making - Project funding decisions in the IT organization are usually in the hands of the business units themselves.  The decision making process for shared assets is distributed, and sometimes, rife with politics.  These companies are concerned about the cost of IT, and IT teams often have to compete for work with external consulting companies who claim to be able to deliver the same value for less.

Note that, in the diversification model, variation is normal.  It is common to see a different CIO for each business unit. 

SOA and BPM in the Diversification Model

The Diversification Model presents interesting challenges and opportunities for Enterprise SOA.  For one thing, you don't have a single enterprise.  You have many. 

Let's say, for example, that you have a business (Contoso) that has two divisions.  Division One assembles retail electronics and sells them through a web channel as well as a few retail outlets (IBuySpy).  Division Two provides security monitoring services for homes and businesses (IProtectU).  Both divisions have "outsourced" their supporting functions to a third company: Contoso support services.  Contoso support provides IT functions, HR, and Finance services to both IBuySpy and IProtectU.

There are three companies here.  Therefore, at least three different ways to build out infrastructure.  Each gets to decide, without consulting the other.  Each pays for their own infrastructure. 

In practice, Contoso Support Services (CSS) is not run like a company, with its own P&L.  CSS is, after all, a monopoly.  Since they cannot "make money" except by taking it out as cost from either IBuySpy or IProtectU, budget for CSS is tight.  The IT group will rarely get much money to spend on the Contoso Support Services business. 

I do need to make a clarification here.  Many Coordination businesses look like this model... from a distance.  The real difference between Diversification and Coordination is "who owns the customer."  In a coordination model, the corporation as a whole "owns" the customer relationship.  In a diversification model, each business unit deals with their customers in a distinct manner.  In many cases, a customer who buys from both businesses would have no idea that they were buying from the same company!

So, where does Enterprise SOA lie?  Nowhere.

In this model, there are two service oriented architectures, one for each of the funded businesses (IBuySpy and ISecureU).  If Contoso Support Services is actually run like a business, and therefore has a secure source of funding to pay for its own overhead, then you have three businesses, and three SOAs. 

And there is no good reason to make them coordinate. 

You have three enterprises.  Within the bounds of each enterprise, you can follow all of the promises and practices of SOA.  The fact that the IT team can see that one business is using SOA and another is not using SOA is frustrating, but unimportant to the businesses.  They are not incented to care. 

My example above is wildly oversimplified.  While I have worked with a company that actually had only two business units before, the vast majority of companies that follow this model have quite a list.  I was speaking with an architect the other day who told me that his company has over sixty (60) independent business units!

Some of those business units may be so small that they will get little or no benefit from a SOA.  Their processes just won't change that often.  Others will get tremendous benefits.  Note that each business unit may use any of the four operating models. 

Geeks would call this "recursive." From a SOA standpoint, each is 'start over.'

The common data model

There isn't one.  Not at the enterprise level.  Instead, you can build out a common data model within each business to build SOA for that business.

That said, there is an integration model.  The shared business services themselves will need to integrate with the business-focused systems.  In our example, the ERP system for IBuySpy will need to integration with the Financial system from Contoso Shared Services.  This may occur as a flat file or as messages.  These integrations tend to be point-to-point, and traditional EAI approaches work just fine.  You can use SOA, but you don't need it. 

Business Process Management

You may not find many uniform business processes across these businesses.  Therefore, BPM efforts within each business tend to focus on improving the processes within that business.  That said, the Business Process professionals themselves may be part of the shared IT group, and could be provided as 'service providers' (similar to in-house consulting services).  If that is the case, then a common toolset and infrastructure is a good idea to make it efficient to deliver these services to different customers in a consistent manner. 

There's an interesting effect here.  Operational process management (orchestration) exists within each IT infrastructure.  But the BPM tools may be common across the businesses.  Taking a business process in digital form and 'executing' it in different automation engines becomes an integration challenge of its own!  Common BPM standards come in very handy in this situation!  Hooray for BPEL.   

Funding SOA

In a way, the diversification model provides a great testing ground for SOA.  If you implement SOA in one of the more 'innovative' businesses, and you are able to show value, then your business leader can tout the value of your excellent IT services to his or her peers.  That may get them interested in using SOA as well.  In effect, the 'start small' concept is built in to the culture.

On the other hand, you may be very hard pressed to get any of the business units to pay for more infrastructure than they need.  It would be rare to see any business unit expressing much satisfaction at the thought that their IT investment had a positive impact on the IT budget of another business unit. 

This is not as 'counter-intuitive' as it may seem.  Think of it this way... Assume both Hewlett-Packard and Dell buy chips from Samsung.  Assume HP asks Samsung for a very large order; one that stretches Samsung's capacity.  Let's say that HP pays extra for the order, in effect "investing" in Samsung to increase their capacity.   HP doesn't want to hear that Dell benefits from HP's investment. 

Yet this is how SOA is sold to the business leadership in many cases!  It's crazy.

So if you are planning to build the SOA infrastructure for one business, but use it for other businesses, you will need to take a hard look at your company culture to figure out how to leverage the investment of one business to the benefit of another.  Some cultures: no problem.  In others: bad news.  Tread lightly.

Direct Impacts of the Diversification Model on SOA Operations

In the other posts, I went into detail on the operating model's impact on Enterprise SOA.  In the Diversification operating model, there is no Enterprise SOA.  There is only SOA in the business unit, and the business units can be any of the four models.  Therefore, look to the operating model of the business unit to see the impact on SOA within that unit.  

Conclusion

The Service Oriented Architecture initiative for companies using the diversification operating model should focus their efforts on a subset of 'innovative' businesses to prove the value of SOA, and then extend outward to other businesses.  At the same time, don't count on building for the enterprise.  Build "just enough" for each business to show value.  And remember: the sharing of information is not a key driver for SOA in this operating model.