Informal systems cover gaps in the application portfolio of most organizations’ formal systems
The world is awash with informal systems. The myriad of small informal systems delivers enormous value to almost every organization known to man. Informal systems are typically based on software tools such as Apple iWork, Google Workspace or Microsoft 365.
Informal systems are typically created ad hoc to cover gaps in the application portfolio of most organizations’ formal systems.
A subset of examples of informal systems includes tracking work status, forecasting cash requirements, tracking product returns, illuminating data inconsistencies between two systems, calculating bonuses, analyzing survey results, scheduling equipment, and analyzing inventory positions.
The appeal of informal systems includes:
- Low cost for software tools and development effort.
- Ability to start extremely small and allow the system to evolve organically.
- No need for planning.
- No need for requirements gathering.
- No interaction with the IT department.
- Incredible malleability.
- Quick responsiveness to changing requirements.
- Concurrent operation and development.
- Avoid rigour of the systems development process.
All these appealing characteristics of informal systems come with risks that are often not recognized and sometimes deliberately ignored.
Below are some common risks that come into play as informal systems grow and even become mission-critical.
Restricted to one end-user
Informal systems are based on a filesystem instead of a database management system (DBMS). This choice restricts their use to one end-user at a time in many situations.
This one end-user limitation risks the system becoming overwhelmed as the data volume grows and the value of the informal system increases.
Restricted data volume
Informal systems are restricted to the maximum number of rows the underlying filesystem can manage.
This limitation leads to the risk of non-performance as the data volume approaches what the workstation’s filesystem, memory, disk speed and processing power can handle.
Difficult software debugging
The development tools used to build informal systems are pretty primitive. This limitation makes finding software defects quite tricky and time-consuming.
As the functional complexity of informal systems grows, the risk that the software will become increasingly unstable and the output will become unreliable also grows.
Informal systems tend to crash quite frequently. Most crashes are caused by the informal software encountering a condition in the data that was not anticipated by the designer, who is typically not a software developer.
The associated restarts and sometimes reboots of the workstation will undermine the organization’s confidence in the output of the informal system.
Knowledge loss on staff turnover
Informal systems tend to be the creation of one bright, energetic business person.
When that person is promoted, head-hunted, transferred, laid off or fired, the risk is that the detailed knowledge of the architecture and operation of the informal system will go with them.
Inadequate data validation
Informal systems tend to focus on minimizing the data entry effort of the end-user entering new data. This focus often means the data is not being validated very carefully by the informal system.
The resultant risk of data quality lapses will gradually but inevitably undermine the organization’s confidence in the output of the informal system.
Inadequate data integrity checking
Initially, informal systems focus on data for one entity, such as customers or orders. As the demand for functionality grows, other entities are added. This situation creates the potential for customers without orders or orders without customers. This situation typically results from inadequate data integrity checking.
The risk of poor data integrity is the increasing number of system crashes and reports whose content will become increasingly unreliable.
No real-time capability
Informal systems primarily operate in batch mode. Data entry is usually real-time, but outputs such as queries, charts, and reports are batch operations. Even worse, no one can perform another batch operation or data entry while the initial batch operation runs.
The absence of real-time capability typically leads to implementing a scheduler function to manage the growing batch reporting workload that will execute overnight. This approach risks becoming overwhelmed as the number and frequency of report requests grow.
Mitigating the risk of informal systems
When these informal systems risks turn into reality, the management response should consist of the following:
- Be grateful for the enormous value the informal system has delivered for your organization over many years at an incredibly low cost.
- Be grateful for how the informal system has increased your organization’s understanding of the detailed requirements of the application domain that the informal system managed.
- Recognize that it’s time to replace the informal system with a formal system that will address all the risks and realities you’ve encountered.
- Remind yourself and everyone else that the higher cost of the formal system reduces many risks, positions the application for substantial future growth and still delivers an exciting net benefit to the organization.
How would you make the case to management to replace an informal system operating with serious risks well beyond its best-before date?
By Yogi Schulz
Yogi Schulz has over 40 years of information technology experience in various industries. Yogi works extensively in the petroleum industry. He manages projects that arise from changes in business requirements, the need to leverage technology opportunities, and mergers. His specialties include IT strategy, web strategy and project management.