As promised yesterday, here are some comments on the SOA Manifesto. It should be obvious that these reflect my personal opinion – it was hard enough for the group to agree on the few words that actually got in, so don't expect a majority (or even a minority) to agree with everything I'm writing here.

The preamble

Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation. We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.

This actually reflects what all of the group had in common – we've been working to achieve certain goals, using an approach commonly called "SOA". If you believe we could have been able to come up with and agree on a detailed definition of what SOA is, you have probably never participated in any discussion of this kind – it's entirely pointless and doomed to fail. On the positive side of things, this gives me the option to view a service as either a set of SOAP/WSDL interfaces or a collection of RESTful resources (and trust me that I'm not suggesting this is an implementation detail; I do know the difference.) In other words: This is not attempt at a definition – it's an attempt to find out what values and principles we could find that we all can agree on. So, onward:

Through our work we have come to prioritize:

We decided to go with "prioritize" instead of "value" to emphasize that we actually see value on both the left side as well as the right side of the value statements.

Values

Business value over technical strategy

This may seem very obvious, yet we see this value violated all the time. People build up grand theories of how things should be, or come up with huge and complex products that attempt to solve all imaginable problems. But however great that theory is, however powerful a product, the focus needs to be on delivering business value. (To use Anne Thomas Manes's words, focus on services, not SOA). We put this at the very beginning to emphasize that we consider it to be the most important value. Note that adhering to a technical strategy (the right side) is also a value - but when in doubt, business value wins all the time.

Strategic goals over project-specific benefits

Trying to achieve SOA goals means to emphasize strategic values, even if this might mean that a particular solution is sub-optimal for a project at hand. In general, it's a good idea to do exactly what's needed - this is the value on the right. But if you want to change your IT landscape so that it conforms to an overarching strategy in the long run, you need to accept that sometimes strategy wins.

If you feel that this conflicts with the first value to a certain degree: Yes, it does – which is exactly the point. What you need to come up with is a balance of delivering value now while creating something that's better than the current mess most corporate IT landscapes are today.

Intrinsic interoperability over custom integration

Instead of integrating systems after the fact, using integration products, data transfer tools, and duct tape, SOA focuses on building services that are designed for interoperability from the very start. Integration is not an exception, it's the rule – or phrased differently, intrinsic interoperability means integration (with the meaning of "getting separate systems to interoperate") is not a necessity anymore. You won't be surprised to find out that I personally see REST and HTTP as the best possible means to achieve this … but for some reason, I did not feel I stood much of a chance to get the group to agree :-)

Shared services over specific-purpose implementations

While building something specific to the purpose at hand is a valuable thing to do, in SOA you want to actually use and re-use something that you've built (as opposed to doing something similar over and over again). In every particular case, building something that matches exactly what you need is tempting; but to end up with something more manageable in the long run, try to use and re-use stuff as much as possible.

Flexibility over optimization

We value flexibility to further re-use, both planned and unplanned, over something optimized e.g. for bandwidth, performance, or any other non-functional aspect. In the local case, optimization might be something to strive for – but if that leads to problems with regards to changing business requirements, we favor flexibility over optimizing aspects.

Evolutionary refinement over pursuit of initial perfection

While everyone would be happy to come up with the perfect design for services – both internally as well as externally –, in reality this is not going to happen. So the continuous refinement and refactoring of both the internal service implementation as well as the relation of services to each other needs to be continuously improved upon. To me, this includes starting with something like a lightweight technical approach and a few services, and then continously evolve this (instead of trying to do a big-bang top-down approach).

(As an aside: I actually got to this point yesterday evening and left the rest for today. Then I noticed Jim Webber has used his well-known martial eloquence to rip the manifesto into pieces (something I can't claim I didn't expect). But if you look at what he and I have written, you might be able to notice that we actually argue for the same things, except that to him it means the manifesto is useless and even harmful, while I co-authored and signed it. In fact I believe that if Jim had been part of the group, he would have agreed to most of the wording, too.)

Anyway, moving on again.

Guiding Principles

I'll stick to a few simple comments for each principle this time; I'll spare some more thoughts for future posts.

Respect the social and power structure of the organization.

This should be obvious – you cannot possibly expect to be able to introduce SOA to an organization otherwise. To me, this affects both methodology as well as technical choices: You can start arguing for what you strongly believe is the best approach in multiple places at once, or you can decide to focus your energy on the most important issues and compromise on others. This is just one example of many things that depend on the structure and organization, both formal and real.

Recognize that SOA ultimately demands change on many levels._

To me, this is one of the main differences between SOA and something like EAI. In my view, SOA, regardless of the technology being used, means to change existing systems. Simply wrapping your legacy systems with some interoperable technology will ultimately not be sufficient (even though it might be a good start).

The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.

Another obvious one – you don't necessarily have to do everything at once (nor will you be allowed to do). So within a domain, however small or large, a certain set of principles may apply; for others there may be no or different rules.

Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.

In other words: You can't buy SOA.

SOA can be realized through a variety of technologies and standards.

The fundamental idea behind SOA is not dependent on any particular technology nor architectural style (in the technical sense). You know what I consider to be the best approach; you might guess that there were quite a few WS-* and ESB people among the authors too.

Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.

At this level of discussion, it's not important which standards and policies you pick – just pick some and stick with them.

Pursue uniformity on the outside while allowing diversity on the inside.

What you want to standardize to as much uniformity as reasonable is the outside interface to your services, not their internal implementation. If you're into WS-*, this means that you should not mandate a certain implementation technology (at least not as part of your SOA initiative); if you're a REST type of person, this is probably obvious anyway.

Identify services through collaboration with business and technology stakeholders.

Business and technology people should collaborate to build something that's meaningful to both.

Maximize service usage by considering the current and future scope of utilization.

As much as you can, try to build something that's usable and re-usable, even in ways that you can't see exactly. Again, you won't be surprised to find out that I believe this is one area where the REST approach shines; see Steve Vinoski's Serendipitous Reuse for more.

Verify that services satisfy business requirements and goals.

Another obvious one; no further comment now.

Evolve services and their organization in response to real use.

Again, while this may seem very obvious, you can often find services with a re-use rate of less than 1 (i.e. no usage at all), and lots of services that suck, and others that work from a technical perspective, but have the wrong granularity from a business perspective … make sure that you actually don't stop thinking about your services once they're up and running.

Separate the different aspects of a system that change at different rates.

This is a rule that works well both at the level of an individual system's architecture as well as on the level of a set of systems.

Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.

Implicit dependencies – e.g. hidden direct database access, dependencies on some piece of code that needs to be embedded in multiple places, some little-known import/export interface – are typically the root cause of IT problems. Reducing these as much as possible is a good idea. If there's one place I have a problem with in the whole manifesto, it's "publish all external dependencies" – I believe that while this sounds great, it will be mostly unachievable.

At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.

In my view, a service (or component, or subsystem, or whatever you decide to call this level of building block) should encapsulate a cohesive set of data and logic. While I believe this is a core principle, I often end up having to justify it. So I'm very happy it's inside the manifest.

So, to summarize my views: I can understand why people have become frustrated with SOA, and I can accept that some prefer to avoid the term altogether. Fine. But if you want to label something SOA, I strongly believe that these are all reasonable values and principles, even though some that you might have wanted to see in there didn't make it (the same is true for me).

I understand why some may call this too vague to be useful. It is, if you're looking for an architectural style (that's on an entirely different level). From a personal perspective, I consider the fact that the group managed to agree that the core values of SOA don't comprise centralized governance structures, machine-readable contracts, application-specific interfaces, orchestration, composition, let alone ESBs, SOAP, WSDL or WS-*, really great.

I've been talking about three possible and common interpretations of SOA in the past: 1) As a high level approach; 2) as a badly-defined architectural style behind DCOM, CORBA, and SOAP/WSDL, or 3) as the architecture behind WS-*.

The manifesto firmly connects SOA to option 1. I couldn't be more happy about it.