On mass-uniqueness

How well does your system-design cope with something that doesn’t fit?

And how can you design a system for a business-context of mass-uniqueness, where the likelihood of coming across something that doesn’t fit – maybe often – is not so much a possibility as a near-certainty?

That’s what we’ll explore in my upcoming free evening-workshop at Skills Matter, near the Barbican in London, on Tuesday 3rd June 2014.

What’s the problem? Well, let’s take a routine example: getting someone’s name on a website, and storing it in a structured SQL database. Given that requirement, this is the kind of structure that someone in the UK would be likely to specify in the requirements-document:

• Title (mandatory: select from picklist – Mr, Mrs, Ms, Dr, Professor, Sir, Dame etc)
• Forename (mandatory: 30 characters max)
• Middle-name (optional: 30 characters max)
• Surname (mandatory: 30 characters max)
• Suffix (optional: select from picklist – Esq, Jnr, Snr, II, III)

And you – or your business-analyst – assume that that should be sufficient for a website that will be open to the world.

But then along comes this guy:

If we force-fit his name to the UK-style format, it could be entered as, say, Mr Pablo Diego Ruiz.

But this is his full legal name: Señor Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso. That’s what he would need to enter on that form if it’s for any kind of legal requirement, such as for booking a flight – and it would definitely break that system-design.

You’d know him, of course, just as Picasso. A one-word name – which would indeed be legal in some countries such as Indonesia, where that name-form is quite common.

And the reason why the confusion about his surname – Ruiz, or Picasso – is that in many Latin cultures the formal name includes both the patronymic – the father’s surname, Ruiz – and the matronymic – the mother’s surname, Picasso: hence Ruiz y Picasso, the son of Señor Ruiz and Señora Ruiz née Picasso. If you visit Latin America, you’re likely to find that the immigration-forms require both surnames – and you might well break their system if your name doesn’t have them both.

Fair enough, your country or industry may try to simplify things for you by imposing a predefined schema. The US does this for all in-country mail-addresses, for example. But that’s not going to help you if you ship anything to other countries; and much the same goes for pre-ISBN book-identifiers, for farmers’ produce that a supermarket wants to sell but doesn’t have a UPC-identifier, for sculptures, for paintings, for handmade clothes, for just about anything one-off, unique, or new.

Most business-systems – and IT-based systems in particular – are designed on an assumption that pretty much everything is the same: mass-sameness. But the reality is that, whatever we do, there will always be some form of uniqueness that we’ll have to deal with – something that will break that presupposition of sameness. And that’s especially true in some industries and contexts, that have high levels of inherent mass-uniqueness – including:

• healthcare
• customer-service
• clothing and fashion
• sales and market-design
• information-search
• farming – weather and micro-climate
• city-planning – topography, geography and ‘local-distinctiveness’

In practice, the scope of every system will comprise a mix of sameness and uniqueness – of predictable and unpredictable, certain and uncertain. If we design only on an assumption of sameness – as IT-systems often are – we set ourselves up for guaranteed failure. The same applies if – as is all too common – we say that our IT-system will handle all of the ‘sameness’ part of the context, and that the ‘not-sameness’ will Somebody Else’s Problem – without giving any means for that supposed ‘somebody else’ to be able to address the rest of the problem, or to link it up with the parts of the context that our system does handle.

The first requirement to make something that works in the real-world is to design for uniqueness, not against it. We also always need to work on the context as a whole, rather than as fragmented parts: hence, for example, if we to be able to handle something like Picasso’s full-name, we need to design-in a means by which some supervisor can do a manual override. We need to use techniques such as Customer Journey Mapping, to build a better picture of what the context is like from someone else’s view. And we might be wise to use a narrative-based approach to architecture – not so much ‘people, process, technology’ as ‘actors, scene, stage’ – to guide our understanding of how everything fits together and works together as a unified whole.

That’s what we’ll explore in the workshop: see you there, perhaps?