We’ve been having some internal debate about the appropriate use of swimlane diagrams. Everyone agrees that swimlane diagrams are a helpful model. They allow you to create a process flow that does not require you to identify the system or actor involved in each process step, as this can be inferred from the swim lane in which that process step occurs.
Where we have some disagreement is in whether or not it is appropriate to mix systems with actors in a single diagram. One side argues that swimlane diagrams should have either all actors or all systems, but not both. The other side argues that mixing the two is entirely appropriate.
While I don’t expect to resolve this argument within this post, I thought I’d highlight a few thoughts about the two schools of thought.
Systems or Actors, but not both
- This is cleaner than mixing, and it allows you to look at the actors involved in a task as a whole, since each actor has its own swimlane.
- Clearly useful for modeling business processes that have no system component, or for representing the business process from a system agnostic standpoint
- Also useful for mapping processes that are implemented by a collection of systems that have minimal human interaction.
- You can always “mix” the model of actors vs systems by identifying actors or systems inside the process steps
Mix Actors and Systems Freely
- Many business processes involve systems taking the role of a person (in fact, many systems are designed to eliminate a person having to do something), so you could argue that a system taking the role of a person should have a swimlane that is a peer to a person
- Interactions between a human actor and a system in a process almost always trigger a use case, though it is not always easy to reference the use case from the diagram.
- If we’re defining human system interactions, are there better models for us to be using than a swimlane diagram?
