Modelling – How Do You Know When to Stop?

I attended JISC CETIS’ Introduction to Modelling workshop in Birmingham last week to try and gain an understanding of issues and what one needs to consider, when attempting it for the first time.

So why bother with modelling? What value does it bring? Models are a way of communicating and sharing experiences. They are very visual and may have some narrative, but with some slight clarification of terminology used, they should be understandable by most stakeholders. This is key. Otherwise, how else can the whole system be shown to stakeholders who may only know a small part?

Whilst the workshop looked at both hard and soft models, it was the softer side that caught my attention. Hard models, such as UML (Unified Modelling Language) or BPM (Business Process Modelling) are ideal for defining technical specifications and describing business intelligence. Soft models, as one would expect, tend to be quite woolly and may include portfolios of evidence (documents, observational notes, video diaries, etc), scenarios and personas, and use SSM (Soft Sytems Methodologies).

There were two practical exercises that we all attempted. One of which was to produce a soft systems diagram showing how to respond to a JISC call for funding. I’d never done any modelling before, but something that had seemed so simple in the introduction, was unbelivably difficult when we sat down to try it for ourselves! We didn’t need any whizz bang technology – just a handful of coloured markers, multi-coloured post-its and a large sheet of paper. Here’s a model that one of the groups came up with.

Attempt at a Soft Systems Model

Attempt at a Soft Systems Model

Using diagrams like this can help tell a story by setting the scene (scenario) and describing the personas (not usually a real person but a ficticious description of a particular role that person might do) and the ways they interact. The main focus of a soft systems model is on the people or actors in the system.

People often have difficulties knowing how far they should go when modelling and when they should stop. However, the presenters were all unanimous in answering this question: the actual purpose for doing the modelling should set the boundaries for how far/deep one goes with it. But, as a newbie, the real key for me was that one should model just enough to achieve one’s aims (otherwise one could end up modelling for years!).

If you’d like to find out a little more about the event, there are notes and presentations from the workshop now available online. You might also be interested in the JISC Innovation Base (a repository of models for the Higher Education domain, which includes both formal and informal models) and the Agile Modeling Website (Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems).

Happy modelling!