SOA, Redefined

Once upon a time, SOA (short for Services Oriented Architecture) was the king of IT Hype; for years people talked incessantly about it, attempted to extol its virtues and many tried using it within their own enterprise environments. SOA has had mixed success over the years, but that's somewhat hard to measure for a number of reasons, including:

1. There were conflicting definitions for it to begin with - some viewed it more as a practice or design approach, others viewed from a product perspective and still others saw it as a standards focused phenomenon. 
2. What SOA was has morphed quite a bit from where it began - it has changed so much in fact that it can hardly even be referred to in its own context any longer. We'll explain that in a minute. 
3. It was never entirely clear from the initial hype, what the real benefits of SOA would be if adopted. That has changed somewhat since the mid-to-late 2000's but that's only because the solution context evolved.

SOA drives design on the right side of this picture...

So, let's back up for a moment and first look at what SOA at several different points over the past decade. 

In the misty depths of the turn of the new millennium...

• In 2004, innovations in software engineering - notably the notion of Object Oriented programming techniques and languages along with pattern-driven design had begun to change the perception that applications must handle redundant tasks each time they faced them. In other words, the notion of software that could be shared as services through abstracted interfaces was becoming popular. The core design concept was extrapolated outwards to an enterprise scale and the first serious discussions about SOA as a practice or set of architectural principles began in earnest. 
• On a parallel track, the W3C (World Wide Web Consortium) Microsoft and several other companies began plotting out a standard communications protocol for linking software objects or services across the Internet. The standard, later called SOAP (Simple Object Access Protocol) was part of a larger set of W3C standards including XML, XHTML, CSS, DOM, WSDL and UDDI which when taken together would provide standard approaches toward encoding data, passing it and locating the places it was hiding as well as defining the format for how to display it. SOAP was adopted in 2003. 
• Also around this time a set of data management technologies emerged; partially based on EAI (Enterprise Application Integration) and ETL (Extract Transform & Load), that linked SOAP with Services concepts in the context of data movement. This new technology was called the Enterprise Service Bus (ESB).

fast forward to 2006-2008...

• A vast array of products have been restructured to accommodate the design principles which have matured somewhat. These products were formerly application server platforms and other governance management tools among others. The "SOA Stack" had been born.
• Industry hype probably reached its apex around this point. SOA projects were popping up everywhere and the idea of what SOA meant was little clearer.
• That definition focused on key design principles (such as "loose coupling" and "encapsulation" both borrowed from Object Oriented Design) and core elements of the stack (which had just evolved) - so the typical SOA solution would follow the principles and use the stack (starting with an ESB, then applying a UDDI registry, governance tool, business process manager and the appropriate app server / container, such as weblogic or websphere etc.)
• Java figured prominently in the SOA landscape, which only makes sense given that SOA evolved partially from Object Oriented Design techniques and principles. Thus, a great many of the SOA projects chose J2EE as the development language because it was designed to support OOD. 
• Some larger organizations, like the DoD, wanted to take this all further and bundle identity management and infrastructure services along with SOA initiatives. This was the beginning of a transition from consolidated hosting environments to Cloud Services in the Federal ecosystem. 
• On the commercial side, something called Software as a Service began to emerge at this time (it had in fact been around before then but got rebranded as SaaS). It involved the notion of a subscription to get thin client applications served directly from the service provider.  
• Virtualization becomes an interesting way to not waste CPU cycles in the datacenter.

2010

• Dave makes contact and the next generation of HAL computers malfunctions yet again! - sorry couldn't help throwing in the obscure sci-fi reference...
• Smart phones conquer the world. This part is accurate - it did happen and it came as a bit of surprise. It also changed the way we looked at development platforms, delivery platforms and 'object communication.' RESTful services, which had been around for awhile, got a huge boost in large part to the explosion of 'apps' being developed and deployed to IOS and Android devices. SOA would never be the same...
• Let's not forget DropBox, Google Drive and a 100 other Cloud offerings that began appearing around this time. Infrastructure got sexy.
• Oh, and everything turned "Agile."

2012 - 2014

• The longest war in American history still isn't over yet. When it started, enterprise IT was still largely mainframe driven - ten years later - what diversity we find...
• The popularity of Object Oriented Programming has hit the skids so to speak. This is because the scripting languages have overtaken J2EE in popularity as those languages support Agile and mobile platforms better (J2EE is still around of course, but then so is Cobol - the coding is on the wall). 
• People seldom refer to SOA projects anymore - or SOA has become synonymous with application architecture where organizations have more or less adopted the principles. Often times now its being done with REST instead of SOAP.

So, now that our tour of the past decade has brought us full circle back to the present; how would we go about defining SOA in 2014? Wikipedia defines it almost as a single pattern - others - like Thomas Erl - have written very interesting books on it.

Services Oriented Architecture (SOA), Redefined

SOA represents a nexus of design principles and standards for internet-driven applications. There is an implied reliance on specific toolsets that support the resulting services created based upon those principles and standards, but those tools do not define SOA any more than Object Oriented Design is defined by Eclipse. In other words, you could conceivably use any number of other tools to produce a solution that might conform to those principles or standards.  

The notion of enterprise services, Managed Services and Software as a Service (thus much of Cloud Computing) are natural extensions of the core SOA concept, but aren't SOA (anymore than SOA is OOD even though it is largely derived from it). SOA or for that matter OOD can be used to help facilitate parts of these other solutions. 

In the context of our blog here, I like to think of SOA and OOD has subcategories within the practice of Application Architecture (which itself fits within Solution Architecture). Management of enterprise services which may have been created using SOA fits into Infrastructure Architecture. Obviously, when one works on an application service that is intended to have a Cloud or SaaS element to it (or must rely on enterprise services to function), multiple architecture tiers or practice areas will be involved - which is another good reason to have IT Architects who can handle it all, right?

opyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc