Site Moving!

New site at ProcessModeling.info

Swimlane, Lane, or Pool? Learn to swim first.

Often I see process models that represent the same basic business concept but are modeled with completely different styles. Technically the BPMN lane and pool shapes are both a swimlane. But which one do I use, when, and more importantly – why?

UML Specification:

Swimlane: a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread.

The term swimlane appears for the first time in formal process modeling in the UML specification. First there was the activity diagram. Then there was a need to separate the activities of individual actors. The swimlane was born. So why are we using BPMN these days instead of UML? Well the answer is quite complicated. The UML specificaiton is full of other types of diagrams including class diagrams, state diagrams, interaction diagrams, and more. Most of the UML specification is very technical, therefore making it less than idea for most business uses.

Many people today believe that the term swimlane is part of BPMN. In a way, this is partially true because the BPMN specification says that both a pool and a lane are techinically a swimlane.

BPMN Specification :

UML was created in 1996. Remember 1996? Internet… What’s that? 1998 – Internet is pretty cool, and by 1999 my mother sent her first email. I recall in 2001 I heard someone say the word “blog” for the first time. In 2002 BPMN was born. And now what we have the history lesson out of the way…

  • Pool: Defines activities designated for a single participant. Pay special attention to the words single participant.
  • Lane: “A further subdivision of a pool”. Quoting from the BPMN 1.2 specification: “Lanes are used to organize and categorize activities”.

The BPMN specification says specifically that both pools and lanes are considered to be a swimlane. So this is where some of the confusion comes from. Technically it’s correct to call a BPMN pool or lane a swimlane, but the swimlane is not defined as part of the BPMN specification.

Here is an example of a UML style diagram using swimlanes:

UML Swimlane Style

UML Swimlane Style

This is a small process where a manager wants to hire someone. The manager submits a job requisition to human resources. HR returns a list of candidates and the manager interviews them. This cycle continues until a suitable candidate has been found. After a candidate has been found, accounting is notified to set up the payroll for the new employee. On the first day of work the manager conducts the initial briefing and gives the new employee a tour of the facilities.

The example diagram used the BPMN shapes but is actually a UML style diagram in terms of swimlanes. Often I see this style of diagram in BPM tools (not calling out any vendor specifically here). This diagram is actually incorrect according to both the UML and BPMN specifications. In UML the shapes and usage is slightly different than they are in BPMN. In BPMN you cannot have a lane without it being inside of a pool. I suppose one could argue that the entire diagram is the pool, in which case the only thing that is missing is the label for the pool. So we would have to assume that the pool has something to do with people.

Now let’s take a look at the corrected version of the diagram with a BPMN pool correctly displaying the lanes.

BPMN Pool with Lanes, single participant

BPMN Pool with Lanes, single participant

In this example the pool is called People because that is the only logical assumption we can make regarding who the participants are. In fact, if you take the specification literally, there is only one person performing all of the activities. Remember that a pool is a container for activities associated to a single participant. In this respect it is not possible to transition from one person to another within a pool. Each additional participant requires another pool. The lane could be used to indicate that the activities are associated with a particular category of work. For example, the subprocess for finding candidates is actually a performed by the same person that creates the job requisition, but the category of activity is human resources. So I suppose we could say this participant role wears a lot of hats in their organization.

Often I see this style of diagram and I realize that the intent was to show that multiple people are involved in the process. However, this is incorrect in BPMN. If the intent is to show the multiple participants’ activities, you must draw them in multiple pools. But this creates another problem; I cannot draw a transition line (solid line) between pools. I must use a message. Why? First we have to understand what transition means.

  • Transition: One activity from a participant has completed and another has begun. Transitions are notated with a single solid line with an arrow head pointing in the direction of the flow (sequence flow line). Sequence flow only occurs within the scope of a single participant.
  • Interaction: A process participant wishes to involve other participants through messaging. Interaction is a form of communication that involves the sending of a message. Interactions are shown in BPMN with a single dashed line with an open arrow head indicating the direction of message flow.
  • Message: A means to communication between process participants. A message has a well defined recipient and can have a message body containing process data or other data artifacts such as document attachments.

You can see from the definition that a transition is not allowed between participants. This is because it’s simply not possible. In any process, no matter if it’s human centric or system centric, any interaction between participants requires some sort of communication. Messaging is the the means in BPMN to have direct communication between participants. It is also possible to coordinate activities with things like signaling, but this is not actually an interaction. Signals (see my other post for details on signals) are used to coordinate events, but are not used to communicate.

So if you wanted to create a diagram that showed correct BPMN formatting, it would look like this:

BPMN Diagram with Pools and communication between participants

BPMN Diagram with Pools and communication between participants

The pools for the Accounting and Human Resources participants are collapsed for simplicity. This is a common practice when you wish to show in your diagram the focus on one single participant, but you still wish to show the points in which this participant interacts with others. Most likely I don’t care to show the details of the accounting department because it’s outside my juristiction, and I have no visibility on what they actually do. Also, it’s better to let accounting manage their own processes.

The other concept of style that I’m including in this example is the looping subprocess instead of the “upstream flow” lines. Upstream flow is when you sequence an activity that has already occurred. This is almost like going back in time. The problem with going back in time is that I’m not actually going back in time here. Something is different. I have a new iteration of an activity, but I’m not redoing the exact same instance. In this example I am interviewing a new job candidate. I’m not interviewing the same job candidate again. So in some cases the upstream flow is acceptable, but only if you want to redo something. Otherwise the proper BPMN notation is to use a looping subprocess, which shows that a new iteration is required, and probably a new set of data input is also required. With this in mind you can see that it is impossible to have upstream flow between participants. Any time messaging is involved I highly recommend using a looping subprocess instead of upstream flow. Otherwise your process participants could be out of sync and you might never know it. This is especially important if you intend to make this process automated and executable.

Another important concept to note from this example is that I actually created a parallel flow without actually using a parallel gateway. This done through messaging. The first interaction with the Human Resources participant creates a blocking asynchronous message. This means that until I receive a response from HR I cannot do anything else in respect to this process. A message must be recieve before I can continue at the step “Receive HR Response”. However the second point of interaction is quite different. When I interact with the Accounting participant I don’t wait for a response. I am not showing in this diagram how long it takes for accounting to set up a payroll account. In fact, it might take longer than what it does for the new hire to start working. In the first two examples above the process showed that I actually cannot have the person start work until payroll is set up. This behavior occurs when two processes intersect.

Process intersection is a concept that is hard to understand so it deserves some attention here. In this small process example we have encountered a problem in just a few small activities. Imagine how complicated this would get if we actually draw the entire set of activies for the other participants. There is a way to avoid this overhead and still accurately depict your process diagram. But you must understand process intersection to determine where to stop drawing one diagram and start on another.

The answer to this problem is that we have two different processes. One is the process of hiring someone. Another process is the payroll setup, in which the hiring manager is the requestor, but the hirning manager is in no way in control of this process. Therefore when it comes to syncrhonizing activity between the manager and accounting it gets very difficult to draw from the manager perspective. It’s better to attack this problem from the accounting participant’s perspective, and show the manager as a secondary participant. You can additionally show escalations and notifications from the accounting perspective back to the manager, which resolves the problem of accountability for getting the job done. But what does this have to do with hiring someone? This is why I say it’s a process intersection, not an explicit interaction within the same process. Attempting to mix the two very different business objectives in the same diagram will lead to a very complicated flow that takes a BPMN expert to understand.

Now back to the 3rd diagram example. Because I’ve seperated out what accounting does by simply showing my interaction point, I can easily go forth with the current process and not have to worry about whether or not accounting has done their job or not. We are trying to show the steps a manager takes to hire someone. If accounting doesn’t do their job, the other diagram from the accounting perspective should notifiy the submitter (the manager) that the work has not been done by the due date. But this is out of scope here. Let’s assume it’s been done. Next all we have to do is wait until the day the new hire is supposed to be at work and conduct the first day activities. Plain, simple, understandable, and and from the perspective of the primary participant – the hiring manager.


