Experience Based Principles for Succeeding at SOA

| by Mark Little Follow 15 Followers on Feb 24, 2013. Estimated reading time: 3 minutes |

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:

  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

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?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

SOA is more about a way of thinking than any specific technology by tom termini

I have seen too many enterprise efforts falter when a CIO has become obsessed with the latest and greatest - enterprise service bus, UDDIs, JSON. I'd say a good approach (if one chooses a "top down" strategy) would be to model the enterprise data -- develop an organization-wide ontology -- and decompose business processes into services. This article explains more...

Nice Practical Advice by Faisal Waris

In my place of work, the SOA program can be considered successful:

- Its been around for a while
- Is well staffed with well trained individuals institutionalizing SOA
- Has the right infrastructure pieces - registry, ESB, XML Gateways, testing tools, etc.

The result is steady growth in services including B2B web services.

The SOA program's guidance matches well with the principles outlined by Jean-Jacque. Although the hardest part is getting the interface right for complex services.

The Service Interface as the Boundary of explicit and controlled Change by Jean-Jacques Dubray

thank you Mark.

I just wanted to add that what "changed" (so to speak) for me in the last 5 years is the realization that "Change" is, and must be, the main focus of SOA. In the first 10 years, I think everyone looked at SOA and services as an evolution of distributed computing towards Web protocols. In that process, many people, including me, have looked for very specific abstractions that could be associated to "Services". Even though, here and there these abstractions can be identified (e.g. entity lifecycles, APIs, events ...), the most profound impact of SOA and the "Service Interface" is to allow changes in the information system to be made explicit and controlled.

Hence, service "boundaries" are not as important as positioning properly the service interface to manage the changes effectively. A sign of unhealthy SOA is when any minute change has large ripple effects across the information system.

The 4 principles are geared towards minimizing these ripple effects. It is unfortunate that our industry focused on "boundaries", "autonomy" or "cohesion". These concepts are not very helpful, because the ripple effects are upward, not lateral.

Of course, some people went as far as eliminating the contractual aspects of the service interface altogether, that effort was pointless. API providers are now forced to ship client libraries in 20 different languages (LoL) to make their APIs consumable. In many ways, these client library provide a strong support to make change explicit and controlled ...

Re: Nice Practical Advice by Jean-Jacques Dubray


>> although the hardest part is getting the interface right for complex services.

yes, agreed, this is where Principles 2 and 3, I think help because:
a) the normalization of the business logic is easy to identify (though not 100% attainable like data normalization)
b) the concept of "explicit and controlled" change allows you to decide on which side of the service interface some of the business logic lands.

>> including B2B web services
We also need to talk about B2Dev (B2D) services for 3rd party (mobile) applications.

Re: SOA is more about a way of thinking than any specific technology by Jean-Jacques Dubray


in order to be successful at SOA, organizations need clear principles that help them "tame their obsessions". What you are saying is not wrong, however, you need more than "an approach".

When you are a developer or an architect (EA/SA), when you are struggling with questions about your infrastructure or precisely what is the "service" interface? where does this piece of business logic lands? .... You need principles, not just an approach. "model the enterprise data", "ontology", "Decomposing business processes into services" appears to me as yet another set of "obsessions".

For instance, decomposing business processes into services simply tells you for that process, that service interface works. This is not enough because you are making decisions in a very limited context (one consumer, the process). It does not help inform infrastructure decisions either.

I have tried to craft these principles to help inform the answer to any question people may have about SOA. So far, I think they work.

Re: SOA is more about a way of thinking than any specific technology by tom termini

To reach the far mountain, you must first put your mind to the path.

As I learned re-architecting the Do Not Call and Identity Theft Systems at the US government's Federal Trade Commission, there can be a plethora of processes in place, but, in the end, it is organizational "uptake" that ensures success with SOA.

To give another example if how adopting the core philosophies of SOA at the outset can increase the likelihood of success, when I was detailed to MITRE I architected the cloud solution to Obamacare's technological components -- the US government is mandated under the Affordable Health Care Act to provide the means for all 50 states to open up so-called "insurance exchanges." The federal government, implementing my designs, built out a hub of services to support the national health insurance initiatives of this new way. A new perspective requires new ideas -- linking sux dispirit agencies' back end business processes (exposing data they traditionally kept close to the vest) meant a service model -- and a new way of cooperating.

You can google "Tom Termini bluedog SOA FTC eWeek" to read more about my "philosophy first" approach.

Re: SOA is more about a way of thinking than any specific technology by Faisal Waris


The SOA program I mention in another comment actually started out with the goal of 'modeling the enterprise'. We quickly realized that it was not achievable, in any reasonable timeframe, given the size of a typical large enterprise and all the time pressures.

Instead the program has adopted an incremental modeling strategy; as new services are added the enterprise model is 'filled-in'. There is a taxonomy for flexibly organizing services around major business entities. Only some parts of the business processes, which are in the ‘context’ of the service, are modeled. The metadata is stored in one or more repositories.

We don’t have a cohesive, fully integrated model of all this metadata. In my opinion this can only happen when we adopt semantic modeling approaches (ontologies based on OWL, for example). Other groups have started to delve into semantic databases but it’s still far from the mainstream.

Re: SOA is more about a way of thinking than any specific technology by tom termini

It sounds like we are in agreement -- an over-arching semantic model is a goal, perhaps ultimately unachievable, but an important goal, nonetheless. The journey IS the destination!

And, as readers of my blog know, incremental approach is THE way to go! Don't drink the ocean!

People, people, people by Robert Morschel

5. The organisational mindset shall have to change

As much as SOA is about good architectural principles, it is much more about people, but I've ranted at length on the harsh realities of SOA elsewhere (

People love the idea of reuse (like recycling) until it costs them (and they have to walk to the bottle dump in the pouring rain). Human nature will mean that business units will look to their own needs, unless there is organisational incentive to do otherwise.

Re: People, people, people by Jean-Jacques Dubray


I agree with your list, and this is generally how people have approached SOA with more or less sucess. The principles stated here can be viewed as a way to both accelerate and minimize the activities / decisions associated to service construction and avoid analysis paralysis, decision conflicts,...

Experience Based Principles for Succeeding at SOA - Reusability by Padmavathy Ramesh

Some thoughts on what JJ says about the Service Reusability principle...

A) The core business function will often remain the same unless the business or the industry context itself undergoes extraordinary upheaval. So functionally well scoped and designed service will be sought for quite a while. But it is unrealistic to expect that we can build a service today and that service will be ready to be consumed by new consumers 3 years from now without any change at all. There will be extensions and some updates to the service because the business is changing, the enterprises where the service is used are changing and this will result in a newer version. It is this new version that will be wanted by contemporary consumers.

B) Exclusive focus on reuse can make us pay less attention to other possible outcomes. Nevertheless, Reuse and the benefits from it are key outcomes to aim for. And if the focus on reuse is channelized well, then it can provide all the needed outcomes.
It may help to look at outcomes using the following questions:
1. Does the service portfolio fulfil the current and projected needs of the business goals and roadmap?
2. Do the current levels of use of the services indicate that there is demand for the capabilities being built into the service portfolio?
3. Are the service consumers willing to opt for the services in the portfolio instead of building up their own?
4. Is the investment made on the service portfolio providing the planned benefit to capability, adaptability, agility and efficiency?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss