Process Models: Who is doing what?

Process Models: Who is doing what?

Process Models
Process Model Diagram

Every Business Analyst and Business Consultant should know something about Process Models and Process Modelling. Creating a simple model of what is happening outside the IT System can be a very useful place to start. You may even benefit when there is no IT System at all!

Ways of using Process Models

A Process Model is simply a representation of what the process is doing in the real world. This representation is usually graphical. There are different notations, and a large number of tools to help you draw the pictures.

Trivial Process Model - Documented using a Process Modelling tool
Trivial Process Model – Documented using a Process Modelling tool

Process Models can be used in a number of ways, many of which overlap.

  • A model can be used as a framework to assess the process against some criteria.
  • Models can be used to explore the effect of some change to the process.
  • Models can also be used to show how the physical world and IT interact.
    Using Process Models appropriately can help ensure that any changes are beneficial to the business.

Process Models: “As-Is” and “To-Be”

Process Models can be used to explore changes to a process. The “As-Is” model shows how the process works now, and the “To-Be” model shows how the process will work after the proposed changes. Comparing the two models allows us to demonstrate how the changes will be beneficial to the business.

The changes need not be changes to IT systems. The benefits which can be demonstrated may be the elimination of roles, or reduction in time or the number of steps.

Process Models: How does IT mesh with the business?

Gears - Process Models show how things interact
Gears – Process Models show how things interact

The Swim-lane process models demonstrate how different roles collaborate or people use several different tools or IT systems to perform their work. Imagine the different roles or tools as “gears” and you will understand what I mean. Using swim-lanes helps you to visualise and communicate how the different lanes interact.

Traps you can avoid using Process Models

Where a business process involves activities in the physical world (and not just doing things at a screen) then a process model can help put the IT systems into context. Doing this may prevent you spending time on details which are not important.

Ways Process Models can trap you!

Many process modelling tools allow you to break-down individual steps into smaller pieces. Resist the temptation to break things down too early, or everywhere. If you keep your models at a high level you will reduce the amount of work you have to do, and you will not reduce the value of the models.


Process Models can be used to put the IT system into a wider business context. They can even be used to analyse and rationalise processes where the IT systems do not play a significant role. Process Models are commonly used to demonstrate the claimed benefits of a new way of doing things, the so-called “As-Is” and “To-Be” models.

The keys to success with Process Models are to present the simplest model which is appropriate for your needs and to control the amount of detail.

Context Diagrams: Putting things in Context

Context Diagrams: Putting things in Context

Simple Context Diagram, application of Context Diagrams
Simple Context Diagram

Every Business Analyst should know something about Context Diagrams. I often draw an informal Context Diagram as the one of my first activities when I start a new project. Context Diagrams are good for focussing the mind and reminding you what you don’t know and need to find out.

What is a Context Diagram?

You have almost certainly seen Context Diagrams, even if you haven’t recognised them by name. A Context Diagram is a shape (usually a rectangle or circle) which represents “the system” which is the focus of our interest. This shape is surrounded by other shapes which represent things like:

  • Users of the system (or actors)
  • Other systems

The satellite shapes are joined to “the system” by lines. Sometimes the arrows on the lines have real significance, sometimes they are there for decoration.

Context Diagrams were commonly used as the top-most level in decomposition methods (such as SSADM). They are still with us in the form of the Use Case diagram in UML.

What will a Context Diagram tell us?

A Context Diagram will tell us about who uses the system we are looking at. It also tells us about the other systems it interacts with. The diagram actually tells us very little about our system!

When are Context Diagrams useful?

Context Diagrams are useful at towards the start of the project. They are good for communication and especially good for summarising who and what interacts with the system.

Although they don’t define our system at all well, they do make it clear what is outside. As a consequence, they are good for communicating “scope”. I even use them to help define scope during project initiation.

A really good use of Context Diagrams is to emphasis interfaces with other systems.

Limitations of Context Diagrams

There is something seductive about a well-drawn Context diagram. It seems to say a great deal, but actually it doesn’t say a lot.

It is wrong to try and make a Context Diagram do too much. Imagine a diagram with tries to show connections with 100 different objects. It would turn into a mess which nobody could read. As a result, the number of satellites is often edited. That makes the diagram easier to read but removes important information.

As a consequence, Context Diagrams are best used for illustration and communication, rather than definition.


Context Diagrams are a great way of providing overview and “putting things in context”! They are easy to produce and people understand them intuitively. They are good for communicating ideas to a non-technical audience.

To get the best from Context Diagrams you have to recognise their limitations. They are good at describing what is outside “the system” but they say very little about the system itself. They are not very good for detailed definition, and if they contain too much detail they actually become less useful!

Business Analysis: Pictures versus Words

Business Analysis: Pictures versus Words?

Image expressing "Pictures versus Words". An image of a pipe and the text "This is a pipe"
Pictures versus Words: This is a pipe

Business Analysts use models which are presented as pictures. Business Analysts also need to write text. This may give rise to a debate:

“Pictures versus Words – which is better?”

(In the picture I’m making a playful reference to Rene Magritte’s famous painting “The Treachery of Images”). Unfortunately, the honest answer to this question has to be “it depends”. It depends on what:

  • You trying to achieve with your model or text?
  • The business side wants and understands?
  • IT side needs and understands?
  • You comfortable with?

Inevitably the answer is going to finish up as a compromise.

The limitations of words

Words used as a bridge between Business and Information Technology
Words alone may form a weak bridge

