The New Enterprise Context for SOA
Service Oriented Architecture (SOA) has always been a fairly complicated topic, especially when compared with other tech trends such as Big Data (Big Data tends to fit into larger reference architectures where SOA can often represent its own reference architecture). The reason why SOA is that complex also helps to explain how SOA has evolved and what its role in IT is today.
First-let's delve into its complexity. SOA is an architecture pattern, it is a suite of loosely-related products, it is philosophy and set of best practices. SOA is also an enabler for a vast array of other IT capability such as the Cloud, Mobile computing and Agile Devops. It is also at its core, a set of standards for web-based messaging. The SOA "pitch" that came along with its emergence as a major IT trend essentially portrayed Services Oriented Architecture as a more or less comprehensive framework for managing most enterprise IT capability both from a design-time and run-time perspective. It was also pitched in as a one stop solution for IT integration. Many who were intrigued by SOA focused on one aspect of it as opposed to the whole, others bought into the full 'package' without perhaps understanding yet the implications of that level of adoption. This led to the typical problems that many early adopters faced:
“SOA is an architecture pattern; it is a suite of loosely-related products, an enabler for a vast array of other IT capability”
1. For those who adopted piecemeal, often there was a higher level of implementation success, however with a limited focus, the resulting benefits may have been less than stakeholders expected as these initial forays into a small part of SOA were confused with the value propositions typically associated with full SOA adoption. (a good example of this was adoption of an Enterprise Service Bus - ESB)
2. For those that did attempt full SOA (early) adoption, the percentage of successful implementations dropped dramatically as those organizations were tackling a large number of paradigm-shifting capability at once.
Either outcome was likely to sour some early adopters on SOA due not so much to the promise of SOA itself but rather due to some level of expectation mismatch.
SOA did not remain static however. There have been shifts in standards (SOAP to Rest), maturation of products and product suites, massive changes in development methodology (The Agile Revolution)-all of these changes impacted the relative success in adopting various portions of SOA over the years. The other really big change was that the concept of SOA as the all-encompassing IT unification framework has been toned down quite a bit. Why this happened is worthy of further explanation.
Let's revisit the original SOA pitch. As an architect, I had some concerns with how the concept was being framed as soon as the trend emerged for the following reasons:
• The perspective was overly Application (architecture) focused - and the enterprise is much more than application architecture.
A big part of the SOA maturity process, both at the organizational and industry levels, has been working through more realistic adoption paths, but it has also involved placing SOA back into the larger enterprise context. Where does that leave us today? How would we define SOA circa, 2015?
We’ll start with an updated definition. Service Oriented Architecture is a set of logically-related enterprise architecture patterns for managing application capability. SOA is ubiquitous in that it can no longer easily be associated with any one group of IT products (e.g. it is evolved beyond the traditional SOA stack) and SOA is already present in some form or another in most enterprises today. For organizations that solely work with application services, SOA becomes the de facto application reference architecture. For organizations that still support legacy applications (like AS400 etc.) the application reference architecture has a larger context than SOA.
Let’s look at SOA in the context of today’s biggest IT trends.
SOA & Cloud Computing: Many view these two IT constructs as almost one in the same given that Cloud technologies naturally extend or expand upon SOA patterns and best practices. However, Cloud technology goes beyond SOA and provides a different paradigm for managing and commoditizing IT infrastructure. Some Cloud providers have gone beyond traditional SOA patterns, introducing “Microservices” that address pragmatic concerns about application granularity in a service paradigm. Another way to think about the relationship here is how the SOA pitch has affected the way people look at much of what IT provides to the rest of the enterprise. Early on, as Cloud began to emerge, it was framed as “Infrastructure as a Service” or “Platform as a Service” and “Software as a Service.” SOA gave us a better philosophical construct in regards to tying IT capability to Service Level expectations (first using WSDLs but later it was abstracted into any sort of SLA or contract). This has extended even further to include vendor relationships and holistic bundles of diverse services now popularly referred to as “managed services.” Granted, much of this was already occurring in some fashion before SOA, but SOA certainly helped cement the notion of “service” as an IT currency or lingua franca.
SOA & Devops: This is of course also SOA, Cloud and Devops, but the relationship here extends into Design time rather than run time management (and sometimes both if we consider release management within Devops). It’s hard to view the emergence of SOA and Agile as completely separate trends, and Agile has redefined Devops in most organizations today. How are they related? Well, think about it–both SOA and Agile emerged based on initial patterns that were developed for Object Oriented Development. Both SOA and Agile have attack some of the same problems–the ability to abstract monolithic solutions into well-defined components of business functionality. That principle then implied more of an incremental approach to build. SOA and Agile Devops go hand in hand when dealing with new application functionality–together they represent the design pattern, the design approach and the runtime environment (which can then be further extended when we bring in Cloud Computing). There are other areas where SOA has profoundly influenced most enterprises, including Mobile computing, business process modeling and workflow and even security architecture. For those wondering what happened to SOA, the good news is that it is everywhere–it has become so entrenched within the larger fabric of IT though that it is now difficult to clearly identify on its own.