According to a Gartner report, 6.7 trillion dollars are spent annually on enterprise software. Yet, as much as we spend on enterprise software, there are no standards or principles for creating software.
Teams literally do whatever they want when they create systems. They name things however they like, use whatever primary key method they prefer and re-design and build functionality common to every business.
Then they throw the system into the mix of systems with the futile hopes of integration. Billions of dollars are wasted on cleaning up the mess of disparate systems with all types of initiatives and tools to aggregate and move data between systems.
The industry for creating software is unlike any other industry in terms of its ability to work as a team to deliver a high-quality product. Take the housing industry. It has strict building codes that builders must follow for creating houses. This applies to every aspect of how houses get created, including structural, electrical, plumbing, heating/cooling, insulation, and fire restrictions.
Imagine if builders winged as IT professionals do for creating systems. Houses would cost considerably more, be less safe, be more difficult to connect into municipal services, and not last as long.
Also, consider the productivity of construction crews if there were no standards. Each house would be a learning experience. Also, when teams of different specialties like plumbing and heating had to work together there would total chaos.
It would be just like the chaos we see when we try to integrate systems and aggregate data from many systems for reporting.
Now, imagine if the IT Industry created building codes from the ground up for creating systems so they could be easily integrated. We could create a network of systems for conglomerates and aggregate data from many different systems for reporting and AI.
These systems would dramatically improve business efficiency because data would be entered once and securely shared with every other system that required it.
Kewal Dhariwal and I have taken the first step toward creating a building code for creating enterprise systems to address this issue. We designed a framework and methodology from the ground up so that systems would have an inherent capability to exchange data and roll data up for reporting.
The book is called Breaking Bad with 3D Enterprise Systems. A video series is currently being created to further support the methodology and framework.
The goal of the methodology is to educate a workforce on the approach, so they learn how to create any type of enterprise system from a core system that has an inherent capability to exchange data.
Organizations can create their own teams or hire teams to create and maintain their system. This will let them take back control of their enterprise systems so they can quickly adapt them to meet changing needs.
It will also allow the industry to create manageable solutions for large complex conglomerates. For example, governments can implement systems for each department, board, and commission. This can be extended out to include systems for healthcare and educational entities.
All the systems will be tailored to each business entity’s needs and will be capable of exchanging all forms of master data and aggregating data from many different systems for reporting.
A system of this magnitude is simply impossible based on how we have been creating systems today, including ERP systems.
As an example, an important principle of the new paradigm for enterprise software is that we need to assign a primary key to all types of master data (including reference data) and transaction data and never have those keys change, no matter how many different systems the data gets transferred.
Most ERP vendors use combinations of composite keys and incremented integers for primary keys. This type of primary key has literally no chance of meeting today’s needs for integration.
The new type of primary key is half the size of a GUID, identifies the system that created the record and includes a unique record identifier that supports up to a quadrillion records. It is high performance for storage and retrieval and includes critical features to support other methodology principles.
For ERP vendors to comply with this principle and the other four, it will be necessary to re-write a substantial proportion of their applications.
The question is, when is the right time to step back and rethink how we create systems? Do we continue to work as individuals and pump out disparate systems for the next decade and waste our customer’s money trying to integrate them?
In the next ten years, we will be rebuilding many systems anyway. Why wouldn’t we recreate these systems based on principles that helps us deliver systems that truly meet our customer’s needs for integration?
