Enterprise Architecture for Self-Driving Companies

Until the early 2000s, three- to five-year plans could be drawn up with reasonable confidence. Since then, the pace at which the business environment changes has increased so much that decisions are made on ever shorter horizons and frequently without a solid data basis. This article explains why the ERP system nevertheless remains the foundation of the self-driving company, which two capabilities it still lacks today, and what an enterprise architecture must deliver so that this foundation carries the organization through to 2035.

Short-term decisions on long-lived systems

Many companies today decide by the motto of plugging one hole after another: whatever is burning gets extinguished, and whatever is supposed to carry the business in five years remains unanswered. In this rush, the essential long-term view has been lost. In "Das selbstfahrende Unternehmen" (Springer Gabler 2021) I describe the consequence: to this day, many companies fail to recognize that their software structures and subsystems are hopelessly outdated and not fit for the future.

That is a contradiction. Strategies are getting shorter, but the systems they run on live longer than ever. In my experience, business-critical backend software has a life cycle of 15 to 20 years, and the large ERP vendors release a new major version at roughly the same rhythm. Anyone who wants to replace an ERP system has to plan for four to five years. So anyone who wants to stand on a solid foundation in 2030 is making the decisive architecture decisions now.

Added to this is a problem of perception. Every technical device gets an inspection certificate; software does not, even though the functioning of entire industries depends on it. While the vehicle fleet drives around with current inspection stickers, the company runs software processes that are long outdated. Every decision maker understands that a highly secure self-driving car cannot be built on the basis of a 1956 VW Beetle. For software solutions, this understanding is still missing.

The monolithic heart: ERP as the foundation

Enterprise resource planning systems are the evolution of what originally began as manufacturing resource planning. By introducing them, companies implanted a kind of monolithic software heart that holds all the data they need for their work: incoming and outgoing invoices, inventory levels, production and logistics data. It manages capital, personnel, knowledge, material, plants, and equipment, and today it covers practically all traditional end-to-end processes, from accounting and human resources to sales and inventory management. The vendors are well known and have regional strongholds: SAP, Oracle, Microsoft, and Sage.

In parallel, these systems standardized companies to a considerable degree, because an ERP implementation brings a large number of standard topics with it. A simple example: when a company buys an iPad, it needs a reported demand, and from that a chain emerges in which several employees are involved:

1. Cost center. The demand is assigned to a cost center.
2. Quote and purchase order. A dealer is selected and the order is placed.
3. Delivery and invoice. The goods are received, the invoice is checked and approved.
4. Payment and depreciation. The amount is transferred and claimed for tax purposes in the quarterly statement.

Before ERP systems were introduced, these sub-processes ran by hand and often in a rough-and-ready way. There were wrong orders, deliveries were accepted that nobody had ordered, invoices were overlooked or lost. The precise rules of the system conditioned companies to the point where processes now run largely correctly, and all the better the higher the degree of digitization. That is exactly the basis of Level 1, the digital company, as I described it in the summary of the book: all data exists in a form that software can read and understand.

I consider it highly unlikely that a newcomer will enter the market and replace this infrastructure. It would be as if a vendor proposed resurfacing every road with a completely new material instead of asphalt. ERP infrastructures have been established over decades and are a fixed part of most companies. The road to the self-driving company therefore runs through the ERP system, not around it.

What the ERP heart still lacks

On the way to the self-driving company of 2035, in my view today's ERP heart lacks two capabilities: real-time accounting and the complete linkage of data.

Real-time accounting

Once all sub-processes are standardized and digitized, essentially everything is already in place to retrieve the company's financial status at the push of a button at any time. A laborious annual closing would no longer be necessary; the results of the last twelve months, weeks, or days could be determined and compared at any point in time. The vendors are not there yet; even SAP S/4HANA is not capable of this.

Why not? The software companies approach the problem too technocratically, and business owners are used to the existing procedure, do not question it, and therefore do not drive this change forward. They believe that a glance at the quarterly figures and the current account balance gives them a good intuitive assessment of the situation. That is a look in the rearview mirror from which forward-looking decisions are derived. If things develop unfavorably, a reason outside their own responsibility is always found: the market, unsettled customers, quality problems, seasonal effects, the suppliers. Self-inflicted errors, for instance in assessing liquidity, remain undetected. Given open receivables with uncertain payment dates, discontinuities caused by back payments of taxes and social security contributions, and countless small supplier liabilities, this is understandable; behavioral economics has long shown how varied such misjudgments are.

