For years I worked as a business analyst. Broadly speaking, the role of a business analyst is to talk to people who want some kind of IT system, ask them the right questions, and then explain everything to the people who are going to actually do all of the technical stuff.

When an IT system doesn’t work it’s not simply because the people writing the code behind it didn’t do a very good job, often it’s because the people who wanted the system in the first place didn’t do a very good job of explaining what they wanted it to do, or the business analyst didn’t asked the rights questions or listen to the answers properly.

Normally it’s for all of these reasons. This will become important later.

Anyway, my experience as a business analyst means that when people propose IT solutions to problems I start instinctively thinking of questions that I want to ask them. It also means that I’ve found it hard to stop thinking about Paul Mason’s article yesterday (21/3/18) wherein he argues that, “there is nothing to stop Facebook being broken up into six pieces in each national market it operates in”

There is, I suppose, nothing to stop it, but it runs up against the most fundamental question that business analysts must answer…what are you trying to achieve?

As of the end of 2017 Facebook reported 2.2 billion active users. It genuinely is a frightening amount of data for one company to hold.

Some of that count will, of course, be taken up by corporate accounts, and other non-personal data, but it’s still an appreciable fraction of the world’s population to have using your platform. Which is, of course, why people use it. It encompasses your parents (who still don’t quite understand they’re not just writing private messages to you), your slightly racist school friends, the people you work with, your drinking buddies, the people who share your interest in buttons of the late Jacobean era, celebrities, overseas friends you’d otherwise lose touch with…everybody, and they’re all tangled together with hundreds of billions of connections and interactions.

Split Facebook into 2, or 6, or 10 and you break existing connections. People scramble to reconnect. From the 2, or the 6 or the 10, emerges a new default platform, and it slowly regathers those 2.2 billion accounts, while its rival platforms wither.

What then have you achieved? A few years of fierce competition to be the platform of choice for the disconnected users, certainly. Many of them will end up signed up to more than one of the rival platforms, spreading their data around more (did you ever go back and clean up your MySpace or Friends Reunited accounts?). We, the people who are supposed to be protected by this measure, get a couple of years of forgetting friends’ birthdays, not seeing their holiday snaps and having to reforge connections that we were, in all likelihood, completely happy with in the first place.

Whatever you’re trying to achieve, this does not achieve it.

Mason does go on to suggest that the database at the heart of Facebook could be nationalised and individuals could give consent to individual companies to access it, in exchange for “innovative” uses of their data, or ad-free platforms.

Again, we could, but here the business analyst turns to the developers and asks, “How the hell do we do this, then?”

That’s because people tend to think of databases like big spreadsheets; you have columns, with titles like “Forename”, “Surname” and “Date of birth” and then a row of data for each person using their platform. So prevalent is this view that you can probably guarantee that, in any given company, part of their operations will be throttled by somebody who’s designed a database to work exactly like this.

Big databases are far more complex and, without getting into technicalities, are optimised depending on what you want to do with them. You can’t take a database that’s geared towards reminding 2.2 billion people when their mum’s birthday is and just make it do something “innovative”, or at least not without it running in geological time – for you and everybody else who’s trying to use it. Neither can you just make it a free-for-all on who can write data to it and what they can write. It’s not like an Excel spreadsheet. Everything is interconnected and relational, and its structure determines how your user platform works (or suddenly stops working, if one of the rival companies makes a change that nobody else is expecting).

Nor can the government legislate that companies must make their data easily transferable. The forthcoming General Data Protection Regulations (GDPR) do mandate this, but only in as far as saying that data controllers must be able to export the data they hold on an individual into a common electronic format (like a spreadsheet), to send to another party. This is great if you want to move banks or mobile phone company, which require comparatively little data to operate, and rubbish if you want to have real-time connections between 10 competing social networks, each of which is trying to work out if you know somebody, somewhere in the world, who’s got a birthday in the current 24-hour window.

Maybe it’s still doable, with a really, really clever design and centralisation of core data, connected to distributed supplementary data. Except that GOVERNMENTS ARE REALLY, REALLY BAD AT LARGE DATA PROJECTS.

No, really, they’re terrible, and they’re almost always terrible because they always fight against putting a fence around and everything and saying, “That’s what we want”. They always push to do just a little bit more, to not rule things out for the future, to accommodate the unaccommodating.

A brief example; many years ago I worked on a project for a government agency. Our stated objective was to deliver a quick win, a system that could handle the 80% of the agency’s work that was simple and straightforward, even if it meant that the remaining 20% had to be done with pen and paper.

During a meeting for that project, on the subject of linking children’s data to their parents, a very senior manager in the agency asks me, “What happens if a woman has two children with the same date of birth, but different fathers?”

Thanks to that question I now know that:

a. This is possible (it’s called ‘superfecundation’)

b. There isn’t an agency in the world where this applies to 80% (or even 20%) of their cases…not by a factor of a million or so.

c. While the government was solving problems like this another Facebook would arise and we’d be back here again.

New, tougher, regulations on data protection come into force this year, but at their heart they rely on us taking personal responsibility for what consent we give to others to collect and process our data. It’s a boring fix, consisting or carefully reading terms and conditions, and thinking about which boxes we choose to tick, but you should trust it above those who promise a magical technological solution to everything, because the question that should prompt is, “What kind of idiot thinks that would work?”