BPMI.org

[Derek Miers]

This thread of discussion is for members of the public to ask questions of the BPMN Workgroup. Please reply to this post if you have a general question that is not covered elsewhere in the discussion. We will attempt to respond within a few days.

I will start the ball rolling by posing a couple of question asked by one of my clients.

Input - Output paradigm
This organisation is struggling to see why BPMN doesn't naturally support the I/O paradigm of process activities. I suppose at the heart of that question is the issue of separating "control flow" from that of "process artefacts". Perhaps members of the BPMN workgroup could comment on what this separation exists.

Pool and Organisational Boundaries
The perceived core issue was about why I/O is different when talking across Pools rather than just inside a Pool. What are the key issues affecting where the Pool Boundary is drawn and how would a major multi-national handle processes that run across Business Units or internal companies.

[Rob Bartel]

We have an in-house champion for the same cause. His question is why should "sequence" flow be any different from "message" flow (or, more accurately, message send/receive). The point would be that "sequence" flow is just a special case of a message in which the input data is all data known to the process, there is no output data (to the caller), and the receive always instantiates.

Or, another statement might be that instantiating message flow IS sequence flow, with an additional semantic of explicit rather than implicit data sharing. Non-instantiating messages are signals between separate threads of execution.

If sequence flow had a Properties list on it like the Message object (note I don't mean the message line here) then would that begin to meet the requirement? Alternatively one could introduce a properties list for the input and output connections of the activity, but I think it's a characteristic of the relationship between two activities rather than a characteristic of the activity itself.

However, in the end I don't see an impact on the *notation*, which is what BPMN is focussed on. Is there some diagramming opportunity, beyond the document object artifact, that I'm missing?

[Manfred Sturm]

A BPMN success story:

ITpearls is running currently a very successful campaign of workshops in various institutions (banking, government), which aim to apply ITIL (http://www.itil.org.uk/) as their Service Management model.

Using BPMN 1.0 as the notation and Process Modeler 2.0 (http://www.itpearls.com/processmodeler/) as the tool to seize the current status of their business processes has been straight forward and easily understood by the workshop participants. The resulting diagrams deliver a good start to redesign and implement their services according to the ITIL world.

Anyhow, we experienced two major issues with BPMN sometimes difficult to communicate:
1) BPMN is not mainly focused on data flow modeling, though it has some support (DataObject element). People like more to talk about their data, than about their work's flow.
2) BPMN is not build for organizational development, though business people are tempted to use Pools and Lanes primarily as Organisational Units or Roles (as defined in the WfMC model). People are more used to think in hierarchical structures and line of command, than about their services, the enterprise wants to deliver to their customers as a whole.

So, we are working on better introductions to give these business process design workshops an easier start. I wonder, if someone has good material at hand to overcome this initial threshold. Steve's BPMN overview is already a good start, but a bit too high level for most of the business responsibles.

Best regards
_________________
Manfred Sturm
ITpearls Ltd.
Product Manager & Head of Services

[Derek Miers]

Manfred,
I too have plenty of material in this arena and find myself running workshops etc.

I think the core issue is one of your core delegates - ITIL is about delivering systems and is, by its very nature, full of programmers and developers who are most interested in what happens to their data.

They get endlessly caught in the classic process chicken and egg situation. Which came first - the process or the data? Clearly, the process is about supporting the purpose of the organisation - the data and docs are just the implementation details of that process.

Have a read of my paper "The Split Personality of BPM" for more on this (www.enix.co.uk). You might also find the BPM Primer useful.

Secondly, IT people like to think of nice neat hierarchical structures. They tend to force all other concepts into that structure. Whereas the world of processes are rarely hierarchically structured. Sure, there are plenty of approaches that see hierarchy and structure as an easy way of splitting up the domain under study, but ask yourself this ... if the firm were to go through a re-organisation, would its processes change (in terms of their description). Clearly some role assignments might, but the processes themselves would not (should not).

[Stephen A White]

I moved this post from the BPMN adoption thread. I think we should just use that thread for a status of things and we can use other threads for the specific questions and issues.

In some sense, this is a matter of perspective and purpose for the diagram. The intent was to create a distinction between interactions between distinctive entities and the flow of activities within a specific entities. There are differences in how entities handle their activities, what their visibility is into their and the activities of other entities, and what their management responsibilities between their own and the activities of other entities. With a separation between Sequence Flow and Message Flow, it is clear how activities within an organization differ from interactions with business partners (e.g., suppliers, shippers, etc.). The difference between internal units should depend on how these units actually interact, are managed, and can or cannot be monitered, etc. The process model should reflect these differences, if they are there, and not lump different things into the same "pool." I may be wrong, but I would say that the interactions between entities will have to be some sort of message, but there may be different ways that two activities can be sequenced within an entity--it may or may not actually be a message. Data Flow is another topic (and another thread).

Naturally, there is no way to enforce how people model things. Thus, if someone only wants to use Lanes and Sequence Flow, there is nothing to stop them.

We also have to consider diagrams that are not intended to show internal activities, but are there just to show messages that go back and forth between entities (see /_ext/www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example6.jpg). This type of diagram is different than a typical internal process flow and Sequence Flow doesn't seem appropriate for this type of diagram.

I was not clear about what Manfred said about BPMN not built for organizational development. You can use Lanes in a hierarchical or matrix format, but I think he was saying something else.

[Stephen A White]

Again, a new title, but I guess it will be under the same topic.

Data Flow is naturally part of BPMN, but it has the ability to be fully separated from Sequence Flow, which I think is an advancement. Data Objects can be Associated with Activities and this can be direction, thus input and output. Additional properties allow the modeler (with a tool) to specific complex inputs, outputs, and input/output relationships.
A modeler may not want to draw to separate connectors between activities when there is both Sequence and Data Flow in the same direction. Thus, a Data Object can be Associated with a Sequence Flow to indicate the Data Flow. The Association connector need not be very long and could be done efficiently with a Tool. Thus, the simple and complex cases can be taken care of.

Perhaps the confusion is in the fact that Data Flow is created through the Association connector, rather than having a separate Data Flow connector. [[Is this a mistake?]] We needed the Association for many things and the association of data to activities is a sub-set.

I would argue that data doesn't really flow between activities, but between applications and that a data flow diagram is a different thing than what BPMN is trying to do. But I realize that some modelers do think of data flow within the process; and we should deal with this.

I'm not sure that we should create a new line style for the Data Flow--from the subset of Association. This would give us four different line types and the necessity of coming up with a new line style and arrowheads that are easily distinguished from the other three. But we can discuss this.

Maybe we just need to highlight the data flow mechanism in documentation or a white paper. What do people think?

[Manfred Sturm]

Thank you Derek for your papers,
Thank you Steve for your thoughts,
It's both very helful.

I try to do some load analysing here:
I fact I am conviced that BPMN has good features to take care of data flow and organizational issues. But BPMN is mainly about Business Process Modeling and only partially about Business Modeling in general. I guess, this is what business analysts intuitively expect BPMN to be, before they learn that they first have to look at the business process itself (FlowObjects & Activities), *before* hooking data flow onto it and draw organisational aspects over it.

A puristic approach could be that UML is to software development, what BPMN is to business development. But maybe this is not a wise approach?

Anyhow, it often occurs to me that my customers compare BPMN with the different UML notation types (what I think is OK). But one major difference is that there are multiple behavioral and structural notation types in UML to capture static and dynamic aspects of an application or system. To the contrary, BPMN is trying to cover both aspects in one diagram type for a business description. So maybe this is why people sometimes don't feel free enough to describe their business?

What can I do against it? E.g. I give BPMN a touch of a methodology and tell my customers what to do first (process) and what to look at next (e.g. add data flow and organizational aspects) to refine their business model. Well, this is a good consultant's job anyway.

Though the organizational notion of participants and roles/entities can be found in Pool attributes, it is not visualized and too rough grained. I miss a concept, where Participants can be visually assigned to Activities (e.g. WfMC's Oraganizational Model involving Workflow Participants like OUs, Roles, Persons/Humans, Resources/Sytems) to describe responsabilities and access permissions (which would introduce the important security aspect to BPMN). Another "hooked on" aspect, why not?

Maybe the working group might rethink this in a future version of BPMN.
_________________
Manfred Sturm
ITpearls Ltd.
Product Manager & Head of Services

[Derek Miers]

Manfred / Stephen

Many thanks for your feedback. I too have had my concerns over BPMN with regard to higher level modelling needs (i.e. how people involved at a higher level might use it).

Stephen, as I said to you in August when we met, I believe that 'Capability' modelling approaches are far more appropriate at this higher level and it is only when one wants to explore how a 'Capability' is implemented do we need to get into the procedural notions inherent in BPMN. Indeed, that perception was re-inforced last week in a workshop I facilitated with a major customer.

[Stephen A White]

We do need to look at how BPMN fits into higher level business modeling.

I think that members should post links to information about different types of modeling that includes processes at some point. For example, a company may want to define their process landscape or, as Derek mentions, their capabilities. These are different types of "views" to which processes are related, but they are not procedural business process diagram.

We need to collect the relevant types of views so that we know how BPMN will fit into these views.

[sca]

At Computas, we are implementing BPMN gradually and we currently have a hybrid approach to process modeling in an Enterprise Model context where have continued to use IDEF0 Inputs. Outputs, Mechanisms and Controls in combination the BPMN-approach. This has proved quite nice both for high-level business modeling and for the integration aspects - we are potentially also modeling organization, strategy, IT-architecture etc.

Unfortunately, I did not manage to enclose an "inline" image showing this.

We will be present at the Butler Group Symposium in London 17-18 November ("Business Process Management and Integration"), and I would be glad to demonstrate this for those of you that will attend.

I hope to meet you there , Derek, we had e-mail contacts years ago on similar issues.

Regards,
Steinar Carlsen
sca@computas.com

[Derek Miers]

I think the point is that