3 Things To Change About Your Approach To Digital Transformation

Composable enterprise is not a magic wand in the hands of programmers. The success of any transformation — particularly digital — begins in the heads of the CEO and the board of directors — the vision of the business and its development for several years ahead. Architecture starts with understanding the core and uniqueness of your business and the change process. Look to the future, where a business wants to scale, launch new products and locations, implement new solutions, and try new technologies. You will have to support all systems. Can you do it with a monolith, third-party SaaS, and current IT infrastructure? Definitely, no. But what if we take several ready-made solutions, customize them for our processes, get them to be friends with each other so that they communicate and exchange data? Let's dive deeper into risks, success criteria and the guiding principles for evolving composable enterprise. Enemies of transformation: legacy, bureaucracy and old school First, let's look at three examples to illustrate the obstacles of smooth digital transformation (DX). Denis is the Product Owner of the international e-commerce/marketplace platform, Kate is the commercial director of a manufacturing company, Mike is the IT director at a logistics company. Each has their own story of what stands in the way of becoming DX. Denis has a client, the owner of a farm in the European hinterland, who did not have time to pay for the package of services on time. He went to the regional centre to make a payment to the bank according to the details but forgot to indicate the purpose. Taking into account the bank's operating hours, the money travelled for several days. During this time, the local accounting department tried to find out whose money it was to activate the payment. And there are thousands of such clients. Denis's company, in turn, cannot integrate with local banks, because the bank has a legacy system and no API. Kate notes that it is impossible to create a DX in a bank that has been operating since 1834. Her company, for example, cannot integrate with clients in terms of document flow. They use a 3rd party SaaS platform for financial accounting and normally wait six months for any request for new functionality. One has to imagine a large bureaucratic structure. It often has independent departments that were created through acquisitions of other companies, and each of them there has outdated monolithic self-written programs that have not been supported for the past 30 years. Mike has led the development department for over 20 years. Their company creates its own system since there are no alternative solutions — this is the specificity of the market. Since IT is the core of the business and the main competitive advantage, Mike realizes the importance of being flexible, releasing new services, functionality, modules faster than competitors. But there is also a pitfall here: technologies are becoming obsolete at a breakneck speed. The digital transformation I carried out While analysing these stories, I realized that my experience of DX can be assessed as successful. I belong to the eight percent of the luckiest who, according to by Bain & Company, have been able to achieve their targeted business outcomes from their investments in digital technology — they accelerate, save and scale. Largely due to the fact that I work in IT, where I have good technical competence. research A year and a half ago, I thought that my department would have to support the new system in a constantly changing environment, and, realizing all the responsibility, I did not want to create problems for myself in the future. Therefore, I have identified the main DX success criteria and guiding principles: And this is not only about the timing and quality of development. My company should have access to its data in real-time, in full, and have unlimited opportunities to generate any reports with any number of dimensions. And this data must be structured. Independence from the provider. We do not reconfigure systems when the structure of the company is changed, and requests for new functionality or adding new services are delivered to the user within a week. The ability to manage time (time to market) is crucial. Ease of maintenance. Here, with all perseverance and perfectionism, I was adamant: if something was introduced once, it goes through all processes and exists identically in all systems. Not a single duplication. Never. I definitely do not want to wait for the DX for several years and spend millions of dollars, and then realize that I made the wrong decision. The principles of iterative agile development and MVP are both relevant and useful in digital transformation. Single point of data entry. Dreams, risks, and difficult choices Watching yet another demo of the solutions offered by the market and getting confused in the variety of SaaS, I indulged in dreams. I wanted to have some kind of framework where component solutions can be strung, replaced when they are outdated. It would be good to transfer data collected by processes and sensors to a single Data Warehouse, which will allow us to easily generate any report. Now, each of these decisions separately is a risk, an opportunity to solve one problem, sagging in others. Not a single person in the company even knows exactly how many systems we have. Each department has something different. It takes several days to put together a simple report — it will become outdated in a couple of hours. A thought arose: what if we took several ready-made solutions, customized them for our processes, get them to be friends with each other so that they communicate and exchange data? Evolution of a composable enterprise If you set yourself a goal, master the API and microservices, you ultimately develop a taste for it and cannot stop. In our minds, as in the market as a whole, a composable enterprise is evolving. Comparing the particles and expecting them to rotate without our help, I imagined the Universe. It is important to influence them by the force of gravity: to pull them towards the core — a tightly regulated and protected system. This is the Core Master system — the necessary framework from which the branches of processes and workflow will grow. It should be located within the organization, and be written for our uniqueness. The rest of the systems — highly configurable SaaS solutions with API — are just components that can be changed as often as necessary. Things to do differently Assessing the possibility of further evolution and scalability, I recommend considering the following things: Never. Even if the UI looks pretty. You will be limited in everything, even in data export. All the processes that we configured ourselves on forms, workflows, scripts work, evolve, and change easily. Those processes where we were tempted to take ready-made solutions turned into a pain in the neck. 1. Don't look at the ready-made functionality and do not take ready-made solutions offered by Saas. If you need to write a complex script, think again. Perhaps it is worth going to the user and finding out that the solution to his problem lies in a different dimension. Just remember that with a change in the provider's authorization policy, you will have to make changes to each script — manually and on all systems. 2. Be careful with the API — many issues are solved by configuration. Some processes will never work. Sit down with the users and see where they click. If they use Tab to enter data, a long horizontal scroll form seems like a better solution than the modern, beautiful responsive UI for all browsers you've spent a week on. 3. Don't underestimate the preliminary user experience and UAT. To sum up, it is obvious that the DX is inevitable, as the industrial revolution in its time. Those companies that do not innovate will be out of business, like Nokia a few years ago. The reality of today is the following: innovate or die. There exists no other possibility. In article Natalia Zub, VP Delivery Management at Innovecs , speaks about the barriers to digital transformation, personal experience of its implementation, and shares the lessons learned.