/Tag: Operating Models

Alternatives to the EPSC Model

By |2016-07-10T00:45:26+00:00February 16th, 2015|Enterprise Architecture|

The Enterprise Partner Supplier Customer (EPSC) Model sits as a core concept of Enterprise Architecture.  It is so much at the core of everything we do that we seldom question it.  Is that healthy?  This post will discuss the core idea behind the EPSC model (differentiation by control) and alternative ways to think about enterprise boundaries.

First off, we only name things when we want to differentiate them.  As the old expression goes, “the fish discovers water last.”  In EA, we tend not to discuss the fact that we assume a particular model of enterprise identification and enumeration on a regular basis.  That’s because the model is built in to the things we say and do.  It’s built in to our business models and our service models.  It’s built in to the way enterprises create policies and budgets and govern efforts.  It’s so deeply ingrained that we rarely question it.  Well, it’s time for this fish to discuss the nature of water.  And to do that, we have to name it.  I’m naming it the EPSC model, which is an acronym for “”Enterprise Partner Supplier Customer”.  It looks like this:

image

The view that an enterprise is a bounded thing, with suppliers feeding in, customers getting the benefits, and partners in a peer-to-peer relationship… that’s the EPSC model.

The underlying assumption of EPSC is control.  In this model, there is typically OWNERSHIP CONTROL over the enterprise.  “Ownership control” means the same people OWN an influential number of shares in each of the organizations inside the box.  That is not necessarily controlling interest.  It is sufficient interest to ensure that the all the businesses inside the box get along well with each other.  It works because employees do what their bosses tell them to do.  Take that fundamental notion and expand it to the enterprise level and you get the assumption of ownership control.

Another form of control is ECONOMIC CONTROL which is typically the case when there is a huge size disparity between the suppliers and the enterprise itself with respect to the end customers.  This happens in retail a great deal. Walmart is a textbook example of “economic control” since their supply chain requirements can drive massive costs into their suppliers without any substantial backlash.  The fundamental model above is the same so I’m not going to redraw it.  It’s still EPSC.  Just with a really big “E”.

Why do we need alternative models?

The Internet has introduced some things we expected, and some things we didn’t.  We expected the introduction of easy communication and easy transmission of data.  What we didn’t expect: the creation of the commercial ecosystem as a differentiating factor in strategy.  In other words, the creation of a product by one company that is combined with another product to be consumed by a customer dependent upon both to solve the needs of a customer that is totally unaware of either one.  This is common now in the mobile applications space.  A mobile app may be created from unique capabilities of four or more companies that are not just peers, they are collaborating peers, all focused on producing the mobile application.  Yet the customer is unaware of the grouping.

The EPSC model is completely broken for understanding this space.  It simply fails.  Because there is no boss telling you what to do.  There are only customer opportunities.  It is organic and bottom up in its very nature.

And the moment we examine the “more than one” condition, we have to open the door to the possibility that there are more than two or three or ten.  How many alternative models are there?  I do not know.  No one has enumerated them and drawn distinctions (hey, doctoral candidates… want a dissertation idea?  Enumerate these).

I will brainstorm a couple of alternatives.  This is not a thoughtful investigation of models.  It’s a brainstorm.  Take it with a grain of salt.  But I encourage you to use the ideas to expand your own thinking.

The Dynamic Collaboration Model

The dynamic collaboration model involves a series of companies that have no common ownership but who collaborate on a very frequent basis to create positive value for customers that is achievable through the combinations of their products.

image

The key to success in this model is to focus on that dynamic collaboration and to build excellent feedback mechanisms with the customer.  This kind of model can fall apart of the customer loses confidence in the collection of companies to meet their needs, and it is vulnerable to attack from alternative collaborative groupings that build better feedback mechanisms.

What other models exist?

My knowledge is not wide enough to suggest that I understand other possible models.  Perhaps recognizing more than collaborative self interest is necessary to even perceive them.  I know that there are more than one, and I’m guessing that there’s more than two.  These are the two that I can see.  Please post your own ideas and we can collaborate.

What does this matter?

Well, I’d suggest that the strategy of Microsoft under Bill Gates reflected the dynamic collaboration model, but that the strategy under Steve Ballmer reflects the EPSC model.  We can see the gradual deterioration of value and innovation during this period.  Microsoft under Satya Nadella has shown signs of moving back towards the dynamic collaboration model.  Time will tell.  He inherited a very weird beast.

But just as important as understanding Microsoft, what does this say about Google, Amazon, Force.com, IBM, Oracle, and the hundreds of other competitors (and open source initiatives) that fill the technology space?

  • Oracle seems to play in the EPSC model.  What does that say about the future of Oracle?
  • Amazon clearly plays in the Dynamic collaboration space?  Does that ensure a bright future?  How important are each initiative in Amazon when vi
    ewed in this context?  While delivery to the neighborhood is necessary, are the drones needed?  Or is that just good buzz?
  • Google… plays in both.  (Kind of like Microsoft).  The EPSC model drives their revenue, but there’s a lot of initiatives in the dynamic collaboration space.  Is this an intentional transition, or just opportunism?
  • Facebook is primarily an EPSC business, with a very large base of users.  (See economic control above).  Will they make moves toward dynamic collaboration?  Can they survive if they don’t?

This kind of differentiation is useful for making these kinds of observations.

 

Your thoughts?

Diversity Versus Replication of Organizational Processes and Information

By |2013-10-23T16:35:00+00:00October 23rd, 2013|Enterprise Architecture|

I recently had the pleasure of joining a discussion among organizational development professionals.  During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geographically around the world, should the organizational structure of each unit be similar?

The illustration that the questioner used: organization structure (org charts).  Should the org charts look alike?

As examples, he mentioned two business units of his own company, one that was fairly “steep” with a Managing director having two direct reports, both Vice Presidents, and each of them having a small number of VPs under them.  The alternative was a different unit of the same company where the Managing director had something like 16 functional managers reporting directly to him or her.

Unit one looked something like this:

image 

Unit two looked something like this:

image

The questioner illustrated his example by pointing out in the “steep” structure (unit one), the director of Human Resources was somewhere down at level four.  In the “shallow” structure (unit two), the director of Human Resources reports directly to the managing director. 

So here’s the problem he faced: the company had a hard time moving a qualified director of Human Resources from unit two to unit one, because he would be “dropping” to four levels below the managing director, and that meant less control, less access, and less effectiveness.  On the other hand, the executive in unit two, who had a large number of direct reports, frequently complained about being overworked.

Should we force each of the units to have the same hierarchy? 

Think about it.  The company had many structures, and they were different from one another, making it difficult for a person doing work in one of those structures to translate their work, their processes, and their efforts from one to another.  This limited mobility of workers and cross-pollination of skills.  It limited information integration and consistency.  It limited process reuse.  It meant that quality of the output could be quite variable, even though each of these different units produce the same (highly complex) product!

image

 

Before I go on… what do you think?  Should the company have the same structure in every one of their geographically diverse operations? 

Would you change you mind if I told you that some of those business units were two orders of magnitude larger and more profitable than others?

Which is better: diversity or consistency (replication)?

The first observation I’d like to make about this “problem” is that it is a problem by choice, and not by accident.  The organization is NOT a franchise model.  This is a large organization that has grown over the past 100 years to be a very successful company.  Most of the life of the company preceded the information technology revolution… before computers and teleconferencing and instant communication.  Each of the business units had no choice but to operate independently.  Corporate management, early on, chose to allow each of the business units to structure itself as needed based on local conditions, people, culture, regulations, and resources.  In the terms of Jeanne Ross (author of “Enterprise Architecture As Strategy”), the organization was not a replication model.  It was a diversification model.

That said, each of these business units provided essentially the same product in each of a half-dozen different locations around the world. 

Only someone who had read Jeanne’s book would recognize that the underlying question in the room was simple.  The person posing the question saw a great many advantages to having a “replication operating model,” and didn’t see an advantage to having a “diversification operating model.”  He was seeking input on whether he was the only person who could see the advantage to making a switch.  (of course, he was not the CEO, so it was a fictional exercise, but a useful one nonetheless).

Switching from a Diversification Model to a Replication Model

