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:

One thing enterprise software architecture teaches us is to rely on layers.  There are various patterns and styles of layers but more than likely if you are missing layers you are missing the mark with your framework.  Inside the context of integration landscapes and even application development, the introduction of “services” has greatly improved our ability to leverage layers well – make them more understandable, reusable and frankly standard.

Services & Layers

Services can mean lots of things, from a simple exposed interface to a data object, to an managed end-to-end business process, to an  interactive SOAP web service or EJB.  But at the end of the day, the term service has become common with the “stuff” or components we should be interacting within our layers.

If it’s a data layer, then provide me data-access CRUD like services.  If it’s a domain layer, provide me with business process logic.  If it’s an application layer, provide me with interface adaptors.  It it’s a presentation layer, provide me with representational views. And the list goes on and on, but we all agree we should be employing our patterns with services in mind in both development and discussion.

Does this therefore mean all architecture lends itself to Service-Oriented Architecture?  Well – no.  Service abstraction is something service-oriented architecture leverages but in practice an SOA is far more.  Furthermore, I contend that due to this lack of understanding, there is a very high risk of creating a “Service Architecture” (SA) and missing the boat all together on the sought after “Service-Oriented Architecture” (SOA).

Service Architecture

The SA is something we rarely talk about and only whispers can be heard of it in JAD meetings, or final production audits.  As a definition, I will give it this:  An Integration Landscape focusing on providing interoperability primarily through exposing and managing services across the enterprise.   In short, take your spaghetti code and stovepipe applications – re-architect them using services and layers (ignoring the true patterns from whence they came) – and you are left with an expensive replica of what you had: a point-to-point mess only this time with fancy service names attached to all those tightly-coupled interfaces.  And just because you decided to run all this on top of the latest “ESB” you hope to god the resultant SOA guarantees all the power it touts.  For this reason, I have grown to hate the term “integration point”.  As if all I need to do is define some necessary communication /action and provide some code to interoperate and “voila”, a true “service” comes out and now we are on our way to an SOA.  Sorry to say nope – designing integration landscapes by focusing on integration points, will usually get you quickly to a place where “web” and “point” are frowned upon.  (Referring the web chaos of point-to-point architectures).  Unless of course you were going for P2P, but since this BLOG is about SOA, I would assume you are not – and thus frowning is applicable.

Service-Oriented Architecture

SOA has evolved to mean so much, maybe too much, but at the least it is associated with a series of highly desired characteristics of enterprise application architecture.  Benefits like agility, governability, real-time, guaranteed, extensible and intelligent add to our ROI while benefits like reusability, maintainability, operational efficiency, automation, auditability reduce our TCO.  So how do we ensure we get all this?  Is it even possible?  Or is SOA another ivory tower pipe dream big software vendors and consultants are helping us peddle?

Check out some of my previous postings for definitions of an SOA – but in short, I would have preferred the “S” stood for Standard.  As in the tried and true standards that have really stood the test of time and now we finally are smart enough to realize it and start repeating it rather than conjuring up something new for our own ego sake.  However, for this posting I will offer this up for defining an SOA: An Integration Landscape that provides both interoperability and infrastructure through a strategic enterprise solution embodying connectivity, consolidation, composition and completeness.  Before I get hammered by the SOA for dummies people who say where is mention of the business people, this is meant to constrain SOA as an integration landscape not a project methodology.  I am not trying to redefine IT departments and IT business as we know it, just pointing out that when I look at what was actually implemented, how can I tell if it was more of an “SA” or “SOA”.  Besides, I added words like “enterprise” and consolidation to include the “business” (yes the stakeholders and business owners are important) – you cannot achieve consolidation or completeness without the business. See my blog on SOA Maturity.

The big deal here is the combination of technology, infrastructure (IT resources and Business resources where resources are people, processes and tangible assets) and standardization in a way that shows evolution and maturity of thought on both sides.  ESBs, web services, integration points, BPM or even technology patterns can not achieve this alone.  For an SOA to begin to produce all the benefits it so badly wants to, it needs some old school experience to pave the way.  Don’t throw out all your old PM methodologies or Architectural gurus in favor for new age hype.  Slow down, question why, document decisions points, make sure you are actually modeling your business not technology or a deadline, and for goodness sake, make sure the solution everyone is going for actually makes sense.