Chris Conway
Chief Architect, Quantiv
“It is what it is” has become a catch-all answer to just about any unfathomable situation.
It’s often an understandable reaction to a world that is becoming increasingly complicated and baffling. It’s a response like: “It doesn’t matter how it came to be, I simply accept it can just, be.”
When history doesn’t matter
Perhaps unexpectedly, this approach to life has parallels in computer system design.
Some IT applications can manage just by knowing a current position. Although what’s happened in the past will have led to that position, what happens next may depend only on the absolute value of that position – not its history.
For example, a sales process may only need to know how many items are available for sale. If some items have recently gone missing or if an order has only been part delivered, this will have no effect on the number available for sale when a customer asks.
In this case, “it is what it is” is enough.
Understand the journey
In other areas, it might be risky to simply accept a position, because knowing where you are is good, but it’s far better to know how you got there.
Knowing how ‘it’ came to be can often be more important than simply what ‘it’ is now.
For instance, a compliance or governance requirement could mean a stock audit must concentrate on the integrity of the operational processes. Here, the audit must prove the end value equals the start value adjusted for the difference caused by any movements (any intake minus dispatches).
“It is what it is” is now not enough. Knowing “what has been” is more important.
Changes in state
Providing a trail of all movements to prove a position might seem overwhelming. And keeping multiple copies of data of different types could suggest the need for considerable resources.
But the problem can seem much more approachable if you consider the core features of the changes in state that led to a position. Every change in state can be defined generically to show what was done, what was used and how much was produced – and to reveal who did it, when and where. These characteristics are universal and can apply to almost any change that results from an activity.
Seen from this perspective, you can use the same format for all sorts of different events, operating on many types of data.
Older than ‘A Christmas Carol’
Of course, this realisation of a common representation of changes isn’t new. Accountants have been using ledgers to record transactions of different types for hundreds of years. In fact, even by the time of Scrooge’s long-suffering clerk, Bob Cratchit, the concepts were old hat.
Simple categorisations also feature in this approach, detailing the types of items affected by the transaction, as well as rules governing how the quantities affected must relate to each other.
So, rather than accept a position “is what it is”, it’s also possible to explain why that position has occurred.
The IT equivalent of a ledger
You can apply a similar pattern to changes brought about by different IT applications.
By using a standardised format (the IT equivalent of a ledger) to record changes, it’s possible to give a history for a position in a way that doesn’t impose significant added overheads.
In this way, you can use a formal record of changes (past) to verify a position (present), and so inform actions (future).
Turn your data into useful information
At Quantiv, we specialise in operational metrics. Our NumberWorks method and NumberCloud platform will help you organise and manage your organisation’s application data and turn it into meaningful information.