There are many problems with making a switch from a diversification model to a replication model.

  1. It is fairly complex to do.  An “ideal” model must be created for all of the business units to follow.  Since none of the current business units is likely to have that “ideal” model implemented, you’d first have to create an “ideal” model and then implement it in one place to get feedback on how it actually works (if it does).  That takes time.  Once you’ve made changes in one place, rolling it out means moving people, recreating processes, and restructuring information and accountability across each of those units.  It’s essentially the same a tearing down a company and starting over.  Only each of those business units will have to keep operating while it is going on, and will have to show profit at the end of the year. 
     
  2. Loss of business unit innovation.  Companies making that kind of switch usually screw up at the “ideal model” stage because creating the “ideal” model rarely involves the right conversations with every one of the business units involved.  As a result, innovations that are working well in one area can be lost because those innovations were not copied to the “ideal” model, even if they would have been useful to everyone.  Importantly, innovations that were about to be implemented in any one unit, but had not been, are completely discarded.  Evolution of the business units themselves can be thrown backward by years.  Also, by the very fact that there is now “replication by policy,” it becomes very difficult for any further innovation to occur because it has to occur once and then be replicated everyone else, regardless of whether that innovation has the same ROI in each business unit.  (Hint: it nearly never does).
     
  3. Loss of local adaptations.  There is a notion that “the person closest to the work knows best how to do it.”  In the case illustrated above, the two business units being compared were in different parts of the world, with different business cultures and business expectations.  The PEOPLE in these organizations have a specific idea of the way that business operates.  They have relationships, cultural expectations, and accountabilities neatly arranged to suit those local conditions.  Your “ideal” structure will come from you, and you live in a business culture.  We all do.  Therefore, you have assumptions about what will and will not work.  If you impose your structure on a group of people, be prepared to re-educate every single person in every single business unit on the “one right way” to do business… and then you’d better hope that the “ideal” you have created will be more effective in a local environment than the one that was previously there.  (Hint: it probably won’t be).
     

A better way

As I have explained in my previous discussions of “Minimum Sufficient Business Integration,” I believe that many modern organizations can benefit from taking the time to find the minimum set of capabilities needed across business units to meet key corporate goals.  After that minimum set is understood, the rest of the choices can (and probably should) be left up to the people closest to their customers and suppliers.  At best, a “reference model” can be widely shared that represents your idea of what an “ideal” structure would look like… but without enforcement from above.

Of course, it can take a little thought to understand what is the “minimum” level of commonality that should be imposed.  It should be very carefully considered because, and this is important, for there to be value in this concept, that level of commonality will be strictly imposed.  No exceptions.  On the other hand, every little thing included in that “common set” will be VERY expensive to roll out consistently across a wide array of business units, so the absolute minimum set should be included.

Conclusion

My recommendation for this situation is to remain in a diversification model, but to consider moving a little closer to process and information consistency through minimum sufficient business integration (MSBI).  This means having consistency for those areas that absolutely positively must have consistency, and then to allow diversity (and innovation) to grow atop that minimum set.

In that case, the org charts would probably remain different from one another… and rightly so.

Happy architecting!

P.S.: I also want to point out that the notion of minimum sufficient integration takes place at the level of business capabilities.  Not business processes.  Not information elements.  Not business functions.  Capabilities.  So if your business architecture methods don’t use capabilities (or if you don’t know what capabilities are), you cannot use this methodology.  This post is not going to teach you what a business capability is, but I’ve blogged about them dozens of times, as have hundreds of other folks including the Business Architecture Guild and the Business Architecture Society.  Start there.

Steps To Create a Core Diagram

By |2012-12-19T08:34:41+00:00December 19th, 2012|Enterprise Architecture|

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post.  I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco.  Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort.  Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

  1. Collect a list of your organization’s business models
  2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
  3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
  4. Make an educated guess about the operating model of the company
  5. Draw the core diagram and build understanding around it

 

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Metamodel for a Business Model

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizatio
ns that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

MSBI–Part 2—What is a core diagram?

By |2012-02-14T07:40:00+00:00February 14th, 2012|Enterprise Architecture|

In her wildly popular book, Enterprise Architecture As Strategy, Dr. Jeanne Ross describes the use of “core diagrams” in Enterprise Architecture.  Shortly after introducing the notion of “operating models”, she provided four example “core diagrams” from successful companies and noted that each diagram reflected the specific challenges that companies with similar operating models would face.

This section of the book is often overlooked, but personally, I think Ross hit on something very powerful.  I spend a good bit of time speaking with CIOs and CTOs about Enterprise Architecture, and I am frequently asked a seemingly simple question: what does an enterprise architecture look like?  What is the “single picture on top?”  You’d think we could answer this question!  But until this book was published, there was no notion of what the “single model on top” should look like, or why one model would sit atop another.   This series of blog posts attempts to answer that question.

If this is the first post you are reading on this topic, you have started in the middle.  Go back to this article for the overview and table of links to the rest of the posts.

What is a core diagram?

A core diagram is an Enterprise Architecture model that reflects the level of integration and standardization that the company has chosen to embark upon, boiled down to specific, tangible, elements for business and technology professionals to discuss and agree upon. 

