For those that do not have time this blog is my quick start that I can give to people in order to have processes modelled in BPMN with as short a learn time as is possible.
Take a look at the diagram below it has everything we need to get started:
Below are the elements we need to get started with BPMN:
Events are things that happen. In the Example “Once Per Week” is an event – Events trigger the start of the process but also the end of the process. Any event can start a process.
These are the circles. The green circle is a start event. BPMN doesn’t specify the color of the elements, but green is a default scheme with the tool I use and the color is an easy differentiator. Example events include
User requires software
Once Per day
An Email Requesting A Service
The Red circle is an end event. Note the red circle has a thicker line. End events define the conclusion. Examples might include:
Software is delivered
Process Completed Successfully
There are other types of events within the specification but normally having start and end events is enough for most modelling I ask people to do at a basic level.
You can have several events both going into a process or out of it. For Example if we have a approval process we might want to have one end event for Acceptance, one for Rejecting.
On the Example BPMN model there are two gateways.
Again, there are more elements in the actual language, but with these two you can represent most things. Normally with a gateway we put a question in there, and label the decisions choices on the relationship. You can see an example of this in figure 4.
Parallel gateways are demonstrated in figure 1. I like to use them because it makes it visually easy to see when process tasks both split and merge.
Tasks & Sub Processes
In Figure 4 you can see examples of tasks and sub processes. A Task (in the example “Approve the Purchase”) is exactly what you would expect.
A sub process is normally a complete process within our process – used to reduce complexity. in the example above “Order Process” would lead to a whole BPMN diagram which describes that process.
Tying It Together
Relationship wise all the arrows I use in Basic BPMN are Sequence Flow arrows. Remember these diagrams are showing flow, from a start event towards an end event. If we need to flow backwards we need to be careful to make sure the flow does not get caught in a loop. This is done by making the flow arrow flow backwards conditionally using a gateway.
Back in Figure 1 I showed a full BPMN diagram. The last thing to talk about are the swim lanes, which represent the roles of the people that are either making decisions or executing tasks or processes. In Figure 1 we had two roles in the swim lanes – Author and Target Audience. Any thing in the respective swim lane is executed by those roles.
The colors used in the example are the default ones used with BiZZdesign’s Enterprise Studio. I do not change them because I think they demonstrate clearly the different element types.
Summing it Up
This article really showed the bare minimums, and I will use it to quickly introduce people to BPMN when I need things done fast and do not have training time.
BPMN is an easy modelling language to get started and communicate with. Take a look at Risk Analysis BPMN models where I take the next steps with BPMN.
People often make risk assessments without a structured approach relying on intuition or experience. In this blog I show some methods I use to quickly identify risks in BPMN models when formal risk methodologies are not in use (such as SABSA).
As mentioned before in previous blogs, I normally do a process overview in Archimate, and then align it to BPMN because BPMN is easy to understand, and creating BPMN diagrams forces us to think about who is doing what, when.
Design vs Run-time
At the highest level I normally thing of things in terms of design time vs run time risks. Design time risks are the ones that are happening due to the structure of the process and the decisions we have made in process build and run time risks happen when we execute the process. I will talk a little more about this in a while but its important we consider both aspects.
Running Through The Process With TELOS
TELOS (Technical, Economic, Legal, Operational, Scheduling) is an acronym we use for feasibility checking usually. If anyone is interested I can blog on this later. for now – the basics; we look at each of the tasks (the square blocks on the diagram) and ask these questions:
Do we have the software / hardware in place to perform this task? If a task requires the user to modify a Visio file, does he have Visio? Are we relying on a specific platform? For example if we need to read something from CRM, what happens if that goes down? Are we relying on a system that isn’t in place yet or is due to be decommissioned?
Is it clear how to do this? Having the correct level of detail in the documentation is important. If we are creating or saving files for example, have we said exactly where to locate them?
Does we have the skills & competencies in place to execute this? Can the person who is expected to perform the task actually do it or do they need training on how? Are they sufficiently trained if something should go wrong?
Are we doing this the most economic way? For example, a contractor may be more expensive to perform a task than an internal resource.
What would be the economic ramifications of this step going wrong? Would it potentially be a breach in the Service Level Agreement (SLA)? Could it result in a major incident, or financial penalties?
Are we violating any known regulation? For example, Non-EU teams may not be allowed to work with personal information under GDPR. Legal requirements may exist for information retention if we are working with financial data so we may need to ensure it is kept as part of a process.
Have we used the proper roles? Its important that the right person is doing the job. For example, you would not design a process to have a Business Architect install a server. Even if its a particular Business architect has the capability to do it, that kind of work most likely belongs to a technical specialist; assigning the wrong resources can cause all kinds of issues..
Do we have the resources in place? In order to execute the process, have we thought through how often the process will be run, and If we have sufficient resourcing?
Will we be able to do all this when the process goes live? For example, will the training be in place? will the resources be in place?
Can the step be performed in good time? would the duration it takes to perform the step force a breach in SLA when you add it up with the related steps?
There are many further questions we could ask around a design using TELOS as our guidelines, but these are questions I will typically ask when risk analyzing the design of a process.
Run Time Risks
When analyzing run time issues I do this very simply. I look at all the relationships between each of the elements and i ask my self the following questions:
What happens if the communication never happens? This normally breaks a process unless a contingency is put in place. A simple example; If we order something that is never delivered – is it a risk we need to handle? We can always handle risk as part of our normal escalations process but sometimes we want to put steps in place to be a bit more proactive. We could have a timed event in our process that after a week checks to see if the delivery arrived and if not escalates with the supplier, so that we get the required deliverable before it becomes a critical issue.
What happens if the communication is wrong? If we send an order for parts that is incorrect then that’s just as bad as communication not happening – if not worse. Do we need to put in steps to check the communication before it happens, or are we willing to accept the risk?
What happens if the communication is delayed? an order delayed may lead to a breach in SLA – do we need something in place to avoid that?
What happens if a resource isn’t available? as well as individual resources not being available for each step consider what happens if resources aren’t available to perform a role at all… if nobody is assigned for example
What About Events?
The things that start and stop our processes, and the events we trigger and receive during a process should be handled with the same questions I listed for run time risk.
Lets Be SMART
Its another acronym – in the slide above it was about goal setting but it applies equally to process – we cover some of them already in TELOS but for each task in our process:
Specific – Is it vaguely defined or can anyone understand exactly what it is that you need to do exactly. For example “check that the architecture is good” can be interpreted in many different ways – “Check the architecture against the ISO 42010 Checklist” is a bit better defined. In the associated documentation you would also state where it is of course. if we are vague in definitions there is a risk we will be misunderstood, leading to communication overheads, and possibly the wrong things being done (an overhead in work).
Measurable – In defining processes we should also be defining metrics to ensure that processes are healthy. Those metrics should be clearly defined and measurable. If we have a process step to deliver something from point A to point B – we should probably have a metric to understand the amount of time that takes – which can act as a key performance indicator. if these indicators aren’t defined its most likely a design related risk.
Agreed Upon – Its OK to build a process with 10 different actors involved but each one must agree. Even if you are the manager of those resources, this step is still important because they may identify issues in process you do not see. If something is not agreed upon – there’s a risk that the execution may not happen according to design.
Realistic – You could define a process step such as “Get Owen to eat Broccoli”. That’s fine. Now try getting me to do it. If you define a step like that, there could be an associated risk!
Time-Based – You should have a fairly good idea of how long each process step takes. If you cannot define this, its likely a risk.
Summing It Up…
What I have presented here becomes very easy once you have done it a few times, and without exception whenever I have personally applied these techniques I have identified unconsidered areas of risk. I haven’t talked about mechanisms for determining impact and probability, but if you follow these guidelines I believe you will have better more mature risk analysis. Remember its not a bad thing to identify risks. When you identify risks, its OK if business wants to except them – and if they don’t you have improvement actions and quality goes up. When you show a risk list with many risks on it shows that you have done a good job in design, and identifying risks is the first step to solving them. These techniques arent as comprehensive as a full risk management methodology, but they are significantly better than just trying to guess what risks may occur. I hope you find this useful, if so, let me know.
ArchiMate is fantastic and connecting different layers of architecture together, and BPMN is fantastic at modelling process – This article demonstrates my approach to marrying the two languages.
Playing To The Strengths
As I mentioned in my article Architecture Languages, Standards, And Frameworks, BPMN strengths lay in creating process detail – and whilst it’s possible to create processes equally as detailed in ArchiMate, generally speaking those processes tend to require more views, and do not look nearly as tidy without a significant amount of effort.
A question I am often asked is which modelling language should be used, and to what level of detail? Both Languages have pros and cons.
For that reason I tend to model the process and its connection to the rest of the architecture in ArchiMate and leave the details in the BPMN model.
The order you do this very much depends on the level of understanding you have of the process. Some people prefer to do the detailed process and then fit it into the context of the organisation and others prefer to do the general overview and then detail out the process later. As part of my standard approach to creating high level designs I normally create the ArchiMate process overview before the BPMN one.
The ArchiMate Process Overview
In ArchiMate, my overview generally looks something like this:
I start with the actual process in the middle. I have found many architects can have a challenging time fully defining a process; its easier to understand what you need from a process and what your expected inputs and outputs to process are, and who needs to be involved, than it is to understand all the minutiae. So the key elements here:
Business Process – I normally start with one process – with a name suffixed with the word “process”, because its just easier that way to be clear when talking in conversation to other people.
Business Actor / Role – I prefer to use roles rather than actors, because it helps with abstraction and re-usability of the process; it’s important to understand the differentiation – actors are assigned to performing roles. Sometimes I might use both or a mixture of two if i have good reason.
Business Events – In the ArchiMate specification it says that events denote state change in an organisation – The way I am using events here is to denote the events that cause the process to start running, and the outputs of the process The direction of the trigger relationships tell us which are which.
In the view above (fig. 1) we can see that our process serves the “My Software Service” – its good to put a process into the context of either a service or a function within the overview. Of course I can just take one or several elements from such a view and include them in other views as needed:
In figure 2, you can see a support process as part of a layered view; in this case we are connecting a process also into the application layer, you can see how if we had a process overview of Support Process our understanding if it work be better. We may have included some elements that would appear on a process overview; but not probably not all of them – this is a judgement call – when creating a view, I am telling a story, and I use whichever elements are relevant to that story. Of course the story of a process overview, is “this is the process from end to end, and this is how it all works”. Its views like the one above where we are able to use the process in the context of other architecture in a repository – that make modelling the process in ArchiMate worthwhile.
Creating a BPMN model
Going to the next level of detail, if we did a BPMN view for Figure 1, we may have created a process that could end up looking like this:
A couple of key things to note
The swim lanes in figure 3, match the roles in Figure 1; of course, if figure 1 had actors, they would be here too; I need to understand easily how the detailed process in BPMN connects not only into the process overview in ArchiMate, but the rest of the model.
Its really important to give the process in ArchiMate the same name as the process in BPMN so later its easy to search and find it.
We match up the events with same names in BPMN as ArchiMate, It makes sense. I think of them a little like being interfaces into the process.
I deliberately didn’t make the BPMN more complex – Its one of those languages that you can get started with easy, and there’s a few things you can do with gateways, and events, and a lot more possibilities than I show on my example. As I have probably said, I am a great believer in keeping it simple – and the 80-20 rule – you can get 80% of the work done in 20% of the time. Of course encourage architects to learn the standards properly and fully utilize them, but the elements i use in figure 3 cover most of my needs – and I would rather not have architects engaged in hour long discussions over what kind of gateway to use, when it is evident from just leaving the gateway empty and seeing it in the context of the view. I have found in the past, after getting comfortable with the basics, most good architects like to explore these modelling languages and will start to figure these things out themselves.
Why Am I Calling It A Process Overview?
So the elements shown in Figure 1 – could be considered to make up a standard process view like is showing in the ArchiMate 3 manual. I consider the process overview to be a specialization of that – because I am asking for specific elements, in a specific configuration – I tend not to want to clutter the view. I also do not limit this kind of model to the business layer – I could just as easily apply exactly the same concept in the application layer, an application process would be triggered by application events, and may serve application functions – Actors & roles would be replaced by other active elements in the application layer – typically the application component.
How Do You Practically Do This With Tools?
Typically I am using BiZZdesign’s Enterprise Studio (BES), which makes it easy, because the model allow me to create models in either ArchiMate or BPMN. I normally connect those view via hyperlinks – both on navigation pages, and in documentation. Enterprise studio also supports cross model relations – so I can link the navigation of one object directly to another and state the type of relationship; so for example, I could create a relationship on my Software Acquisition Process in ArchiMate to show it is refined in my BPMN model; a number of cross model relationship types exist. I could also tweak the meta-model to give me better options, but I haven’t done that.
Enterprise studio has some new compliance functionality – I did a quick video on it (with some notes in another blog) –
If I was using Archi & Visio, I would create a custom property on the element in the Archi Model and link it to the Visio file in a shared space. All of the modelling tools out there support hyperlinking in one way or another. Another option would be to link from the actual views rather than the specific process elements – but I don’t do that.
Summing It Up…
Of course we don’t actually need to do produce both BPMN and Archimate in all cases, but I do like to leverage the benefits of both together.
The approach I have presented today has a few advantages:
The ArchiMate view is quick and easy to get started with when you don’t have all your process detail.
BPMN is easy for process developers and other people to develop the detail in parallel. This is important if you work in an organization where process is developed separately from architecture.
Following some of the rules I presented will make it really easy to understand ArchiMate in the context of the more detailed view – because the inputs and outputs align.
Having naming aligned, and hyperlinks in place helps you find things – the alternative to this is to have disconnected processes.
I personally believe that not aligning your BPMN models with your ArchiMate ones, is effectively disconnecting process from architecture. But of course, Let me know what you think.