Can IT modernization lead to revenue loss?
IT Modernization is one of the key factors of today’s digital transformation. Most of the enterprises trying to define digital transformation strategy. IT organizations trying to redesign the organizations to meet the changing business need, and uplift the technology and people. Non-IT organizations are also trying to setup digital department to take care of companies digital assets and modernize them. However, IT modernization does not always result in a profit, it may lead to revenue loss if it does not fit to the organization design.
Here is an example statement that you may get from your client:
We have rewamped our old mobile site to new prograssive web app, and we are observing 6% drop in conversion rate, impacting the revenue.
Assume that the client is a non-IT organization, and they have a digital department taking care of the digital assets (Website, App, Mobile Site etc), and also trying to upgrade assets to the latest technologies.
Here are the general patterns and observations, which may be the major cause of the revenue drop even after the tech modernization.
Its a matter of changing the technology
IT modernization is generally considered just as a matter of changing technology. But it first requires people who accept the change and take it forward. We have observed missing ownership from the stakeholders, and the modernization was looked as enforced on the teams then it was embraced. Most of the team was new in the digital department and the existing people were holding a lot of history and knowledge, which they do not want to expose, in a fear of devaluing.
Sometimes the organizations try to project itself as an agile organization, aims to change anything at any time, but this becomes the anti-pattern.
Activity Oriented Teams
The teams are structured on activity and not on the outcome; eg — Product Design, Development, Test, and DevOps are working silos. It is hard to sync up on the quality outcome. Teams structure should be based on outcome and business value. Ref to my earlier post.
For example, you noticed that 10–15 AWS instances were getting spawned in every 24 hours, and the existing instances were getting killed after heavy memory utilization. It went unnoticed for long because, as per DevOps SLA auto-scaling was working fine and the site never goes down, and the memory utilization issue is a headache of the development team. The development team is not interested in monitoring production health as it comes under the DevOps purview.
Cross-functional knowledge is missing in such teams, and there is a lot of people dependency, which hinders taking a feature from business analysis to the deployment.
Inadequate Development Practices
It is a pattern when the standard development practices are missing, then the feedback cycle to developers are too long. Most of the issues are captured in the production. Test automation and CICD pipe are not up to date, so developers do not trust and maintain the test suites. It will become a practice to bye-pass the test suite and deploy directly to pre-production or production. It some times a result from a lot of pressure for quantitive delivery from the top management than on quality delivery.
You will see that the client would have a history of uncaught broken functionalities for a longer period of time, which would also be a cause to not trust the web site, and eventually impact the conversion rate and revenue.
Product and Business Observations
We have noticed the following observations related to business and product perspective.
- No business continuity — It is observed that the application is not stable enough, and there is no mechanism to keep the user engaged if the user has lost the product order journey.
- User experience — There are some major usability issues on the new app such as; a lot of clicks require to customize the product and order, redundant information placement.
- Integration Issues — History of issues with 3rd party gateways. It is taking too long to identify such issues. Define ways to measure 3rd party system’s performance and held them responsible for revenue loss if they do not follow the agreed SLAs.
Following are kind of technology observations, and these are mainly due to taking technology decisions without proper ownership and knowledge. Technology choices are followed for the sake of changing to a new concept. Eg: Server-Side Rendering on PWA was not well evaluated but applied.
- Memory Leaks — As mentioned in the earlier example, AWS instances are getting killed after getting out of memory. The exceptional increase in NodeJS server memory, which is leading to crashes every 2–5 hours. It is mainly due to, a) Too many global variables declared at the node level, b) Unwanted setTmeouts written to cancel each fetch request. After fixing the leaks the node instances may run in just 300 MB of memory, which earlier may be taking 20GB.
- Older Tech Stack — NodeJS, NextJS and React are at the older versions.
- Request Traceability across app is missing.
- There was a load on API servers due to unnecessary calls from the UI.
- Incorrect Progress Web App Strategy
- Issues in Cloud front caching strategy
- Incorrect Auto-scaling strategy. Instead of fixing the memory leak issue, an unnecessary auto-scaling configuration was done, which gracefully scales a new instance after every 10000 requests to a node.
- Missing Infra Health Monitoring alerts
The success of IT modernization is closely linked to the organization design, it may not always lead to success if the changes it may require are not accepted and owned by people. Just by changing the technology will not lead to IT modernization. The new technology comes with great promises but it also comes with its own challenges. We must always choose a new technology with the right tooling to address the challenges.