These two dimensions: process integration and process standardization, are the two independent variables that drive the selection of an organizations operating model.  This distinction is so important to the Enterprise Architecture itself that Dr. Ross defines the concept of “Enterprise Architecture” in these terms!  According to the book, Enterprise Architecture is: “The organizing logic for business processes, data, and technology reflecting the integration and standardization requirements of the firm’s operating model.”

Going beyond the book, this post will describe the concept and value proposition of a core diagram, while the next post will describe the business scenarios in which a core diagram can be valuable.  Between these two posts, I hope to clarify the reason why your EA program should create a core diagram.

The value of a core diagram

A core diagram is a very useful EA artifact for many scenarios.  A core diagram removes ambiguity that business stakeholders either suffer from, or take advantage of, when dealing driving change in the organization.  You can provide direct EA value by removing that ambiguity, presenting clear ownership, and addressing the occasionally emotional attachment that business and IT stakeholders have to overly complex implementations.

  • The core diagram illustrates processes that must be standardized.  Depending on your operating model, some subset of business processes (from a small subset in diversification companies to a large subset in unification companies) are standardized.  The challenge comes “on the line” where there is a case to be made on both sides of the debate: e.g. “this process can be valuable by being non-standardized.”  Assuming that you have a process owner who can decide one way or the other, a core diagram can help make that decision stick.  By clearly denoting a process as “standard” or “agile” in the core diagram, the decision can be clearly communicated and ownership clearly enforced.
  • The core diagram illustrates which data facets must be managed as “master data.”  Operating models with high levels of integration will have some number of shared data facets that are available across the enterprise (in a secure fashion, of course).  Which data facets depends on your company and your level of integration.  Clarity about which facets are shared, and which facets are NOT shared, is necessary for a simple and clear set of information sharing processes. 
  • The core diagram illustrates which systems will stand as “systems of record” for the management of specific functions.  Operating models with either high levels of integration or high levels of standardization will need to denote specific systems as being the “source of truth” for master data and the “system of record” for support of standardized activities.  Clarity removes the temptation to “build your own shadow application” or to “build for one silo” (two antipatterns in highly integrated environments).

 

A core diagram specifically supports the mitigation of these anti-patterns:

  • If we build it, they will come. (Anti-pattern)
  • I am different, so I need a different process (Anti-pattern)
  • It is too much of a hassle for me to share my data with you. (Anti-pattern)

 

It goes without saying that a core diagram is not sufficient, by itself, to eradicate bad behavior.  It is NOT a silver bullet.  In addition, there are examples of companies that have succeeded in creating a mature Enterprise Architecture program without one. 

That said, I asked Jeanne Ross about the value of a core diagram and this is what she told me:

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation. It helps management understand to what extent everyone is on the same page—prior to drawing the diagram, they think they all mean the same thing, but they usually don’t.”

Jeanne Ross
Director and Principal Research Scientist
MIT Center for Information Systems Research

Personally, I believe that a core diagram is an essential part of most EA programs.  If you think it would be difficult to create a core diagram, your company is probably one that most needs one.

What are the criteria for a core diagram

A core diagram is not “just any EA model.”  It has a specific purpose and a specific part to play in the development of an EA.  It does not have a specific look and feel, although some suggestions for good visualization can be found the “Enterprise Architecture As Strategy” book.

You will know you have a core diagram when it meets all of these criteria:

  1. It is a single diagram with a clear scope representing either the entire enterprise or a specific independent business segment.
  2. The diagram reflects the difficult choices that were derived (or will be derived) from the selection of the company’s operating model(s). 
  3. A non-architect stakeholder can understand and use the model with less than thirty minutes of discussion.

Note that a core diagram is normally a “future state” model of the enterprise, reflecting the direction that the company should go.  However, this is not a requirement.  A current state core diagram could be created, as long as the compromises reflected within don’t make the diagram too complex for it to be simply understood.

Next up: Scenarios for the use of a core diagram (this link will be updated when the next entry is posted).

Creating a Core Diagram for Agile Business

By |2012-01-31T16:47:00+00:00January 31st, 2012|Enterprise Architecture|

Today, I gave my talk at the Open Group conference that presents a step-by-step method for creating a core diagram that is useful for agile business.  I will blog a series of posts on the topic to share this information to my friends and colleagues on the web.

I will create the following posts.  As I do, I will come back and edit this post to provide a link.  This post will stand as an introduction and table of contents to the topic. 

I will post the following articles:

 

This will likely take a few days, and I’d like to take a few minutes to describe each of these topics.  The talk lasted 45 minutes (at a wildly accelerated pace).  I plan to provide a better, albeit slower, set of information for the folks who read this blog.

WP_000279

Nick Malik speaking at the Open Group conference, Jan 31, 2012, San Francisco

If you’d like to see the original presentation, see the following slideshare presentation:

The responsibility of architecture is to create an architecture of responsibility

By |2011-03-09T01:47:43+00:00March 9th, 2011|Enterprise Architecture|

I cannot take credit for that aphorism… credit goes to Jan Van Til.  He coined the term after reading Tom Graves’ excellent post on the architecture of responsibility.  Tom’s post details the philosophical challenges of a responsibility-based economy.  However, I’d like to get a little more tactical in the Enterprise Architecture space, and discuss more of the “intra-company” and “intra-solution” aspects of “The Architecture of Responsibility.” 

One of the key accountabilities of Enterprise Architecture is to provide a mechanism to govern the development of corporate business capabilities. In other words, we want to make sure that specific capabilities are developed, in a principled manner, prioritized on the strategy of the business. 

When making that governance mechanism work, I find myself routinely dealing with the same issues that Tom outlines.  We do not select a system because of it’s technical prowess or smart operators.  We look at the capabilities needed by the business, and assign responsibility to the business team that is willing, able, positioned, and passionate about taking on the responsibility for that capability: shepherding and improving it, operating it effectively, remaining agile, while keeping a keen eye on both risk management and cost efficiencies. 

I’d like to point out a key aspect of governance.  It is not about assigning responsibility to a system or system component.  No one can govern the assignment of a responsibility to a system.  What can be governed, effectively, is the assignment of responsibility to a business unit.  That business unit can own information and the systems that manage it.  You need people to make governance work… not just to govern, but to be vested in the success of the “optimal architecture.”

Hence, the architecture of responsibility is the mapping of capabilities and business processes to people.  Sometimes that means consolidation to common processes, but not always.  That depends on the operating model of the business.  But always it is a problem if a particular capability within a business model has no owner.  Identifying the businesses within an enterprise, the capabilities within the business, and the owners of the capabilities… that is a key deliverable of Enterprise Architecture.

One that is not often discussed… but in the end, extraordinarily important.

Introducing: Ecosystem Quality Attributes

By |2010-08-31T19:00:05+00:00August 31st, 2010|Enterprise Architecture|

There are benefits to taking an idea from one domain and applying it to another.  We all know of the famous case of “software patterns” that emerged from the concept of architectural patterns developed by Christopher Alexander for the world of building design.  Similarly, we have recently seen the emergence of checklists in medicine which is an idea borrowed from other complex domains (like airplane piloting).

I’m going to follow in that long path of “cross-domain pollination” to take an idea from software architecture and apply it to business architecture.  Not a big stretch for an Enterprise Architect, I know, but I’ve not seen this idea discussed elsewhere.  (Just because an idea is obvious, that doesn’t mean people will think of it: witness the length of time it took to add wheels to luggage!)  That said, I leave open the possibility that prior art exists, and that I’m simply not aware of it.  If that is the case, please don’t hesitate to point it out.

The concept I’m going to borrow from software architecture is that of System Quality Attributes.  They are the various “-ities” that a software system exhibits. These include Scalability, Reliability, Maintainability, and many others.  System Quality Attributes can be used to measure the ability of the system to meet business needs.  There are lots of ways to use SQAs but I am going to focus on one specifically valuable practice.  In my opinion, the best thing you can do with software quality attributes, during system planning, is to prioritize them.

Prioritizing the relative importance of a system’s quality attributes, early in system planning, can have a dramatic impact on the design of the system.  The design is simpler, and more intentional, because the goals of the system are more clear.  A prioritized list of System Quality Attributes provides “guard rails” for the design of a system.  Creating this priority, and then driving a design to meet it, is the domain of the solution architect.

Now for the new concept: Ecosystem quality attributes

Ecosystem quality attributes are the specific measurable attributes of a coherent ecosystem of business processes, information systems, and human actors constructed to deliver the required capabilities demanded by an organization’s business model.

At the highest level, an Ecosystem quality attributes may be applied across an entire operating model.  (For the sake of this approach, an operating model is the widest example of a business ecosystem).  EQAs may also be applied at the level of end-to-end business processes within an operating model. 

