Some of the topics:

• What is SOA Governance and Why do we need it?
• SOA reference architecture – The importance of solid standardization.
• Service life-cycle governance – Design and build the right services and the proper way to reuse them.
• Service repository – With examples of repositories based on Oracle Enterprise Repository (OER) and a wiki.

rsvp.

Dis-economies of scale

One of the main reasons for centralization is to gain economies of scale. Less known are the dis-economies of scale. I’ll give some examples in the paragraphs below.

The cost of communication between the central group and the rest of the organization. Although there are lots of tools that make communication easier. Distance in the physical sense or within an organization can create boundaries. These have to be dealt with and there are costs incurred for that. Besides that it has to be clear who to communicate for what matters. This, in my experience, is not always the case. With a greater (organizational) distance more effort has to be put into this.

There is a large possibility that top heavy management in a centralized department becomes isolated from the effects of their decisions. In other words the feedback loop is broken. Because the communication loop is broken, decision become more and more dysfunctional. This due to the lack of real world knowledge that should be incorporated in these decisions.

Centralization can lead to reduced agility. On one hand standardization is a great asset. The larger part of architecture, whether it is enterprise architecture, process architecture or infrastructure architecture, is about standards and reducing the “solution space”. This has several advantages, among which the reduction of software- and systems entropy. The downside of a centralized body that maintains standards is that it probably will lead to inertia and unwillingness to change.

I’m a big fan of (open) standards. They simplify life! However we should not neglect that standardization comes at a cost. There are the costs for implementing, adapting to and maintaining standards in our organization. Say for example that we use a canonical (data) model. There is are maintenance costs (at least some effort) while adopting to change outside and within our organization. These costs of standardization tend to be hidden.

What to do?

Bring the effects described before into the business case for centralization. You did make sure that there was some sort of trade off when you decided to centralize a certain part of your organization didn’t you?

Take measures to prevent these risks. It goes without saying that these measures will take effort, time and possibly money. Now you know you’re going to take measures don’t you?

As was stated in a previous blogpost on measuring the business value of SOA, project metrics for business value created by SOA projects, IT projects, or even projects in general are rare. If I were a CFO this would worry me.
Besides that SOA efforts in a way also demand a different way of cost accounting than the traditional silo based. If my organizational unit owned (and had to account for the costs) of a rather popular often reused service, I would like to charge them. Say for example in a pay-per-service-call way. How do the financial systems under the responsibility of the CFO facilitate this?

Of course there will be lots of other stuff on your agenda if you are the CFO. But hey due to the crisis interest rates are low, labor is cheap, as are materials, so why not invest now in the foundation/infrastructure for the future
If you’re a CFO and – by incident – are reading this blogpost please let me know what you think, and add a comment…

• 36% of SOA projects lack a business justification
• 1% of all SOA efforts actually measured benefits

From these statistics it doesn’t seem to be a natural thing to do, measuring the business value of SOA. By measuring the business values we mean value in monetary terms – “hard cash”. Think in terms like:

• Increased revenue
• Lower costs
• Better use of assets
• Solve customer business needs

In order to have a good assessment of these we need a solid baseline measurement. This is where it gets hard. How many organizations actually have baselines like these. So the intricacies of measuring the business value of SOA aren’t necessarily related to SOA! It might very well be an issue for IT or even businesses in general.

What is specific for SOA or any other architecture or maybe project management approach, is to single out SOA as the direct responsible mechanism for the business value created (causality). In other words what part is SOA specific and what is “just” the availability of a new application? SOA has an indirect impact on business outcomes.
As an example of the previous point: In one of the SOA efforts that I have been involved in – that was at least in my opinion successful – the realization of the business case was very clear: 5 to 10 employees of a department had no longer work to do after 11.00 am. However because we automated a process that wasn’t automated before, it would be very hard for me to point out what part of the savings was actually directly caused by implementing in an SOA context.

This is one of the reasons why I’ve been advising organizations to implement SOA as part of their “normal” projects, or at least projects with a valid business case. Dealing with your project in a SOA way will not only deliver the monetary outcome described in the business case. Applying SOA principles like “Separation of concerns” and “Loose Coupling” will yield in solutions that are modular, interoperable, and shareable.

