Simplicity is the ultimate sophistication

So said Leonardo da Vinci, and by his measure the software used to help run business is far from sophisticated.

Take ERP. Over the last 40 years it has become progressively more complex, resulting in a stubbornly high implementation failure rate. There’s nothing in this that fits Leonardo’s description of sophistication.

There are three facets that have always bedevilled software and made it unsophisticated:

1. Not getting an accurate statement of the problem the software is to address,

2. Using development tools and techniques that are inherently error-prone,

3. Being unable to keep pace with the rate of change in a business environment.

There is a simple solution to these problems, and it marks a fundamental shift in power structure away from the IT specialists who currently control what is provided to business, and into the hands of businesspeople, who today use software developed by IT people.

There is one widely known example of a simple solution – the spreadsheet.

When was the last time you used a spreadsheet which required you to undertake a series of tests to ensure that the total of a column of numbers you asked it to add was in fact correct, and when was the last time, having entered a large quantity of data, that the spreadsheet encountered a coding bug and crashed?

You assume that whatever data you key into a spreadsheet, the answers will not need to be verified by testing, and you don’t expect the software to blow up and need to be debugged. This is because a spreadsheet is a model.

A software model is a pre-coded set of structure and rules that replicate a real-world entity. In the case of the spreadsheet, it is an accountant’s ledger, with its columns, rows, and cells. The model verifies that what you enter conforms to its structure and rules and requires you to correct errors. As a result, you don’t have to test your worksheet for technical validity.

The same principle can be applied to solving the business issues that ERP addresses, using a model of business, its structure, and rules. While this model is an order of magnitude more complex than the spreadsheet model, the principle is the same …complexity is hidden from the user, who is given a simple way to solve major business problems.

What differentiates a business model from a spreadsheet model is activity. The accounting problem centres on processing data within a structure. The business problem centres on processing data within activity with a structure, and this brings into play the need to deal with time, people and resources. Activities themselves embody a wide range of complexity. This all serves to make the underlying model very complex, but also very powerful.

The AptumX Digital Twin model addresses each of the three facets that have degraded software from day 1:

1. Accurate problem definition

This is the key issue. Solving it enables systems to be automated, thereby unlocking the huge wealth of productivity currently blocked by the inefficiency of managing processes manually. Imagine a spaceship crew trying to get to the moon using manual controls. Spaceflight is a completely automated process. Indeed, it was NASA who first introduced the concept of a Digital Twin to describe a software tool designed to solve real-world problems.

A model doesn’t in itself solve the problem, but it provides a framework to do so, and it provides a very fast way to rectify inaccuracies. As a framework the model replicates the way business works so that the people using it intuitively understand its content, in the same way people understand adding up columns and rows in a spreadsheet. Most, if not all non-model-based software tools used to define business are designed for use by IT people and based on IT concepts rather than the reality of the real-world.

2. Eliminating coding errors

Writing computer code is a freeform activity. There is little to constrain what is entered. It needs testing to ensure it does what’s intended and has no unintended consequences. Testing is not foolproof, and software failure is a fact of life in enterprise systems today.

Encapsulating the basic complexity of business into a model provides a template that ensures consistency and conformity in the business characteristic details that a user enters. The model verifies the validity of data entered, removing the need for testing, and eliminating the potential for a post go-live system crash.

Understanding and systematizing business activity is complex in itself without having to deal with the complexity of software coding. Not only does the business model eliminate coding complexity but the model framework also simplifies the way business is defined.

3. Keeping pace with change

This is a real and growing issue for business. The potential for change in the business environment has risen dramatically over the last 40 years as technology facilitates new business models and external events impact the operational effectiveness of business. Yet the ability of software on which business depends to aid a response has altered little.

The metaphor ‘set in concrete’ is often used to describe the fact that business is held hostage to its ERP system. As a result, business turns to a wide range of ‘Apps’, small standalone software functions, to help respond, further increasing systems complexity. The Digital Twin model completely erases this issue.

The process of creating coded software, even with ‘low-code’ techniques, is a lengthy multi-stage process that is flawed at the first step – ‘User Requirements’. Because the process is driven by IT, businesspeople are required to define what they want. Not only will their statement be less than perfect, but it is subject to interpretation by IT people who often have only a passing knowledge of the subject they are addressing.

The imperfect start passes through the stages of design, specification, coding and testing before the users are presented with what they requested. The process is beset by issues such as ‘scope creep’ and alterations that make the project even more complex. Once completed the result is subject to User Acceptance Testing, which throws up issues to be addressed in the system, resulting in more coding and testing. The net result is often a suboptimal solution, whether or not Agile techniques are used, and one that users must live with for years to come.

Contrast this with a model-based approach.

From the very beginning the users are involved, initially defining the system using visual representations of work as it passes through the business. In a short time, sufficient data has been modelled that it can be converted into a running system - basic, incomplete, but a running system. It is at this point that users really get to understand what is being asked of them. They recall and feed in far more detail that they would have described in their ‘requirements’. 

The beauty of this approach is:

• The outcome is always guided by the people who will use the system. They say when it is ready to go live, and at this point they are very familiar with how it works – no need for User Acceptance Testing or User Training.

• By removing the testing and debugging activity, changes can be made to a model and a new version of the system created at the push of a button. This is not only true in the development stage but also when a system is live. If something has been omitted, it can usually be accommodated so quickly that the ‘go-live’ can continue rather than having the plug pulled while IT fix the issues.

• Users finally get a chance to iron out the inefficiencies that in today’s ERP systems they are required to live with, plus they can make more changes as the need and opportunity arise. Productivity enhancement is a daily reality. Simplicity has genuinely proven to be in harmony with sophistication.