I’m in Fred Cummins’ BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred’s an EDS fellow who writes occasionally on the EDS Next Big Thing blog.
BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).
We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what’s required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it’s own internal activities fully within swimlanes in its own pool.
Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:
- BPM: Business processes are the orderly execution of activities that achieve defined objectives.
- SOA: Services offer capabilities that can be used in a variety of contexts.
- Business processes may use services to achieve their objectives.
- Services implemented with explicit business processes can be more quickly adapted to business changes.
Personally, I find that list a bit circular, and I think that his “definition” of SOA is actually a definition of services — maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:
- Primary impact of business changes is on the business processes and organizational structure.
- The actual work (concrete services) and data of the business tend to stay the same.
I posit that business processes can change in response to changing business because they’ve been implemented using BPM tools that enable this agility, and services tend to stay the same because they haven’t been architected to allow for change. Possibly Cummins’ views are a reflection more of EDS’ client base and their own practices than what’s really possible in terms of agility. Of course, there’s also the view that published services need to stay the same (or at least their external interface) since the publisher may be unaware of all the uses of the service and doesn’t want to risk breaking it, but that doesn’t mean that a service shouldn’t undergo internal optimization or an extension of its functionality as long as it can be easily changed to adapt to changing business requirements.
There’s a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation “you’re being too rigorous!” was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general… (several minutes elapse)
Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that’s necessary to make business process modelling a fully participating activity in enterprise architecture.
At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn’t really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.
Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year’s think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.
Sandy,
A couple of things. First, in re: defining BPM and SOA, I think that SOA is the alignment of IT assets in a way that can be easily consumed by the business. BPM is the definition of the consumption. BPM is where “the last mile” is defined and is, therefore, arguably, where agility is made real. But there has to be a recognition that there are many IT assets that are, will and probably should always be managed by IT (think of the telephone network for example: I would never want to manage any part of that, yet I still want to manage how it touches me – through my phone). Those assets are more properly aligned to the business via SOA. It’s not circular at all, it’s how assets are aligned, governed and consumed.
Second, BPDM vs. XPDL? Come on. XPDL was built for workflow and although you can reposit a BPMN model in it (according to a couple of vendors), it certainly is not built to hold the metadata required for modern process notions (BPMN, BPEL, BPRI and others to come). The XPDL community has an asset and they want to prolong that asset (which never achieved status from an independent standards org, by the way). Fair enough. But to suggest this is a “standards war” is giving it way too much status. BPMN is not the only BP-* standard of interest. BPDM recognizes this and is purpose-built to acknowledge a growing body of process standards. As to specificity… the BPDM spec is floating around and will be issued with a reference BPMN implementation sometime around June 30. I wasn’t at the BPDM track today but I think the idea was to give general guidance to a crowd new to it… if you want the details, I am sure the spec as it stands today is available…
See you tomorrow,
Phil
Phil, don’t mistake my live blogging (which I do at the conference, hitting “Publish” before the applause dies down at the end of a session) for well-thought-out analysis. I’m not an expert on the distinctions between XPDL and BPDM, but hoped to learn a bit more about how this layer of standards (whether de facto standards or those recognized by standards bodies) and how they compete and/or interact. I didn’t learn that in this session.
I agree with you on SOA and BPM. My argument with Cummins’ view was that he equated SOA with the actual services, not with the architectural “philosophy” that encourages the creation of those services.