Modelling business processes.

The first step is to agree upon a way to describe business processes in the organization.

You must consider the domain of business processes the entry point to the Land of Enterprise Architecture for the organization. This calls for a requirement to make the model simple and accessible for everyone in the organization. However, your own agenda – as the enterprise architect – is to be able to map the business processes described by the organization further on to services and SOA infrastructure.

As stated in the previous article the domains of business processes, services and SOA infrastructure are mutually dependant. Hence also the modelling principles within these domains are mutually dependant.

If the organization has an existing well implemented way of modelling business processes, we usually continue to use that model. However, we check to see that 4 particular requirements are satisfied. The model must:

  • describe the process,
  • describe the events going in and out of the processes,
  • describe which events initiate and end each processes, and
  • describe who is responsible for the performance and quality of the process.

Most models we have seen are able to tell us these things. They are common components of most models describing business processes as it is considered common sense to know these things about any business process.

Consider the popular swimlane diagrams like this one:

 

Processmodel

The diagram above states that the HR department holds the responsibility when the organization hires an employee. The outcome from the process "Hire person" is called a "Contract". A copy of the "Contract" is sent to the Salary department who is responsible for the "Assign salary" process that takes place. Likewise a copy of the "Contract" is send to the IT department who is responsible for the process "Create user".

The diagram will be the same regardless if the process is automated or performed manually. Consider the process supported using paperforms with carbon paper in between - like we did it back in the 1960's. It is the exact same process today and in the 1960's. Only difference is that potentially the process holds a higher degree of automation today.

This model satisfies the above-stated requirements;

  • The processes are depicted.
    Depending on the tools you can usually find a description of what’s going on within the process.
  • The events are shown.
    Again depending on the supporting tools you can find a description of the content of the entity Contract.
  • In the sample above Contract is the event fired by the Hire Person process. The same event triggers the processes Assign Salary and Create User. Now we know which events initiate which processes and the outcome of the processes.
  • The swimlanes themselves tell us which department within the organization is responsible for each process.

Having this sort of model we know most there is to know about which processes are initiated by certain events and what the processes are supposed to end up with. We also know where to go if a problem arises or if changes occur in any process. This information represents most we need to know for now.

The model is simple and easy to understand for most people in the organization and it is easy to introduce to people with little experience in process modelling.

In some organizations the issue of authorization needs to be addressed in the initial model as well. We will get back to how you deal with that later.

On to Service boundaries.