Chris Conway
Chief Architect, Quantiv
It’s festival time in Edinburgh, which inevitably leads to lists of hit shows, favourite comedians and best/worst jokes at the Fringe. This in turn reminded me of a personal favourite I heard a few years ago (although I can’t remember the name of the comic who delivered it). It went as follows: “Yesterday I had a premonition that today I’d have déjà vu.”
It wasn’t exactly a joke or a pun, more of a mind-twister. But I love the way it conjures up an infinite chicken-and-egg loop that just about makes sense unless you think about it too hard. It’s a bit like a dog chasing its tail or (slightly more highbrow) an MC Escher staircase.
Déjà vu in IT projects and systems
It’s perhaps no surprise it resonates with someone like me, being that I work in IT design. Technically, it’s almost a summary of the tricky-though-desirable programming concept of recursion, and I think it can also relate to wider project processes.
I’m not as involved as I used to be in those programming concepts. But where I do still get involved is in the technical details of a project or system, mostly at the database level. Admittedly, this is partly because it’s slow-moving technology, and so I still know how to read and use it, hence the ‘déjà vu’.
However, being more generous, I think it’s also because the data model is often the primary (or indeed only) long-standing description of a system’s purpose. So, it provides a definitive reference point against which any change in requirement can be judged.
Breaking the cycle to achieve continuous improvement
Conversely, I also value being able to produce consistent answers over time. A data model is essential in both these contexts, which means it’s almost inevitable it will be used again, hence the ‘premonition’.
But as its name suggests, a data model only defines the structure of the data held in a system. Of course, the instances of those structures (i.e. the data itself, particularly the instructional parts) can provide some indications as to how a system behaved. But neither the structure nor its instances show how it should have behaved.
This makes a process of continuous improvement more difficult because the ‘premonition’ will be of the same results, as well as the same techniques.
So, to break this cycle, you need more than just a model of the system’s data. You also need an understanding of the system’s behaviour: a process model.
Interaction-oriented analysis and design
But while data models are often rather formal, the techniques used to define process models aren’t so precise. There are multiple options, from simple flow charts and data flow diagrams, through to more prescriptive approaches such as activity and sequence diagrams.
However, unlike database models, these process models rarely form part of a system’s physical implementation. They’re not the design-time definitions that drive the run-time behaviour. This means there’s no need for them to be consistent with the system’s implementation or kept up to date.
It’s better to have both the data and process models, rather than just having one on its own. But unless they’re connected in some way, there’s still no guarantee they’ll be consistent with each other. It’s possible to have data that isn’t used in processing and equally processes that aren’t reflected in the data that’s recorded.
You need a different approach to ensure that consistency; a method that considers not just data and processes on their own but how they work together. And that’s what we call interaction-oriented analysis and design.
Analyse data and processes together
System behaviour only becomes clear when data and processes are examined together, i.e. when they interact. These interactions are therefore better starting points for overall behavioural analysis than either data or processes, and so make it easier to model your whole organisation rather than just specific aspects of it.
Working from this perspective, the data and the processes required to manipulate them are still important. However, in this approach they’re evaluated together as part of that starting interaction concept, rather than each being a candidate to be that starting point.
Working in this way also makes it possible to add detail gradually rather than having to provide it in advance, which leads to continuous improvement of the model.
So, while an interaction-oriented approach might not make for such good Fringe content, it could be very useful in breaking inherent IT design and analysis circularities.
Need help organising, managing and analysing your data?
Contact the Quantiv team on 0161 927 4000 or email: info@quantiv.com
