SOA as an Architectural Style
by
Alex Cameron
Lord Kenneth Clark, the famous English peer who wrote and presented the watershed BBC TV documentary "Civilisation," reflected that, “Architectural style cannot take root unless it satisfies some need of the time.” Of course he was referring to structures and buildings but this resonates with what we know of the IT industry as well. We all know that architectural styles have come and gone and been displaced because technology has enabled different approaches.
We have learned the hard way that this mixture of styles has caused the mess most IT shops have today. It seems absurd when you think about it and indeed, it would almost be tantamount to mixing say Romanesque, Gothic and Renaissance architectures with connecting bridges, halls and corridors for traffic to pass between - such a thing would not only be unrecognisable as conveying any style or grand design, but it would be torn down as being grotesque. But this is what we have done in the IT industry to a large extent - we have built accidental architectures that have focused on architecture from an application perspective, not an enterprise or integration perspective.
There are various views on the benefits and differences between monolithic, layered and n-tier architectures but how does SOA fit into the picture?
Most architects in the IT industry would argue that SOA in many respects is the first architecture that truly can be called an Enterprise Architecture as it based on a paradigm of loosely coupled integration. This of course does not make it a loose connection of objects lying around the network, but a true evolution of what attributes we now know make sense in an architecture - this has been learned over the past 40 years. What of course makes sense to us now is the loose coupling of independent units or work that have a granularity that reflects true business functionality. This functionality is called a service within SOA and should be a formally defined and contracted service reflecting the appropriate QoS. (This is where the OO paradigm failed as it could not address the high level business functionality and so tried to drive re-use from a programming paradigm rather than a business - as such re-use was doomed - but that will be the subject of another blog).
Now whilst a layered architecture can be viewed as an integration architecture, it is predominately a local integration model and thus should be seen as an Application Architecture as such, where as SOA addresses the Enterprise integration model and therefore I would argue is a true enterprise architecture style.
So why isn’t a N tier application architecture equivalent to an A3 and SOA architecture? N-Tier has application elements that are tightly coupled, dependent and focused on achieving levels of scalability, fault tolerance or security that can lead to complex integration problems (figure 1).
N-Layer is more about how components of applications are logically grouped. Layers are loosely coupled and organised in highly cohesive areas that reduce the impact of change and help improve maintainability and agility of the architecture.
Although these are useful abstractions for the construction of services, or indeed applications, they are not enterprise architectures.
We have also learned from bitter experience that connectivity between systems quickly becomes an N*N problem that can be exceedingly complex if built on a sea of non standard middleware - so we now know that open standards has provided the route for us to begin understanding the solution to the enterprise integration problem. And we also know that point to point connections create a major problem and that Message Oriented Middleware that supports loose coupled systems is the way forward; so there we have it.
Now using this new found wealth of knowledge, we should be able to draw a quadrant diagram (figure 1 that positions our recent architectures). So a networked SOA basically extends the layer concept to allow self contained services to be integrated (using messaging) to form applications without impacting the integrity of the layer concept.
So the future should allow us to design to the Architecture Style of the time, but the architect should always be able to recognise this style and how to integrate new design or applications into it as he would use a building blueprint that conforms to that style. If we take that architecture view, we then see the integration problem very clearly and will not continue to build accidental architectures in the future. Of course enterprise governance must play a role in constraining those who wish to compromise the style, and better still if the architects and business leaders form and run the governance group. SOA offers this opportunity as an enterprise architecture.
Lastly, SOA not only can address the legacy of today, but can help bridge the "needs gap" that has existed between business and IT.
