Over the years we have had a lot of coverage on SOA principles as well as what can help it succeed or hinder adoption. With well over 7 years of articles, it is possible to track the evolution of SOA from initial hype, though to large scale enterprise adoption, Web Services and including the relatively recent influence of REST. However, over that period success stories for SOA were often hard to find, with some suggesting that only 20% of SOA projects succeed. Successes did include such notable examples as CISCO and eBay.
One of our editors, Jean-Jacque Dubray, has not only helped to track SOA for us over that time but also had much to say independently. He has influenced SOA as well as helped deploy many successful systems based upon SOA principles. It is with this background of experience in mind that Jean-Jacques (JJ) has recently blogged about what he believes are four principles for successful SOA:
- Service Interface shall be decoupled from Service Implementation
- All Business Logic shall be normalized
- 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
- Service Versioning shall be based on Compatibility
JJ believes that if you follow these principles consistently and throughout all phases of design and development, the chances of success are much higher. Unfortunately in his entry he does not go into more detail on these principles although they are relatively straightforward to understand. For "Service Interface", JJ has this to add:
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. [...] Don’t sweat over your service boundaries, invest in building the best service interface possible (i.e. efficient at managing change)
However, JJ does cover some other areas that have caused others concern around SOA in the past, including governance, where he suggests:
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
Loose coupling is something that is often cited as a core part of successful SOA and JJ suggests that it can be 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.
One other area of SOA that is often cited as important yet just as often appears to be difficult to achieve is service reuse. Back in 2009 we quoted Burton's Richard Watson who had this to say:
A service may never be reused, but still be used to create value in other ways: by being adaptable and less costly to maintain, reducing redundancy, increasing security and compliance through consistent enforcement of policies, to name just a few other desirable outcomes. Exclusive focus on reuse blinds us to these other outcomes.
And JJ agrees:
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
In fact on the 2009 article, JJ had this to say in the comments:
what most people still don't understand is that "reuse" does not mean in SOA what people usually understands when they hear the word "reuse". Reuse in SOA is forward reuse or as I heard it this morning, upward reuse. In SOA, reuse means that the new version of a service built for a new consumer does not break the existing consumers. Thinking that one can design a service today that can be "reused" in two years is for the most part a fantasy. In SOA older consumer "reuse" the service versions built for the latest consumers
As mentioned initially, all of these principles and thoughts have been influenced by many years of JJ's experience in the field. What do others think? Care to share your own experiences?