We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

SOA Manifesto has been Released

Vote 0 Votes

On 23 October, 2009, the group of SOA leaders has released so-called SOA Manifesto. It says that the authors "value the items on the right" but "value the items on the left more":

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection

I am very glad that "Business value" and "Strategic goals" are the first two statements of the Manifesto. This clearly proves the shift in the understanding of the SOA world toward business-centric vision of the service orientation.

I think that the SOA Manifesto is in sync with OASIS SOA Reference Model and coming Reference Architecture (RA) standards. Following SOA Manifesto's principles

• Respect the social and power structure of the organization.
• Recognize that SOA ultimately demands change on many levels.
• Identify services through collaboration with business and technology stakeholders.
• Maximize service usage by considering the current and future scope of utilization.
• Verify that services satisfy business requirements and goals.
• At every level of abstraction, organize each service around a cohesive and manageable unit of functionality

have explicit reflection in the OASIS SOA RA, Public Review Draft 1. This means that SOA standards and Best Practices from different groups of experts have started to demonstrate a tendency to merge focuses and recommended directions, which is very important and pleasant fact.

The SOA Manifesto can significantly contribute into evident distinction between B-SOA (Business SOA) and T-SOA (Technical SOA), which is so needed for accurate combining them in the next step. In this step, service orientation, being understood and realised in Business via composition of business functions, will cascade into the technical implementation and automation of some elements of these functions. That is, the problem of selling SOA to Business and plug-in technical services into manual business operations will be left in the SOA history.
cReference Lable.JPG


| Leave a comment


Thanks for the positive feedback. I notice that you did not copy the principles (there is a link to them on the manifesto page).

The first value statement, which you expressed a liking for, was the easiest of all to arrive at. I think it must have taken the group minutes to decide on that one.

We have all shared stories on miss-alignment and were anxious to dispel myths and keep the focus on business value, which without lead to rack and ruin.


Steve T


thank you for noticing my comments. Frankly, I was very positively surprised with the content; I expected much more technicalities...

Actually, I did copy the principles but not all. The ones I’ve copied are easily traced in the OASIS SOA RM/RA contents;a matching for the others requires more accurate reading through the standards’ text.

Anyway Big Congratulation to You and the Team !

It is truly unfortunate that the elephant in the room for most SOA projects is they don't perform well. When users hit submit on a web form and it takes 5 seconds to respond, that is often too long in a business setting. The manifesto principle of flexibility over optimization might sound good, but it doesn't work at all for online or user facing applications.

This performance issue also impacts systems with traditional batch cycles. There is often no faster way to implement a data exchange than using a file exchange. Good SOA design can eliminate many batch information exchanges by using queuing and other mechanisms for asynchronous data exchange. However, many systems must exchange information only after business hours when data is static. Sending 100,000 records through a queue or web service is often a tremendous amount of unnecessary overhead.

The practical issues around using SOA in systems that require real time performance cannot be ignored. I have seen a great deal of "flexibility" ripped out of systems because it requires processes that are simply too slow.


I do agree with you that “5 seconds to respond? is not accptable in many cases. However, you are not concrete in your statement for me to assume that it is the service fault in the delay.

