Looking for Nothing

If you’re struggling to know where to start in creating a better control environment for your organisation, a good place to start is nothing.

Image by S K from Pixabay

Key thoughts on this topic

· Looking for zero - seeking the absence of something, where something is expected - is a simple and effective way to find issues.

· What looking for zero means in control terms

· Why this is one of the simplest controls to deliver

Summary

When your IT processes don’t work as expected or things fail to happen at all, it can be tempting to find ways to monitor data transmissions between systems and seek other ways to look into the core of system processing to track the flow of data. While this may be required and can be highly effective, these kinds of controls can take a long time to design and build correctly and this can be expensive, all the while, your issues persist.

Another way to tackle this problem can be to look for nothing – or more specifically the absence of something in its entirety. While this method isn’t subtle, it can pick up on common faults and is far quicker and simpler to deliver, meaning that as a control method, it can be implemented rapidly giving immediate results.

Why look for nothing?

We take the concept of zero, representing nothing of something, for granted. This wasn’t always the case though and it seems that zero was only adopted widely in Europe in the 12th century and is a concept that has been developed and adapted over the centuries to get to our understanding today.

Zero is important as it denotes the absence of something, however, zero without context is a little meaningless: “Zero of what?” would be a fair question. Zero then is meaningful when there is an expectation of something, that there is something to be counted that could reasonably be expected to be non-zero, for us to find it relevant that we don’t have any quantity of it.

Why am I talking to you about zero? Because this is exactly what we should be looking for when we have processes failing in, or between, our IT systems.

When a technology process such as a data transfer or an internal system process runs, it does something; it produces an output or a change of some form. This, after all, is why we have created the process in the first place. If we look for that output, we can spot when the process producing it has had an issue.

Why are these types of controls a great place to start?

A “Looking for Zero” control may be one of the simplest and most effective controls you can create because:

You don’t need to know anything about how the process runs

This is one of its biggest advantages and leads into the other advantages. With a “looking for zero” control, we focus on looking for the output of a process. To do that, we only need to know the expected outcome. This is important as it means we can completely ignore how the process operates, the technology it is based on and any of the other questions that other controls need to deal with. The process could be a single data transfer or a chain of complex processing combining data from multiple systems and incorporating manual input – we don’t care. We simply look for the expected outcome and when we don’t find it, we know we have an issue. This makes these types of control beautifully simple as they focus on the result we’re looking for and consider the mechanism to get to that result irrelevant.

You can implement it at a single point/system.

As we are only looking for output, we only need to look in one place – the place where we expect to find it. If it isn’t there, then we have a problem. While this sounds obvious, think about how some other controls work in comparison:

· File completeness checks rely on header and footer information and checksums or hash totals to ensure that a file has been received completely or needs a feedback loop to the origin system.

· Point-to-point reconciliation controls need data from at least two points in a system or from different systems to be in the same place (often a third system) to check data in one system against another).

In each of these cases, at least two systems are involved, and much more complex logic is needed, including an understanding of where the processing originated to be able to perform checks.

When “looking for Zero” we don’t have these issues; one team can usually implement these controls without even talking to upstream teams or engage in complex systems analysis. Think about how this would work if you were ingesting a data file from a third-party supplier – establishing data controls to work between companies can be difficult but looking just at your own system to see if you have received the file on the date and time specified is simple.

The control is "change resilient" – it keeps operating despite system changes

So often, carefully designed controls that have had significant investment simply stop working when technology systems or business processes are changed. These controls are specific to the technology or data structures of those systems and are monitoring the detail of how those systems are working meaning that when those systems change, the controls either need to be changed too, or they stop doing their job. This increases the cost and time required for system changes if the control environment is to be maintained.

When Seeking Zero, if we still need the output, we keep checking for it. The owner of the upstream IT systems or processes can make whatever changes they like and, this control will continue to function, triggering when the output isn’t received. The upstream system could be replaced entirely, suppliers changed or code re-written and this control will continue to do its job and look for the expected output requirement to be met.

The importance of this cannot be overstated and there are principles in technology system architecture designed to achieve exactly this type of separation of system functionality to allow functions to be ‘ignorant’ of each other, focussing on integration patterns where messages or established data packets are passed, usually via a common messaging bus. Businesses can spend millions changing their systems to use these patterns to achieve the same change resilience – we don’t need to do any of that and can use the same principles in establishing the core of a control framework.

Limitations and Expansions

I’ve talked about why you would want to use these types of controls over more complex ones, but the story is never that simple. While these controls are a great way to get up and running, they are limited in what they can do and what they can tell you about what has gone wrong. It would therefore be remiss of me to finish without mentioning these limitations:

They give little indication of what has gone wrong

Given these controls look purely for output, they don’t tell us anything about where in the process something went wrong or where to start looking. While this might not seem like a big issue with a simple process, with something more complex, knowing where to look for a fault can be vital in ensuring a speedy recovery time. Consider this in business-critical functions such as a payments component of an e-commerce solution or a festival booking system when the tickets have just been released. Downtime matters in so many cases in today’s always-on world where customers expect to be able to do business at any time of day or night. Being able to pinpoint a failed component to target rapid service restart can be vital to service delivery.

They are not subtle – however, they don’t need to be blunt either

Looking for a complete lack of something means we can miss a lot of problems. It’s perfectly possible that we’ve received a file but that it contains garbage, only has a single record when we should have thousands or that it has been tampered with. None of these things will be spotted if we’re simply looking for the existence of the file and this makes looking for nothing a blunt tool.

While we’ve talked about looking for a complete lack of something as the principle here there are ways to expand this a little by defining our something - the context for our nothing - more tightly.

For example, instead of looking for the existence of a file, we could look for the existence of a file that is in the right format and contains at least one record.

Or we could look for data in a specific table with a date-stamp of yesterday for a specific record type.

By defining our “something” more specifically then, we stay true to the principle of this control type and retain the advantages of looking purely for the outcome and can target the control more precisely.

They can be susceptible to false positives

One thing to be aware of is that if we simply look for something not happening, we may find more errors than truly exist.

For example, it may be that some system processes don’t run on non-working days, and therefore “nothing” is what we would expect to see on these days.

It could be that if we are dealing with a process with low volumes, or a process that is highly seasonal such as something to do with hotels and holidays or say agriculture, Christmas, or tax, that sometimes, we receive no data.

In these instances, we may trigger a report of a problem where none exists. This is not a problem unique to these controls, but these controls may be particularly susceptible, and this should be considered when putting a control of this type together.

Final Thoughts

Looking for nothing when something is expected can be a fast and effective way to establish some control around your IT or business process

They are great because:

· They focus on what you need and not how the process runs (you don’t need complex systems analysis)

· They are often simple to implement (you don’t need to bring lots of tech teams together – and can be light on your budget)

· They are resilient to upstream changes

You need to consider:

· They don’t tell you what has gone wrong or where to start on the most rapid fix

· They are a blunt tool

· They can report an issue where none exist

First Published 13/08/2021

All views expressed in this article are solely those of the author

© Alex Cowhig 2021