Highlights

30 December 2009

We reach the end of another eventful (for some) year. I have had some interesting experiences, some of which I have recorded in this blog.

Looking forward to 2010, I see WSO2 having a breakout year with their complete SOA platform as described by Samisa. We now have a complete and comprehensive platform for SOA. As our tagline states, it is lean enterprise middleware.

This is going to be a challenging time for me, as we sign on more customers for Professional Open Source Support - which is my domain of responsibility.

Personal highlights 2009

1. Celebrating my wife's academic achievements (she wants to remain anonymous)
2. Working for WSO2 - what an enlightening experience
   
3. Returning to Sydney, winning the Super 14 tipping comp and of course being frustrated by the Waratahs 
4. Actually writing entries to this blog - my most consistent thus far
5. Consistently running 5-8kms two to three times a week

On other things that stood out for me were:

1. The end of the LTTE - after 30 bloody years
   
2. Obama - can he resurrect the hope for change, or has he gone feral?
   
3. Tiger Woods (oh what a fall)
4. Angelo Mathews - a cricketer from my alma mater
5. Usain Bolt
   

In general, it has been a very challenging year. One, which I hope, I navigated with equanimity - something that I will aspire to next year.

Here's to a peaceful and happy 2010 for all.

Getting started - WSO2 Cloud Computing with Amazon EC2

WSO2 have just released their products on the cloud. Their AMI's (for Amazon EC2) can be found at [1].

It is actually quite easy to get your AMI up and running. First, you need to create an Amazon Web Services [2] account. Once this is done you can use the Amazon console, or elasticfox [3] (a Firefox extension to control your EC2 instances) to create/launch your AMI's.

This alone is not enough. You need to allow your EC2 instance of the WSO2 product to accept traffic from other machines. This can be done by modifying the security group. This can be done via the EC2 dashboard, or via elasticfox. What you need to do is allow https traffic on port 443 from your IP address.

Once you have setup your security group, you can navigate to your WSO2 product at https://{$public dns}/carbon.

When you first startup your WSO2 product has a default admin password (username: admin and password: admin). The first thing you should do is to change the administrator password by
Click on 'User Management' on the left navigation
Under the 'System User Store' click users, and then
Change the password for the Admin user

Once this is done, you are good to go.

[1] http://wso2.com/cloud/virtual-machines/amazon-ec2/
[2] http://aws.amazon.com/
[3] http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609
[4] http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1797&categoryID=174

2009 Q2 WSO2 Technical Update

WSO2 recently published a technical update for 2009 Q2.

2009 Q2 WSO2 Technical Update

View more documents from WSO2.

WS-Security explained

Prabath from WSO2 has an awesome presentation that simply explains WS-Security.

Summer School - Security in SOA

View more documents from wso2.org.

Gatherspace's view of writing effective use cases

I'm always on the lookout for good reference points about keeping use cases simple and to the point. Gatherspace has a great static page on this subject.

Link to: Writing Effective Use Case Examples

What makes an ideal model

I am currently reading BPMN: Modeling and Reference Guide by Stephen A. White and Derek Miers (ISBN: 978-0-9777527-2-0), and it is a great introduction to BPMN.

As I was reading it, one thought stood out clearly. And that relates to an earlier post I made about flowcharts.

Chapter 4 puts my thoughts of a good model quite articulately (quoting Marshal Clemens from Ideagram). Namely they should be

• Salient - only include detail that is relevant to the task at hand.
  
• Accurate - it should reflect the correct state of affairs, not a biased or incorrect view.
  
• Complete yet Parsimonious - it should be simple as possible, but no simpler
  
• Understandable - it should not be too complicated for the reader to understand. Any assumed knowledge should be indicated.

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.