SOA is Turning Things Upside Down

In my recent post about "Layers" and "Patterns", I was trying to argue the importance of "Services" and their role (as not the only player) in an SOA. With that said, I am being reminded of a diagram I used to see describing Enterprise Architecture Frameworks by decomposing an organization into "Layers".

Wikipedia currently is showing this image:

I believe the intent was two-fold. (1) Identify specific roles and domains and (2) show respective hierarchy to one another. The latter may be more subtle, but clearly it is important for architects to understand the Business artifacts come first, then the data, then applications, then technology so why not stack them like the diagram suggests. However, I was wondering why the triangle was chosen? By using this representation, it seems to typify another generalization, albeit maybe unintended. The domains on top are smaller then those on the bottom. Was this on purpose?

I am pontificating now, but is this because we think we need to put more effort in terms of output for those with larger area? Is this true and if so why not more outcry from the business? Or maybe we all realize that in practice we see our architectures made up of more from the bottom then the top? If nothing else, even today I see more energy, more conversation, more debate and more specialization in the technology space then any other domain of Enterprise Architecture. Is this age-old symbolization of architecture the genesis of unintended consequences: Technology is King and the business is it's humble servant? How can that be, the business is at the top right?!? Well maybe better said, Technology is King and the business is it's diadem.

Consider flipping the triangle. Where not only is the business at the top but also consumes the most area. Then follows data, applications and technology where the bottom is smallest portion of the architecture. I know this would never fly due to experts smarter than I saying, "It all points to technology and thus counterintuitive" or my favorite, "It does not have a flat foundation, how can it stand?" Even so, I believe there is some merit in this new depiction.

With the advent of SOA traction in Enterprise Architecture, it should ideally minimize the importance, effort, and landscape of technology. In a very real sense, technology is merely the interface gateway and maybe infrastructure to the enterprise. The process modeling, data management, decision intelligence, service components should begin to be extracted from the technology space and become more common place in the business domain. BPMN, BPEL, rules engines, process improvement and the like are forcing us to get the business people more involved in architecture - the true allure to an SOA.

And since I am busting down some long-standing doors, why not even change the domains slightly. Why do we even need to bring up Applications anymore? In the past we modeled our business after COTS or IT limitations, so the application domain is where the real business logic resided. This lead to it being recognized as it own domain. Now we realize we should model our architecture, systems, technology after our business. Allow agility to enable technology to meet the individual need. In this sense, the application domain has become a Service Layer. Business oriented services that interact with applications, data or people. I would still agree that the data domain trumps the service domain in both significance and effort thus higher on the diagram. Finally that leaves the business at the top that is most important as well most invested in. The business thus leverages data, services and technology to build the very processes and methodologies that model their goals, motivations, differentiations, etc.

My new diagram would look like this: