/2007

Focusing on Customer 2.0

By |2007-11-23T13:19:00+00:00November 23rd, 2007|Enterprise Architecture|

There’s been talk, for years now, about concepts like Enterprise 2.0 and Web 2.0.  We are all so enamored with technology, we sometimes forget that it is about the customer.  There is a Customer 2.0 in here, and I’d like to speak to her.

Have you met Kai?  Kai is the name that we (the MS IT EA Team) are thinking of giving to Customer 2.0.  She is young and lively and one of the most demanding customers we’ve had to deal with on the web.  Know why?  Because she expects us all to grow up.

Geeks and Nerds: Kai is calling to you.  She is calling to you to make her internet experience Fun, Social, and Engaging.  If she uses your services today, that does not mean she will use them tomorrow.  She is brand loyal, but your site will hold her attention primarily if it holds the attention of her community.  Her group.  Her peeps.  Welcome to the fad.

No more expecting Kai to live with badly designed sites.  She learned about programming in high school (or middle school) and is unafraid of making her own mashups.  That said, she doesn’t need to.  You will provide something beautiful to her.  She is outright offended when she sees a site or service that she feels is not professional or trustworthy.  She’d never hand her friends over to something klunky. 

A few demographics will bring this into focus.  Kai may live in a western country… or not.  She is as likely to be speaking Mandarin Chinese or Hindi as she is to be speaking Spanish or English.  Gabriel Morgan put up a good post on the facts surrounding this interesting new person.  (link fixed –nm)

In Enterprise Architecture, we are innovators.  We talk about, and hopefully practice, the fine are of alignment.  We want the business and IT investments to align.  But we cannot possible do that unless the IT team is drawn towards the same destination as the business is.  We have to understand the aspirations of the business, and then understand the needs of the customer.  Only then can we look at where her needs coincide with the services we offer.  Only then can we justify the investments we are making.  That is alignment.

In order to go after a customer like Kai, we need to be a different company, and we need our IT department to change.  This is the crux of Enterprise Architecture.  It is not just about aligning to the business… it is about aligning with the business to the same end goal: the customer.

The first step towards building a new Enterprise Architecture is understanding how different we need to be in order to meet Kai’s needs.  So we wrote down Kai’s needs.  (Marketing to validate).  From that, we looked at how the business will need to react to meet Kai’s needs.  Then we looked at how that will create or exacerbate the forces on IT. 

Honestly, unless we change, we will snap into pieces.  IT cannot possible hope to deliver to a rapidly innovating business model without changing the way we do business.  And that is where EA comes in.  If we are to change… how do we do it?  Change without a goal is chaos.  It is up to EA to envision not only the application infrastructure, but also the organizational roles and responsibilities within IT, that will make IT successful as we work, as a company, to win over Kai.

This new customer, and our desire to chase her, is the compelling event that drives SOA, and that pushes us towards a coordination model.  That understanding lives in EA.  And honestly, no where else.

Politically, Can I live without an enterprise canonical data model?

By |2007-11-21T09:33:00+00:00November 21st, 2007|Enterprise Architecture|

Finally, getting back to “normal” blogging after my series on the CISR models.

By the way, Microsoft is a diversification model company… where enterprise canonical models don’t exist.  We are moving towards a coordination model, where specific elements of an enterprise model exist, but the majority of the model is not governed.  That move is being hindered by a lack of consistent governance.  No one is comfortable with the idea of governance. 

What is the impact on Enterprise SOA if we don’t have an enterprise canonical data model? 

Some folks have been busy trying to create an enterprise canonical data model for Microsoft IT.  They have gotten a good measure of success in the analysis effort, in some areas, and I applaud their as-yet-unfinished work.  It is well on the way to being ‘as complete as a coordination company needs it to be.’  However, no enforcable process exists to insure that (a) it is evangelized, and (b) governance is applied to make sure that projects in other teams align to it.  In other words, despite the best efforts of a few, our long-term success in this area is probably less than 10%.

Ah, this is where the life of an EA is as much ‘political’ as it is ‘technical.’ 

