Strolling through informatics #29 – How to tackle digital transformation

previous #28 ––– next #30

by Enrico Nardelli

(versione italiana qua)

We discussed in our last post the need for a different perspective on digital transformation, reflecting on the fact that informatics automation amounts to replacing people with "cognitive machines," which however lack their flexibility and adaptability.

Ignoring this aspect has led and continues to lead to the many failures we periodically see computer systems stumble into. Here's what we should do instead.

The traditional workflow for acquiring informatics services and products involves an initial phase of defining the requirements for the necessary service/product with the drafting of detailed specifications, based on which potential suppliers submit proposals. The best one (using criteria based on cost and technical evaluation, which are very rigid in Public Administration procurement procedures and more flexible in private companies) wins, and the contractor begins implementing what was requested. At the end, if the service/product passes the final tests, the operational phase begins.

What are the consequences of the current approach? The sad reality is that development programs involving the creation of software components are always those most behind schedule and with the greatest cost overruns. Periodically, industry publications list the most spectacular disasters that have occurred in computer system development: here's an analysis of what happened just in 2024. In 2018, the director of the Procurement Division of the US Department of Defense, Will Roper, declared that the traditional acquisition system used for decades to buy ships and airplanes could not work for software because "a software system is never finished, it's a continuous process."

The world's most innovative tech companies have long understood that this method doesn't work. If users only see the software at the end, it's highly likely that not only will the initially defined requirements not have been met, but also that what they need has changed in the meantime. From the collaboration between the research world and industry, a radically different approach to software development emerged right at the beginning of the 21st century: the so-called "agile" approach, which is precisely what cutting-edge tech companies use because it allows them to develop successful services/products.

On the other hand, if you think about it, this is what we see in the apps we all use every day. They seem the same to us, but behind the facade there's continuous work of updating and evolution. Just like with people who, behind an organization's facade, provide us with its services. They evolve as contextual conditions change or based on any changes decided by management. Computer systems – to a much greater extent than any other human-built system – are systems in continuous adaptation, for which the human role continues to be essential. This remains true despite the impressive advances in artificial intelligence and as long as we want a society of people and not machines to continue to exist. As I wrote in 2010, for the 6th edition of the European informatics conference (ECSS) regarding computer system development: "maintenance is the real implementation."

From a procedural standpoint, the acquisition of computer systems should therefore no longer be based on the initial definition of all requirements, but rather a narrow set of initial objectives and use cases should be identified, on which a small joint group of developers and users will begin working with the task of producing a first working core within a few weeks. From there on, this iterative approach continues – which is precisely what's called "agile" – constantly learning from successes and failures in the field and adjusting course based on evolving scenarios.

It's an epochal change if we consider acquiring a software system like any other product. It's the natural solution if we look at it from the perspective of personnel acquisition.

While this new acquisition paradigm can more easily be adopted by private entities, provided their leadership has developed this cultural vision of informatics automation, its introduction in the Public Administration (PA) context requires alignment with the legal framework of reference. It will therefore be necessary to change the entire regulatory apparatus that governs the procedures by which the PA acquires computer systems. Here a strongly interdisciplinary effort is needed, because all the competencies that come into play in this process must be mobilized: legal, documentary, informatics, managerial, psychological, under the guidance – it goes without saying – of politics that must take direct responsibility for managing such issues.

And it's precisely to the role that politics must play in governing the use of informatics in society's development – a necessary and irreplaceable role – that we'll dedicate the final stretch of this stroll.

[[The posts in this series are based on the Author's book (in Italian) La rivoluzione informatica: conoscenza, consapevolezza e potere nella società digitale, (= The Informatics Revolution: Knowledge, Awareness and Power in the Digital Society) to which readers are referred for further reading]].

--
The original version (in italian) has been published by "Osservatorio sullo Stato digitale" (= Observatory on Digital State) of IRPA - Istituto di Ricerche sulla Pubblica Amministrazione (= Research Institute on Public Administration) on 23 April 2025.