Real-life accounts of successful and failed SOA projects discussed first-hand by those that experienced the project lifecycles and have a story to tell. These veteran practitioners will provide advice and insights regarding challenges, pitfalls, proven practices, and general project information that demonstrates the intricacies of implementing and governing service-oriented solutions in the real world.

I will be presenting the first session in this track on Using a Service Bus to Connect the Supply Chain. If you have any topics or questions in advance that you think I should address, please post them in the comments. Hope to meet you in Berlin.

There is a call for presentations:

The SOA and Cloud Symposium 2010 program committees invite submissions on all topics related to SOA and Cloud, including but not limited to those listed in the preceding track descriptions. While contributions from consultants and vendors are appreciated, product demonstrations or vendor showcases will not be accepted.

All submissions must be received no later than June 30, 2010. An overview of the tracks can be found here. Other resources:

• My blogpost of the SOA Symposium 2009.
• Presentations from 2009.

Service Orientation – Paul Allen

The following definitions come from Service Orientation: Winning Strategies and Best Practices by Paul Allen.

A service is functionality that must be specified in the business context and in terms of the contracts between the provider of that functionality and its consumers. Implementation details should not be revealed. The implementation of the service does not have to be automated – it could consist of purely human activity.

A business process is a set of activities that is initiated by an event, transforms information or materials, and produces an output. These sets of activities are either value chains that produce outputs valued by customers or infrastructure processes that produce outputs that are valued by other processes.

With the remark that “a business process is usefully pictured as being composed of re-configurable services”.

A software service is a type of service that is implemented by software and that offers one or more operations (or software functuions).

Web services technology is a set of XML-based industry standards and specifications that specify a communication protocol (SOAP), a definition language (WSDL), and a publish-subscribe registry (UDDI).

Succeeding with SOA and Implementing SOA – Paul C. Brown

The following definitions were taken from Succeeding with SOA by Paul C. Brown. Who also wrote Implementing SOA.

A service is a unit of functionality packaged for convenience and consistent use.

With the remark that typically, this functionality consists of a body of information and a set of operations for managing this information.

A business process is a structured set of activities organized to produce results.

A process, or more specifically a discrete process, is a sequence of distinct activities that produces (or attempts to produce) discrete countable results.

An activity is a function performed by one or more agents that uses on or more inputs and produces one or more results.

SOA Design Patterns- Thomas Erl

This post could simply not exist without quotes from Thomas Erl. A complete list of his books in the Service-Oriented Computing series can be found on soabooks.com.

Services are collections of capabilities. A Service is a unit of solution logic to which service-orientation has been applied to a meaningful extent.

Services exist as physically independent software programs with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing.

A Web service is a body of solution logic that provides a physically decoupled technical contract consiting of a WSDL definition and one or more XML Schema definitions and possible WS-Policy expressions

In a Web service Capabilities are exposed as operations.

• The philosophy
• The process
• The goals

Find the complete article here.

Is SOA still dead?

My personal opinion is that SOA is still alive or reanimated. The declaration of the SOA Manifesto has contributed to this. The least it has done is start discussion online and offline. These discussions will lead to a better understanding for the participants and those following them. The result will be more mature and successful (in business terms not technology) SOA implementations. This would be quite an achievement if the statistics that Anne Thomas Manes presented are accurate:

fewer than 10% of companies have seen significant business value in their SOA efforts.

Although the quotes on this page seem rather negative, I’m still an optimist on the case for SOA. It brings us solid principles and guidance in developing software of better quality.

Views on the SOA Symposium

The proclamation of the SOA Manifesto has resulted in most of the blogpost on the SOA Symposium. However there are post dedicated to a broader spectrum of the SOA Symposium. These give an impression or reflect back on things.

Reading the blog of Linda Terlouw, I remembered having the same expectations on the “Service-Oriented Solution Evaluation Criteria” session: some info on how you can measure whether or not (or to which extent) a service conforms to certain principles. Instead it was a summary of the principles as they are defined by Thomas Erl.

Comments, like this one, are appreciated.

SOA Manifesto

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.
Through our work we have come to prioritize:

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

That is, while we value the items on the right, we value the items on the left more.

source
You can watch the Announcement of the SOA Manifesto on Youtube.

SOA Manifesto in Wordle

Update Oct. 26th
I found some blogposts of people participating in the creation of the SOA Manifesto: Clemens Utschig and Stefan Tilkov