For want of clear direction on our Operating Model, we don’t have executive committment to share
For want of executive committment, we don’t have project-level cooperation
For want of project cooperation, we don’t have a workable data model that others can leverage
For want of a useful data model, we don’t have message consistency between systems
For want of message consistency, we don’t have the ability to substitute one service for another
For want of substitutability, we cannot lower costs or speed up innovation: our business drivers
For want of business effects, we cannot demonstrate results from SOA investments
For want of justification, our funding support could dwindle
For want of support, our funding for next year could be cut
For want of funding assurance, some SOA folks are hiding their work so that it doesn’t look ‘cuttable’
For want of openness, folks who want to use SOA services, cannot find them
For want of discoverability, SOA soldiers proceed merrily creating new services in a pall-mall fashion
For want of reuse, some IT leaders see little advantage in the newest fad, SOA

It goes on and on.  I don’t know if the folks who so oppose the idea of a canonical data model have any idea of the effect that they can have on an IT paradigm.  Mostly, they are doing it for measurable reasons: to make a short-term deliverable goal more successful by removing scope from the project.  There is no counter-measure: amount of cooperation with a data model initiative… yet.  The long term effect is corrosive.

Microsoft IT is without a CIO these days.  No major changes will occur in the interim.  No one wants to go and try to “sell” a program that may not be supported by the new CIO, when he or she arrives.  That would be an expensive mistake, from the standpoint of a career.  So, as funding approaches, I look around and wonder: just how much of Enterprise SOA will remain standing in Microsoft IT two years from now. 

Who knows?

Happy Thanksgiving to my American friends.

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.

SOA in the Unification Model

By |2007-10-27T15:16:00+00:00October 27th, 2007|Enterprise Architecture|

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

What can you get from this series?

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

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

I am hopeful that this series helps folks to

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

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

The Unification Operating Model

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

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

operational models - Unification

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

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

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

IT in the Unification Operating model

As I said before, the operating model is the single largest driver of decisions in your SOA.  The impact of the model starts with the business, extends through business funding of IT, and into the architecture, design, and complexity of the IT ecosystem.  In a company based on the unification model, the following situations are typical:

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

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

SOA and BPM in the Unification Model

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

The common data model

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

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

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

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

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

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

Funding SOA

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

Direct Impacts of the Unification Model on SOA Operations

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

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

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

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

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

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

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

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

Conclusion

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

SOA in the Coordination Model

By |2007-10-19T21:12:00+00:00October 19th, 2007|Enterprise Architecture|

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

Quick note about the CISR models

Before I go into a lot of detail about the operating models, I want to make one thing clear: The operating models from CISR follow the same laws as any other reference model.  To whit: “All models are wrong.  Some models are useful.” 

In other words, most enterprises will exhibit behaviors of each of the four CISR models in one aspect or another.  That said, most businesses will exhibit the behaviors of one model more than the rest.  This is usually apparent in the financial filings of the company (annual report, 10-Q) because it is difficult to hide the operating model of a company when you have to tell investors how you plan to deliver value in the coming year.

Also, as with all models, before you assume that your business is a Coordination model, make sure that you ask the business, not the IT team.  Best case: ask the executive leadership (CxO level) to debate the point.  It does no good for IT to have one view and the business to have another (path of pain).

The Coordination Operating Model

“The Coordination model provides integrated service to each key customer group.  The integration results from sharing key data across the business units to present a common fact to the customer.” (Enterprise Architecture As Strategy, by Ross, Weill, and Robertson)

operational models - coordination

The illustration that I use is above.  I have similar illustrations for the other models in the overview page. 

How to read this image: a single gray horizontal box represents commonality across business units.  In this case, a coordination model company will share customers and partners, even though each of the business units are managed seperately.  The business processes are distinct by each business, as is the operational data, but it is all brought together in the business intelligence as a way of understanding the customer from a 360-degree view. 

The example provided by Ross for a Coordination model company is Metlife, a financial products company that provides insurance and other financial services to millions of customers.  The customers themselves may qualify for, and should benefit from, the products of many different business groups.  However, each group may have their own “view” of the customer that is pertinent to their business. 

IT in the Coordination Operating model