Hypothesis: The relative priority of Ecosystem Quality Attributes can have the same dramatic effect on ecosystem design as we’ve observed at the system level through the prioritization of System Quality Attributes.

Managing that relative priority of these attributes for each business model, and influencing the emergence of the operating model to deliver it, and then governing the systems within that ecosystem to insure that it comes into being, is the domain of the Enterprise Architect.

Attribute Definitions

In this section, I will outline a relatively useful set of Ecosystem Quality Attributes (EQAs) that an Enterprise Architect can use to measure their business ecosystem.

Note that Ecosystem Quality Attributes measure a business ecosystem, and therefore must include information that is not available unless you work outside the “boundaries” of IT.  In other words, using a system of EQAs to measure a business ecosystem is a business method, not an IT method.

Ecosystem Quality Attribute Description
Operating Model Alignment A measure of how well the ecosystem of processes, information, systems, and roles align to meet the business model and operating model requirements of the enterprise.  The business model places specific requirements on the ecosystem, requirements which may change as external influences, opportunities, customers, and markets change.  Systems that do a poor job of keeping up the the changing requirements of the market incur a “tax” on customer loyalty, top line revenue, customer service costs, and operational efficiency that is difficult to address without systemic change.
Federation Consistency A measure of how well the ecosystem supports, defends, and enforces the vertical division of duties, responsibilities, and accountabilities demanded by a federated decision structure.  Federated decision structures are very important in each of the four CISR operating models, but they apply in different ways with different amounts of federated control.  The ability of the system to keep “true” to the principles of federation intended for the ecosystem, with a minimum of unnecessary stress, is reflected by this measure. 
Collaborative Maturity A measure of how well the people and processes within an ecosystem support collaboration, ranging from information sharing at the low end, continuous measurement as a normal practice, and continuous improvement at the high end.  Core contributors to collaboration effectiveness, like shared commitment, consistency, culture, and expected level of rigor, all play into the level of collaborative maturity of a business ecosystem.
Dependency Risk A measure of the relative strength of the ecosystem as indicated by the number of dependencies taken on immature capabilities, information sources, systems, and shared processes.  A business process that takes a dependency on a weak supporting system accepts an increased level of risk as a result of that dependency.  Business leaders may decide to reduce the number of dependencies or increase the maturity of the supporting systems, based on their preferences for business efficiency and effectiveness.
Information Consistency A measure of the consistency of the core information elements across the breadth of an operating model.  A low level of consistency drives a “hidden tax” on efficient operations and business intelligence that is difficult to quantify.  Higher consistency reduces this tax, improves information velocity, and can have dramatic impacts on the ongoing costs of maintaining a business intelligence infrastructure.
Interaction Complexity A weighted measure of the number of interaction points between independently managed business elements (business units, information systems, master information stores) needed to perform core business processes within the ecosystem.  Weight is applied to interaction points indicating the level of standardization and isolation in the interactions themselves, so that factors that lead to increased cost of ownership drive up the measure.
Readiness Complexity A measure of how difficult it is for stakeholders to the ecosystem to learn to behave within the expectations of the business processes and culture of the ecosystem. 

This inclu
des readiness with respect to key scenarios, customer requirements, conceptual ontologies, key decisions, governance mechanisms, implementation details, systemic problems, planned roadmaps, change project status, and outstanding list of incidents.

 

Open question: is this the “right” list?  Am I missing elements?  Are there attributes that are not important from an ecosystem standpoint, and if so, why?  Answering these questions will require research, and is beyond the scope of this article.  I am more than willing to consider this list to be an “initial draft” for the use and refinement of the EA community. 

Prioritization and Tradeoff Method

It is a well-accepted premise, in software architecture, that there is no such thing as a perfect system.  A system has to be optimized for its use, and in doing so, the designer of the system has to apply tradeoffs.  We accept this idea without thinking in our daily lives: that a car can be designed for speed, or towing capacity, or gas mileage, but you cannot optimize for all three.  You have to set up your priorities, and optimize the system on the basis of those priorities.  A Sport-Utility Vehicle may put a priority on towing capacity first, acceleration second, and gas mileage last.  A small commuter’s car may reverse those priorities.  Both are acceptable.

I posit that the same is true for business ecosystems.  There is no perfect operating model or end-to-end business process.  Each is designed to suit the specifics of the business that demands it, and the business culture that drives it.  Each business ecosystem has to be optimized for specific quality attributes, and priorities must be taken.

