By Bozidar Spirovski
Large enterprises rely on software products. And as everything else in large enterprises, the software products are large, complex, cumbersome and nearly unchangeable.
This last attribute is better known as vendor lock-in. Software vendors love vendor lock-in.
Here is a definition borrowed from Wikipedia: "Vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."
Vendor lock-in exists in most large enterprise industries like Telco, Healthcare, Finance, Energy. Such industries rely heavily on certain computer systems or software products, usually dubbed Core Systems. Because most of the business transactions, logic and information are stored and processed by these Core Systems, the transition to a different Core System vendor is extremely costly and time consuming.
So most large enterprise companies simply continue to operate with the same Core System vendor, while they suffer:
1. Delays in patch or version delivery;
2. Poor quality product versions;
3. Inadequate compliance from the Core System to their local law and regulation; and
4. Ever increasing maintenance costs.
On the other hand, switching to another Core System vendor will result in probably the same end effect, with the added costs of the switchover.
So is there a way to improve your position? Indeed there is, but with a radical move: there is only one thing that any software vendor reacts to -- risk of decrease in earnings from a customer.
To make this risk a reality for the vendor, the customer needs to reach a situation where competitors can successfully bid for software upgrades and new functionality without actually switching the Core System.
This is most easily achieved through the Core System's API interface. Most Core Systems have extensive Application Programming Interfaces (API), which can be used to exchange data with the Core System or issue commands to it. So instead of asking for every possible modification or new functionality from the Core System vendor, just use it as a processing core -- move everything else to other developers, which will need to adhere to the Core System API specification.
This way you can outsource the development of a lot of applications to other vendors, achieve better response from everyone and always have healthy competition.
Oh, and it will keep the Core System vendor on its toes!
Copyright © 2008 To Present · Information-Security-Resources.com
Bozidar Spirovski is an information security expert with Information Security Short Takes.
Only registered users can write comments.
Please login or register.