Modular platforms (Composable Enterprise) are not a magic wand in the hands of programmers. The success of any transformation, including digital, begins with a vision of the business and its development for several years ahead.
When a business wants to scale, launch new products and locations, implement new solutions, try new technologies, you will have to support all systems. Can you do this with Monolith, third-party SaaS (software as a service) and current IT infrastructure?
Enemies of Transformation: Outdated Code, Bureaucracy, and Old School
Recently, my friends and I shared our thoughts on digital transformation. Denis is a product owner of an international e-commerce platform, Katya is a commercial director of a manufacturing company, Mike is an IT director at a logistics company. Each of us has our own story of what stands on the road to digital transformation (DT).
Denis spoke about the 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 center to make a payment to the bank according to the details, but forgot to indicate the purpose.
Taking into account the operating time of the bank, the money went for several days. During this time, the local accounting department tried to find out whose money came 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 an outdated system and no API.
Katya noted that it is impossible to make a digital transformation 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 they 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 in each of them there are 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, and modules faster than competitors. But there is also a pitfall here: technologies are becoming obsolete at a breakneck speed.
The digital transformation I made
Listening to friends, I understood that my experience of digital transformation using the composable enterprise can be assessed as successful.
I belong to those 8% of the lucky ones who, according to Statistics, reach DH targets - accelerate, save and scale. Largely due to the fact that I work in IT, where I have good technical competence.
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 criteria for the success of DH and the principles that we will be guided by in our composite enterprise:
- Provider independence... 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 unlimited ability to generate any reports with any number of dimensions. And this data must be structured.
- Easy to maintain. We do not reconfigure systems when the structure of the company is changed, and requests for new functionality or the addition of new services are delivered to the user within a week. The ability to manage time (time to market).
- Single point of entry for information. Here, with all perseverance and perfectionism, I was unbending: 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 CT for several years and throw out millions of dollars, and then realize that I made the wrong decision. The principles of iterative agile development and MVP (minimum viable product) are both relevant and useful in digital transformation.
Dreams, risks and complexity of choice
Watching one demo after another of the solutions offered by the market, confused by the variety of SaaS, I indulged in dreams. I wanted to have some kind of framework on which component solutions can be strung, replaced when they are outdated.
It would be good to merge the data collected by processes and sensors into a single Data Warehouse, from where we could easily generate any report.
Now each of these decisions separately is a risk, the ability 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 take several ready-made solutions, customize them for our processes, make friends with each other so that they communicate and exchange data?
Evolution of modular platforms
If you set yourself the goal of mastering the API (application programming interface) and microservices, you get on with the taste and cannot stop. In our minds, as in the market as a whole, modular platforms are evolving.
By juxtaposing the particles and expecting them to rotate without our help, I imagined the universe. It is important to act on them by the force of gravity: to pull them towards the core - a tightly regulated and protected system.
The Core Master system is a necessary framework for a composable enterprise, from which process branches and workflow will depart. It must be located within the organization and be written for our uniqueness. The rest of the systems - easily customizable SaaS solutions with API - are just components that can be changed as often as necessary.
What would I do differently
For me our digital transformation with modular platforms composable enterprise - success. However, evaluating the possibility of further evolution and scalability, I would do some things differently:
- I would not look at the ready-made functionality and would not take ready-made solutions offered by SaaS. Never. Even if the UI (user interface) looks pretty. You will be limited in everything, even in data export. All the processes that we configured ourselves on forms, workflow, scripts, work, evolve and change easily. Those processes that were tempted to take ready-made are a continuous headache.
- I would be more careful with the API - many issues are resolved by configuration. 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 plane. 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.
- Wouldn't underestimate the preliminary user experience and UAT (user testing). Some processes will never work. Sit down with the user and see where they click. When you see that it uses Tab to enter data, a long horizontal scroll form will seem like a better solution than the modern, beautiful responsive responsive UI for all browsers you've spent a week on.
It is obvious that DH is inevitable, like the industrial revolution in its time. Those companies that do not innovate will be out of business, like Nokia a few years ago. The realities today are: innovate or die (English innovate or die. - Ed.)... There is no third.