The business model is the single largest driver of decisions in your SOA, whether you know it or not.  The impact of the model starts with the business, extends through business funding of IT, and into the architecture, design, and complexity of the IT ecosystem.  In a company based on the coordination model, the following situations are typical:

  • Shared data sources – in order to “bring together” the results of many different transactions into a rational Business Intelligence view, systems across the enterprise typically consume a set of core data tables, often from a small number of “source” systems.  If you agree on the ids for things like “country” and “operating unit” and “employee”, then business intelligence becomes possible. 
  • Coordinated Transactions – a business transaction in one business unit may affect the view of the customer in another unit.  For example, it would be rational to offer a discount on auto insurance to a customer who has purchased life insurance.  You may also have a situation where the revenue from a single customer has to be divided up among two or three business units for reporting. 
  • Integrated Business Intelligence on customers, products and suppliers – If you make no attempt to understand your customer in an all-up view, you are probably not in this business model.  The goal of this (frequently expensive) business activity is to provide insight into the patterns and behaviors of your customers, both in how those patterns work to the company’s advantage and how to root out sources of customer dissatisfaction. 

Note that, in the coordinated model, each of the business units is managed separately.  This allows business leaders a great deal of flexibility (and accountability) for making their part of the business successful.  It also means that the IT group tends to be divided up so that there are separate funding or reporting models to each of the different business units.  Centralization is infrequent, and coordination (of funding, of architecture, of standards) requires consensus.

SOA and BPM in the Coordination Model

The Coordination Model is interesting because (a) SOA can provide real benefits, and (b) this is the most difficult of the four models in which to create a SOA.  That is because of the impact of separate business management on IT funding, especially of a shared infrastructure like “common data models” or “common messaging standards” or even “common OS platforms.”  Anything ‘common’ is difficult, because the business units do not typically provide an incentive for their IT teams to create common models, and yet commonality is the key to getting value out of SOA.

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

Distributed / Federated Process Management – Each business unit manages its own processes, using its own tools.  Processes are rarely coordinated across business units.  This is a fact of life for the BPM tools, and frequently there is little business value behind forcing all business units to use the same BPM tool, since they cannot share the primary value chain processes anyway.  Common corporate processes (like HR and Finance) are typically the only exception to this independent spirit.

Distributed / Federated Governance Model – A favorite topic among SOA folks is governance.  Governance has many meanings.  SOA Governance tools may prove ineffective if you use the tool to find a service, because you may not be able to tell which of your businesses paid for that service.  This is important because the businesses themselves are quite likely to affect the amount of governance they want to occur, and therefore the governance rules that “their” services are to be judged against.  

Semantic dissonance in the data – Making a service that is useful is nice.  Make a service that is reusable is great.  Getting two or more business units to adopt the service is darn near impossible.  That is because, in this model, you are expected to integrate the data, but not the business processes.  This usually creates a situation where the “semantic understanding” of the data is quite different between businesses. 

For example, in one business, a purchase order may be created by anyone but is followed by an approval process if it exceeds a threshold.  In another business, the purchase order cannot be created until the approvals have occurred, and perhaps, all purchase orders require approval. 

So, if you look in a database and you see a purchase order… has it been approved or not?  The answer depends on the business unit that created it.  While this example is overly simplistic, the goal is to show that, for some core business entities, there will inevitably be places where the underlying states for the information cannot easily be aligned.  This is semantic dissonance, and it makes Enterprise SOA a distant fantasy for those enterprises who are unprepared or unable to muster the consensus needed to find the commonalities in the various business processes. 

To bring together the full benefits of SOA will require a costly process to align the events that create your business documents and to create a shared understanding of “when the purchase order becomes a purchase order.”  That says nothing about “what data is in a purchase order” or “what system does a purchase order live in.”  All of these variables create complicating effects on Service Oriented Architecture.

Consensus processes for designing and deploying SOA – the decision to deploy Service Oriented Architecture cannot be made by one central group.  It must be made by many people, working together.  In a “coordination model” company, centralized groups are rare and often quite small.  They don’t have the clout to bring about the kind of change needed to deliver truly reusable services.  That requires “virtual teams” or “steering committees” that are often difficult to manage and can seriously delay deployments.

Service consumption is voluntary – Ever heard this fantasy: “If you build it, they will come.”  In a Coordination model, this idea, far fetched in any model, is downright silly.  IT projects, especially ones funded by different business units, are going to have a difficult time explaining to their business why they created a service that another business can use… especially if they don’t get some benefit out of it.  Reusable services are more expensive than point-solution services. 

