BPMN 2.

0 and SoaML Integration

Joint BPMN 2.0 and SoaML FTF Meeting, OMG TC, San Antonio, Tuesday 8:00 AM to
10:00 AM
BPMN 2.0 Co-chairs: Steve White (IBM), Ivana Trikovic (SAP), and Mariano Benitez
(Oracle)
SoaML 2.0 Co-chairs: Arne Berre (SINTEF), Jim Amsden (IBM)
We agreed a while back to defer addressing integration of SoaML and BPMN 2.0 until
after BPMN 2.0 was adopted and the Beta document was available - primarily because of
resource and time pressures in getting the BPMN 2.0 spec completed. The OMG P&P
specifically states that FTFs are appropriate for raising and addressing integration issues
between specifications.
We are nearing completion of the SoaML issues with the comment period ending Aug
30, and most issues already resolved.
So the San Antonio meeting would appear to be a good time and place to restart the
integration discussions, and raise any further issues that the FTFs should address. I
suggest we schedule a joint SoaML/BPMN FTF meeting with the purpose of:
1. Understanding SoaML/BPMN integration progress so far
2. Scope remaining work
3. Raise applicable issues for the FTFs to address
4. Begin discussions on possible resolutions to those issues that improve integration
and interoperability between the standards.
The integration is centered on these different aspects of BPM and SOA integration:
1. The use of BPMN and SoaML to address some aspects of business architecture
including the outward facing business view of customer, partner and supplier
interactions and the design of the activities a business uses to accomplish its goals
and provide its products and services.
2. The ability to use BPMN to formalize business requirements for identifying
business capabilities needed to achieve goals, and using SoaML to identify,
specify and implement services that expose those capabilities to customers.
3. The ability to use SoaML services in BPMN processes, and to use BPMN
processes to describe methods for implementing SoaML services.
4. Both BPMN and SoaML can be used to drive implementations. The parts of these
integrations can be used together.
The BPMN FTF agreed to establish a subgroup to address the integration issue. Initial
candidate members include Steve White, Matthias Kloppmann, Ivana Trickovic, J im
Amsden, Cory Casanave, Conrad, and Fred Cummins. www.omgwiki.org/bpmn2.0-ftf
There will be a joint SoaML and BPMN FTF meeting at San Antonio on Tuesday AM
starting at 8:00 AM and running for two hours to kick off this work At that meeting we
will:
Discuss the motivation for integrating BPMN and SoaML
Review the current progress on integration through a concrete example
Raise any joint FTF issues that need to be addressed to complete the integration
Charter the joint BPMN/SoaML integration subgroup
Establish action items and a meeting schedule to provide resolutions to the raised
integration issues
Additional meetings may be scheduled later in the week to begin the work.
Additional Notes for the meeting:
Motivation for the integration:
How are the two languages used together. Mapping or common high-level classes. But
disconnected mms. Can't get away with just the abstract super-classes. But will have to
do mapping.
Confusion between Collaboration, Conversation, and Choreography
Simplify the 3 C Models.
Maybe down to two models. or even abstract at a higher level.
Use them together why?
some aspects of business architecture are common to both. outward facing and inward
facing
BPMN formalize the behavioral requirements and expose activities as services
SoaML describes services. Use BPMN to specify methods for implementing SoaML.
Combined
What is the overlap?
Who are the participants?
What are their services and how they are connected. And the order of the interactions.
Protocol between them.
Looking inside the participants are not choreographies.
Ports are closest to Conversations.
Conversation don't show the Choreography, but should it?
How do we relate them graphically.
SoaML is everything that BPMN interactions do. SoaML is another way of doing things.
The audiences are important. High-level IT modeling and Business Modeling.
Mapping between the standards is an admission to failure.
Tooling will have to work on it.
What is the boundary for SoaML? can do orchestration (through Activity Diagrams). Or
basically all of UML for doing SOA
What are the alternatives.
Be able to embed BPMN processes in SoaML
Map SoaML services between the BPMN interactions
What makes each spec special:
Composite Structures
Wiring is structure, but not behavior
Messages to Activity is difficult
We need to be able to flow between one and another.
Two extreme examples.
We will have different sets of users that start from different viewpoints.
Transitions between the different view.
Scaling was important for Choreography
A federation between the different models.
Design reusable services. through SoaML
Processes Drive out the services, then consume services.
I wouldn't call it service modeling
But the BPMN side is really modeling services, but the BPMN comes from it a different
POV
A Glossary mapping has been started.
Do the examples, both ways
Do the mapping, Is the mapping reversible. Don't do orchestration.
Do an evolution of Coll and Chor in BPMN.
How these standards should be used, a White Paper.
Use State Machines, Info modeling, in BPMN.
Use BPMN Orchestration in SoaML
What is the size of effort?
What is the practical end result.:
What is the relationship between the specs? in a table.
What are the strengths of each spec. So we can provide guidance.
Summary of email discussion on BPMN and SoaML integration:
Matthias
Very generically, ultimately it will be necessary to have some basic guiding principles that
describe
1. what is the core purpose/capability of each of the specs where it would be naturally used
and no other spec can,
2. how can the specs be used together to cover the union of their capability, and
3. how to deal with the redundancy stemming from the fact that the specs overlap to some
extent.
Now, while I am drawing my analogies from technical spec because that's more familiar ground,
the basic principles apply to the business level too: there is a requirement to describe the
1. Static structure of a system (roles, relationships, interfaces, contracts),
2. Dynamic behavior (interactions, message exchanges and their order, conditional actions,
reaction to unsolicited events, ...).
In an attempt to address static structure I am positionining SoaML to do the former, BPMN to do
the latter. Of course many modeling needs regarding collaboration and interaction can be
satisfied with either spec, because of the overlap, but also with that tendency: SoaML for the
structure, BPMN for the behavior (for simple cases, activity diagrams will also work to describe
behavior).
Only if we agree there is such a basic principle distinguishing what SoaML is good for that BPMN
doesn't address as well, and vice versa, does it make sense to look at (2), integration and interop
of the two specs at all. The principle above may be wrong in its simplicity, but that's exactly why I
like it.
So I wonder what, in your mind (and those of others following this discussion) makes each of the
specs "special", i.e., is their core purpose, and how an interop/integration story can be derived
from that? (Or, moving to the meta-level, whether this is the right discussion to have, or what it
should be instead.)
Cory:
SOA is a way of understanding business and technology in terms of loosely coupled entities that
provide and use each others services it is way of understanding the business as much as
understanding the technology.
We view SOA and BPM as two sides of the same coin SOA provides the outward facing view of
an entities responsibilities and what it requires of others (the structure of the interactions between
participants). BPM provides a design of the activities an entity has chosen to accomplish its
goals (including providing services). Processes both implement and use services. Both concepts
are valid at both the business and technology level. At least, this is the approach enabled by
SoaML and that we have practiced for more than a decade.
A lot of the SOA Technology vendors have, in my mind, usurped this Architecture- focused
view of SOA and cast it in terms of WSDL, Soap and their ESP. I have nothing against
technologies to implement SOA, but lets not confuse the architecture with the platform.
J im:
Businesses are organized in supply/value chains. One way to think about this is to distinguish the
demand-side (or outside-in) view from the supply-side (or inside-out) view. A business sees its
goals, strategies and supporting information and processes from the inside out - how and why
they do what they do to meet their business goals. This can be process centric because visibility
is within the enterprise focused on what needs to be done to achieve business ends.
Customers see the business from a demand-side view, the value propositions or products and
services the business provides that the customer may be interested in consuming. A services
view is more appropriate here because the business does not want to expose how it provides its
products and services, only what they are and how the customer consumes them. In this view,
processes are the second level - how the business provides its products and services to realize
the customer value propositions.
So we see this synergy between organization, information and behavior from different
perspectives. BA can approach a business domain from any and all of these perspectives.
There's really no need to constrain it to one view or the other.
Cory:
If you look at all of the higher level architectures SOA, BPM, EA, Information Modeling, Etc.
They are all sold as business focused but soon get dragged down to technology products and
services. BPM becomes a BPEL execution engine, SOA becomes an ESB this is often driven
by product marketing. My expectation hope that this group, as interested in architecture,
counterbalance this product orientation and get back to what SOA and BPM can represent a
way to understand the organization and a link to the technology that supports that organization.
As for not seeing services in business models, I guess I may have been overly influenced by our
work for the General <Services>Administration with divisions such as the Federal Supply
<Service>and Public Building <Service>. Or, perhaps some of the work in Healthcare
<Services>. In terms of high-level representations of the business at the C level, the process
used to deliver the organizations products and services is not the driver the products and
services they deliver are next come their collaborations within the supply chain. When we look
at organizational units and the supply chain that supply chain is a network of services. After
all, your process is how you have decided to deliver your value the process may change under
those services. Where we ant our organization to be agile, over specifying the processes can be
killer an Enterprise SOA orientation works well at the high level. So when I look at the high-
level descriptions of an enterprise I most often see organizational structure and services more
than processes, most processes are not visible.
Now, Im not saying SOA is the top, I find these discussions about the top as useless we need
to recognize that there are multiple viewpoints relative to the enterprise at many levels and these
viewpoints are related and overlapping. Process, Services, Rules, Resources, Security and
Information are all viewpoints on the underlying enterprise model.
J im:
But the key point is that businesses don't exist if they don't provide something to their customers,
and they can't provide anything without process that say how the work gets done. So BPM and
SOA are two parts of the same coin (structure and behavior), not different, competing ways of
doing the same thing. Depending on the situation and stakeholders involved, there may be a
preference to start with or focus on one or the other - just like sometimes there's a preference to
start with data instead of processes or services. In the end though, all these have to fit together,
structure, processes, information, events, service, etc. By creating silo'd standards, methods and
products, we don't help integrate these different aspects of architecture and solutions. This is
what creates the tension between BPM and SOA, justifying and working around those barriers.
J im (and Ed):
On the relationship between EA and BA: Maybe this is an oversimplification, but clearly if EA is
about the enterprise, it has to include BA since business is a critical part of any enterprise. [ >Ed-
H>] Agreedfully! And clearly there are things about an enterprise that aren't necessarily,
directly about the business - separation of concerns is a good thing. And EA is no longer just
considered IT architecture, BA isn't just about BPM.[ >Ed-H>] Ohif we could only get the
rest of the world singing to this tune! I think the confusion here is that some people think that
having BA be part of EA implies you can't do BA without EA when clearly you can if it meets your
needs. BA and BPMS as ITA are clearly applicable for a broad range of enterprise problems. But
this would be insufficient for enterprise architecture.
On the relationship between TOG and OMG re: TOGAF and BMI standards concerning BA:
These two efforts are complimentary, and working together may help address some of the issues
of both organizations' standards. TOGAF is light on the content metamodels - they are intended
to express high-level concepts that are customized and extended for each instantiation of the
ADM. TOGAF 8 didn't provide anything at all for the content model, and this was a problem.
TOGAF 9 is abstract and flexible enough to not over-constrain the needs of particular
organizations.[ >Ed-H>] Its EXACT intent! OMG BMI has lots of detailed standards, but these
standards lack an organizational context in which to integrate them with each other, let alone with
other OMG standards. It is possible that by focusing on EA as a strategy (instead of just MDA),
and providing more open-world technologies to support standards integration, we could finally
have a context in which to relate and integrate standards so taken together, the whole is greater
than the sum of the parts, not less.