Words are marvellous! You are reading this blog post! Informally, most projects start off with a short statement “we want to do something”. We add detail to that statement and it becomes a list of “requirements”. That is good, but as we start to describe our “pipe”, sometimes we find that “a picture (or model) really is worth a thousand words”.

In the “Pictures versus Words” debate, the strength of words is found when they are brief and used to define the details. They are less good for explaining how things relate to one-another.

Words alone may make for a weak bridge between business and IT. And beware! Lawyers have been arguing about the precise meanings of words since time immemorial!

The power of models (or pictures)

Orthographic projection sketch of a chair
Orthographic projection sketch of a chair

“Orthographic Projection” is one standard way of arranging different views of the same object. You know very quickly that the diagram describes a type of chair.

Picture models like engineering drawings are strong when they are used to provide overview and show how things relate to one another. By using different views of the same thing we can check each one against the others and detect inconsistencies at an early stage.


In summary, pictures and models are useful and so is text. Use both as appropriate. Add detail as you need it, but limit the amount of detail to what you need. Choose the models you use with care so that you can use them to validate the requirements. My advice is to apply Ward Cunningham’s comment “The simplest thing that could possibly work” to documentation and requirements.

Are you wearing a Business Analysis Hat?

Are you wearing a Business Analysis Hat?

Business Analysis Hat
Business Analysis Hat

Are you wearing a “Business Analysis Hat”? You may still find yourself performing Business Analyst activities even when it is not your job title.

For a great deal of my career my job title has been “Something… Analyst”.  I have found myself performing analyst activities even when “Analyst” has not been mentioned in the job description. Lots of people tell me they have had similar experiences.

Rigid demarcation or flexible roles?

Some organisations have rigid demarcation between roles. In these organisations just reading someone’s job title tells you what they do: Business Analyst, Project Manager, Developer etc.

In smaller, less structured organisations, everybody “mucks in” to do the work.

Even in the more rigid situation, Analysis is an activity overlaps with others. Analysis clarifies what needs to be done. Business Analysis is not so much a question of who is doing it, as what they are doing and what tools they are using. Anyone can find themselves wearing a Business Analysis Hat!

What kind of Business Analysis?

One of the classic metaphors used for Business Analysis is a bridge connecting “Business” and “Information Technology”.  Business Analysts use metaphor a lot. We spend a lot of time saying:

  • “This is a bit like that”, or
  • “This represents that”

When we do this we are trying to “facilitate” communication between the two sides of the bridge and helping each side understand what effect they are having on the other side. “Facilitate” is one of the buzz-words you may hear a lot!

Business Analysis Bridge
Business Analysis Bridge

This facilitation role has several aspects, which are not mutually exclusive. Some of the activities I have seen are:

  • Managing “Requirements” – Put what “The Business” asks for into a formal structure. These “Requirements” are used by “Information Technology”. “The Business” understands the solution in terms of these requirements.
  • Encapsulating IT – Summarise the complexity of “Information Technology” so “The Business” can make informed decisions.
  • Working with Numbers – Use IT tools to understand aspects of “The Business” and present those insights to the business.

What kind of tools will you use?

Analysts use “soft skills” and “documentation skills” but they also make extensive use of “models”. You will hear mention of:

  • Process Models
  • Data Models
  • Use Case Models
  • and several more.

Understanding what the different types of model can give you and choosing the appropriate model for you situation can make communication more effective. I plan to explain some of the different models and notations in later blog posts.


Business Analysis facilitates communication between The Business and Information Technology. Analysis clarifies what needs to be done. Almost anyone can find themselves “wearing the Business Analysis hat”!

Communication is not only in one direction. Analysis uses many kinds of model and using the model which is appropriate for the situation can make communication more effective.

Simple ideas are the best – BA toolkit?

Today I stumbled across a blog post from a year ago where Ron Healy suggests creating a “Temporary Whiteboard” to carry about. The “whiteboard” is created by laminating a sheet of white paper! Sometimes simple ideas really are the best. You can’t get much simpler than that!

Ron suggests having parallel lines on one side which can be used for:

  • multifunction swimlane
  • activity diagram
  • sequence diagram
  • class diagram
  • hierarchical chart
  • system & subsystem diagram

This is such a good idea. As I commented on Ron’s blog – I’m a Business Analyst and I have been been using a daily plan made the same way for years and it didn’t occur to me to extend the idea.

Simple ideas - Laminated Daily Plans
Simple ideas – Laminated Daily Plans

I have two “plans” which I use which you can see in the picture. There is an A5 size one which is punched with two holes so I can have it at the front of an A4 ring binder and an A6 size one which I keep at the front of my Time Manager.

The layout of my plan is based on the forms I used to use in my Time Manager, but I like to remind myself of the “Elephant” and “Frog” tasks I am dealing with at the moment.

Once way in which I differ from Ron is that he uses dry wipe markers. On the other hand, I use a permanent marker and then wipe the plan down with alcohol at the end of the day when I am planning what to do the next day.

More simple ideas: What do you keep in your toolkit?

“Simple ideas” got me thinking about the Business Analysis or BA “toolkit” I carry around with me. For at least some of my working life I needed to use public transport, and that encourages you to carry the minimum you need.

My toolkit contains:

  • Laptop
  • Laminated plan
  • Diary
  • A4 ring binder to contain the current notes
  • Pack of Post-It notes
  • Pack of file cards
  • Foolscap or A4 wallet folder to hold loose bits together
  • A4 spiral bound notebook
  • Whiteboard Markers

What do you keep in your toolkit?