The future can be seen, if we decide to look

Harry "Devhawk" Pierson, whom I'm glad to count among my friends, sent me an e-mail last week.  He mentioned that he was going to post on his blog about why my call for a shared global integration model was a fantasy.  "This will be fun," I thought.  Well, Harry did (See Nicks Flawed Vision).  I would like to take some time to consider his arguments.

Harry's right about one thing: I don't think small.  I'm far from alone in Microsoft.  "The willingness to take on big challenges and see them through" is one of the company's core values.  Add two more elements to the mix: I am an Enterprise Architect, so I'm PAID to look into the future, and I've been fortunate enough to contribute to the work that Microsoft is doing to build out our Software+Services offering, with is also a future-looking initiative.  Add together these three elements (Culture + EA + SaaS) and you can see why I spend so much time talking about BIG IDEAS.

And the big stuff that Harry jumped on this time: my call for a Shared Global Integration Model.  Harry provided two arguments that concluded (a) it is not possible to create the model, and (b) the model won't deliver innovation.  I will cover the first argument in this post.  I will cover the second argument, dealing with innovation, in my next post.

Let's look at Harry's first argument.  I'm filling in some gaps in his argument with things that he did not say.  I'm doing that to make the argument complete in a Logic sense.  (I e-mailed this to Harry, and he didn't object). 

1. Creating a shared architectural model is difficult and requires a huge investment.
2. No shared model exists today, so any solution here is going to be speculative.
3. Since the model is speculative, we will do it wrong, which means we will need to change the architecture many times to get it right.
4. Each change will cost money.
5. Therefore, to get to a "sufficiently good" architecture will be expensive and time consuming.
6. If the integration architecture is not "sufficiently good" then it will hinder the ability of systems to deliver value.
7. If we take a 'standards' approach, then no system vendor will have a stake in the shared architecture.
8. System vendors that have no stake in the architecture will not, therefore, invest in making their systems 'fit' since doing so hinders their value proposition, removing economic benefit.
9. If system vendors do not adopt the architecture, it becomes academic and pointless. 
10. Therefore, the idea is academic and pointless. 

There are really two logical arguments here, one feeding the other.  The first is that getting a sufficiently good architecture together will be difficult because it is iterative.  The second is that vendors won't adopt it. 

Assertion #2 is wrong.  A shared model exists in the Telecommunications industry.  An organization called TMForum has been coordinating various industry players for years, and their needs have driven many iterations of a shared process, application, and technology model that is more mature and more advanced than most of the rest of the world: NGOSS/eTOM. 

With TMForum, it has been expensive and time consuming, and many iterations have come and gone.  Vendors have struggled, and they have compromised, but their solutions are still able to compete on the basis of value.

Since their model is pretty good, and they already have vendors that have adopted it, then the conclusion reached in step 8 is incorrect.  That invalidates the entire argument.  (Note to logic fanatics: Disproving Harry's argument does not prove the value of my proposal.  It does prove that Harry's argument is insufficient to counter my proposal.  Someone else may come up with a better argument...)

With all due respect to the Luddites, market forces have been gathering for years that drive people together to create shared non-vendor-specific solutions.  Harry is right about one key element: these solutions don't come because a vendor foists it on the marketplace.  That part of my original post is not correct.  These solutions come because a handful of big customers demand it.

Let me clarify one thing: I don't work in the part of Microsoft that writes products.  I work in IT. I represent a big customer, and I'd like all who read this post to consider my voice to be a customer that is demanding the creation of a shared integration infrastructure.  I'd like to get together with other IT folks, in other industries, to create a clarion-call that all SaaS vendors can hear: we demand a pre-integrated architecture, so that we can outsource the commodity aspects of IT, and we can avoid vendor lock-in, especially in the SaaS world.

The value of SaaS, as a business model, depends on it.

Comments

• Anonymous
  January 23, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/01/23/the-future-can-be-seen-if-we-decide-to-look/

• Anonymous
  January 28, 2008
  There are lots of barriers in achieving ubiquitous pre-integrated enterprise applications, but citing Ludditism is frankly a cop out.  The issue you seem to be arguing about with Harry is with plumbing, which is the wrong problem.  The Web's got enough standardized plumbing to be a great starting point. You want to define an enterprise system by collecting SaaS-based point solutions like eggs in a carton. You are certainly not the first or alone in wondering why that's so hard.  The problem is that the economics in formulating semantic compatibility between enough point solutions aren't (yet) in your favor.   You might study the collapse of Project Green (Microsoft 2003-2006) and Project San Francisco (IBM 1996 - 1999) and let us know what you would have done different (architecturally).  IMO, they both (ironically) broadened lock-in to not just the users, but to their vendors as well.  This happened even though one was centrally developed and the other was a consortium (albeit managed under a benevolent dictator).

• Anonymous
  January 28, 2008
  Hi Erik, Give me a break.  Project Green was about bringing together all of Microsoft's business apps.  Their scope was never to create what I'm talking about. It worked, BTW.   San Francisco was a good effort, and I applaud it.  But the end result was to create a COTS package integration model.  It was too early for the Web service / SaaS trend.  There is no reason, however, not to use those standards as a starting place.  Note that they also failed to create boundaries for their systems, or to create a method of injection that would allow a new system to be inserted to replace existing functionality.  IBM didn't put a system into the framework.  They expected the partners to do that.  IOW, they made no attempt to do what I'm calling for, and that is part of why they failed... there was no competitive value to the San Francisco business framework. Thanks for your confidence.

• Anonymous
  January 29, 2008
  Nick, You are misunderstanding me.  I am actually with you on the principles.  I could have made that clearer, I admit.  I agree with your point about the San Francisco project, but not about Green.  But that's all beside the point, I raised them only in an attempt to find out whether those kinds of projects were in scope for your thinking. My confusion about your posts is that I'm not sure where you think the problem is.  In my mind, enough of the plumbing issues are sufficiently worked out.  Solving the issues at the next level up the stack requires a shared definition of data and behavior, which has been difficult.  But, is that what you are asking for?

• Anonymous
  January 30, 2008
  Hi Erik, For my negative tone, I apologize.   The stack is an interesting thing.  At the base is the messaging technology, and we got that part licked.  Next up is the data model.  So many folks have tried this that we can, honestly, pick one.  Project San Francisco could probably work, but I'm more inclined to OAGIS.   The problem is that above the data model, everyone assumes is the transaction model.  We get thousands of definitions of particular transactions that cross one boundary or another. The transaction model is not the next step up.  The system model is.  We need a partitioned space where system responsibilities are defined and partitions between them are laid.  Within those systems are information stores with definitions of their own.  That partitioning is the next step up. Above THAT is the transaction model. Everyone seems content to skip a step.  I'm not. I could have been more clear about that as well.