Intalio

For the last few days I have been playing with Intalio. Specifically, the IntalioDesigner.

Intalio have integrated the BPMN designer available with eclipse to the Intalio Server - which implements BPEL 2.0.

So far this tool looks quite promising. There are a few quirks in the software (probably due to the fact I am using an old Macbook Core Duo). It also helps if you know a bit about deploying software on a Unix machine.

The tutorials provided by Intalio can be improved. A combination of going through the tutorials, and their forums is needed to get some basic items working. This increases the learning cost.

Hopefully, I will be able to upload some useful tutorials on this tool soon.

Business Process Modeling Notation

Business Process Modeling Notation (BPMN) is one of the current buzzwords. Does it hold its value? Will it last a long time? I think its a giant step in the right direction.

A BPMN diagram does two things.

1. A visual representation of the process that is easily understood
2. A mapping to BPEL (Business Process Execution Language)
   

The theory here is that you should be able to generate BPEL from a BPMN diagram.

Why should BPMN be more successful than other graphical modeling notations? The answer is simple. The BPMN diagrams are simple. Almost as simple as flowcharts discussed earlier.

BPMN uses four basic categories of elements:

1. Flow objects
2. Connecting objects
3. Swimlanes
4. Artifacts

There are three main flow objects that define the behaviour of a business process

• Events
• Activities
• Gateways

These flow objects are connected to each other by three possible types of connecting objects:

• Sequence flow
• Message flow
• Association

These objects and connections can be grouped in swimlanes using:

• Pools
• Lanes

Finally, the following artifacts can give additional details about the process:

• Data object
• Group
• Annotation

There you have it. A core set of 11 elements in four categories to describe a business process visually.

My recommendation is to keep the diagrams as simple as possible. As the author of the diagrams, do yourself a favour, and make it as easy as possible for you to explain the process to someone else.

For further information and a primer on BPMN visit DiveIntoBPMN.org.

References:

• Busiess Process Modeling Notation (version 1.2)

Minutes to Cover Your Arse

Requirements will change during the course of any project. Ideally your customer will have designated a requirements champion who signs off on the requirements. Often you will have to deal with competing requirements from multiple stakeholders.

Trying to accommodate competing requirements usually results in increased scope, and therefore increased cost, longer time or lower quality (or all three if you are careless). Project managers (customer and contractor), business analysts and engineers all play their part in managing scope.

I have a simple rule - cover your arse. I usually do this by sharing notes of any discussion with the participants of that discussion. These discussions can be formal (meeting, workshop) or informal (a chat in the corridor, over a coffee, over dinner etc.). Either way I send out a note with the contents of that discussion - a minuted record of the discussion.

To paraphrase Humphrey Appleby from the satirical comedy Yes Minister (series 2, episode 2):

The purpose of minutes is not to provide a written account of a meeting, but instead to protect people. They allow a pause where anything regrettable said in the heat of the moment can be safely put to one side and not appear in the official record of events.

Use meeting notes, minutes, followup emails to cover your arse and protect yourself.

My meeting minutes or notes contains five sections - who, where and when, notes, decisions, and actions.

The contents of each section is self explanatory:

• Participants: The participants of the discussion - full names and initials in brackets if needed.
  
  
• Where and when - location, date/time, duration: If a phone conversation, indicate the phone, or conference call number.
  
  For formal meetings with an agenda, I usually include it here.
  
  
• Notes: These are general notes made during the meeting. For example, 'Henry did a great job on that module', 'We are having further discussions on strategic direction of the company' etc.
  
  These are notes that are related to this meeting, but not necessarily an outcome. The aim of recording it here is to establish a context to this discussion and future discussions. These notes do not result in a decision or an action.
  
  
• Decisions: All decisions not resulting in an action should be listed here. For example, 'postpone module A deliverable'. 'The delivery will be made at a lower quality threshold'.
  
  Its always a good idea to indicate who made the decision - whether it is an individual participant (who may be acting as a proxy to another member unable to make it to the meeting), or the collective team.
  
  If a decision results in an an action, then add it to the actions section.
  

• Actions: List out any follow up actions that need to take place, the owner of that action, and when the action will be completed by.
  
  The owner of the action is the person responsible for ensuring the action is completed by the agreed date. Occasionally the owner may ask someone else to execute the action. Either way, the owner has the responsibility to deliver on the action.
  

All in all, its quite a simple process. Breaking it out to each section makes it easy for the reader to understand the context and result of any discussion or meeting.

For informal discussions, I try layout the notes so it can be viewed by a simple text reader - such as a blackberry. The result is a neat, clearly spaced out note that can be read and comprehended quickly.

Why I Like Flowcharts

Flow charts are simple and everybody understands them. You can draw a reasonable flowchart with just five shapes.

• Start/Stop or Begin/End

• Activity

• Process (pre-defined)

• Decision

• Arrows

For very large and complicated diagrams, I occasionally use swimlanes page connectors - to cover multiple pages.

There are other flowchart shapes in common usage as well. I prefer not to use these unless it is absolutely necessary.

Flowcharts have their limitations. It only shows what from the 5 Ws (who, what, where, why, and when). To make it more descriptiveve, I just have a call out box with an explanatory note. This is usually sufficient to give the reader all the information required.

Swimlanes can be used if you wish to make it more formal and add who performs the activity or makes the decision.

Again, this is intuitive and easy to understand. Do take time on the text within the shapes. I prefer to use short sentences that can be read and understood quickly.

I have only one rule: all decision boxes should result in a yes or no. Taking care on the text within a shape has a twofold benefit:

1. It forces the author to think about what they are writing
2. It makes it easier to comprehend

The aim is simplicity.

The breezetree site has some additional rules to follow when drawing flowcharts - these are also quite useful.

Further reading:

• http://en.wikipedia.org/wiki/Flowchart
• http://www.breezetree.com/article_generalflowcharting1.htm

First post

I have been documenting business processes and requirements for several years. My guiding principle is to 'make it easy for the reader to understand quickly'.

Use-case is a great formal notation technique - if your target audience knows how to read this documentation. With Agile re-emerging to prominence, user stories are also becoming a common method to document requirements.

My aim is to share my tips and tricks for gathering and documenting requirements, and the tools used for it. I intend to cover Business Process Documentation as referred to in the title as well.