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.

More then Just a Connection

Consider your internet connection (Information Bus).  Even with best throughput, it means little without a web browser (System Interface).  Add your browser of choice and you are not going very far without specific web addresses or Google (Service Discovery and Definitions).   Once you determine your desired URL, you then need to manage potential user credentials, maybe even VPN requirements and at a minimum play tip-toe around your local anti-virus software ensuring you can even get access (Governance and Security).  If you are lucky enough to make it through all that, you land on your page of information and then what?  Well in today’s 2.0 world of portals, viral advertising, RSS feeds, blogging and other “features” designed to provide data; you quickly navigate and disseminate (Process Engine) to extract the thoughts that are the most important to you.  So you still think you can get around with just connectivity?

Maturity Model

So is SOA about connectivity, or the data?  Is about interfaces or standards?  Does it have anything to say about governance or process improvement?  SOA is a guideline to all these challenges and purports to deliver a clear roadmap to tying these concepts together.  Oshyn’s approach is one that boxes SOA into distinct degrees of maturity growing an integration landscape from the “Connected-App” to the “Complete-App”.

Every integration project starts with the need to connect.  Delivering a Connected Middleware Application is valuable but is greatly limited in its overall enterprise relevance.  Its value increases significantly at this point in a ratio indirectly proportional to its maturity.  It’s a rite of passage from the Connected-App to the Consolidated ESB Application, but one that immediately demands attention from the business community (after all its their attention we want – they hold the budgets).  From there, the proposition evens out, where each step adds the as much value as the next.  What this diagram does not show is level of respective efforts.  In truth, the amount of work to move from step to step is more of a function of architecture (understanding SOA as a collection of practices) than it is anything else.  A properly planned, designed and executed SOA should be able to move through maturity model with increasing efforts – not decreasing where the first step is this insurmountable endeavor, but just do it so you can reap all these benefits a year down the road.  Quite the opposite, SOA infrastructure is fairly straightforward and with current toolsets fairly easy to implement.  SOA Value-Add can typically involve much iteration to get it right from designing the Enterprise Service Layer (ESL) to agreeing upon composite application ownership and scope.

The Evolving App

The Connected-App is just that – an application landscape that is able to cross-communicate.  The focus is on both interface management and data modeling.  This is the first degree of integration maturity – data level problem solving.  Here we apply adaptor patterns, common data models (CDM) and mapping translations along many other techniques to achieve enterprise plug and play.

The Consolidated-App is maybe the most critical maturity milestone to reach, and interestingly often of the most overlooked – in favor for delivering the “Composite-App” as soon as possible.  However doing so will also most certainly be a recipe for low ROI ignoring the most significant advancements in integration from the last decade.  Consolidation origins are birthed out the evolution of data-level integration through message and event driven interoperability to true process execution.  Consolidation is to solidify and unify an integration landscape with both message and process architecture that defines the organization scaling across the enterprise.  The focus here is not just the use of an ESB, rather defining its place as simply an enabler for the events that make up the process, with the emphasis being on the later.  Integration maturity and, in turn SOA ROI, is as much about process engineering as it is connectivity.

The Composite-App is the SOA playground.  The next step with plug and play processes is to leverage them.  Often touted as agility, the composition is the icing on the integration cake enabling those rich and necessary consolidated business processes to be used over and over in a multitude of use cases.  Truly this is the “service” oriented allure of SOA – its technical versatility to provide value to the ever-changing business.  Composition is a landscape where the library of services and access to the system’s they represent allow the freedom of erecting powerful business solutions quickly despite technology stacks (new or old) that are part of your organizations core competencies.

The Complete-App is a today’s representation of a mature integration landscape.  As with any software deliverable it must be production ready and enterprise robust to withstand the flurry of diverse transactions it is to encounter.  For SOA this can take on various forms to meet the needs of industry verticals, but usually focuses on one more of the following: Business Activity Monitoring, Policy Management and Governance, Security measures as well as actions for High Availability (HA), High Performabilty (HP) and what I call High Maintainability (HM) for production support.  The most mature SOA implementations include all of the above as implicit architectural decisions early on as opposed to add-on after thoughts.

At this point it is essential to note, that maturity model expressed here is not meant to be understood as a project plan methodology.  As a matter of fact, if a integration project was to start by delivering the “Connected-App” without first architecting the “Consolidated App” as well as defining the “Composite App”, that project has little hope of delivering ROI on its SOA, and has taken a time machine backwards doomed to make the same mistakes that eventually made speaking letters E.A.I. forbidden and punishable.