Plus, reusable services force the IT team writing the consumer service to take a dependency on another team for delivery.  That nearly always causes problems.  Therefore, the only services you can easily reuse are services that (a) developed by the same business unit, or (b) are dictated from executive management, or (c) are so “thin” that they provide no real processing, and therefore, no real value.

Federated Service Catalog – Since processes may be different in each business unit, but some data elements are expected to be shared, it is typical to see one of two effects on the service catalog.  Either (a) each business unit has it’s own catalog, or (b) one common catalog exists, but each service is flagged with whether that services is “core” or if it is provided by a particular business.  The assumption is that non-core services will only be consumed by applications that are part of the same business unit as the service publisher. 

Conclusion

The Service Oriented Architecture for each of the business operating models will be quite different.  Those differences can determine not only how difficult it is to create a SOA in that business environment, and the amount of business value that can be generated by doing so.

SOA and the CISR Operating Models

By |2007-10-12T11:04:00+00:00October 12th, 2007|Enterprise Architecture|

I’m begining a new series on Integration.  Five parts.   Clear up some of the noise on SOA.  This series will refer to the set of four Operating Models described in the excellent book, “Enterprise Architecture as Strategy” from the great minds at MIT’s Center for Information Systems Research (CISR), Jeanne Ross and Peter Weill.  If you have not read the book, that’s OK.  Working Paper 359 on the CISR site will provide the right level of depth (there is a free registration on the site).

To quote from the working paper:

Companies make two important choices in the design of their operations: (1) How standardized their business processes should be across operational units (business units, region, function, market segment) and (2) how integrated their business processes should be across those units.

That’s two variables.  Assuming each has two values: Low and High, and you get four possible combinations.  Ross gave these four types of models different names.

  1. Low Integration, Low Standardization – the Diversification Operating Model
  2. High Integration, Low Standardization – the Coordination Operating Model
  3. Low Integration, High Standardization – the Replication Operating Model
  4. High Integration, High Standardization – the Unification Operating Model

I’ve illustrated these models in this way.

operational models

The book I mentioned above goes into excellent detail on the implications of these models, and what kinds of companies are well suited to each model.  Using success as a guide, you can quickly see how these two choices: Integration, and Standardization, drive huge effects across the organizations of these companies.  They also drive the kind of “Big Picture” Enterprise Architecture models that the organization should produce, because each one benefits differently from EA.

Many folks now believe that SOA and EA will gradually combine, so that they are two parts of the same message.  That story is interesting when you consider these four models, because SOA is radically different in each one.  I believe it is true, because the four models each benefit from both EA and SOA, but in different ways.  I believe there will be four types of Enterprise Architecture organization, and for each one, there will be a different set of methods, artifacts, and outputs… and a different SOA for each one.

And that is what this series will be about: the effects of the operating model on SOA.  I will cover each of the operating models and describe the effect on a high level SOA reference architecture for that type of business, as well as the technical implications with respect to governance, catalogs, standardized schema, and mechanisms for gaining unity.

Here are a list of links to follow-up blog posts that discuss the different aspects of SOA in each of the business operating models described by CISR.

SOA in the Diversification Operating Model
SOA in the Coordination Operating Model
SOA in the Replication Operating Model
SOA in the Unification Operating Model

Why do this?

I see arguments every day, in the blogosphere and in books and white papers, where thinkers disagree about the value of a catalog or the need for standards or the future of SOA in general.  The problem with these arguments is that most of the speakers are (a) correct, from their viewpoint, and (b) not changing their minds.  We have a set of entrenched voices saying different things.  So how can all of them be right?

I believe that there is more than one right answer, and that it depends on the operating model of the company.  In other words, the tools, standards, and approach that is useful for a Unification model are simply not optimal when applied to a company with a Coordination model.  That doesn’t mean that you won’t get progress, but you won’t get as much as you could without considering the operating model first.

For years, the IT thinkers have been saying “let’s get closer to the business… then IT becomes more useful.”  Guess what, folks!  There is no “THE” in business!  There are ten thousand ways to make money, and we need to serve all of them.  One size, or one approach, or one toolset, will not suit all businesses.  But chaos and cacaphony won’t suit our ability to be effective.

