4. Support Systems
The Digital Transformation changes business, manufacturing and societal processes. This requires a change in the support infrastructure. Our whole society is based on access and use of infrastructures and these are enabling and constraining its operation and the products and services we use.
The digital transformation makes use of all the pre-existing infrastructures, both because it still has to deal with atoms, with the physical world, and because it wouldn’t make sense, nor be practical to start building infrastructures from scratch. However, it changes them and adds to them to manage and leverage bits and integrate bits with atoms.
In particular we are seeing:
– The progressive automation of existing infrastructures (from self-driving cars to self-routing goods, from self-balancing power grids (smart grids) to self-healing roads, …
– The evolution from (tele)communications infrastructures to communications fabric
– The growth of distributed clouds supporting edge computing, micro data centres, encapsulated data, semantic-based data access
– The creation of world-wide and vertical specific platforms, including PaaS (Platforms as a Service) and Tools (AI, Data Rendering, Voice Interface management, Computational Photography and Image Recognition…).
Infrastructures have historically been built in a top down way, a central authority (in the past it was a state business to build and ensure the viability of infrastructures) coordinating the effort of a plurality of players (including slaves…) and regulating their use (paying tolls, getting the right of use and so on).
This has been the case in modern times in the development of modern infrastructures, like railroads, highways, telecommunications networks… However, here we saw the entrance of private capital and initiative but still the “states” had their saying by granting concessions and regulating several aspects of their use and operation.
The issue of interoperability among infrastructures, like using the same gauge in rail tracks, the loading gauge, the same voltage/frequency in power supply, was soon on the table, although the solutions have been different (like exchanging the bogies to allow a railway wagon to move from Western Europe to Russia…). Standards have been designed to ensure interoperability although sometimes they do not work backward and specific “hard” solutions have to be found.
The shift to software-based interactions has somewhat simplified the interoperability and development of standards (you need a software adaptor to match two software interfaces if changing one to match the other is impractical) but at the same time it has multiplied the interoperability issues given the proliferation of products and the interest of industry to differentiate their product. The JPEG standard came as the solution to the problem of representing an image in bits in such a way that any application could read those bits and render the same image. In these last 20 years although we still have and use JPEG, each digital camera comes to the market with its own specific way of creating a digital copy of the image and for each camera there need to be a converter to create an interoperable file (like Adobe DNG – Digital NeGative).
All these issues are very much present in the Digital Transformation and support tools are the ones that have to take care of them (at the same time they are also the ones creating de-facto standards and interoperability issues). This is made even more crucial given the fact that the Digital Transformation is happening everywhere, meaning in different geographical places -often subject to different regulatory frameworks-, in different verticals –each one with its own heritage and specificity-, and by different parties –each one having its own motivations and goals-.
Sometimes incompatibility is seen as a competitive advantage, leading to customers lock-in, other times it is an unavoidable consequence of the speed of evolution and need to go-to-market in the shortest possible time (rather than waiting for a standard I’ll push my product to market; if it becomes successful it will become a de-facto standard). The possibility to create a software envelope to overcome interoperability issues and support interoperability is also another factor decreasing the effort towards software and data (ontologies) standardization.