Why we should talk about systems

By Andrew Clifford

When discussing IT with our non-IT colleagues, we should not start with details of technology, or business concepts like processes and drivers. We should usually start by talking about "systems".

One of my sons really enjoys sport. Because he is so active, he gets more than his fair share of bumps and bruises. He fell badly onto his knee and it swelled up. We took him to the doctor, who sent him to the local hospital for an X-Ray.

At the hospital, the radiographer found his details. The details said he lived at an address we haven't lived at for more than ten years. We would have thought that the records would have come from the local doctor, or from a nearby larger hospital, where our son had been more recently.

To give another example, I used to work for one of the UK's largest retailers. We were taken over by a mail order group. One of the reasons they gave to their investors was that they were acquiring us for our "customer database".

In the IT department we thought this was very funny. Being a large retailer, we had a large number of customers (a large "customer base"). We had a lot of detail about what our customers bought (a "sales database"). But we didn't have a "customer database" holding names and addresses of people for mail order.

These two anecdotes illustrate how we in IT we should talk to our non-IT colleagues.

We should not talk about technical detail. In the hospital example, there will be detail about data stores, interfaces, archiving and purging that meant the hospital had the wrong records. In the customer database example, there are details about sales data processing, mainframe and UNIX servers, and a SQL Server database for understanding customer behaviour.

But neither should we start by talking about business processes and drivers. We should not initially discuss data accuracy responsibilities and processes for managing patient records. In the customer database example, we should not start by talking about increasing customer reach or the value of sales data analysis.

Why not? Our responsibility is to advise on the IT. We need to start with the obvious. In the hospital example, the starting point is, "The system is wrong". We can then work out from this with questions, such as "Who owns the system?", "What patient data is held in the system?", "What rules does the system have for keeping data up to date?"

In the customer database example, the starting point is "We do not have a system that stores customer names and addresses". We do not have to talk about technology, or about broader business aspirations.

There are times when we need to talk about business concepts or about technical details. But most of the time IT is much simpler. Our non-IT colleagues have a notion of "IT systems". We can use that as the starting point for communication. We can talk about what information systems store, process and communicate, and systems boundaries and scope.

And our son? He has Osgood-Schlatter disease, which is temporary swelling of the knees common in over active boys of his age. He's fine.

Subscription