I've had a number of conversations with people since SOA became the vaunted architecture of the future.  Everybody that I've come across has slightly different thoughts on what it means, and many are in the "it's exposing objects as Web services" camp.  I'm really comfortable with what I think it is now, so maybe this'll help clarify it for a few people...

Firstly, let's start on what SOA isn't.  It's not a replacement for DCOM or .NET Remoting or any other object technology.  It's not simply exposing objects as Web Services, (that approach is in some ways a replacement for those technologies).  It isn't just a way of getting round firewalls to allow remote commmunication - once XML Firewalls proliferate within enterprises, that problem will resurface in many situations.

What SOA gives us is a new slant on architecture, rather than simply extending the object paradigm that's been evolving over the last couple of decades, it addresses a couple of fundamental shortcomings:

• The interoperability between disparate platforms (using standards based technologies)
• The ability to distribute these systems over an arbitrary distance

I won't dwell on these points as everybody knows about them, and the term "Service Oriented Architecture" makes people immediately think of "Web services" and those two are purely benefits of Web services.  To me, there's a third aspect that's equally important in most scenarios, and potentially far more important in internal systems:

The ability to design systems around business processes rather than the technical implementation details

This is a really key point that's not immediately obvious - if an attempt at an SOA system is made where standard objects are exposed via Web services, then it may not be apparent for quite some time that this has been missed.  Designed correctly, the service interface will abstract the internal implementation from the business function.  This is a subtle but critical difference from OO - although OO offers encapsulation, the object relationships are still both apparent and externalised, creating dependencies.  A well designed service will never expose a single facet of implementation.  What this gives a business is the ability to continually introduce change within a service, rather than the slow-down and increasing cost of change you usually get over time in OO systems.

The best way to think about this is in terms of paper forms in an office.  If you imagine application forms for accounts, invoices, and so on, these rarely change within an organisation, whilst the computer systems that produce and process them change fairly regularly.  If the essence of these forms (the fields on them and the form's purpose) can be captured rather than worrying about the internal details of the implementation, then change can be managed behind the service interface.  A good example of this is representing and managing a Customer within a system.  On first examination, you'd probably come to the conclusion that you'd need an "UpdateCustomer" option.  But that's implementation detail, and the customer object you passed in would probably have fields like CustomerStatus which clearly wouldn't ever exist on an paper form sent from a client.  More likely, there'd be a ChangeAddress or ChangePersonalDetails method; these methods should only take in the business-data required.

If a system is designed this way, and a change to the address (perhaps to add an extra line of detail) is introduced, there will be very few parts of the system that need to be updated and tested to support this - how much of your system is dedicated to address change?  But imagine that was part of the UpdateCustomer method - that would probably be used throughout the system if implemented, and the change/risk surface would be huge.

This is the first thing to take away about SOA - it's not about another level of technical abstraction, it's about capturing the business process as-is, defining it precisely with contracts in XML and allowing internal OO change as necessary.  Again, if you find yourself simply exposing an internal object as a parameter/return value from a Web service, then the SOA paradigm has been broken.

I'll probably write an entry about data immutability in SOAs over the next couple of days, as that's another really important subject...