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.

Audi S5

Besides innovation it is said in the Dutch magazine Management Team that reuse is one of the driving forces. It is great to have another example of how the principles behind Service Orientation not only deliver value in IT but also – or probably mainly – for the business when applied e.g. in other engineering disciplines.

Reusable building blocks

Audi has limited the number of modules engineer are allowed to use to construct a new model. There are two main lines, based on how the engine is placed:

• Modulare Querbaukastensystem – transverse engine platform
• Modulare Längsbaukastensystem – longitudinal engine platform

Limiting the number of construction modules for engines, gearboxes, air conditioning results in several benefits:

• Lower costs per car compared to it’s competitors.
• Serve a larger number of niche markets compared to the competition.
• Shortened time-to-market.
• At production lines both employees and robots can work on several models. This enables Audi to produce the models that are in demand, while at the same time keeping a high utilization rate.

Audi claims to save 20% per manufactured car, and to save 30% on the development of new models. The economies of scale are further leveraged because of the reuse of components in the Volkswagen Group.

• The philosophy
• The process
• The goals

Find the complete article here.

Still searching for the correct answer on the question: What skyline is in the picture on slide 12?

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