How to break free from one software vendor and cut down on system maintenance costs?
07.06.2021 - Read in 5 min.
See how, in 3 easy steps, you can modernize your system so that its maintenance costs drop by 50%, while increasing its security and becoming independent from its creators.
What is Vendor Lock-in?
Vendor lock-in is a situation when a client relies on products of their vendor to such an extent that they have no possibility of changing the vendor without incurring additional costs.
This term may refer to infrastructure providers as well as to software and hardware providers. You may be both dependent on your cloud infrastructure vendor (e.g. Google Cloud) and a producer of printers, who may threat that they will terminate the warranty, if you use a replacement of the original toner.
Even Snapchat Knows the Risks of Vendor Lock-in
The notion of vendor lock-in is widely known and well understood in the IT industry. Despite that many companies have managed to avoid it. The owner of Snapchat, the app that doubled its number of users in 2016 and reported a 700% increase in revenue, may serve as an example. In order to further develop its business, Snapchat needed key infrastructure. As a result they entered into a 5-year 2 billion dollars agreement with Google Cloud for the provision of cloud infrastructure.
In its S-1 document Snapchat devoted a lot of attention to their dependency on Google’s operations. They wrote, among others, that: “Google is capable of taking action that remains beyond our influence and that can prove detrimental to our business.” (“In addition, Google may take actions beyond our control that could seriously harm our business, including: discontinuing or limiting our access to its Google Cloud platform; increasing pricing terms; modifying or interpreting its terms of service or other policies in a manner that impacts our ability to run our business and operations.”).
The company was aware of the risk but it did not manage to become independent of Google’s cloud infrastructure. This shows how serious and challenging this problem is.
The Bigger and Older Custom Software Is, the Higher the Risk of Vendor Lock-in
Monolithic, dedicated systems developed for years by an external company are highly likely to make your company dependent on its creators. The risk is especially high for tailored systems packed with functionalities. This is true irrespective of whether we are talking about WMS, ERP, CRM, PIM or other systems.
As years go by, these solutions grow by hundreds of models that sooner or later become obsolete. This way systems become more difficult and expensive to maintain. Disconnecting each obsolete module is challenging as, in many places, it is connected to other modules. It is also time-consuming and requires a lot of tests to prove that the operation has been successful.
It will be equally time-consuming and expensive to expand the functionalities of such a system in order to satisfy an important business need (e.g. adapt to new EU regulations).
An Extensive Monolithic System Creates a Host of Other Problems
As it turns out, the risk of vendor lock-in is only one of many problems arising out of extensive monolithic systems. Other threats involve too high costs of maintenance and development and the fact that such a system does not live up to your business needs.
Fortunately, a monolithic system is not the end of the world. You can modernize it in 3 easy steps, solving all of your problems.
How to Become Independent of One Software Vendor in 3 Easy Steps
The risk of vendor lock-in is predominantly related to software based on monolithic architecture. This is why in RST we use a proved road map allowing to abandon this architecture. Download a free e-book: Microservices or Monolith.
STEP 1 – Technological audit and selection of the right modernisation path
You should start modernising the system from analysis. A technological audit will help you test the condition of the system and define threats as well as areas that require improvement.
The technological audit should involve the following areas:
- Implemented technologies
- Automatic tests
It is a key stage for the owner of the system as identified problems are a basis for a recommendation for an optimal path of modernisation that would maximise benefits at a reasonable cost.
STEP 2 – Modernisation
At this stage we start modernisation. Depending on what problems have been identified in the audit, step by step, component after component, we implement one of the available approaches:
- Code refactoring – restructuration and optimisation only of the code of the component, without changing its functionality
- Rearchitecting – Modifying the code of the component of the application in order to move to new architecture with greater capacit
- Rebuilding – Redesigning or rewriting a component of an application from scratch, leaving its specification and scope unchanged
- Replacement – Eliminating a component of an application and replacing it with a new one, keeping in mind new needs and requirements
The approaches listed above have been ordered from the least time-consuming (refactoring) to the most time-consuming and beneficial (replacement).
Rearchitecting – Opportunity to brake free and… more!
Companies struggling with a large monolithic system benefit most from dividing it into smaller parts and embedding them in cloud-based micro-service architecture (rearchitecting).
What are the benefits of moving an application to micro-service architecture?
- Breaking free from the only creator of the system – by dividing the application into smaller parts each part may be developed by a different software provider.
- Lowering maintenance costs – applications divided into microservices are easier to manage and more failure-resistant. They also allow for selectively choosing technologies. This makes them more efficient and cheaper to maintain.
- Increasing efficiency while optimising scaling costs – Microservices allow you to scale your resources for a single microservice. It is less expensive than investing in infrastructure supporting the entire system. What you get in return is necessary efficiency for a price of only used resources.
- Faster implementation of a function into a system – it is easy to implement new functions in microservice architecture. In order to do it, you simply need to modify one of the existing microservices or create a new one. You no longer have to test the entire system after each modification.
Moving the app to microservice architecture requires code modification. You can either keep its original functionality or expand it.
Integration with Open-source Solutions
Such changes allow you to integrate the system with open-source solutions that may be just as flexible, efficient and safe as their paid counterparts, without the necessity to pay a fortune for licenses.
Using technologies such as data buses (ESB, WSO2, RabbitMQ), REST or RPA (Robotic Process Automation) you can integrate almost every application. So it is good to use this opportunity to automate processes and robotise repetitive manual tasks.
STEP 3 – Maintenance and easy development of the system
In order to maintain Business Continuity, the modernised system will require maintenance by the IT department. Yet, it has become more flexible and easier to develop. From now on even a few suppliers will have the possibility to work on elements of the system at the same time. They will be able to develop each component separately in whatever technology they might choose.
Does your company have a system that is currently struggling with flexibility issues, generating high costs and calling for modernisation? Check it before it is too late!