Does using the USoft platform cause vendor lock-in?

Customers sometimes ask USoft whether they become completely dependent on us and our software if they go into business with USoft. In short, whether a so-called vendor lock-in occurs when using the USoft low-code platform? Fortunately, this is not the case. This short article explains why not. 

What is a vendor lock-in? 

To begin, it is important to provide a good description of vendor lock-in. A vendor lock-in means that customers are and remain dependent on a vendor to a greater or lesser extent. For example, customers cannot easily migrate from one product to another. In addition, changing or adding functionality may no longer be possible or may be limited. This is something you will always need the vendor to address. 

With any technology, there is always a certain degree of vendor lock-in. Even open-source software is subject to some degree of lock-in. There are often no license fees and sometimes there is not even a vendor, but there is a technology lock-in. You use the product because it can do something specific. With any transition, you lose these capabilities or have to implement them again in a slightly different way. So, with that, you always have transition costs.  

What matters most is that a supplier limits the lock-in as much as possible and allows customers/users to switch to another supplier or product. That means you have to (be able to) store knowledge outside the product and also the data. The business logic used within an application must remain transparent as much as possible. 

It is good to realize that the principle of lock-in does not only apply to product vendors. A form of lock-in can also occur on services when very specific knowledge is involved. 

Make dependent, that's something nobody should want 

As said, vendor lock-in has several perspectives. First, from a perspective of knowledge and its embedding in a product in a way it is no longer clear how the product works. Second, from a technology perspective, dependence on a particular technology can make it difficult to switch to another technology. Lastly, from the perspective of being dependent on a supplier to make adjustments.  

If you put this next to a USoft implementation you will see that lock-in is reduced as much as possible. A USoft implementation has several key features for this:  

1. Rules/logic are implemented in a structured and neat way so you can always find both definition and implementation. The knowledge is therefore also stored outside the application which prevents knowledge lock-in;  
2. All data remains available even outside the use of USoft. This significantly reduces the risk of technology lock-in; 
3. USoft is a low-code platform. Customer developers can work on the applications themselves which also minimizes dependence on USoft consulting.  

The logic executed within the USoft application is reflected in USoft Studio. For each project, business rules and agreements are defined and managed in USoft Studio. Business rules are defined in natural language and clarified with diagrams. Based on this, the logic of the application is thus always traceable and can be replicated in another application. If the software license is terminated, an export can also be made from USoft Studio, preserving all information for the organization. The bottom line is that switching costs must be incurred, but there is no lock-in. 

Moreover, the data generated and/or processed in all USoft applications is always stored outside the USoft platform in an external database. This includes all information about the application (metadata), such as rules and processes. This database is always readable by external tools and contains no surprises. And is additionally fully insightful from industry standards based on SQL and XML, for example. For example, the data model, as declared in USoft, can be found 1 to 1 in the database. This makes it easily usable for other applications.  

Lastly, USoft's business model is not focused on making customers dependent on consulting provided by USoft or partners. USoft's low-code platform allows customers, who have business analysts and developers of their own, to train them to use the platform. Based on this, the entire application can be maintained and modified as needed. 

Long-term collaboration is a good thing

Now a little lock-in is not bad at all. Long-term cooperation also ensures that more and more mutual understanding and shared knowledge are built up. It allows USoft to devise and build better solutions for customers. And it also allows our platform to be further developed in collaboration with the customer to stay in line with customer needs. The customer gets more and more knowledge from USoft. Over time the cooperation will get better and better. 

Technical Background 

Functions that are built in USoft as business rules will no longer work if USoft goes down. The rules engine that executes and controls the business rules is an integral part of the USoft platform. So, if the platform becomes inactive then the engine function is lost. That means the application that executes the logic does need to be rebuilt or renewed. But as with the data structure, the business rules are also being stored in an optimally readable and testable way in the database. Not only can the business logic be properly rebuilt with other software, but it is also possible to test whether the business rules "still work". Since the business rules are built based on standard SQL, they can be used to create the new software. Because everything is based on open standards, no knowledge is lost when the use of USoft is discontinued. 

Finally, some of the functions in a USoft application are built outside the rules engine, for example in the CSS and JavaScript layers of Web pages. Limited lock-in applies to this functionality: it is non-USoft-specific technology that only needs to be modified at the points where it communicated directly with the rules engine and the underlying data.