Using Archimate in the Enable Project

The project team are nearing completion of the development of an application to support external examiner appointment and reporting processes. This has provided an opportunity to assess the value of Archimate modelling in a limited scope.

Background

At the start of the Enable project, projects in the programme captured a snapshot of curriculum design and development practice to act as a baseline against which changes could be evaluated later on. We carried out an extensive series of interviews with a wide range of stakeholders to capture current practice, problems and concerns. From this we identified two major barriers to innovation with curriculum design and development processes. These were:

• a lack of communication and coordination between change projects leading to conflicting project goals and duplication of effort and a sub-optimal result for the organisation as a whole
• a focus on business process re-engineering leading to changes at the business level alone, with the potential benefits of supporting IT often overlooked.

These were aspects of change management that could be improved. Project alignment and co-ordination could be realized by introducing programme management and the focus on business architecture changes could be reduced by applying an Enterprise Architecture approach.

Quality Review

An opportunity to pilot the EA approach on a small scale arose from the recommendations of an internal quality process review which had looked at re-engineering course development, approval, monitoring and review processes.
The review identified some duplication of effort and recommended further work be done to streamline quality processes. We consulted with the University business re-engineering manager who had led the review and agreed that improvements to external examiner processes would provide an appropriate scope to try out enterprise architecture modelling.

Stakeholder Interviews

We took process maps created in the review and interviewed stakeholders from faculties and the central quality improvement service to create a snapshot of the current processes.
We used the enterprise architecture practice of looking at the processes in the context of the surrounding ‘system’. In the interviews, this required a shift away from capturing process detail (as you might if you were looking to produce BPMN models) towards capturing overviews of processes and what applications and data are used to support the processes.
This omission of process details in favour of high-level dependencies is a hard task initially as traditionally we do not model the big picture and there is a natural tendency to want the details. What must be understood is that these models are for a very different purpose than business process models. The intent of enterprise architecture models is not to document all the details but to document the coherence of the system. They show where dependencies exist and act as a focus for discussion of issues and trade-offs with stakeholders. The stakeholders know the details.

Archimate Modelling

A key part of the enterprise architecture approach is to model the current situation (the baseline or ‘as is’ model) and the future situation as it would be with your proposed changes in place (the target or ‘to be’ model). Then you analyse the gap between the two models and plan developments to bridge the gap. This could be all in one go for small scale developments or it could involve a series of incremental steps for a more strategic-level engagement.
We created a model representing the current state of the business processes based on the information provided by the stakeholders during our interviews. We then created another model to represent our vision of how the processes would operate after the improvements had been made. We used the free Archi modelling tool to create the models in the Archimate modelling language.

Using The Models

From the models, we created a series of slides to illustrate our proposal and presented it to the Enable Senior Management Working Group. In the slides, we built up the ‘as is’ and ‘to be’ models incrementally to explicitly illustrate the duplication of effort in the current situation, and how we were going to solve it.
An updated version of the slides, refactored to use Archimate 2.0, is shown below. They are best viewed full-screen to see the detail.

Archimate in enable

View more presentations from theparsnip.

Based on our presentation, we secured approval from the Senior Management Working Group to develop the application.

Conclusions

We found that the Archimate language provides a powerful means of communication with stakeholders at a relatively low cost in terms of extra effort. In particular, we found that:

• the duplication-induced chaos introduced incrementally in the slides provided a more compelling call to action than a verbal description of the problem
• the ‘to be’ model presented a clear overview of our proposed solution in the same context in which the problem had been described
• Archimate models show the big picture (coherence and overview) making them particularly well-suited to communication with senior management
• the modelling itself was a relatively small task with the bulk of the effort spent interviewing stakeholders which we would have done anyway to investigate the problem, even if we were not using Archimate
• the modelling exercise provided extra insight into the problem and the models helped to quickly develop shared understanding of the problem between stakeholders
• the Archimate language is easily accessible and stakeholders immediately engage and ask questions about the content of the model rather than what the symbols and shapes mean
• the models provided useful business context for the software developers showing explicitly how their application would support the business processes.