Flexibility vs. Optimisation is a problem when you want the ‘thing’ to be flexible and optimal in the same characteristic. For SOA services, the mastery of the service design is capable to combine Flexibility and Optimisation in the same service addressing different characteristics. For example, it is doubtful if an independent UI (Web) calling for SOA service right from the dispatching servlet will performes optimally. Why? Because a Web Page and SOA Service have different requrements in the User Experience area. Another approach is if the Business Service exposes its own UI, i.e. the Web Page, and, in this case, all possible optimisation is done within the service design (see my article at http://soa.sys-con.com/node/730632). Also, to my understanding, Flexibility in the Manifesto is meant as the business flexibility in combining different autonomic business services into collaborating aggregatinos or compositions to address changes in the functional business requirements (which is not the same thing as User Experience requirements).

As of batch systems, we need to remember that SOA is not a panacea – there are some technical solutiosn that do not require service orientation. However, file transmisstion (batch processing) may be one of the types of SOA services with special FTP protocol instead of HTTP (SOA Services != Web Service) and related interfaces. If you define FTP service in the manner of SOA service – with appropriate Service Definition and Service Contract as well as registration of the prorammatically accessible interfaces and SLA – I do not see any problems in having SOA FTP Service. We should not mix design of service-oriented solutions (SOS) with its technical implementation, correct? Going a bit bold, I can propose a SOS where an FTP transmissions or even ETL transmoissions go in accordance to their technologises while the Web Service interface of these services just sends a notification and meta-data about actual data movement via other SOA service channels/intefaces...

With this response, I hope to give you an idea that SOA Service is not an interface only. The SOA Manifest, IMO based on the combination of outlined SOA aspects and principles, assumes (let me repeate – I have not consulted with the authors on this) that a SOA Service may have several communication channels and interfaces (Web Service is just one of them and even not mandatory). There are two major aspects of the service we have to preserve – service-oriented behavior and related interaction with the consumers; if these two are preserved, any technology can suite the purpose.


I believe we are making two different arguments.

My comments are based on having to clean up after many poorly designed SOA projects. Good technologists can make most technologies run well. However, I have seen multiple projects where my clients have bought into the sales pitch for SOA labeled products such as rules engines and process orchestrators only to discover that no matter how much hardware is tossed at the problem, these products frequently cannot perform well enough to serve as the basis for an application that requires real time performance.

To be perfectly clear, I believe technologies labeled specifically as SOA based are oversold. You allude to this exact point when mentioning that "SOA is not a panacea."

The concept of a service is not new, and I agree with your analysis of using any technology as a service. Most descriptions of an Enterprise Service Bus specifically make this point by introducing the concept of wrappers to enable almost any legacy technology to act as a service.

My point is really around the continued overuse of SOA technologies such as web services in place of simple lightweight process integration, unnecessary fragmentation of business logic, and other design flaws in the name of business flexibility.

A technology or an approach must produce business value, as the first principle of the manifesto contends. The fundamental problem I have seen is that most organizations lack the IT maturity to properly apply SOA and govern its growth. As many articles have discussed, SOA for frequently degrades into just a bunch of web services or queuing everywhere. I do not believe a good general solution has been presented to resolve the application and governance problem, meaning most organizations are better off focusing on what they know or already do well.

I have seen very few enterprises willing to pay the transitional costs to grow out of their pain points to a mature application of SOA principles. This half measures approach is actually more dangerous than sticking with traditional application design and less flexible integration. Consequently, I have seen very few enterprises with the organizational will to either buy or build the expertise necessary to use SOA well.

It seems the biggest problem SOA is intended to overcome is the anti-pattern known as stovepipe or silo development. This anti-pattern occurs over and over again in almost every enterprise with two or more development groups. Obviously, SOA is an approach to resolve this problem. However, often a better approach is application consolidation, which is the complete opposite of SOA.

In summary, the knowledge deficit around SOA in IT degrades its value and frequently results in slow and brittle applications.


I take issue with your semantics regarding T-SOA and B-SOA. These distinctions do nothing but further cloudy the already unclear understanding of SOA, as evidenced by the response by Mr. Weiss regarding performance on Web forms.

A system is a system and an application is an application. We have semantics that represents these entities just fine. If a system or an application follows a design pattern that follows an SOA strategy, it doesn't make them something new. They're still just a system or an application.


JP, I think I know what you mean (magic!). As you, probably noticed I’ve mentioned B-SOA and T-SOA to _separate_ them at the beginning. The SOA Manifesto is talking about business flexibility while people (as evidenced by the response by Mr. Weiss) take the statement literally and try to apply it to the technical realisation of the some service features.

Principles of the SOA Manifesto as well as the Manifesto’s statements themselves may be differently applied to the business and technical parts of the business service. This is why I posted my comments. To end-up with cohesive business service properly supported by technology, we, first of all, have to clearly separate the roles and responsibilities, and create clear semantic that bridges both parts of the service development.

When I talked about B-SOA and T-SOA, I did not try to replace semantics of systems and applications. They both were, are and will be in the Technology area. B-SOA may or may not include any systems or applications; B-SOA is about Business with or without technical components represented by T-SOA; B-SOA is not about a SW application that implements some business logic though the latter may be included as an automated part of the business logic of a business function or feature.

"Principles of the SOA Manifesto as well as the Manifesto’s statements themselves may be differently applied to the business and technical parts of the business service"

Couldn't agree more.

The flexibility value is one that you could read many different ways and means different things when considering T-SOA and B-SOA, to be honest I wasn't really sure what exactly it meant at the B-SOA level (whether flexibility within the business services, or in their orchestration, or both).

Flexibility at B-SOA level means ability to adopt business changes with minimal investments and time-to-market. This is reached via both flexibility within the business services and in their orchestration.

In my book 'Ladder to SOE' I have a formula for B-SOA:
max(flexibility) = min Sum {investment into change implementation + investment into change adoption by surrounding environment + time-to-market}

I hope this helps a bit.

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives