Replacement of data entry with data sensing can enable better, faster, and more relevant results from application software. But it’s important for software architects to see that this change means they are setting a course for their application away from decision support and toward control.

Find the data
Let’s start with a manufacturing example. People still do stock checks. Some examples of manual stock checks are remarkably efficient, such as a factory manager who walks past the sheet metal stores on the way to the parking lot at the end of each day. If any stack is below the line marked in its bay, then before she gets to her car, she phones in an order. But this is an exception. Most stock check procedures introduce hours of work and many chances for error: counting, weighing, estimating, then transcribing and formatting results, then keying-in the data.

But this data is one of the critical inputs for production and supply chain planning software. Errors here can fool even the most sophisticated algorithm as it plans supplier orders, production, and shipments to customers. And that’s even before things go wrong at suppliers, in production and in distribution.

(Related: How machine learning tackles the ‘big’ in Big Data)

So supply-chain processes need several layers of safety nets, even when the planning software provides an optimal plan. Progress chasers and rush job procedures are symptoms of the underlying problems and waste. Forget the plan: The real trigger is the production supervisor finding an unanswered Kanban replenishment signals and idle work cells due to a lack of materials on site.

Why bother?
The manual stock check isn’t needed anymore—at least, not for the planning systems. The data was only ever an estimate of the real world. Now, network-connected sensors are everywhere, particularly in factory and warehouse automation. Costly, error-prone manual data entry can be replaced with low-cost, quick and reliable data sensing processes.

For developers, the easy, minimum-impact change is to make data sensing a new option for data entry. Store the data into the same places used for the manual data. Gather and record data at the same daily/weekly/monthly frequency. Run the same reports at the same schedule. Costs go down, and there are fewer errors from incorrect data.

But every software architect will recognize the transition to data sensing creates the opportunity to ask fundamental questions about the application. After the transition, a continuous plan update approach is possible and might even be desirable.

But can the old architecture support continuous (or even frequent) plan updates? The old daily or weekly report outputs are no use. No one wants a whole new plan being issued on every change. In place of the old outputs, the application will have to report incremental changes, with whole plan restatement on demand, and a publish/subscribe approach so that people (and also machines) see just the data they need. Some plan changes may override subscriptions—a new order from a critical customer probably needs acknowledgement not only from sales, but also from the people whose work schedule must change to meet the promised delivery date.

New software architecture
The point I want to make is broader than production planning software, and it applies wherever a manual data input process is replaced by online data sensing. Naturally it will be tempting to build the new capability by adding layers over the existing software.

But the implications will run deeply into the software. The existing code will contain hidden assumptions—for example, a fixed sequence of changes to shared data. This is OK because it’s in one block of code. The new approach may need separate modules, or a web interface may be leading you to different sequences of new or changed inputs. So, to fulfil this assumption, you’ll need a way to lock the data while one (or more) of the new modules is going through this fixed sequence.

This is the world of control systems. Data models to represent finite-state machines can help manage the response of multiple independent software modules to asynchronous changes. Messaging interfaces take the place of parameter passing. A robust architecture for the new system will look more like a control system than a batch data processing program.

But as you pause to consider potential opportunities for replacement of data entry with data sensing in your environment, here’s a small counter argument. If the only way to get the data in is to set it up physically and read the sensors, you might find you’ve made it hard to handle what-if queries.