So the challenge of this level of business architecture is to illustrate the importance of these attributes and host a discussion, among your business stakeholders, about the relative priority of each.  The deliverable is a simple document illustrating that priority and commenting on the intentional tradeoffs that result. 

What are some of the questions that your business leaders will consider:

  • How important is it that your business be constantly improving?  Is it more or less important than the need for information consistency? 
  • Does your business culture foster interdependency or would you prefer federation? 
  • Do you need to be able create a copy of yourself, where readiness matters, or can the business take on large scale interaction complexity in order to create market differentiation for the products and services?

 

The process works like this:

  1. Present the ecosystem quality attributes (in concrete terms, with example tradeoffs) to a set of senior execs and host a discussion.
  2. Create a simple document resulting from the discussion that outlines the “decision criteria” that managers should use when improving their processes and systems.
  3. Run that document past the execs to make sure that they agree with your distillation of their ramblings, and with your plan to communicate the results.
  4. Communicate the resulting priorities to mid-level managers, key subject matter experts, and the folks involved in making changes to the business (especially Quality, BPM, and IT professionals who are frequently involved in tradeoff decisions).

 

Value proposition

So why should we host this discussion?  What is the value of taking the time of senior business leaders to make them consider the relative importance of complexity, consistency, readiness, (etc) in their business? 

The value is in building a company that knows what it wants, knows how it will go get what it wants, and wastes as little time, as possible, debating the relative merits of obscure decision points, or fighting political battles based on competing business goals.  The value is in clarity.  If you WANT a company that is able to replicate itself at the drop of a hat, say so.  If, on the other hand, you want a company that uses a complex set of interactions in order to create a wide array of different services in the marketplace, saying so will reduce internal “churn” that occurs when smart people are left to their own guidance about what is the “right thing to do.”

Example (Help Wanted… Looking for victims volunteers)

When I outlined this blog post, I thought “I will describe this concept with an example, here.”  However, as I got to this section, I decided that it would be more effective to ASK for your input than to tell you what an example should look like.  So… I’m looking for volunteers.  If you are an EA or a Business Architect, and you’d like to submit yourself to a two-hour telephone call where I ask you probing questions about your business model, business culture, and business behavior, then I’d like to hear from you.  Taking your input, I’d like to produce a couple of sample “ecosystem quality attribute prioritization documents,” and using that experience, refine the method. 

So if you are game for a phone call, drop me a line.  I will be in the New York/New Jersey area in about two weeks, and in the Chicago area for a few more days, in mid September.  If you’d prefer to meet in person and it works out to be convenient, perhaps we can do this face to face.  Respond by clicking the link labeled Email Blog Author in the upper right hand corner of the page.

Conclusion

I don’t find it “startling" or “novel” to say that Enterprise Architecture should directly impact the structure, function, or responsibilities of various business units.  My readers know that this is not a new proposition for me.  To the contrary: I believe that an EA that does NOT have the intent of impacting the business itself (in terms of business unit alignment, processes, roles, scope, funding, or vision) is not performing the role of an Enterprise Architect. 

The EQA concept and method is very much in the domain of Enterprise Architecture, not IT.  This method is concerned with the measurement of the structure and function of the business itself.  Where that structure and function is influenced by software systems, then IT folks would provide input.  Information Technology is not, however, a predominant concern. 

That said, the business method I described borrows shamelessly from the concept of System Quality Attributes and the ATAM architectural method.  I believe that the concept is sound and that a rigorous approach to business architecture, along the lines outlined here, has the potential for providing clear, simple, and elegant guidance to the army of business people (including IT folks) that are charged with taking the often-nebulous intent of business leaders and translating it into an effective, intentional, enterprise.

As always, dear reader, I’d love to hear your feedback.

Should IT run “like a business” or “like a non-profit?”

By |2010-03-05T17:54:01+00:00March 5th, 2010|Enterprise Architecture|

Why is it so hard to run IT like a business?  Because, I can choose to be a customer of a business, and I can choose not to be a customer.  Businesses don’t mind because there are usually lots of potential customers, so getting a market share of 1% can lead to a great deal of success.

IT does not have that luxury.  If IT is to run like a business, then its services have to be consumed by some or all of the business units.  It has to win MOST of the time that IT is in competition with an outside vendor.  The more successful any particular IT service is, the less expensive it gets because much of the overhead is spread out over many customers.  Economy of scale.  This is how businesses work.  Unfortunately, there is not an infinite supply of business units!  IT does not have a broad array of customers to compete for.  IT has a small handful of customers, and that is a problem.

