This page contains the result of the SOA/BPM symposium at ODTUG Kaleidoscope 2009. This was a highly interactive day with two workshops and a panel discussion. This can serve as a start for gathering of knowlegde and common solutions in SOA/BPM projects.
The goal is to increase the success rate of projects that are concerned with SOA, BPM and EDA. The symposium was a starting point, feel free to add the results of similar events to this page.

Pictures of the symposium can be found here. Please add links or add photos to this page if you have more!

SOA from a Business Perspective

The morning was dedicated to SOA from a business perspective. The following questions were discussed in three groups:

• How to ‘sell’ SOA
• First steps/approach
• Business case / ROI

To get the discussion going, we used 'an airport in a country x' as a case.

Group 1. Results

First steps of any project, including SOA/BPM projects involves understanding the business context

• who are the stakeholders
• business segment matrix
• objectives
• critical success factors
• key performance indicators

The first project should:

• Address the fear factor. SOA and BPM architecture looks scary, we don't want to show the 'layered sandwich' architecture. Show something that is:
• Slim, or lean, based on existing infrastructure. Don't involve the entire company at once, start with one or two departments.
• Make sure it adds business value and it is something that is exciting or cool so it can be sold to the rest of the company: people need to be wanting to be part of it.
  
• it should be non trivial
• agile
• adhere to a broader vision, to make sure you are moving in the right direction

When you 'sell' SOA, make sure that you know who you are talking to. Talking to C-level executives requires different vocabulary and different levels of details compared to talking to people in the operation or the IT department.

Airport Case
When you think about the stakeholders in this case, and their objectives it is important to keep in mind whether the goal is to

• attract more travelers
• attract different travelers (business instead of tourists)
• make existing travelers spend more money

This will impact the choice for the first project and your approach to the business problem at hand. The first project should make it clear that SOA and BPM are feasible solutions and will add value to an organization without needing a big upfront investment or a complete reorganization of the entire IT landscape.

The success of the project needs to be visible. You need to make sure you know what you want to achieve and make sure everybody knows it succeeeded. Examples are:
cost saving on licenses, increased number of customers, increased spending per customer, etc.

A possible first step that was discussed in this group was a 'treasure hunt service' that uses location based services to show restaurants, gift shops on the way to your gate, or close to your current location. This could in a later phase be personalized with offerings, discounts etc based on previous sales and experiences.

The advantage of using SOA in this case would be agility. The ability to add retailers and services quickly without having to recode the entire existing system.

Group 2 Results

Problems

• Understanding business problems/business processes
• Undocumented processes
• To-Be processes
• Is BPM a solution? For Who?
• If it ain't broken, don't fix it

Selling SOA - Business drives SOA inititative
C-level:

• Increasing revenue
• Reduce cost
• Mitigate risk

Other:

• Visibility into operation
• agility both technical and business
• increase business opportunities
• Rationalisation
• Nirvana approach
  

First steps/Approach

1. Convince Management
2. Deliver
1. Proof of concept -> biggest painpoint should be solved
2. Reflect: insight in cost/delivery
3. Roadmap -> START WITH THE ROADMAP

Issues:

• Experience factor
• Investments (spread of)
• Poc does not take performance into account

Roadmap

• goals -> business, long term (business case) and short term
• requirements -> infrastructure, training
• investments, it and non it
• timelines
• impact
• dependencies
• transitions
• scoping
• risk mitigation
• resources
• skillset

• sponsor
• owner
• governance
• standards & methods

Group 3 Results

Issues with selling

1. Don't believe you
2. Heard it all before
3. Technology can't do that
4. we haven't got time
5. Money is tight
6. risk of change
7. when ROI

Approach

1. Find a business pain (cost/time)
2. Either find a strong business sponsor or start small interdepartmental. Biggest gain for lowest impact
3. Deliver and show success

Airport Case
Business drivers

1. Minimize outages. Unlink dependencies. Planned and unplanned. Riks based
2. Easy for airlines to use airport (business integration). Startup time plus cosst for airlines.
   
3. Joined up customer service (experience, identity, do it once) -> share information
4. Visible data, compliance, cost of ownership
5. Operational efficiencies

Initial Focus
Interview stakeholders, look for cost in business. Issues with understanding business.

1. Cost! -> efficiency. In this case, for the airlines to use the airport. For example make on boarding more efficient for pilots and staff. When a new airline starts operating from an airport, a lot of time and effort is being spend in security clearance, data about staff etc.
How? Common plus flexible service. Save on time and dollars to add an airline both for the airline AND the airport.

$$$$$Business operations
IT operations cost can be lowered as well by SOA:

• power because you need less datacenters because you reuse data and services.
• License rationalization. Instead of having multiple applications having the same information, you have a service that can be used by many systems. This saves you in licenses.
  

SOA from a technical perspective

The afternoon was dedicated to SOA from a more technical perspective. Clemens Utschig set the stage with a presentation about the role of EDA and events in a SOA environment. We then split into three groups again, and discussed the following questions based on the airport case again:

• No SOA without an ESB
• REST is the future
• SCA enables reuse
• A service is asynchronous. Always!

Results group 1

We first discussed the advantages of asynchronous communication:

• It promotes loose coupling, which in turn facilitates change and agility
• ensures dealing with resource issues (outages, capacity) etc.

BUT: you have to decide based on the use case at hand because it adds complexity (error handling, retries). So you need guidelines.

Asynchronous communication and event driven architecture are closely related, so we discussed Events at length.

You need to understand your events. How?

• Create a canonical model of your events, just like with sevices
• Make sure it is part of your SOA/BPM architecture. It is not something different!

Use events when you have:

• high volume or
  
• light weight messages or
  
• fire and forget or
  
• asynchronous communication or
  
• non transactional or
  
• loose coupling
  

Use synchronous services when you have:

• A clear need for a contract
• need an immediate answer

Service execute activities, events are the result of activities and trigger activities.

An event is the equivalent of an event message in enterprise integration patterns

Results Group 2

Airport case.
Point to point coupling will give you data issues.
Tight coupling of airlines to systems
more work to add an airline

There should be no technical barriers to add an airline -> use a canonical model
You need extra analysis upfront, to analyze the messages. It's what make SOA and EDA adaption scalable.
Events should be in canonical format

Canonical model
Where start?
1. Business stakeholders
2. Industry groups

Who owns the model?
EA group and the business

Make a difference between a EBO (entity business object) and a EBM (Entity business message)

Do we need an ESB
We need a pattern. Abstraction, policies, common information model plus transformations.

Do we need events: to minimize dependencies between processes.

Synchronous versus asynchronous
Is this a business or a technical issue?

Results Group 3

Missing.