SOA should enable diversity inside and uniformity outside: what does that mean?

Is hiding IT system complexity too narrow a focus for SOA?

"Pursue uniformity on the outside while allowing diversity on the inside."

What does this phrase from the recently published SOA Manifesto mean, exactly? Miko Matsumura questions the wording of this guiding principle (one of 14), announced at the end of last month:

"First and foremost, I chastise this statement because it is sloppy. Sloppy architecture is what got us into this mess in the first place. But more importantly, this statement reflects a narrow, IT centric view of the scope of Architecture which leads down a dangerous path.... The problem with this statement is that it ignores the concept of diversity on the outside (of the service interface)."

"Everyone is presently overfocused on the complexity of the IT Supply rather than the complexity of Demand on IT..." Miko says. "By ignoring the consumption pattern diversity, attention is only drawn to the IT problem of managing complex IT supply."

I was part of the SOA Manifesto Working Group, so here's a little background -- as I see it -- on this principle. There was actually a lot of debate over the wording of the statement, and it was originally focused on SOA as an enabler of diversity.  That is, if you have all sorts of platforms and systems -- ERP running on Unix boxes, supply chain management running on System i boxes, CICS running on a mainframe, and all kinds of other things running on Windows and Linux -- that shouldn't stop or slow down an SOA effort. To get to service orientation, you shouldn't feel pressured -- or be be forced -- to rip and replace everything just so your applications will talk to each other and exchange data.

The journey to SOA should be able to start or continue no matter what kind of tangle of systems you may have at your enterprise.

But... and here's where the wording comes into play -- this tangle should not be evident to the end user. The end user should be buffered from this complexity by a consistent interface layer that is presented to the outside world. As far as the interfaces you present to the world are concerned, there needs to be uniformity, not a "diversity." Your end users should never be concerned with rewriting or re-installing their connections to your systems.

In other words, don't let people see your mess.

It seems Miko's point is that the statement focuses too much on the internal workings and optimizing IT operations -- a valid point when it comes to SOA, which should work for a much broader purpose -- improving the business and positioning the organization for greater growth. Business processes can be just as complex and messy as IT systems. The focus of SOA needs to on resolving the complexity and inconsistencies of both business and IT systems.

Also, Miko makes the point that "diversity" is something to be supported at the user interface as well. This came up during the Working Group discussions, and it was agreed that the principle focused on the service layer. Anne Thomas Manes also discussed this phrase in her recent post on the Manifesto, noting that "'Outside' refers to the interfaces that systems and services expose to the outside world" -- versus actual consuming applications or systems.