What physics teaches us about systems analysis

The start of a new academic year reminds me of my own time at school and, more specifically, which learnings have stayed with me.

One thing I haven’t forgotten is that physics doesn’t really explain how the world (or everything in it) is or how things do what they do – but only what happens, i.e. how things behave.

This could seem like a pedantic distinction. Surely how something behaves defines what it is or how it works? But if anything, I think the reason the phrase has endured in my mind is precisely because of that subtlety. In effect, rather than being a lesson with a simple fact, it’s more of an instruction or even caution about how to view information.

So, when looking at information, consider:

• What it really tells you, i.e. what you know now, and what you still don’t know.
• Don’t disregard the information just because it’s an analogy or metaphor. These are still important tools for learning and understanding.
• Use it in context, because the same information seen from different perspectives can produce different conclusions.

NumberWorks: a new approach to systems analysis

I was reminded of the distinction between ‘is’ and ‘behaves’ recently when considering the merits of different approaches to systems analysis, and especially what makes Quantiv’s NumberWorks different from other methods.

Traditionally, systems analysis methods have fallen into two broad categories:

• Those that concentrate on the things in an organisation (broadly ‘object-oriented’ methods)
• Those that concentrate on the organisation’s processes (‘function-oriented’ methods)

At first sight, that split could seem similar to the physics distinction between ‘is’ (objects) and ‘behaves’ (functions). But I think both these concepts actually explain how the world is, i.e. the world is made up of objects or the world is made up of functions. So, they are two different views of the same concept, not two different concepts.

The importance of interactions

In contrast, true behaviour really only occurs when the objects and functions interact. As such, interactions form a much better starting point for analysis, making it easier both to create a model of an organisation, and then to use that model for implementation. The objects/data and the functions required to manipulate them are still important, but they are then seen as two subsidiary parts of that higher interaction concept.

This approach is at the heart of our NumberWorks method. We call it interaction-oriented design.

As its name suggests, in this approach the interaction is the root of the analysis model, while objects and functions are then branches from it. Moreover, rather than being independent features in their own right, the definitions of the objects and functions involved are then defined by the interaction.

Interaction definitions also flow more naturally from business process descriptions and so can be identified earlier and more easily than the lower-level data stores and functions. This means that an IT solution can develop more naturally than by starting with concepts that immediately require detailed knowledge.

Seeing the problem in this way also explains why it can be hard to get started with traditional analysis processes. They first require working up the object/function branch to get to the root, and then working back down the other branch. In effect, the objects and functions involved can be seen to be details of implementation, not design concepts.

Starting at the interaction means gradually increasing speciality along each branch, possibly at the same time.

Requirements and use cases

In standard modelling terms, interactions could be considered at an equivalent conceptual level to ‘requirements’ and ‘use cases’. However, while an interaction concentrates on defining the change in overall state brought about by an activity or process, a use case is intended to describe the steps required to bring it about.

‘Requirements’, meanwhile, gives the impression users know what they want a system to do. Sometimes that’s true, but often users know more about what they do. For example, “I need a car” is a requirement, but “I need to travel 5 miles from A to B at 8am on weekdays” might give more clues as to the problem to be solved. And while that problem description could indeed be a use case, I think the outcome could be considered an interaction.

Lessons in physics

So, while there’s little that remains of my school French, that valuable lesson from physics continues to have a positive influence not only on me, but on the organisations that benefit from Quantiv’s services.

Learn more

To find out more about how we help organisations to turn their data into useful information, call the Quantiv team on 0161 927 4000 or email: info@quantiv.com