Kapernikov enables Umicore to increase plant capacity
Kapernikov helped Umicore to make its precious metal recycling processes more efficient. This enable ...
Implementing enterprise software systems for utility or manufacturing companies can be a gargantuan task. The cost and effort of setting up such systems is often underestimated, not to mention that derailing budgets are not so exceptional. The industry’s application-centric approach is to blame for this, says Dave McComb, author of The Data-centric Revolution. In his book, McComb argues that enterprise system implementation needn’t be that complex. Even more, a lot of the money spent on IT today is wasted. Instead, companies should apply a data-centric approach. Here’s our take on this eye-opening book.
Every once in a while, a book comes along that changes the way you think profoundly. McComb’s The Data-Centric Revolution might well be such a book. Recently, one of our customers who became interested in the data-centric approach recommended us reading it. And we are glad we did.
Enterprise software systems
The book talks about enterprise systems, typically deployed in large corporations. Belgian rail infrastructure company Infrabel is a good example. This organization has a lot of operational assets to manage (railway tracks, overhead lines, electrical cabinets, trackside poles, etc.). In addition, the company also manages projects, customers, suppliers, subcontractors, etc.
To manage all these concepts, we need software applications. Historically – let’s say from the late sixties onwards – enterprise systems were introduced for every application area or problem that needed to be solved, silo per silo. Typically, companies would start with a payroll or bookkeeping system, and then add new applications along the way. For every new problem, a new application project was launched.
The problem with this way of working is that implementing new applications got increasingly difficult, because of all the previous applications that were introduced. Trying to make all different applications talk to each other has become more complex, and this complexity has been building up with every new application that is launched.
Implementing new applications has become increasingly difficult, and complexity has been building up with every new application that is launched.
Runaway complexity
The big drawback of the application-centric approach is that software applications have a much shorter lifetime than the actual data and concepts they describe. In the case of Infrabel, a railway asset will be operational for many decades on end. A software application will never last that long. So, what happens when an application no longer meets the needs of the organization? In a first stage, updates are added onto the original application, which will partially solve the problem. However, during the upgrade, developers will start tampering with the original data structure and user interface, which will require new software integration work.
Over time, the ability to efficiently upgrade the system will decrease and the need for a new software application, requiring a new data structure, will arise. Because of the application’s new data structure, the original data will need to be forced into the system (data conversion) and new integrations will need to be made. This is what the author calls ‘runaway complexity’, and it’s costing organizations a fortune in integration work.
The data-centric revolution
But it doesn’t have to be that way, McComb argues. In the data-centric approach, organizations see data as a permanent shared asset, while applications that are built around it come and go. In this approach, the data model from which you start needs to be as simple and as close to the organization’s reality as possible (although it cannot be oversimplified). Changing applications then adapt to the data model, instead of the other way around. As a result, no data conversion is needed, and migrating to a new application is seamless.
In the data-centric approach, organizations see data as a permanent shared asset, while applications that are built around it come and go.
Standardization or customization?
Obviously, this all sounds very nice. But the data-centric approach has an important implication, namely that standard software solutions are no longer interesting. Instead, the application software needs to be customized from the ground up to reflect the organization’s reality.
Is this wise? Isn’t there a good case for standardization? Don’t we want standard software applications because of their cost-effectiveness and extensive features? Let’s nuance this a bit.
- More cost-effective: Yes, standard enterprise systems have a lower acquisition cost, compared to customized solutions. However, if you have to count the data conversion cost and integration cost with every new application, then a customized application is often much more cost-effective.
- More features: An enterprise software application that can do it all and that checks all the boxes of your requirement checklist may sound great, but in practice it isn’t. More often than not, more features – some of which you might never need – only add to the complexity of the system. Apart from that, adding more whistles and bells and more configurability almost always comes at the expense of user-friendliness.
Is data-centric the new way to go?
After reading this book, a data-centric approach, with the data model at the center of your enterprise, and with customized applications tailored to your organization, makes perfect sense. In this approach, adding new applications is becoming much less painful, and the cost of migration is negligible.
More organizations are starting to see the benefits of the data-centric approach. And the good thing is, you can implement your data-centric enterprise in steps, with one project at a time. However, if you really want to make an impact with the data-centric enterprise, then you need to make the upfront investment. There’s no denying that.
But in contrast to the early days of software development, today’s technology and linked data structures make a data-centric approach perfectly possible. The only thing that might restrain developers and data architects from choosing a data-centric approach, is that they always have done things differently in the past.
It seems like you're really digging this article.
Subscribe to our newsletter and stay up to date.