By using simple models like the Operating Model concept from CISR, we can create reference architectures that can be reused in different organizations to base not only their Enterprise Architecture program, but their SOA implementation, and with it, the toolset that they need to build an agile, responsive, efficient, and highly valuable IT organization.

Once the SOA leaders realize that there is more than one right answer, we can begin to have productive conversations, not about whether a catalog is needed, or not, for everyone, but what role a service catalog plays in a Coordination operating model SOA, and how that role is different in a Diversification model.  (it is, wildly).  Consensus can be reached if we understand the scope of the problems that we are trying to solve.

That is my goal. 

A Tale of Two Visions

By |2007-10-11T09:17:00+00:00October 11th, 2007|Enterprise Architecture|

As I am called upon, more and more, to present a clear “vision” for how SOA will occur, I realize that folks are using the same words for two completely different requests.  The trick is to provide both.

The question may be phrased as “Where are we going with SOA?” or “What is our integration story?” or “Why is it so hard to build shared services?”

There are two answers.  I need to provide them both, and if you are sharing vision, you do too.

Regardless of whether you are creating the vision for information quality, or application simplification, or a new way to manage the funding of projects, you need to provide two different vision statements.  In fact, you cannot possibly succeed unless you do.

You see, people like leadership.  They abhor pretentious noisemakers.  There’s a thin line sometimes.  And you can be the leader, instead of the noisemaker by putting yourself in their shoes.  Take the viewpoint of your audience when you share the vision(s).

First off: distant but attainable and highly valuable goal.  You have to show that there is not only light at the end of the tunnel, but that it is the light of nirvana.  You have to really sell a 3-5 year future where things that are broken today are not broken anymore, where folks do good work as a matter of course, and the business is successful. 

Second: the immediate and important first step.  Once people feel like you’ve painted your fantasy future, you need to show them what the first step is.  It has to be a valuable first step.  It has to have some use.  We must all benefit.  It also has to be a little bit painful, to make it clear that this is not a step that folks would take if it weren’t for that big-picture goal.  It has to be emminently feasable, politically attainable, and requires a small number of key changes, mostly affecting a single role.  That way, you have a small audience to influence, while you gain support from the greater community. 

Some people will be motivated more by the distant vision, others by the near term goal.  Regardless, you need both to make real changes occur.

Let’s say you want to bring in Agile development practices.  What would you need to do?

Well, you could convince a single development team to move forward with agile development.  That would work for a while.  But the other teams would not be interested in your success and it wouldn’t matter if it worked or not… after a while, the managers would move to different jobs and the department would revert to bad practices.

On the other hand, you could make your pitch to the CIO and the top level folks, convincing them of the amazing value they will get if they use Agile development practices.  What will you get?  A set of executives now expecting YOU to fix things, regardless of whether you believe you can.

You need to do both.  You need to take a pressing problem, one that is going to get solved, that is going to get funded.  With that problem, you need to convince key folks that the future of the solution is either “elegance” or “chaos” and you have the road to elegance.  However, you tell them, the entire organization cannot change at once, so you want “Just This Project” to adopt the new techniques and that will prove the value.

At the same time, you need to convince the team to take the first step.  Get training and coaching.  Start using some of the techniques.  Start using the terms in conversation.  Tell them that it is a new way and it will require unlearning some of the old habits, but that it will pay for itself.

At every step, you have to keep painting both visions: nirvana someday, effectiveness and value for now.

And then it must work.  If it doesn’t work, you will be set back, but if it does work, you will be ready to demonstrate it’s success to the people who want things to change.  And then, maybe, just maybe, they will sign up for “step 2.”

Two visions, near and far.  Both necessary.

If you don't like the senator's politics, attack his clothing

By |2007-10-10T15:55:00+00:00October 10th, 2007|Enterprise Architecture|

Pete Lacey started an interesting discussion a few days ago when he reopened the debate over the use of the term “SOA” in his blog post “What is SOA?”.  He certainly dove in to attack the idea of SOA, but did not come to any useful conclusions.

