I’ve been thinking a lot lately about the gap between “what we have” and “what we need” in the Enterprise SOA space.  I think I have a need that is not yet filled by software.  (that I’m aware of).

I put up a post back in June about the difficulty in creating a common information model in a large enterprise, especially one with a federated environment like ours.  (CISR coordination and diversification models).  The feedback I got back was telling.  The majority of respondants told me what I suspected: developing an enterprise-wide common information model was so difficult that many folks considered it unfeasable.  (Actual words included things like “utopian” and “big design up front.”  I’ll stick to “unfeasable”).

That said, I have also stated in public that I believe, firmly, that SOA at the enterprise level requires some levels of agreement on the way that information is understood and coordinated.  Each business unit can own information that is specific to that unit, but in the areas of coordination, where there is value, the business needs to be able to communicate.

So, we have something that is hard to do (build a CIM and keep it up to date).  That something is useful (to get the benefits of Enterprise SOA).  So, why not take the software approach?  After all, I do work at Microsoft.

What business scenario would this tool need to support?

Basically: each business unit would submit their information model to a common repository.  The submitters are architects, and they MUST align the models in some way, even if it is just to show that there are differences.  Services are posted to the same repository, and must be lined up under specific information models.  In order to consume a service, the business has to agree to the information model.  Multiple competing models are allowed to co-exist.  What do we get?  An economic model of self-governance that produces an optimum information model: one where agreement is reached only where agreement makes financial sense.

Specific capabilities:

  • A business unit architect can consume part of an information model without consuming the entire thing.
     
  • A business unit architect can assert part of an information model without proposing the entire thing.
     
  • A business unit architect can offer services tied to their information model.
     
  • A business unit architect can assert that a portion of an information model is “standard” for their use
     
  • A developer, writing software for that business unit, can easily find and adopt their information model.
     
  • A project team can provide a report to a governance committee proving that they are conformant to local standards
     
  • An enterprise architect can run reports to isolate “points of difference” between business unit information models.
     
  • A system designer, intent upon consuming services from another business unit, can begin a workflow to insure that the consuming business unit agrees to the information model of the presenting business unit. (an “information adoption workflow”).
     
  • The workflow needed for a consuming business unit to agree can be custom-tailored to the organization.
     
  • Organizations that present a service have an automatic measurement mechanism built in allowing them to “charge back” the businesses that consume the service.  Various financial models must be supported (one time fee, pay per use, annual licenses).  This provides economic incentive for sharing of code, as well as the incentive to create services that align to commonly needed information models.
     
  • Built in support for the versioning of information models over time (including both past and future versions) allows the business to change their minds, and even chart their course.

That’s what my gut tells me.  This has some pretty interesting effects:

  1. Information architects have a clearly defined and critical role at the earliest stages of a project: get consensus on information model changes needed to allow the consumption of existing, lower cost services.
     
  2. Economics will drive good behavior.  No need for an Enterprise Architect to “design” good behavior. 
     
  3. Less emotion.  There will not be consensus on everything, and this model doesn’t require it.  Consensus will be reached surprisingly easily on some key areas, and it will happen without any architect looking to make it happen.  This helps remove politics from the picture as well.
     
  4. It is easier to adopt existing code than build new code if services, offered by other groups, aligned with the information standards of the consuming business, are already clearly identifiied. 

We may be closer than we think.  With bits from various MS products, and with Oslo coming, this vision is getting closer to reality.  It’s an end-to-end idea. 

Something to consider.  Comments?