Capital One has repeated that phrase to me so many times, it's amazing.  The fact that I cancelled my Cap One card after they charged me 10 times the fees of any other card means that this phrase now has another meaning... what should NOT be in my wallet.

Applying that to architecture...

One cool thing about EA, we get to think about the future.  What capabilities are required by the company, in the future, in order to meet the needs of a vision, a business goal, a dream...  It's fun.

So I'll ask "what's in your roadmap?"

A federated ESB?

A common information model?

Matrix or Cloud database management?

Business process execution engines?

Near-real time Business Intelligence?

B-to-B federated identity management?

What bit of esoteric infrastructure or wild-eyed darn-near impossible business requirement is creeping into your five year view? 

I'd love to know...

I'd like to draw a distinction that I should have drawn before.  I had an interesting discussion in e-mail after my previous blog post on EA and Customer 2.0.  I suggested that Kai, our persona for Customer 2.0, learned how to write code and develop mashups in school, but she doesn't need to use that skill because we would have to provide her with a beautiful experience...

That created an unintended perception in the mind of one reader: that only mashup artists and bloggers would qualify for my definition of Customer 2.0.  That is certainly not my intent.  My definition is not so narrow.

I do believe that Customer 2.0 is far more 'internet literate' than I was at the age of 20.  That said, she is not a geek.  On the contrary.  She is a digital native, and has no tolerance for poor quality services or navigational dead ends or any of the things we overlooked when HTML was cool. 

She will not decide where to put her hard-earned micro-transactions and ad-clicks on the basis of geekiness.  She will choose largely based on unique interests, self-defined identity, and membership in one or more communities. 

Therefore, while the early adopters, bloggers, and mashup artists who help to build the communities are clearly included in the definition of Customer 2.0, so are the men and women who use twitter to keep up with their friends, or write quick notes on other people's Facebook pages.  They will listen to new music that their friends are listening to, and will visit restaurants and clubs that their extended community recommends. 

Customer 2.0 is motivated by community.  Mass marketing is not as effective, but word-of-mouth advertising is more effective than ever before.  Acquisition is difficult.  Retention is everything.  Brand matters.  Cool matters.  Trust matters.

Geekiness is OK, but not required.

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.

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.

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

Artificial Constraints and the SOA Message

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

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

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

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

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

The Diversification Operating Model

"Diversification applies to companies whose business units have few common customers, suppliers, or ways of doing business.  Business units in diversified companies offer different products and services to different customers, so central management exercises limited control over those business units." (Enterprise Architecture As Strategy, by Ross, Weill, and Robertson)

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

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

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

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

IT in the Diversification Operating model

For those folks new to this series: The operating model is the single largest driver of decisions in your SOA.  The impact of the model starts with the business, extends through business funding of IT, and into the architecture, design, and complexity of the IT ecosystem. 

In a company based on the diversification model, the following situations are typical:

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

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

SOA and BPM in the Diversification Model

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

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

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

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

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

So, where does Enterprise SOA lie?  Nowhere.

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

And there is no good reason to make them coordinate. 

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

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

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

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

The common data model

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

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

Business Process Management

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

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

Funding SOA

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

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

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

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

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

Direct Impacts of the Diversification Model on SOA Operations

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

Conclusion

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

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

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.