He starts by offering a humorous anecdote to explain, to himself apparently, why we need SOA.  The most interesting line is this, when describing how CORBA was a huge innovation:

“CORBA. Look, see. Interoperable remote procedure calls.”

Interoperable remote procedure calls.  Yep.  That was CORBA.  Jump down a little…

Worse, CORBA wasn’t quite as easy to use as it seemed. It was complex, nothing interoperated, it didn’t work through firewalls, and a bewildering number of specs were coming out of the OMG.

“Well, how about this new SOAP thing,” said the new new guy…

OK… so here comes SOAP to replace CORBA for what… interoperable remote procedure calls.  See where this is going?  Fast forward again.

We just need to give this idea a name.”

“I’ve heard it called service-oriented architecture,

So, according to Pete, SOA is a name for a technology, based on SOAP, used to give us interoperable remote procedure calls.  I shudder at the thought.

From there, Pete goes on to criticize SOA because it isn’t an architecture and the term ‘service’ doesn’t suit his mindset.  Heck, with that definition, he’d be right.

Give me a break!  Service Oriented Architecture is not RPC.  People who write RPC code to integrate applications have created a ball of rubber bands in their infrastructure… I don’t care if they used CORBA, or DCOM, or RPC, or Stored Procedures, or synchronous pixie dust!  When you follow an antipattern in your architecture, the technology cannot save you.

 The moment you criticize SOA on the basis of the technology, you’ve missed the point.  SOA is an architecture… a technology agnostic architecture.  It requires the basic things that are so difficult that folks are afraid to do them, and therefore the technical implementation fails and people blame the technologist… what are these so-important things that people are afraid to do?

Common Information Model

Common Business Event Model

Common Solution Model

Common Technology Model

I dare you to make any form of simplified, integrated, agile infrastructure work without these things. 

What is going to become of the ‘beloved SOA’ for those geeks who live and breathe the term?  Oh, who cares?  We will rename it and it will keep coming back, just as it has always done. Pete even suggests a new name, “Network Oriented Computing.” 

Oh… right… we renamed it.  THAT will make it work!

The concept is sound.  The concept works.  (Every implementation of SAP is based on the above elements.  SAP integrates extremely divergent systems into a single scalable platform.  There’s your proof of concept).

So stop arguing about the name, for goodness sakes.  Attacking the name of something you don’t understand is a tactic best reserved for pundits and political candidates.  If you don’t like the politics of your opponent, attack his (or her) clothing, hairstyle, automobile, whatever… something that has nothing to do with the point.

Just as Pete did.

The culture of art vs. the culture of engineering

By |2007-10-09T08:28:00+00:00October 9th, 2007|Enterprise Architecture|

You know what seperates an artist from an engineer?  Let’s say Joe designs something pretty cool.  Mary sees it and uses that design.  In Engineering, Mary is wise.  In Art, Mary is a thief.

For years, in many IT shops, and throughout the computing world, we have built a culture where it is better to write your own definition, your own design, your own snippet of code, than it is to use someone else’s.  We still reward this thinking. 

I work in the area of EA Frameworks.  There are quite a few frameworks emerging these days, and most of them are wildly similar.  The solution is right in front of us, and with some thinking, we are converging on the answer.  Yet, few people have taken the time to learn any of these frameworks (except the oldest and least comprehensive, Zachmann).  The number of people who have taken time to study two or more frameworks: geometrically smaller.

In Engineering, this would be foolish, but in Computer “Science” it appears to be simply acceptable for professionals to invent new definitions when existing ones will do, invent new frameworks when existing ones are ample, and invent new services when existing ones meet the stated needs. 

We need a broad array of people to take the time first to LEARN what is available, before inventing new things.  It is a culture of learning that is missing.  We have replaced learning with invention in Computer Science.  And as a result, we are a group of artists competing for space to show our artwork, instead of teams of engineers leveraging excellent ideas to build greater and taller and stronger constructions.

The lack of reuse is not a problem that we will solve by installing a SOA product or inventing a framework.  Building a culture of engineering requires that we recognize and reward the people who reuse other’s ideas and work, and that we remove the obstacles to their success. 

You can reuse code TODAY.  If your employer paid you to, and you took the time to learn, you could do it again tomorrow.