CopernNet : Point Cloud Segmentation using ActiveSampling Transformers
In the dynamic field of railway maintenance, accurate data is critical. From ensuring the health of ...
Published on: October 13, 2022
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.
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.
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.
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.
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.
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.
Subscribe to our newsletter and stay up to date.