2

My company is venturing into a niche area of the telecom business. The challenge we are facing is there are very few vendors of some critical software we need and in turn there are very few customers to buy the software. It's just a small market for this particular product.

Vendor lock-in is a huge concern but seems inevitable.

We have ruled out developing the software ourselves as leadership feels that may be expanding our mission too much at once. The vendors will also not let us buy the the source code (i.e. the intellectual property), so if we ever do decide to change vendors we will have little that can be reused other than our data.

Does anyone have experience or pro-tips on working with a vendor pool of 1-2 providers where one cannot easily (matter of years) move from one vendor to another? How can we avoid lock-in? My request for proposal (RFP) experience so far has never really been limited by vendor selection and the niche market dynamics is uncharted territory.

Improve this question
1
  • 1
    Hi Feik, welcome to PMSE. I've edited your Question to avoid it from being too broad ('How do I manage?' to 'How to avoid lock-in?'). If this doesn't capture the essence of your question, feel free to edit, but be wary that being too broad could risk Question closure.
    – Sarov
    Commented Mar 4, 2019 at 22:11

4 Answers 4

Reset to default
1

TL;DR

You avoid lock-in by owning the process, and by routinely taking control of the project's artifacts and deliverables throughout the project life cycle. Especially in the software world, so long as you have the source code, you're never truly "locked in." You can always take your football (or source code) and go home, although that's not always your best business strategy.

In addition to actively participating in your own process and keeping control of your bespoke artifacts, you need to consider how you will work with your vendor. A collaborative, transparent approach is often your best bet for maintaining flexibility and reducing risk throughout the project life cycle.

Value Collaboration, Transparency, and Tight Feedback Loops

We have ruled out developing the software ourselves as leadership feels that may be expanding our mission too much at once.

Anytime you rely on goods or services outside your company, this represents project risk. The size of your vendor pool may change the size of your risk, but it doesn't really change the fundamentals of the type of risk you're facing.

As a rule of thumb, always avoid the mistake of "throwing work over the wall" to your vendors. You own the product or service that they're building for you, so it is in your best interests to collaborate with them as closely as you can.

From an agile perspective, your goal should be to have a very tight feedback loop. There should be ongoing transparency, and potentially-shippable increments of functionality should be reviewed together by your stakeholders and your vendor on a predictable cadence of 1-4 weeks. This review should be more than just a sign-off or a slide show; it should be a collaborative inspection of the increment of work. This inspection provides feedback to the vendor, so that any on-the-fly adjustments to scope and direction can be discussed together. It also provides visibility to stakeholders, so that business decisions and trade-offs about cost, budget, or schedule can be made in an informed way.

The very worst-case scenario is that you discover the project can't be delivered on time or on budget. By working more closely with the vendor than may be typical, you'll discover that sooner and can "fail faster." What you do then is also a business decision, but it's often better to discover that a project will deliver late, cost more than expected, or fail altogether sooner rather than later. No methodology will guarantee success, but "failing fast" is the best way to keep your options open and avoid the sunk cost fallacy.

Improve this answer
2
  • Very good and answer, transparency, and collaboration was the only approach I could think of. I did update my question to note that we will not own any IP or source code from the vendor. If we change vendors it will be green field. These companies have spend 40 years developing their codebase, so it makes sense but also makes the vendor lock-in that much stronger.
    – user35229
    Commented Mar 5, 2019 at 13:56
  • 1
    @Feik That's a business decision, of course. You might ask your legal team to add requirements for code escrow and data portability to your contract, and consider doing business elsewhere if they say no, and if "no" exceeds your company's risk tolerance. Risk can be accepted, transferred, or mitigated. There is no fourth option. :)
    – Todd A. Jacobs ♦
    Commented Mar 5, 2019 at 14:06
1

You have already ruled out doing development in house, but the question is, is this code central to your business. Is it "what you do"? If it is, then there is value in doing the development internally, on the side after you have hooked up with a vendor.

Let's say for an example, you go with a vendor named DS9Commander. Eventually you will find a few areas that chafe a bit. you can create your own solution that can specifically address those issues to 1. differentiate yourself, and 2. use it in the business case to get your clients to pay for the conversion to your system later.

Sometimes you can use middleware to help prevent tight coupling. If this is a possible option I highly recommend it, as I have been involved in a Telco project that was able to replace some back end devices by doing some data mapping/translations in the middle without needing to modify the ends.

Improve this answer
1

You want to make sure you have clear boundaries. In general you want to make sure there is a clearly defined interface between your software and their software. Then, when you replace their software, it's not all entangled within your systems.

This may require additional effort upfront, but it will pay off later. Even if you owned both sides of the interface between system 1 and system 2, you want clear boundaries.

I've worked on many contracts that require the vendor to use standards. This can be a standard in format (like a known XML structure) or a standard in data (HON means HONDA).

You also want to make sure your contract with the vendor includes support for migrating/transitioning to another vendor -- the most important of which is getting your data and getting it in a usable format (like CSV) along with a data dictionary.

Improve this answer
0

In my opinion "avoid vendor-lock in" this is more a topic of software architecture that belongs do http://softwareengineering.stackexchange.com/

Technically you are locked in to a vendor when your code directly uses vendor-specific-propriatory-datastructures

To make changing from one vendore to an other more easy all vendor specific code should be hidden behind a software Adapter. In the onion software architecture this is called the infrastructure layer: You have thin adapter interfaces in the core that your own code uses. The vendor specific adapter implementation itself is implemented in the "infrastructure" layer

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.