The practice of good systems analysis and design

When I began my career, my business card featured the lofty-sounding title of ‘Computer Systems Designer’. I was rather chuffed, until I discovered everyone in the company had the same title. But it was well intentioned, as it was the company’s way of saying we were all travelling in the same direction.

Over the years my title has changed, perhaps just because of fluctuating IT fashions. Generally, it’s been a revolving door of different terms, with ‘computer systems’ being replaced by things like ‘software’, ‘application’, ‘solution’, ‘enterprise’ and ‘cloud’. Changes to the subject itself have been slower, with ‘architect’ or ‘engineer’ eventually taking the place of ‘designer’.

Maybe those different terms are more fitting in an IT context, but it also feels like simply tinkering.

What’s perhaps more significant is they all imply the end result of a project is all you need, so you finish a job once a system is designed or an architecture is established.

Best practice for systems analysis and design

In the traditional uses of the terms, that assumption might even be reasonable. Graphic designs only change when a client asks. Engineered products tend to last for their design life and then stop. And once built, architecture tends to retain its original structure, albeit with cosmetic tweaks (and not always for the better).

And while you could argue these characteristics are also true of computer systems, to me that feels as if it misjudges how systems change considerably over time. They’re not static, so what worked last year/month/week/day won’t fit so well today and therefore is replaced. And what seems right today can feel awkward tomorrow/next week/month/year, so changes are planned.

And this means those systems, and especially the IT supporting them, are expected to change in ways that aren’t really envisaged in the more traditional contexts. Maybe buildings should also change, but there’s a general expectation they don’t (at least not easily).

In turn, this means systems analysis and design – the process of describing what’s required of the system and how it will be achieved – must accommodate not only current requirements, which can themselves be fuzzy, but also the changes that may then happen.

In effect, systems analysis and design must consider not just how something is/should be now, but also what it might become. Essentially, ‘dynamic’ approaches must describe the roads that could be taken, not just how a specific destination can be reached.

The importance of good analysis and design in systems development

It’s this ‘future time’ dimension that makes it challenging to analyse and design these systems.

But it’s also this aspect that makes analysis and design so crucial for any development – both human and artificial. And to be good, you need consistent definitions for the problems and some idea of how they relate to the expected solution.

You could create those analysis-solution ‘journeys’ simply by brute force, i.e. considering every route taken or possibility and trying to allow for them. (Think creating mappings based only on pictures of previous journeys; in effect, travelogues.)

But in reality, something always emerges that thwarts the original route, such as a changed feature like traffic, works or weather, or a new road or entirely different destination.

So, it’s not enough to only have the details of the roads already taken. Instead, dynamic analysis and design must concentrate on more generic concepts relating to the overall problem (junctions, methods, road types). These concepts relate to more durable patterns that persist and connect over time, and so can be combined in different ways to create better pictures than simply combining lots of potentially outdated and unrelated images.

Guidelines for system building

This is about having a set of guidelines for how something could be built and, most importantly, rebuilt. It’s not really a design or architecture at all, but perhaps instead a practice.

At first sight, data modelling could be thought of as fulfilling this role. But this method could be overkill as it would provide more details than what’s actually needed as part of analysis and design.

A better technique is to define the ways in which processing could intersect. To do this, you need the inputs to and results of activities and processes to be defined cohesively but significantly, without mandating a predefined sequence. In this way, while one activity could lead to another, it doesn’t have to.

This should be the primary method to be used when trying to identify emergent and potential behaviour. Once those intersections are clear, the data and associated detailed functionality models will emerge from them.

A path to continuous improvement

When you have a definition of current intersections, you can imagine how they could be altered. And because the data and functions needed to manipulate them are both subsidiary parts of an intersection, it’s easier to develop a system more naturally over time than by starting with assumed concepts that quickly become set in stone.

Working in this way also makes it possible for you to add detail gradually, rather than having to provide it in advance. You can therefore benefit from continuous improvement of the model.

Quantiv’s NumberCloud service and NumberWorks method are both designed to support this approach. Our NumberWorks method allows the patterns to emerge over time and be described in a consistent format, while NumberCloud supports the collection of metrics without the need for predefinition of the data to be collected.

So, maybe I have another title-change looming, one that reflects not just what I do, but how I do it. Perhaps I’ll contact the printer to add ‘practitioner’ to my business card.

Discover how NumberWorks and NumberCloud could help you

Talk to the Quantiv team on 0161 927 4000 or email: info@quantiv.com