Thoughts on the SOA Manifesto 1/2

October 2009 I was at the 2nd SOA Symposium in Rotterdam where the final efforts were made and the actual presentation of the "SOA Manifesto" happened.

This post is how I interpret the SOA Manifesto statements and I would like to encourage people to post their concerns / remarks on this vision.

Business value over technical strategy

While having a planned technical strategy is extremely important, it's also the business who pays the bills. The cost of projects is often not really aligned with the expected business value, so we have to make a trade-off between our strategy and make tactical decisions to keep the business happy. When we keep the business happy, we are most likely allowed to continue our planned path to destiny and in the end get close to our technical strategy goals. If we push too much on the technical strategy end, we risk loosing our customer's commitment which may blow the entire SOA architecture efforts, since they invest in things that do not generate the appropriate business value.

Strategic goals over project-specific benefits

Traditionally, project point of view would strive for short term gains, to reach the project goals. But sometimes the project goals are not in the right direction of the strategic goals. Although the project manager has all interest and most value to gain from meeting the project benefits, some restraint must be taken in order to pursue these at all cost, especially when they are not aligned with the strategic goals. Usually a project is aligned with the strategic goals of the company, but sometimes these goals are not the way to deliver the project easiest. This is where mixed concerns get in the way of everyone. One should not allow project goals more significant than the strategic goals, the latter typically being the reason why the project was started in the first place. As SOA delivers enterprise strategic value, the projects should implement this value on a project-by-project basis whilst inside those projects, never loosing the enterprise strategic goals out of sight.

Intrinsic interoperability over custom integration

Although often a custom integration may be quicker to implement, it is typically as the name says, custom work - it cannot be reused somewhere else, give or take a few exceptions. By using standards and standardized interface definitions, it is easier to use and reuse these interfaces. This statement means that both the standardized technical interfaces as well as a shared data definition model can help. Particularly the latter helps in a semantic way - understanding the interface is made a lot easier. This results in quicker adoption of the interface and hence its used standards. Even the shared data model can be according to industry  standards. Using these industry standard data models typically requires a lot more ramp-up time and implementation time due to the learning curve, but once understood, they can be discussed about with people from ie. other companies, without their prior knowledge of your company - this could even make it easier to hire external help to finish your projects.

Shared services over specific-purpose implementations

When focussing on specific-purpose implementations, these often very easily delivered. Issue with the approach is that for every new business functionality requested, a new tailored service is created. This causes that no reuse happens: services are not shared. A typical approach is where service logic is copied, and adapter for a slightly different service. Although quicker to develop, the use is minimal if not negligible, you still increase the problem operational complexity whereas a shared service typically requires no modification at all, hence must be managed only once. Note that to work with shared services, considerable extra design/development time must be incorporated to cope for service discoverability and description of the service interaction in the context of new functionality. Then you have the issue of "i'm special", "not invented by me" syndrome. These are often symptoms of arrogance or distrust and are killing to any organization. When getting over these issues organizations allow for use of shared services, reducing the total cost of ownership as no custom designed implementations have to be managed.

Flexibility over optimization

What happens very often, is that logic is optimized for the current scope. This would typically be the case for any project-based approach. Any service or capability delivered often is a service with limited scope from project point of view. However from enterprise point of view it may be very wise to add some flexibility (at the cost of project budget and timelines). Don't think this will come for free. Issues like up-front planning and rethinking design from multi-use point of view may take extra time during design. Often the implementation time is not too severely impacted. For example, a service may be built to perform work for an online shop application. But this typically locks the service to be useful for the online shop channel only. If we were to foresee that this service can be used by other channels, or in other service compositions, we could cope for the future flexible use by ie. as simple as adding channel ID as a parameter, even though we do not need it for the current project. Any next project or service composition could use the service in a channel-aware fashion.

Evolutionary refinement over pursuit of initial perfection

Reaching initial perfection is probably utopia. Most SOA implementations are complex systems and all the ins and outs are learned over time. Trying to reach it when starting with a new solution will delay projects, cost a lot of money and ultimately may not fly at all because the cost of this is so high, that the business forces us to look for other alternatives. Remember, the business pays the bills :). Initial perfection is hard to reach anyway, if not unrealistic because it would require that all requirements, including future requirements, must be known at the start of the SOA initiative. As requirements change over time, the 'perfect' solution would grow out of sync with requirements soon. This would mean you spent a lot of effort on things that may never happen. Perhaps a better approach is to use KISS: "Keep It Small And Simple". Start small and be pragmatic. Do what you can now and leave what you can't until you can resolve in future iterations or projects. This is what is being referred to as evolutionary refinement


------------------------------------------------
As you can see the value statements in the SOA manifesto are not defined in a "SMART" way. They are not measurable and this causes confusion and leaves room for discussion. Discussion is good however. As long as it does not stop us in our tracks because we cannot resolve our differences, there is progress and it forces us to think about what we are doing. Not one implementation of a SOA will be the same. There is no "one size fits all" solution. If this were the case we would be out of jobs. Use the statements made here to your own benefit when you need them and make up your own mind if you need to. Nothing stated here is "the unified truth for all", just use these statements as best practices whenever you find fit.
------------------------------------------------