In a previous post on this blog about our use of Archimate I
talked about the difference between Archimate views and business process maps. It can be a struggle to find the right level to model at
when creating Archimate views. There is a natural tendency to include too much
process detail, especially if modellers have process mapping expertise. Archimate
views are intended to act as the focus for discussion of issues and trade-offs
between domain experts, not to document process details. Consequently, the goal
of the Archimate modeller is to capture enough information from domain experts
to create the view whilst resisting the temptation to cram all the details into each
view. A 'just enough detail' approach is needed. Because this can be a tricky balancing act, I thought an example of how they
differ might be useful. This post shows how a simple Archimate view can be
derived from a Business Process Modelling Notation (BPMN) process map and illustrates
how the resulting Archimate view captures an overview with the BPMN process map
providing the details.
The BPMN process map below, captured as part of the StaffsXCRI-CAP Course Data Project, shows the process for creating a postgraduate
course sheet for a new award. The postgraduate course sheet is used to
advertise the award. The process map shows the flow of actions carried out by
staff involved in the process. The horizontal swim lanes denote who does what.
Each of the boxes describes behaviour that occurs in sequence as part of the overall
process. BPMN process maps such as this one describe the process in sufficient
detail that someone given the process map would know what to do to participate
in the process.
Throughout the process map there are references to actors, roles, business objects and other entities that we would want to include in the Archimate model. These are highlighted in the text of the process map below.
The highlighted items refer to Archimate elements as shown in the process map below. The overall process becomes a Business Process element in the Archimate view. The swimlanes refer to Archimate Roles. The text describes several Business Objects, software applications and bits of infrastructure like shared network drives (represented as Technology Nodes).
These Archimate elements can be collected into an Archimate view and relationships and inferred elements added to arrive at the view shown below.
You can see that the Archimate view doesn’t contain any of
the process detail. It only shows that there is a course sheet creation process
which has a range of roles involved in performing it, with business objects and
applications used along the way. The value of this level of modelling might not
be evident from this single view but as more views added to the model, a
critical mass is reached whereupon the model becomes a useful tool for
analysis. Individual actors, roles and business objects can be quickly dragged
into a view and related elements added to find out, for example, what processes an actor or role is involved with or who needs access to particular business objects for what purpose.
In the JISC Enable project we used existing process maps,
corporate process documentation and notes from a series of interviews with
stakeholders as input for the creation of our Archimate models. The approach
shown above works for written documentation in the same way as with process
maps. Pick out references to Archimate elements in the text and add them into
Archimate views.
To make gathering of the right information easier, we used a
simple template for making notes from interviews which is shown below. The
columns acted as a prompt for us to ask about all aspects of the business architecture
and enough about the other architecture layers to have a good go at creating a
model on the first attempt. This reduced the need to revisit the same areas
with stakeholders because of missing information.
At Staffordshire University, everyone who has tried Archimate modelling has found that the process of modelling itself has raised
questions about how everything fits together. Answering these questions has led to improved
understanding of the problems we are trying to solve, improved understanding of
the solutions and improved communication with stakeholders.
1 comment:
Tibco online training
Tibco spotfire online training
RPA online training
Ruby on rails online training
Post a Comment