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.

SOA Governance

On governance I like this quote from Anne Thomas Manes:

If you can’t manage and govern your services with a wiki, a registry/repository won’t help you, either.

This goes great with the statement that I’ve put on this blog before that it is not about the tool it is about people and process. Besides that managing a Service Repository also isn’t a Silver Bullet either, it has proven to be very useful for some of our customers.

BPM

Here are some quotes from Mike Rollings on BPM:

Too much focus on business process automation is detrimental to your BPM initiative.

Automation helps reduce human effort, but fixating on automation gets in the way of optimizing the business.

Automation can be an enabler for optimization, however it should never get in it’s way of become some kind of burden. Yes software can help, but software is a means to (process) optimization not an end or a goal.

So far, I am not sure where I stand on the following quote from Anne Thomas Manes:

BPM infrastructure tools: process modeling tool is key. But models are not to be created to generate code.

On one side I’ve worked with tools that generate good code from models. At the same time I’ve worked with analyst and other functional people that do not have the skills to create a model that will result in great software. Please share your thoughts on the subject in the comments!

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.

There are loads of examples in litterature but also in more popular books like Freakonomics that:

People respond to incentives

In the animation you’ll see the kind of incentives that work well for tasks that go beyond mechanical skills and that require rudimentary cognitive skills (like conceptual and creative thinking). These incentives include the following aspects :

• Autonomy – Which demands engagement instead of management and control.
• Mastery – It is great fun to learn things and sometimes even be (really) good at something!
• Purpose – Humans are purpose maximizers even more than money maximizers.

Please note that money isn’t one of them. In short for organizations and managers it boils down to:

Treat people as people!

Let me know what you think on this subject in the comments….

Many of the arguments that have traditionally been brought forward in favor of Spring are invalid or outdated, because they target disadvantages of J2EE 1.4 and prior versions, rather than Java EE 5/6. … the original argument that this is not supported by Java EE is simply gone, and the remaining argument, if present, is much weaker.

If you’re in a position where evaluating these alternatives read the entire blogpost. Generally speaking there is no best way to go. Both are viable frameworks for writing Java applications.

The choice should be made by taking into account the particular requirements and technology strategy of the organizations building and using the application.

If there’s an opportunity we’ll see if we can come up with some rules of thumb for the selection.

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.

The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.

BPEL is an execution language. There is for example no standard graphical notation in the BPEL standard. The main focus is not on readability, it is on execution.
So BPMN and BPEL aim for different goals. It should come as no surprise that there is gap. There are several resources that describe the mapping, provide translation, or transforming BPMN to BPEL.

Guidelines

Here are some guidelines that help you bridge the BPMN to BPEL gap:

• Be as specific as possible in BPMN diagrams (In Oracle Business Process Analysis Suite you can use e.g. automated activity, notification , and human tasks.).
• Add additional information in BPMN activities. Sure this doesn’t enable automatic transformation, but it does reduce the need for additional design documentation. This will improve documentation consistency, and reduce the required governance.
• Use templates in your BPMN activities. Structure and check completeness of your descriptions.
• Use a Service repository. This will enable both designers and developer to communicate about “the same thing”
• Use a GUI components reposity, for the same reasons as you use a Service repository