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:
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:
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:
Do you agree? disagree? Any other question?
This post has 16 feedbacks awaiting moderation...