Carnets de bord

I was asked recently to reflect over the last 15 years working on SOA and distill what I learned in the most succinct form possible.

I came up with "the four principles" that will make you succeed at SOA:

1. Service Interface shall be decoupled from Service Implementation
2. All Business Logic shall be normalized
3. Changing a service shall be easy
   • Changes shall be hidden to service consumers until they are ready 
   • Changes shall be easy to consume when the consumer is ready
4. Service Versioning shall be based on Compatibility

 I strongly believe that if you drive your SOA following these four principles, and these four only, you will be very successful at SOA.

Here are the answers to a few more questions that you may ask: 

What is SOA?

SOA is an architecture that positions your organization to manage change in the most efficient way possible.
  

What about Governance?

Don’t “over-govern”, governance should remain minimal and based on common sense with a short term horizon (3-6 months)

Data Governance is far more important since any change to your information model is generally impacting the service interface

What about Cohesion, Autonomy and Service Boundaries?

There is little or no cohesion possible in SOA: Data is relational, you cannot slice a relational model in "autonomous" entities.

When a high degree of cohesion is observed, it is plain common sense, for instance: Google Maps APIs rarely needs to be implemented within your Purchase Order service 

Don’t sweat over your service boundaries, invest in building the best service interface possible (i.e. efficient at managing change)

What is the nature of the “Service Interface”? 

Most people fail at SOA because, they think of a Service as an abstraction, something like a “class” in OO. The Service Interface is a contract that enables changes to be explicit and controled.

How do you define loose coupling?

Loose coupling is achieved when:

• The business logic implemented behind the interface is not involved in managing the context of interaction with a consumer
• There is no duplication of the business logic involved in managing the state of the system(s) of record in the consumers of the interface

What about reuse?

Nobody can expect to build a service today and that service will be ready to be consumed by new consumers 3 years from now. That is ludicrous. If you think of reuse that way you will fail instantly and come up with silly conclusions such as "SOA does not work". 

In SOA (and in the real world too) reuse works the other way around:

• it is not a new consumer who is reusing an old service
• it is almost exclusively a new version of a service (changed to support new consumers) which can be reused by old consumers without breaking them

Do you agree? disagree? Any other question?