In 2035, the current EBIT will resemble a stock price rather than an annual report: visible at any time, in real time, and at the push of a button.

Complete data linkage

The second capability is the complete linkage of data. All the sub-processes from the iPad example are essentially predefined the moment the decision is made to order from a particular dealer: delivery, invoice, payment, tax deduction. Already when the order is entered, the system could know whether and to what extent the item is depreciable. The entire process chain would be available, bundled, at that moment. The same applies to every other decision in the overall system, so that the overall situation adjusts at second intervals and can be retrieved without distortion. On this basis, a forecast for any time window becomes possible, and when the iPad is bought, the company immediately knows how the resulting depreciation will take effect.

The data for this is essentially already in the system today. It has simply not been linked. This linkage is the challenge of the coming years and the real lever on the way to the self-driving company.

From real-time data to automated decisions

If we assume that all data is available in real time, that is, purchasing, inventory, supplier invoices, personnel costs, allocated fixed costs, and future tax and social security effects, and that a forecast can be produced just as quickly, the basis exists for making operational and tactical decisions fully automatically and having software execute them. If a vehicle manufacturer signs a contract with a steel mill to produce 1.2 million vehicles in the following year, the steel mill can immediately make all the resulting decisions needed to manufacture the required quantity of sheet steel coils in the desired quality and deliver them on time.

Today, many operational decisions are already highly automated, but tactical decisions are made by middle management. Errors happen there again and again, often because the decisions are not precisely aligned with the strategy or because the strategy itself rests on insufficient or misinterpreted data. A service company that considers its margin too low raises its prices without being able to calculate how demand will react. In the future, exactly such scenarios will be simulated, in a quality not achieved before and at any desired point in time. What is decided today in meetings with controversial discussions and flip charts will increasingly be decided on the basis of data. This is the transition from partially automated to automated business execution, and it cannot be had without the two missing capabilities. How algorithms replace linear processes along the way is described in the article The end of processes, long live the algorithms.

What enterprise architecture must deliver

Just as a house is built from bricks, concrete, and mortar, the self-driving company is built from individual software solutions, network connections, and data pools. Enterprise architecture is the constructing and planning element: it describes the interplay of all IT and software solutions in the company and turns historically grown structures into a planned, company-wide architecture. Integration, data transfer, and data storage are at its center. It serves no purpose of its own but is aligned with the needs of the company and its markets. From our project practice, six principles follow:

• Decouple the two speeds. Systems that interact with customers have a lifespan of roughly three to five years; websites, apps, and customer portals have to be rethought every few years. The central systems live 15 to 25 years. Central business functions are therefore provided as standardized services for the long term, and the customer-facing applications build on them. This service layer is the clutch between the layers.
• Standard as the foundation, individuality as the differentiator. With near certainty, the foundation of a self-driving company consists of standard software solutions. The unique selling point comes from special integration or from unique individual solutions.
• Assess the core honestly. In numerous large companies, the core applications are 30 or more years old, surrounded by auxiliary solutions and technical crutches. In my experience, some have been running smoothly for more than 40 years. Nevertheless, the company must ask itself whether it wants to build a self-driving company on these structures. It will not work that way.
• Know every data pool. Every data object a company manages must be able to be created, read, updated, searched, and deleted by the other software solutions (the CRUDS principle: Create, Read, Update, Delete, Search). Without this accessibility, data linkage remains a wish.
• Build data sinks and a semantic metamodel. Analytics tools need a quick overview of all available data, and learning algorithms rest on historical data. A semantic metamodel must therefore exist for all data the system can process. In our experience, it is precisely the large companies that have the most catching up to do here, and a large part of the decisive development of the next ten years will take place in this area.
• Plan the entire life cycle. Enterprise architecture is not an academic exercise. You pragmatically compare the current state with the target and work out a long-term plan that includes operations and further development. The biggest misunderstanding concerns the time frame: planning usually covers three to five years, but the key lies in a horizon of ten to twenty years.

Anyone who starts today with a well-planned enterprise architecture can use the potential through 2035. Anyone who waits until the curve rises steeply will not catch up with a four- to five-year ERP replacement.

The next step

The vision, the autonomy levels, and the role of the ERP heart are described in detail in "Das selbstfahrende Unternehmen" (Springer Gabler 2021): About the book. If you would like to know where your architecture stands today and which steps toward real-time accounting and data linkage are worthwhile for your company, we are happy to talk: Book an expert consultation.