The Modern Analyst Blog for Business Analysts

Howard Podeswa
Howard Podeswa

BA ABCs: “A” is for Activity Diagram

BA ABCs: “A” is for Activity Diagram

Activity Diagram - Howard PodeswaThis blog begins a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I’ll be moving through the alphabet, highlighting a BA tool that begins with the letter of the day (not quite Sesame Street, but not PeeWee ‘s Playhouse either). Today’s letter is “A” – for activity diagram.

The following activity diagram example describes a portion of the workflow for the business process, Review Pursuit – one of the processes within a Customer Relations Management (CRM) system. The two participants in the process are represented by the columns (referred to as swimlanes, or partitions), named “Growth and Markets” and “Pursuit Team.” The example indicates that the process starts when a Pursuit Team reviews an opportunity report. If the review has determined that the opportunity is not worth pursuing, the process ends. Otherwise, Growth and Markets schedules a post-review meeting and discusses required support.
This kind of diagram could have also illustrated which computer systems automated which activities, by depicting the systems as swimlanes - and, in fact, this is precisely what was done in the real case from which this example was derived.

Background on the example:
A number of years ago, I did some consulting for a financial investment firm. The goal of the project was to improve the business process workflow for tracking opportunities and proposals in a Customer Relations Management (CRM) system. The company had been using a number of software products to handle the process – CMS Open for one aspect and PeopleSoft for another. Amongst other things, they were unhappy with the amount of double entry they were doing – entering client information on one system while an initiative was at the proposal stage and doing it again on another system once the proposal was accepted. As a first step, I was asked to develop an As-Is workflow diagram for the current process. Suspecting that one must already exist, I asked to see it but was told that no, there was no diagram. After a while in this business, you develop a sixth sense for detecting when somebody is holding something back so I persisted – and sure enough, the interviewee pulled one out of his desk drawer. I knew it wasn’t perfect (which is why he hadn’t wanted to show it to me) but I was glad to have it – as it was a great aid in facilitating group interview sessions. It’s much easier to look at something and find the errors than to begin from scratch; or another way of putting it: better to have a straw man than no man at all.

The diagram I used showed the steps of the process and indicated who or what system was responsible for each step. This type of diagram is known by many names: Flowchart (which often only shows the sequence of actions but not who does them), Swimlane Workflow Diagram (where the doer of each action is shown) and (if you are using the UML standard) an activity diagram (which may or not show the doer, depending on how it’s drawn).

Activity diagrams are useful in the situation I’ve described – when you need to analyze the workflow of an existing (As-Is) or future (To-Be) business process. In the UML, (using Rational Unified Process [RUP] terminology) are used this way when specifying business use-case realizations (descriptions of the internal workflow used to execute business processes). In this type of situation, they are drawn so that the doer is shown – by indicating a swimlane (or ‘partition’) for each participant.

Another context for using activity diagrams is in describing system use cases. A system use case is a user task – typically a task that a computer user expects to accomplish in a single session on with a software system. The requirements for the interaction between the user and system are usually described in text, but an activity diagram is added if the steps within the text connect to each other in complex ways. (The document that houses all of this is called, in RUP, a ‘use-case specification’.)

Howard Podeswa, author of Noble Inc.

This entry was published on May 17, 2010 / Howard Podeswa. Posted in Unified Modeling Language (UML). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  7 members liked this article

Related Articles

COMMENTS posted on Wednesday, July 28, 2010 11:19 AM
Visual modeling is the best way to get people from a variety of functions to understand something. Interestingly, when you start with pictures you start with the 'big picture' and when you start with words, you start only with the details. BA's are well advised to always use visuals to improve collaboration. Mendix actually has a Business Modeler that allows you to deploy apps from the initial visual models - really cool feature for agile development.
Howard Podeswa posted on Tuesday, September 21, 2010 5:58 PM
Re: "Visual modeling is the best way to get people from a variety of functions to understand something" (Eric Peters) - I couldn't agree more - though I wouldn't go so far as to say that BAs should "always use visuals to improve collaboration". Sometimes, you need details (for example, when documenting the required user-IT interaction for a new application) - and these are best expressed with words, as are definitions etc.
Howard Podeswa posted on Wednesday, September 22, 2010 9:26 AM
This is true when you're not using a tool like the Business Modeler I mentioned, where visual models of requirements are actually plugged in and generate/deploy a working app in your browser. In this case, even your detailed requirements like user-IT interaction, can be modeled in a microflow, or generated with user roles. In other words, activity diagrams can be more integrated with the actual programming than you think.
Putcha posted on Monday, December 30, 2013 10:45 PM
Hai Howard Podeswa:

Activity Diagrams:

Activity Diagrams are a wee bit better than "flowcharts" in that they identify the performer of activities but still they only show "imaginary" control flow, leaving out the more important and substantial "things flowing into an activity as input and flowing out of it as output".

In the early versions of UML there was provision for object flow though it was not much used. From version 2.0 onward, "the objects are shown as nodes". So, the simplicity that "every node is an activity and every arrow a thing that flows" is lost. This is a needless confusion without any benefit (as I see it).

Hope you will be covering these aspects in the revisions of A and B.

UseCase Modeling

UC in Single Session

I appreciate your emphasis on "single session". Many professionals DO NOT see that implication. I had to explain at length why a UseCase has to be a "single Session" but many professionals fail to see the need for it. You may see:

and let me have your views.

UC Representation:
For representing UseCase I find Sequence Diagram better suited but even that goes beyond the "Scope of UseCase" which I think is only "the messages of dialog" but NOT activities of internal objects of the System to be Developed STBD,

Please take a look at and let me know your views.

Best wishes,

[email protected]

Maurice posted on Thursday, August 4, 2016 10:55 AM
Really found value in this post and the subsequent comments have been insightful especially - Visual modeling is the best way to get people from a variety of functions to understand something. Interestingly, when you start with pictures you start with the 'big picture' and when you start with words, you start only with the details.
Only registered users may post comments.


Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts. LinkedIn Group on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Copyright 2006-2024 by Modern Analyst Media LLC