Bpmn and Soaml Integration

8/12/2019 Bpmn and Soaml Integration

1/7

BPMN 2.0 and SoaML Integration

Joint BPMN 2.0 and SoaML FTF Meeting, OMG TC, San Antonio, Tuesday 8:00 AM to10: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 ofresource 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 issuesbetween specifications.

We are nearing completion of the SoaML issues with the comment period ending Aug30, and most issues already resolved.

So the San Antonio meeting would appear to be a good time and place to restart theintegration 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 far2. Scope remaining work

3. Raise applicable issues for the FTFs to address4. 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 architectureincluding the outward facing business view of customer, partner and supplier

interactions and the design of the activities a business uses to accomplish its goalsand provide its products and services.

2. The ability to use BPMN to formalize business requirements for identifyingbusiness 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 BPMNprocesses 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.


2/7

The BPMN FTF agreed to establish a subgroup to address the integration issue. Initialcandidate members include Steve White, Matthias Kloppmann, Ivana Trickovic, Jim

Amsden, Cory Casanave, Conrad, and Fred Cummins. www.omgwiki.org/bpmn2.0-ftfThere 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 raisedintegration 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. Butdisconnected 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.
http://www.omgwiki.org/bpmn2.0-ftfhttp://www.omgwiki.org/bpmn2.0-ftf


3/7

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). Orbasically 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 differentPOV

A Glossary mapping has been started.


4/7

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.


5/7

Summary of email discussion on BPMN and SoaML integration:

MatthiasVery generically, ultimately it will be necessary to have some basic guiding principles thatdescribe

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, and3. 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 dothe latter. Of course many modeling needs regarding collaboration and interaction can besatisfied 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 describebehavior).

Only if we agree there is such a basic principle distinguishing what SoaML is good for that BPMNdoesn't address as well, and vice versa, does it make sense to look at (2), integration and interopof the two specs at all. The principle above may be wrong in its simplicity, but that's exactly why Ilike it.

So I wonder what, in your mind (and those of others following this discussion) makes each of thespecs "special", i.e., is their core purpose, and how an interop/integration story can be derivedfrom that? (Or, moving to the meta-level, whether this is the right discussion to have, or what itshould be instead.)

Cory:SOA is a way of understanding business and technology in terms of loosely coupled entities thatprovide and use each others services it is way of understanding the business as much asunderstanding the technology.

We view SOA and BPM as two sides of the same coin SOA provides the outward facing view ofan entities responsibilities and what it requires of others (the structure of the interactions betweenparticipants). BPM provides a design of the activities an entity has chosen to accomplish itsgoals (including providing services). Processes both implement and use services. Both conceptsare valid at both the business and technology level. At least, this is the approach enabled bySoaML and that we have practiced for more than a decade.

A lot of the SOA Technology vendors have, in my mind, usurped this Architecture- focusedview of SOA and cast it in terms of WSDL, Soap and their ESP. I have nothing againsttechnologies to implement SOA, but lets not confuse the architecture with the platform.

Jim:Businesses are organized in supply/value chains. One way to think about this is to distinguish thedemand-side (or outside-in) view from the supply-side (or inside-out) view. A business sees itsgoals, strategies and supporting information and processes from the inside out - how and whythey do what they do to meet their business goals. This can be process centric because visibilityis within the enterprise focused on what needs to be done to achieve business ends.


6/7

Customers see the business from a demand-side view, the value propositions or products andservices the business provides that the customer may be interested in consuming. A servicesview is more appropriate here because the business does not want to expose how it provides itsproducts 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 realizethe customer value propositions.

So we see this synergy between organization, information and behavior from differentperspectives. 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 andservices. BPM becomes a BPEL execution engine, SOA becomes an ESB this is often drivenby 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 away 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 ourwork for the General Administration with divisions such as the Federal Supply and Public Building . Or, perhaps some of the work in Healthcare. In terms of high-level representations of the business at the C level, the processused to deliver the organizations products and services is not the driver the products andservices they deliver are next come their collaborations within the supply chain. When we lookat organizational units and the supply chain that supply chain is a network of services. Afterall, your process is how you have decided to deliver your value the process may change underthose services. Where we ant our organization to be agile, over specifying the processes can bekiller 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 morethan processes, most processes are not visible.

Now, Im not saying SOA is the top, I find these discussions about the top as useless we needto recognize that there are multiple viewpoints relative to the enterprise at many levels and theseviewpoints are related and overlapping. Process, Services, Rules, Resources, Security andInformation are all viewpoints on the underlying enterprise model.

Jim: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 andSOA are two parts of the same coin (structure and behavior), not different, competing ways ofdoing the same thing. Depending on the situation and stakeholders involved, there may be apreference to start with or focus on one or the other - just like sometimes there's a preference tostart 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 iswhat creates the tension between BPM and SOA, justifying and working around those barriers.

Jim (and Ed):On the relationship between EA and BA: Maybe this is an oversimplification, but clearly if EA isabout 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 justconsidered IT architecture, BA isn't just about BPM.[ >Ed-H>] Ohif we could only get the


7/7

rest of the world singing to this tune! I think the confusion here is that some people think thathaving BA be part of EA implies you can't do BA without EA when clearly you can if it meets yourneeds. BA and BPMS as ITA are clearly applicable for a broad range of enterprise problems. Butthis 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 issuesof both organizations' standards. TOGAF is light on the content metamodels - they are intendedto 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 particularorganizations.[ >Ed-H>] Its EXACT intent!OMG BMI has lots of detailed standards, but thesestandards lack an organizational context in which to integrate them with each other, let alone withother 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 finallyhave a context in which to relate and integrate standards so taken together, the whole is greaterthan the sum of the parts, not less.

Documents

Bpmn and Soaml Integration