How enterprise IT infrastructures got sick after global pandemic

As shocking, troubling, and impactful was the pandemic it did something thousands of managers weren’t able to do for years. It managed to fast-track digital transformation to never before seen speeds. When the time came to choose digital-first or no business at all, many made the decision and built web stores within days, integrated delivery options, and other options. Now companies had to compete to get into the some-sitting client’s home. Often not having any previous experience at all in the digital land. 

According to McKinsey – seven years’ worth of digital transformation progress was done in a matter of months. First with public online stores than with new services and active digitalization of processes and technologies to compete in the market even better (or at all). These changes as good as they may sound came with some bad symptoms that will haunt companies for many years to come. And if accumulated enough will cost millions to fix. 

Temporary solutions

“Nothing is more permanent than a temporary solution.” 

In general, confusion when businesses were fighting to survive and any solution was better than no solution at all, many solutions were made as “temporary solutions”. Temporary web stores, temporary business processes, and temporary products and services. Once they were implemented, they required some finetuning adjustments. After the adjustments came a new functionality was required as businesses discovered how much easier it is to innovate and deliver new products in the digital environment. Gathering statistics on existing products also got easier so temporary improvements were deployed on top.

A lot of these solutions became permanent – somehow working solutions that are not properly tested, documented, and included in the product’s vision or any roadmap. Either because of increased delivery requirements or inexperience (and sometimes both), the “temporaries” went into production and stayed there often with additional functionality on top. Someone at this point may say: “If it works, it works. MVP is delivered, carry on”. It is, yes. It may work fine for the time being, but without proper testing, and documentation it can become a pain.

New solutions, lack of procedures

When introducing new functionality to their technology stack enterprises should make sure that all of the previous capabilities are extended to the said new functionality. All security controls, access controls, processes, etc. After the pandemic many newly implemented systems were not monitored at all, many had various procurement issues and lack of information that such systems are used. Departments started to use different services and approaches in a very siloed manner as communication was disrupted. Everything that could be sacrificed in the name of speed was sacrificed and that built up huge technical and functional debt which was resolved by implementing some additional quick fixes. Problem is that to fix this mess you still need the originally planned investment with the addition of investment in removing the patch, aligning the new process, and re-working everything that was built on top of the patch of patches. 

Process on process

The rule of thumb is that your API flow should reflect your business process. Problems started when businesses needed to adjust fast by implementing various processes to support the new way of living in a pandemic. Closely coupled processes that rely on each other while supporting entirely different solutions. Additional processes on top of already established processes cause huge disruptions.

One of the limitations that were issued during the pandemic was that building materials in the store could be sold only to professionals and companies. Individuals could only order the materials online and pick them up at the store. One of the leading hardware stores in Latvia had a huge issue to face: due to their leading position in the market and many physical locations, there was no need for a webstore. Now they needed one and quick. A technical solution was implemented within a month with very bad search functionality. Every time a client couldn’t find something they flooded the service desk with questions. As there was no dedicated service desk, new duties were assigned to someone in each store (the search was also store-based) while previous duties remained. Suddenly they started to realize that people order stuff and then it’s just waiting to be picked up so now they needed to free up space in the store to temporarily store the orders. Meaning all products from freed-up areas needed to be put in other places of the store. This came with 2 issues: employees couldn’t find anything as everything was spread around. What’s worse – there was no tracking system. You either had to describe to the employees how big your potential cart of goods is and then they disappeared in a 30-minute treasure hunt or sometimes it couldn’t even be found (or actually completed) so it had to be redone. As only some employees were assigned to the process, the waiting time for some people in the line was more than an hour. The same process had to be implemented for delivery which often mixed with store pick-up storage space so which caused extra errors and frustration. And on top of all that – a new invoice handling system had to be implemented on top of existing invoicing systems and synced to the delivery part. Many just went to the competitors – bit higher prices, but no hustle at all as their webstore and delivery setup was done years ago.  

The bigger you are the more flexible you have to be as unexpected changes may result in adjusting and implementing many new processes while aligning them is hard work and requires constant feedback. 

Too many APIs to handle 

API economy provides us with many easy-to-use SaaS products, many services, and products that can be implemented in extremely short time periods and deliver very specific and rich functionality. What came previously as a small part of a huge system you can get as standalone software. No need to do huge implementation projects to get an online piece of functionality and adjust all business processes to fit the remaining functionality. This comes with a price – there are more and more APIs to handle. As often each team needs specific functionalities your IT stack will end up with many uncategorized APIs that others don’t know how to use. During the pandemic when the goal was simply to adjust in the shortest period possible, many ignored the overwhelming issues that will have to be solved later. The goal was to keep the business above water. Systems without API lifecycle management are set to fail sooner or later.

How to cure this, doctor?

As in many cases, recovery is a long and costly process. But here are some tips:

1. Draw your existing process and landscape and identify your strong areas, risk areas, and potential risk areas. Identify your weak points (e.g., if any of cloud SaaS goes out of the business, what is the impact you are facing, do you have redundancies in services, processes, etc.)
2. Draw your target process and landscape. Your APIs should reflect your process and allow you to have room for innovation
3. Your target architecture should remain as flexible as possible (for example by introducing an API management platform)
4. Make a list of all tasks that need to be done to reach the target architecture. Prioritize the list based on business impact, value, and dependencies. 
5. Split the tasks into measurable chunks (sprints) and start executing

Once you get to the third point you need to stop and think – what is the best option to:

• Maintain a centralized set of rules that would make everyone play the same game reducing overhead
• Grant freedom and flexibility for each system and their teams
• Allow you to review, change and maintain processes and their API/Microservice counterparts as part of system lifecycle management
• User, API, traffic, log management, monitoring, and access control
• And most important point: a system that would allow you to quickly innovate new products and add/remove APIs or even whole applications in your ecosystem

The moment your API platform is up and running you can start mapping the APIs, doing the administrative work, and building blocks for your next, big product. For digital products, it doesn’t get any easier than that. Keep the momentum you have of flexibility and speed, but decrease the risks and liabilities around these innovations. 

To conclude, maybe the speed of transformation was the real speed that companies can work with. Throwing out endless meetings and decision points companies could get to new and improved products in a matter of months. Maybe this is the true agile approach – get the product out of the doors and worry about details later while sometimes the forgotten, small details can be major liabilities. If there was only one takeaway from all of this it’s to understand how effective enterprises can be and how many results can be delivered in a very short time. And maybe that is why you should invest in an API Management platform to keep the flexibility, but decrease the liability. Don’t fall back to your old habits, lead your enterprise into a truly connected world and have the flexibility of a startup.