15 Responses to “Swimlane, Lane, or Pool? Learn to swim first.”

  1. Sandy Kemsley Says:

    How is “participant” defined in this context? For example, you take it to mean an individual when you create a pool for the hiring manager, but as a department when you define the human resources and accounting pools. I’ve seen many cases (possibly incorrect) of defining “participant” as an organization, so that the roles within the organization are shown as lanes within that pool.

  2. Rick Geneva Says:

    Welcome to my site. It’s good to see you here.

    You are correct. A participant could be defined as the entire organization. It depends on how far into detail you want to go. One of the the points of this post is to introduce the idea of properly scoping the diagram. The first example shows HR, Accounting, and the Manager all in one pool. Great for a high level process but there are three distinct roles, and they are not likely to be the same person. In a large organization, it’s not practical to say that all participants are internal, unless they are in the same workgroup. It would be nice if the world were that simple. But the reality is that we all communication via some electronic means these days more often than we have direct person to person collaboration. Therefore all communication is performed in proxy through a system participant of some kind. I didn’t go so far as to put all of these system interactions into this example, but in some cases I do when the context calls for it.

    If the diagram is completely high-level, to me, the lanes don’t add much value. To be completely honest, I rarely use lanes. In many cases they just make the diagram harder to read by making my eyes wonder up and down the page. If you are going go call the pool “my organization” it’s easier to put better labels on the activities to show who performs the activity. For example “conducts interviews” in the lane “manager” easily be replaced by “manager conducts interview” with no lane. But what you cannot do in any of these cases is explain the cycles of communication, the wait states, the asynchronous state, the parallel activities, etc. For this you must have pools.

    There are still many cases where I like to use lanes and they add value to the diagram. Like I mentioned in another posting, if I have a participant that performs many roles (one person who wears many hats) I would tend to put these distinct roles into different lanes. But the interesting part is when I would do this. Most likely it’s the last thing I do. I would never start out by modeling the roles first. Anyone that has done a lot of process modeling knows that phantom roles tend to be invented based on limited knowledge of the process. If the process is well established and the roles are not likely to ever change I see no harm in starting with swimlanes. However, if you are using BPMN for analysis, I’ve found that starting with swimlanes nearly always leads to inaccurate results.

    The thing to remember about process modeling is that a process that involves another participant is not necessarily the same process. For example, the manager is including the accounting participant. I’m betting that accounting has their own process. Now if I am in accounting I would most likely label this process “Add new employee to payroll”. In accounting I don’t care how many iterations of interviews it took before they were hired. The new hire could be the boss’s cousin. It really doesn’t matter. The point is, the context is quite different and there are many details of the accounting process that are not relevant to the employee hiring process, and vice-versa. So what happens when I need to change my process later on? How many people are involved in this change cycle? Now if I take this same process and involve one participant – the hiring manager, and everyone else is external, how is this change control cycle different? Now I only have to involve one role. So the points of interaction for one process are likely to be the points of intersecting another process for another participant. Therefore I don’t like putting them in the same pool, because they are probably activities belonging to another process owned by someone else.

  3. Column 2 : links for 2009-04-12 Says:

    […] Rick Geneva

  4. Anatoly Belychook Says:


    It’s hard to accept your statement: “Remember that a pool is a container for activities associated to a single participant. In this respect it is not possible to transition from one person to another within a pool.”

    The spec says at page 87: “A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g., a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer).” Glossary section at page 289 says basically the same: “A Participant is a business entity (e.g., a company, company division, or a customer) or a business role (e.g., a buyer or a seller), which controls or is responsible for a business process.”

    So one could name the pool “The Company” in your example or better “The Hiring Process”. More pools should be better reserved for external entities, e.g. a candidate in your example. Maybe you will find Bruce Silver’s article on this matter usefull: http://www.brsilver.com/wordpress/2008/06/11/bpmn-to-requester-get-outta-my-pool/

    By replacing lanes with pools and control flows with messages you complicate a diagram, please refer to the example on my blog: http://mainthing.ru/item/154/


  5. Rick Geneva Says:

    Thanks for your comments.
    I suppose I should have provided a better definition of a participant. Participant basically means anything that participates in the process. It could be a person, group of people, a system, and entire data center, or an entire organization. Technically it would be possible to use a single pool for everything and call that pool your organization. But this is more of a flowchart process modeling paradigm, not BPMN. This is the point of the whole post is that there is way to be more explicit about your process modeling and show more details. There are many features of BPMN that many people just don’t use.

    Referring to the specification, yes, those two references you provide are correct. If you look at the context for the diagram in which I’m trying to represent, the hiring manager is the only participant that is required, because they are the primary participant. Yes, you could argue that I need another pool for the candidate, and you are right. I chose not to add this extra participant because I didn’t want to make the diagram too complicated for my example.

    To me, BPMN has a lot of subtle implications. One pool = one participant. I model a process from the perspective of one participant, the one I would consider to be the primary. Everyone else is considered external. The systems this participants interacts with is also considered to be external. Next step: pick another participant and model from their perspective, etc. This might seem like an odd approach to some, but in my experience it creates a much more accurate process model with more explicit details. If I don’t want to show all of the intricate details and all of these points of interaction, I’ll simply put a collapsed subprocess in the diagram and label it accordingly. In this example I used the subprocess “conduct interviews”

    Putting everything in one pool is easier, and I suppose this is why I see this style more often. But the fact is, communication exists between the participants. This should require a message of some sort. I can understand if this is a completely paper based process where everyone is sitting right next to each other. But in today’s world this is simply not the case. If you want to get really technical about it, there is yet another participant, which would be some kind of application in which the participants interact. It could be email, or a BPM system, or something custom built. For diagrams that I do for customers I actually draw out all of the points of interaction, including these system participants. This is because by ignoring a participant you are leaving the diagram open to interpretation errors.

    Regarding Bruce’s Posting I don’t think he got into enough details to get his entire point across. His post seems to back up what I’m saying more than argue against it. Bruce didn’t break out the manager and HR participants. Maybe this is is because they meet the criteria I was referring to above. The HR and Manager might be sitting in the same room, or maybe they are actually the same person. The diagram does not say.

    I tend to use a lane only in cases where it’s actually the same participant. For example, I could say “managers” is the participant. Obviously this implies there are many managers. Then from here I could break this down into “project manager” and “supervisor”. This could technically be the same person that performs multiple roles. However when I know that a participant is “developer” I would never put them in the same pool as “managers” because it’s highly unlikely that this would ever be the same person.

  6. Warwick Moyse Says:


    Implicit in your approach is the old ‘silo’ view of process that BPM is trying to eliminate. BPM is promoting an end-to-end concept of a process – for example ‘order-to-cash’ – to try and get away from the departmental hand-offs that so often caused sub-optimal process outcomes in the past.
    The HR example you have used might be called ‘need-to-resource’ – ie the process that is initiated when the need for an additional (or replacement) person is identified and ends when someone is in place and provisioned to meet that need. Based on this view of the process, it would never be acceptable to say (for example) that the hiring process and payroll setup process are two different processes.
    BPM advocates that a ‘process owner’ be assigned to the end-to-end process, not just the various bits of the process. With this approach, the former departmental silos become contributors to a unified process that delivers a useful outcome, not just a part of a process that in and of itself really isn’t much use.

  7. Rick Geneva Says:

    Thanks for your comments.

    I think we are saying the same thing here, but with a different style. The “silo” view you are referring to only exists when you don’t fully show the details of the other participants. I limited the scope of this posting for discussion sake, but as I’m seeing the comments I believe I should have expanded this out a bit more.

    The approach I normally use is to model out the end to end process from the perspective of the primary participant. The secret to this is that the primary participant is not always a person. Sometimes it’s a BPM automation system, in which case all people are the contributors (secondary participants). In the example for this posting the Manager participant is the primary. This might not be the most perfectly optimized process but if this is how an organization is run, the process model must reflect the way the process works. Let’s just assume that I wouldn’t actually do it this way on a full scale large enterprise application.

    I don’t understand why you say it would never be acceptable to separate the accounting process from the rest of this process. Let’s say for example that my accounting is outsourced. This is very common these days to have a third party payroll company that processes paychecks and does all of the payroll taxes. Are you saying I should include this in my process? I have no control over this third party, no visibility into their process, and no jurisdiction when it comes to change control of their processes. I think you get my point here. Now, how is this any different than using a large corporate accounting/payroll department? As a manager in my workgroup I have no control over what they do because the processes are governed by someone else and I have no jurisdiction or even a vote on how the process works. I simply participate with long-established process. However my process is not theirs either. So who is the owner here that I should assign? This is my point. There isn’t always one process owner. When you cross this boundary you should realize that more than one process might exist and you should leave it alone. It’s going to require another diagram not because it makes logical flow sense to do so, but because someone else owns that process and I have no control over it.

    It’s perfectly acceptable to put as many pools within a diagram that you like. I try to limit this down to a reasonable, manageable number, which greatly adds to the readability of a diagram. But each of these pools can be further broken down into lanes if you like. For example, the HR pool might be further broken down into a lane to include “recruiter”, “candidate screener”, etc. I believe this would be completely acceptable because they are part of the same workgroup.

    I don’t believe in putting everyone in the same pool because interaction takes place, and it’s important to show the points of interaction in the diagram. Otherwise I end up with a very simplistic high-level diagram that doesn’t acknowledge that communication exists, is if information flows from the brain of one person directly into the brain of another. There are subtle implications in a diagram that shows points of interaction that are highly valuable to show the true nature of the process. However it doesn’t make sense to use message lines for every point of communication. For my example in this post, let’s say that the manager works in a small workgroup isolated from the corporate office, and all communcation is done via email. Does this sway your opinion on how it should be modeled? Or should we just ignore the fact that an implicit participant (the email system) is involved in this process? So this is my point here. If I modeled everything in one pool with a bunch of lanes then many people would automatically make assumptions based on the over simplification of the process. I prefer much more detail, and this you cannot do with just lanes.

  8. Anatoly Belychook Says:


    You are right: many people try to model an and-to-end process within a single pool and don’t know how to use message flows. It’s a well-known problem rooted in the lack of BPMN knowledge and skills.

    However I believe that modeling all kind of participants with separate pools is another extreme, the truth is somewhere between.

    My primary concern are human members of our organization participating in the process. Messaging is like negotiations: you send a message and the other party has a freedom in response. Control flow is dictatorship: you do this, they do that. A customer or a candidate should be negotiated indeed, but are you going to negotiate with a clerk about performing a well-defined activity within a process? As for me, I’d better give a direct order and use control flow to the activity placed into appropriate swimlane. No pools, no messages in this case.

    Members of other branches in a global organization may be similar to external entity so this is a grey zone.

    I’m sorry but your initial point that a pool corresponds to a single participant and hence the pool must be called “People” is misleading. You refer to BPMN but it’s rather your personal view and style. It’s legal yet other reasonable approaches exist.

    I know one BPM vendor that promotes this view. They are just unable to execute a diagram without every human participant being placed into a separate pool – the approach your promote here by coincidence I guess.

    Other BPMN-compatible vendors don’t have such limitation: you may put every participant into a separate pool and link them by message flows but guess what? People prefer to use lanes and control flows as long as the process stays within a single process/entity. Does such model produce robust executable BMP solutions? Sure it does.


  9. Rick Geneva Says:

    Modeling every participant in their own pool is only an extreme if your intention is to model a higher-level diagram that shows an abstract of the entire process. There’s a certain level of detail that you cannot easily achieve with lanes that only pools will allow you to do. If you choose not to show this level of detail, this is up to you as the process modeler. However I know from experience of making nearly a hundred processes executable in my career that the “happy path” modeling leads to creating systems that have a shelf life of the first few weeks before a revision is required to deal with exceptional conditions. I put more detail in my diagrams because I sincerely believe that the happy path occurs less than 50% of the time in the real world. Lanes don’t offer a simple way to deal with exceptional conditions. I can easily place various levels of intermediate events explaining how to deal with all of these conditions when I’m in a single pool. This is a detailed view. But if you try this in a single pool with 20 lanes then your process quickly becomes unreadable due to the complexity. So this is my point – focus on what one person does (the primary participant) and the others will fall into place easily.

    You are right. I don’t want to negotiate with the clerk about well defined activity. But if I don’t own that activity and have no jurisdiction over how it’s performed, then all I can do is make a request and get a response. This is the true nature of the process, so I don’t want to insert any assumptions to the contrary in my process model. It’s all about providing accurate communication to people who read the diagram. I don’t want someone to read my diagram and assume that I have any sort of control over what the HR clerk does.

    The “People” label, as pointed out by Sandy Kemsley, is better labeled as “My Organization”. But because the entire process is based on human interaction with no system involvement (or at least this is what the first two diagrams are implying) a logical way to group the activities while using this style is to call them people. Many BPM systems use this approach with a single pool I would consider to be called “human workflow” or “people” and then a seperate “system” pool for anything that is performed without human interaction. I don’t believe that I said it’s not legal to do in BPMN. I just don’t use this style because I prefer process models that offer a finer level of detail. In fact, if your BPM system is primarily workflow centric then there is nothing wrong with this approach, as it accurately depicts the primary participant – the system that the people log into. The actual people are not shown, but instead the user interface forms are shown. And again, back to the point of the post, it’s about understanding what exactly it is you are modeling and choosing the correct style for the actual behavior of the process.

    I get your hint about “a vendor that promotes this view”. I can appreciate how you might see things that way, but let’s not go there. I remain vendor neutral on this site, and in fact I’m the biggest advocate for full BPMN specification compliance for this particular vendor. If you do your homework you’ll find that the vendor I believe you are referring to does in fact allow everything in one pool and using swimlanes. Two comments on this: 1) This is not the only system I use. 2) I’ve had the capability to use a single pool with lanes since October 2008 in this system. I still stand by what I say. Successful detailed analysis of executable processes is achieved through careful consideration of the various points of interaction between people, systems, and other processes. This has nothing to do with any vendor. I can do this same sort of diagramming style in nearly any system and achieve the same results. In fact, I developed this method while working for another vendor a few years back.

    Your last point is also valid. But consider my points about exactly what a process is. I don’t believe that processes are totally linear. Layers exist in large processes. Often the subprocess shape is very underutilized. There is another style that I’m suggesting here that offers the best of both worlds – detail and high-level abstraction. When a geographic or departmental boundary is crossed, most likely you have another point of ownership. I’m referring to a long-term governance strategy. By placing abstracts of multiple intersecting processes in one view, I end up getting 10 stakeholders who take months arguing about how the process works before I get anything done. On the other hand I can get through a huge modeling exercise in just a few days by focusing on individual participants, while sacrificing that high-level overview. So you be the judge. If it’s more important to create a large overview process that everyone argues over or many smaller processes that fit together nicely, I get no arguments about them, but I cannot show a high-level overview. which is better? Both approaches have their advantages. The large view is the only way to see the entire process end to end with all the participants in place. However, the large view doesn’t offer detail and causes many opinions at the points where the lower level processes intersect. So what’s the best answer? I suggest that you should create both in order to tell the whole story.

  10. Anatoly Belychook Says:


    Thank you for the detailed explanations of your position. I share a good part of it with a belief that a good process model is not a single-threaded behemoth but a choreography of relatively small (10-20 activities) process fragments, few swimlanes in each.

    But I believe that 1) you go too far this way and 2) the tool shall not restrict you by one or another style but support both.

    The link to the homework is in my original post. I found out that the only way to model human activity in BPMS we are talking about (let me call it “i”) is by creating a separate pool. As the result one comes to 4 activities and 6 flows instead of a plain simple human activity. Of every human activity.

    I’d actually be very glad to be wrong at this point because this is the first, main and only reason why we don’t use “i”. With that level of complexity “i” is a product for IT people only and I believe that without business analysts involvement any BPM initiative is doomed.


  11. Rick Geneva Says:

    Just for you, I will do another posting that offers an alternative middle ground style. It’s going to be a large diagram this time that includes all of the styles.

    The “I” system you refer to… oh, let’s just go ahead and say Intalio so that others can understand the conversation. Take a look at the new version. I’m not going to post a link here but I will write about it in the tools section sometime later this week. It supports both styles, exactly as you say it should. It’s not the most intuitive to create lanes inside the pools at this point, but I’ve heard this is being worked on.

    Not to get into specifics for one particular vendor here, but you have to realize in any system what you are actually modeling is the executable portion. For example, systems that only support one pool with many lanes are implying that they are human centric workflow, with some system capability. Again, I’d prefer not to mention names here but feel free if you know which systems I’m referring to. On the other hand, there are other systems that are SOA based for services orchestration. This approach usually requires a pool based modeling because all activities have a data scope similar to how pools work. Then you have some systems that have capabilities for both styles, in which you can use any diagram style you like if it suits the need.

    There are many systems that require technical skills to use it, and there are just as many systems that are “watered down” and have restricted execution capability because they are so simple to use that you cannot easily integrate with other systems. I’m not saying that one approach is better than the other. You always need both IT and BA resources involved in every full scale project. I suggest the collaborative approach where IT and BA work together. But in a way you are right “without business analysts involvement any BPM initiative is doomed” because someone needs to drive it. And if the BA folks are not loving the tool they work with then it’s hard to keep things moving. For this I teach my BA students process modeling skills and tell their IT people to implement it. This works because when you have a good, well formed process model it’s very easy to make it executable on any system. And there won’t be anything lost in translation either because the high level and the intricate details of process flow and interaction are all captured in the BPMN.

  12. Rick Geneva Says:

    As a follow up to my previous reply I put together a diagram quickly in the system we were referring to. The diagram style is a hybrid, which shows both the swimlane approach and the single pool approach that shows only the BPM automation system. In this case the primary participant is the automation system. However I could easily reverse this to have any one of my people participants to be the primary.

    Link to the diagram Hybrid Diagram Style

  13. Anatoly Belychook Says:


    I really enjoy our discussion. To be able argumenting with diagrams not just words I commented it on my blog: http://mainthing.ru/item/182/

    = AB

  14. AS Says:

    See also http://improving-bpm-systems.blogspot.com/2009/04/re-humans-swimming-in-intalio-pool.html


  15. Rick Geneva » Blog Archive » The ins and outs of process loops Says:

    […] you you to do a loop across multiple swimlanes, but be cautioned that this is not always a good idea (see my other post about […]