If there are only three business units interested in a particular IT service, and two of them sign up, you have a 66% market share.  That’s great… until one of them decides to outsource.  Then you have dropped from a 66% share to a 33% share.  If I was an automaker, or even a consulting firm, and I have a product line that goes from 66% to 33% market share in a year, I’d go through organizational chaos.  Most businesses cannot scale back that quickly and neither can IT.  In addition to the human cost, financial costs for the service’s remaining customer will soar.

You also have the fact that IT works for the same CEO as the customer (business unit) does.  That means the CEO can issue an edict, and both the business units and IT must comply.  If the business unit chooses not to comply, but IT does comply, then the business unit has little choice but to outsource. 

You could be thinking “but how can a business unit ignore the CEO?”  For many organizations, accountability to the CEO’s edicts are governed very differently within IT than they are within the lines of business.  That is because IT is a cost center, while a line of business is a profit center.  Profit centers are given a LOT more flexibility.  Therefore, IT has a constraint that few successful businesses have: it has to comply with rules that its competitors do not have to follow. 

Running IT like a business, with these economic and market constraints, is nonsense. 

The more rational approach is to run IT as a two-headed organization.  One is a governmental agency, able to levy and collect taxes and responsible for providing uniform services to all citizens (the business units).  The other is a non-profit service provider that is under contract to the government, providing subsidized services to those citizens who need them.

The Governmental approach

Whether we want to admit it or not, this is often how IT runs.  The cost of IT is simply deducted as a corporate expense.  In other words, the cost of running IT is a tax.  In large organizations, a simple formula may be applied to determine the amount of money each business unit needs to pony up.  In Microsoft, your business unit pays a flat fee for each employee or contingent staff member that you have.  For that money, you get a wide array of networking, collaboration, security, and information management services that you don’t even think about.  The stuff is free and it runs.

The Subsidized Non-Profit Service Provider approach

While there are services that we all need, like a secure network and good collaboration and messaging tools (like Exchange and SharePoint), there are also services that some teams need while others really do not. 

For small companies, or companies with very simple business structures, this is not even an interesting conversation except to say that the line-of-business funding pays for line-of-business software.  It is still subsidized, because once the line of business application is running, the “government” side covers many of the operating, networking, and data management costs.

However, for a very complex organization like Microsoft, business-service funding can be a good bit more difficult.  That is because any single service may have five, ten, fifteen different business units that could, potentially, be their customer. 

This is where the “non-profit service provider” idea starts to take shape.

Here you can use some principles of business, like setting up a mechanism to insure that the business units who make the most use of a service are the ones that pay the most to use it. 

For example, let’s say that your company is a retailer that operates branded stores (like Gap and Old Navy).  Your company also sells uniforms to hospitals and health care institutions.  Marketing to these two different markets is quite different.  The marketing team for the branded stores will directly consume individual customer data at a far higher rate than the marketing team for the uniforms business.  Therefore, they should pay more for the “Customer Marketing Profile” services.

It is a non-profit model because you are billing the customer, but you are not billing them for the full costs, and you cannot make a profit on it.  The advantage of running IT this way is that the services provided are always competitive with market rates (due to the subsidy), while IT itself is buffered from the chaos that ensues when a business unit decides to use the cloud for a service and stop paying IT to do the work.

Conclusion

For years, we’ve heard the old saw: If only we could run IT like a business!  But really, we cannot.  IT does not have a market the way a business does, and IT cannot ignore the edicts of the CEO like an outside service provider can. 

It is far better to make a clear distinction between the services that need to run as cross-organizational “platform” services and those that support one or more lines of business.  The services that support one line of business can be funded by that line of business.  The ones that support many lines of business can use a “non-profit” model like I outlined above.   These are really two variations of the same model: the subsidized non-profit service provider.

One is government, the other is non-profit.  Both live together under one IT umbrella. 

SOA in the Diversification Model

By |2007-11-13T20:58:00+00:00November 13th, 2007|Enterprise Architecture|

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).

operational models - diversification

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.

contoso

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.

SOA in the Replication Model

By |2007-11-05T15:33:00+00:00November 5th, 2007|Enterprise Architecture|

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 company and 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).

operational models replication

Companies that use a Replication model encourage innovation in their business units but require common processes to create consistency and reduce costs.   Some attributes:

  1. Small centralized management environment
  2. Company grows through creating new operating businesses to serve different customers (often geographically). 
  3. Process standardization keeps costs low, allows for rapid creation of new operating businesses.
  4. 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.