An old proverb goes: “Who knows does, who does not know talks”. The truth is that, every single day of our lives, we are pestered by silly, storytelling ads full of buzzwords where the narrative element wins over the practical and tangible ones. “Digital Transformation” comes across as something that can be easily achieved just by saying some smart words and by showing enthusiasm as if the reality could be bent according to the story we want to share.
Is the person you may be listening to a trustworthy one?
Here are some buzzwords which should make you understand some possible dangers and ponder if the person really knows what he/she are talking about:
- Win-Win Solutions,
- Quick and Dirty Strategies,
- Happy Problem,
- It’s commonplace.
One of the most important things I have learned after years spent looking after digital projects is that a quick and dirty solution is usually always dirty and never quick.
It is a misleading solution that is written in a difficult way to understand and it promotes a hurried approach (which later means a cognitive gap for those who need to intervene) for a number of reasons. It can be because the solution has created an obvious technical gap, it being adequate for when it was created but inadequate for future needs. Business needs require a maieutic approach which usually involves interaction.
Such an approach has recently seen organizations to concentrate on the aspects of Presales and Sales, often following the logic of discount: selling a project is a “happy problem” and once the contractual difficulties are overcome the rest of the process is just a keyboard exercise for developers.
Adopting a software solution aimed at empowering, changing, and duplicating a business process or service (check the Digital Twin idea) means a clash with:
- the complexity is given by the business domain,
- the complexity is given by the technical aspects of the implementation,
- the need of having two aspects interact synergically in an interdependent system.
This operation is not trivial and cannot be seen as a mere filing exercise similar to an assembly line or as the development of a videogame ready to be bought.
How many times have we recently seen brand new products in the gaming sector fail immediately? One example is Cyberpunk 2077, a video game full of bugs which had to be recalled even before the first release.
BREAKING UP THE PROBLEM RATHER THAN CLIMBING THE MOUNTAIN
The bottom line of every Digital Transformation Project is the breakdown of the problem: the complex issue needs to be divided into different “parts” to have them addressed singularly.
What distinguishes a solid company from a storytelling addicted one is its design ability: it is the same quality which makes great programmers stand out from the standard ones.
The Digital Transformation process is a cognitive exercise that requires intelligence and vision. It is not an inner talent or something that comes straight out from a factory. It is actually way more similar to a group of students attending a writing workshop and applying an iterative process: they write a draft, they get some feedback on it and they go back to the draft and make some changes to make it better.
Whilst designing software we usually face issues quite similar to philosophical questions such as how to manage data ubiquity. In such case, we need to define the meaning of a specific object and build an appropriate ontology. It is therefore a process that requires a bigger effort rather it being a simple exercise of mere abstraction. As a matter of fact, designing the system which will be implemented there is an active learning exercise: writing the code, making mistakes and experimenting with them, and finding the solution are all parts of the learning curve.
Digital Transformation allows the organization which is starting this new adventure to gain a competitive advantage – in the Veneto area this is seen as “fare schei” (to make money)”.
Such process needs a deep understanding of the path that will need to be followed and of the minds involved in such a creative exercise: experts in translating thoughts into clear and distinct requirements are fundamental.
If you can sketch and visualize a system there is a high chance that you can implement it in a software tool too.
But what does it mean?
It means that the biggest limit whilst writing software is our ability to understand the system that we are creating. It is a system that evolves progressively whilst acquiring new functionalities and amplifying its complexity and incrementing the dependencies of its components.
Complexity is an element of exponential increase in both human and professional experience and for the software too. The more challenging the program, the bigger number of people are working on it and the more difficult it is to manage its complexity.
The fundamental quality to start a Digital Transformation process is the ability to understand the relations among the different organizational components of the business and translate them into requirements to implement.
The complexity can be solved using four different complementary approaches:
Picturing the system components, the relations, the structures, and trying to obtain dynamic “images” of what we are trying to achieve.
Decomposing the problem and the business requirements until they reach their most basic status.
Building a shared language with the client or business partner (complexity and problems are often found in things that are usually considered insignificant).
Incapsulating the complexity and fractioning it into different modules so developers can work on different aspects of the system.
To put this in easy terms, it means breaking down the application which needs to be realized in different modules designed to be independent from each other so the development of each one of them can be carried out without understanding the details of the other modules.
THE INCREMENTAL DEVELOPMENT
It is important to highlight how easy it is to find two types of Agile Approaches:
- The Agile story, which belongs to the chit-chat world
- The practical Agile which becomes a daily way to approach production, business life and, for same, life itself.
Agile has become an incremental progression which protects both suppliers and clients maximizing the resource investments. This happens through a design which aims to focus on a smaller subset of functionalities compared to what was initially desired. Such subset of functionalities or micro requirements is designed, implemented and then assessed. Possible issues about the initial design are found and corrected. Then a new and more functional design is started by implementing and adding new functionalities. It is a process which uses concentric circles: from “core” functionalities to more external “nice to have” ones.
By distributing and weighing the complexity in this way, some problems of the initial project can be solved whilst the system is still “small”. Furthermore, the other functionalities learn from the experience gained during the implementation of the previous ones, having fewer problems.
Such an approach makes software development different from the construction industry. To explain this better, the incremental approach works well for the software because it is a cognitive project – like the text I have been writing so far – it is malleable, and it allows significant corrections whilst implementing it. In the construction industry, the dimension is physical, and the structural changes would be way more challenging (if not impossible) – who would ever dream of changing the number of pillars supporting a bridge whilst it is being built!
The Digital Transformation of a business process is therefore not comparable to buying a videogame or anything else from a shelf. Everything is based on incremental development, from its design and it means that it will never be fully complete.
I do understand that if you are a superfan of Gantt’s diagrams, of milestones and similar things, you might have already burst out and you might have stopped reading what I have been writing. Fair enough…
È importante sottolineare come ormai circolino negli ambienti di business due tipologie di Agile
THE DIGITAL TRANSFORMATION AS A LIVING BEING
If you have decided to carry on reading, I would like you to understand that the planning happens constantly during the lifetime of a system: you always need to think about design issues as if you were dealing with a living being.
A good comparison exercise is considering the software design and development processes in a continuous learning way – like raising a child. A project for software development (or Artificial Intelligence) has recurrent phases which determine its moments of life, in the same way, it happens for the biological phases for a creature. This does not mean deadlines, milestones, and Excel spreadsheets cannot be created but it presumes that those details will be treated in the same way you would try to guess the job your three-year-old child will have when he grows up.
Our role as software developers is to guide companies through a Digital Transformation Process which does not only mean “creating a code” to work in an easy way but it is writing the code in a way that others can also be helped in their jobs by having simple, reliable and accessible IT systems.
Transforming means being able to read the business contexts whilst owning a domain, handling the complexity and reducing the cognitive burden. Dealing with the cognitive burden easily translates into simplifying, with little but clear information: this allows developers to not waste precious time to understand enigmatic requirements, allowing them to create refined software which can reduce bugs since they did not forget something along the way.
Neutralizing project unknowns, sharing implementation methods, reducing the global variables of the system that needs to be implemented and reducing the inconsistencies and dependencies across the different modules mean a great software quality.
If you are looking for a travel partner who can support you through a real Digital Transformation, these are the characteristics you need to look for.
Only companies which have enough experience across several projects and in their implementations are the only ones who can help. Their competencies and their correct vision to understand your problems are what you need to have the right solutions investigated – this is how you can have a great code.
For all the others, and for the storytellers, you can just use this adage: A ship on the beach is a lighthouse on the Sea (Dutch saying mentioned in “The Mythical Man-Month” by Fred Brooks).
YOU MIGHT ALSO LIKE:
How to be a business superhero in 3 days
After Covid IoT: high value services for organizations, public administrations, and citizens
Big Data and Artificial Intelligence: Lesson Learnt
