SOA in the Replication Model
This is fourth in a series on the impact of the business operating model on Service Oriented Architecture. (see overview)
Does IT choose the operating model?
One bit if feedback that I've been getting about this series seems to stem from a fundamental misunderstanding of my intent. I am not intending to offer a set of choices to Enterprise Architects.
I am not saying: look at your company and decide which model you need to use.
I am saying: look at your companyand try to understand which model the business has selected.
If an enterprise architect thinks that the company should change the model from where the business is at, he or she will need to go get the business to agree. That is a difficult conversation and completely outside the scope of these posts. Read the book.
In a nutshell: The operating model is not there for IT to choose. It is there. Cope with it.
The Replication Operating Model
"Replication model [companies] grant autonomy to business units but run operations in a highly standardized fashion. In a replication model, the company's success is dependent on efficient, repeatable business processes rather than on shared customer relationships. [...] Business unit managers have limited discretion over business process design, even though they operate independently of other 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 Replication model encourage innovation in their business units but require common processes to create consistency and reduce costs. Some attributes:
- Small centralized management environment
- Company grows through creating new operating businesses to serve different customers (often geographically).
- Process standardization keeps costs low, allows for rapid creation of new operating businesses.
- Excellent delivery of a small number of product offerings.
One example that Ross uses is the direct banking business of ING-Direct. Another example would be a franchise operation like McDonalds, but we will stick with the notion of replication in retail banking because it is more interesting from an IT standpoint.
IT in the Replication 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 replication model, the following situations are typical:
- Replicated enterprise systems - Large IT systems may be used to reinforce the centralized nature of business process in these companies. It is not uncommon to see a similarly configured ERP system in each operating business unit, managing a wide array of core functions, including HR, manufacturing, customer relationship management, and financial management.
- Customer Data is not shared - the systems are largely turnkey delivery. This means that the operating unit, when it gets set up, gets its own copy of "shiny new software" and then owns it. The 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. It is interesting to note, however, that the formats and schema of the transactional data is often similar or identical. This would allow the sharing of this data, if it were deemed interesting to the company.
- 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. The difference between a unification model and a replication model is that, in a replication model, this is usually done through consensus of the individual businesses. Innovation will come from the edge and adoption is at the edge, so a consensus approach is required.
- Central IT decision making - Decisions in the IT organization are centralized as much as possible. Systems are purchased, and deployed, with the goal of improving the cost effectiveness and efficiency of the company's core business processes. These companies are concerned about the cost of IT, but are friendly to innovation as long as it can work within the common process framework.
Note that, in the replication model, variation between business units is minimized for the sake of efficiency. It is common to see the CIO report to the Finance Director or Chief Financial Officer.
SOA and BPM in the Replication Model
The Replication Model is an odd one for SOA. Since the purchase and configuration of systems is largely centralized, the SOA integration story is one of leverage. If you spend the money to create a service oriented architecture, you can implement it over and over, in each of the business units.
Therefore, the cost of SOA is amortized. The benefit accrues to the business units themselves, while the cost is borne by the corporate IT entity. That can make funding an interesting discussion. That said, these companies are familiar with purchasing on behalf of their operating units, although they may be more comfortable with 'packaged solutions' which is a distortion (IMHO) of what SOA means. (I'm in the "SOA is something you do, not something you buy" camp).
One downside to SOA in the replication model: Centralized IT is often minimally funded, especially if the company only occasionally adds a new business unit. That is because the need to create and maintain a "reference technical implementation" is an overhead that can be 'purchased' from one of the business units themselves. That unit will end up having most of the decisions to make about how to build out the infrastructure.
The common data model
You don't really have a single enterprise SOA in the replication model. Operationally, you have a different (extraordinarily similar) SOA in each business unit. From that standpoint, the discussion of common data model takes places between the systems that are implemented in each business unit.
That said, the common data model is a fundamental first step in allowing this integration to take place. SOA, within each business unit, will be based on that model. The model can be developed once and, depending on the level of standardization between units, the model can be largely reused in other units. This amortizes the cost of creating the model, but may introduce the delay that comes from collaboration, since adoption is also in the business units.
The benefits of SOA within each unit will be very similar to those described in the Unification model because, within each unit, the unification model is usually the norm. The benefit of SOA at the enterprise level is low, at best. Focus on the business units to reap the benefits of SOA in a replication-model company.
Funding SOA
Assuming you are building SOA in an existing infrastructure, you will want to start in the business unit that largely drives the IT decisions for the other units. In the majority of cases, this is the "home office" business unit (the one that operates in the first city that the business ran from). Any success there can be driven out to other units. Note that if you are working in a non-home-office unit, and you want to create a new SOA... your success will depend on the corporate culture. If the central unit is willing to adopt innovation from a 'non-central' unit, then you may succeed. This may be less common than you think.
Similar to the unification model, you need to get your information model in place first. Once you have done so, 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 within the home office business unit. (Reuse of Bottom-up SOA will not frequently extend to services developed at non-central business units).
Direct Impacts of the Replication 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 frequently developed through collaboration, but are centrally required. 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 Tools, Distributed SOA Governance - SOA Governance tools are quite useful in each of the operating units. Governance across the units is not useful.
SOA Service Adoption - Adoption of a service will happen first when the service is running in the home-office IT department and then integration projects are launched to adopt it in waves, with adoption in the home-office IT department first, followed by distribution out from there. Big Bang projects are sometimes attempted but are risky. Depending on corporate culture, a non-home-office IT unit that creates a reusable service may need to focus on getting the home-office unit to adopt it before focusing on other units.
Cross-system process concerns - Similar to the unification model, each business unit can benefit from SOA by allowing enterprise processes to cross many systems. To make it simple, repeatable, and adaptable (which is a core competency of replication businesses), 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 the home-office IT group may decide to implement SOA, each of the IT teams in the business units 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 service is propagated out. This may not be a large overall cost, because the IT staff in the non-home-office units is often quite small.
Centralized Service Catalog - Similar to the unification model, you are likely to end up with a single catalog. See the advice for layering in that model.
Conclusion
The Service Oriented Architecture for the replication operating model should take an innovative and consensus based approach to delivering business value through process efficiency. The sharing of information is not a key driver for SOA in this operating model.