ArchiMate Workshop – Bolton University, May 19th 2009

An interesting event that helped to crystallise my views of the level of detail we should engage in when modelling relevant University processes. There were several presentations from JISC projects that had engaged with modelling processes using the ArchiMate language though using different tools. There was also a brief introduction to the JISC Innovation Base which resulted in a partially complete contribution of our proposed modelling activities for inclusion in the emerging IB.

A couple of presentations were from completed JISC Enterprise Architecture projects where substantial parts of university people, processes and systems are being modelled. It was clear from these that there is a considerable amount of time and effort required to both capture and model University wide activities, though there are potentially considerable benefits for the institution. In both cases there were identifiable full time staff involved in the modelling activity and such staff are based outside the typical University structure i.e. not associated with any particular strand of the University. They could be seen as the guardians of the models of existing organisational roles, processes and systems. Both groups were using a tool called BizzDesign which includes support for ArchiMate – this is an expensive modelling tool [ £2000 per year per licence was quoted].

A third presentation (by Alan Paul from APS Consultancy) showed part of the modelling done as part of the MMU SRC project. This was at a lower level of detail and used MS Visio but it was more detailed than the modelling that I have done for PC3 in that roles and data are separated out from the processes and rules used to represent our Academic Award Validation Process.

With regard to the overall workshop there seemed to be an implicit expectation that participants were already using ArchiMate as there was no actual introduction to the language semantics, similarly there were references to approaches such as ‘The Open Group Architecture Framework – TOGAF’ and an expectation or awareness of the levels of support offered for the language within various tools. It was clear during the discussions that there are shortcomings with regard to ArchiMate in that it appears to be well suited to modelling (and visualising) the relationships between roles, processes and systems but was less suited to more detailed process descriptions particularly where there decision points with alternate paths that could be followed.

I propose that we look at my existing models of the Academic Award Validation process and represent it with the roles and data elements split off and then present it back to SRO to see if they find it more useful.

JISC Programme Meeting

Attended the JISC programme managers meeting today with John. As usual the Sarah’s team put together a well organised and structured day, with good food and space to socialise. The theme for this meet was change management and how this impacts on the structure of the evaluation plan. A particular emphases was again placed on the need for base-lining, particularly form the perspective of stakeholders and their expectations. I found the presentations interesting and informative.

Peter Bullen (University of Hertfordshire) a critical friend, gave a presentation on the CABLE project, developed to support change at a local level using the HEA’s SOME NAME  methodologies. The point I particularly liked here was the inclusion of student representatives within the teams instigating the change process. This is something we should possibly consider, once we have a first cohort going through the PC3 process. While capturing the student perspective is part of the evaluation process,  having live input during the revision process might be very beneficial.

Several models of change management and assessment were also presented. As table teams, we  were asked to consider our current institutional environment form several  perspectives and identify the types of strategy that might support the changes required by the project. This was a very debatable topic, and John and I found that we had fairly different views. However this does highlight the importance of role and experience based perspectives. While it is not possible to accommodate all (a most frequently quoted phrase) the more you are aware of the more likely you are to be able to adjust to those that become barriers to change.

The final exercise of the day (other than a quick cluster debriefing) was to consider the project stakeholders. This was facilitated by a very handy set of documents that I think might be useful for us as a team to consider at our next meeting. Several issues/considerations were raised during this. The difference between the requirements from a stakeholder’s role and their requirements as an individual were raised during our tables discussion. This was brought up in light of the prospect of an individual changing jobs, which also reflects on the risk analysis. Another issue discussed and also highlighted by other groups, was where to draw the line regarding which stakeholders to include within the projects process. This becomes a particular issue when stakeholder views/requirements change frequently, and in effect pull the project in directions others than those intended. As with most things these issues are not new nor unique, and require a balanced approach and well documented justification for the decisions taken.

All in all a good day.