This point has been explained in many other places, but still seems to need reiterating for some audiences:
SOA means Service Oriented Architecture
The most important word in that phrase could be ‘Architecture’, not the ‘Services Oriented’ piece – that just applies a modifier for the type of architecture; it does not mean that SOA is just the use of Web Services. Those are a technical interface mechanism and related standards that are indeed prevalent in any SOA environment, but that is only a part of it.
I, and my colleagues, often come up against a technical-biased viewpoint that implementing SOA is just a matter of using Web Services, SOAP, XML and WSDL for application integration. Maybe this comes about from the frequent over-use of the ‘Technical Architect’ job title, but that would be a different discussion with no real ending in sight.
In this context, an architecture implies a framework that is used within an organisation, whether it applies to business, information, application software or technology infrastructure. An architecture should include some form of blueprint and an associated set of principles to be applied to projects or solutions that fit within that architectural domain.
For SOA, a blueprint is an absolute prerequisite for any implementations to go into that environment (actually, for design and even project feasibility). Along with the blueprint should be a set of standards and principles that can be used to ensure the strategic SOA vision can be met. Tactical solutions may deviate from the strategic aims, but only if they can be shown to have strong justification for breaking the defined rules, and even then should have further plans to bring the solution into line for future strategic use.
The process of defining and applying SOA standards is that of governance, which is a form of quality control that applies to a greater level than is commonly seen in technical development projects where design and code reviews tend to take a project-specific view.
For SOA implementations to be successful, services should be designed to support business needs, so that they can be reused by multiple processes and applications, and using common approaches for interface definitions, data models, error handling and security. If these are not defined up front, as part of the architecture, it is highly likely that each set of services introduced into the SOA platform will be inconsistent, requiring additional effort for integration into any composite applications or services. Some of these points, especially that of security, can be very hard to ‘retro-fit’ if a standard is defined after the implementation of a number of service-based solutions. The same problems arise for any other standards that may be defined ‘after the fact’.
Hopefully these comments give a flavour of how SOA requires a broader level of thinking for application and solution design. There is a huge difference between a set of ad-hoc Web Services exposed in an ESB product and that of an architected design using SOA principles for compatible, consistent and reliable service-based developments.
If you are embarking on an SOA implementation, you really do need to form this holistic view of applications, services and business processes, with an architecture governance programme to ensure that the defined principles are applied. Of course, this is where the full ‘Enterprise Architecture’ approach comes in to play, with SOA being a subset of EA.
To those organisations, or more likely, development teams, that are just extending their EJB or COM components with a SOAP interface on an ESB, you should refrain from calling this approach a Service Oriented Architecture, as it most probably is not. It is quite likely to be just another bunch of incoherent application interfaces that will form a birds nest (or can of worms) with connections crossing all manner of boundaries. Well, that is my opinion of what I have seen happen, at least. Oh, one other whinge on common errors, it is ‘Oriented’, not ‘Orientated’. Shoot me if I use the wrong phrase!
SOA isn’t trivial, but if applied properly it can be a much better way of developing solutions within and across and organisation. So don’t be put off by the apparent overhead – doing SOA ‘properly’ is a good idea and should ideally be undertaken as part of a new approach to IT solutions that are using best practices in all possible areas.
I hope you now agree, that SOA is not just about exposing and using Web Services, and that if you are one of those committing the ‘crime’ of misusing or abusing the SOA moniker, please think again and take a step up to the greater view of architected solutions.
