By now, most of us have experienced vendor “lock-in.” Cell phones sold at a discount in exchange for contract agreements that lock you in to the provider. PC applications that are a nuisance to put up with but would be an even bigger nuisance to switch. And—we all love this one, don’t we?—the surprisingly cheap printer that requires you to buy that company’s surprisingly expensive ink cartridges.

In the business world, we’ve got vendor lock-in and we’ve got it bad. We spend tens of thousands—or tens of millions—of dollars on a complex business system, by which I mean some combination of hardware, software, and business processes sufficiently embedded in the company’s day-to-day operations that it would be extremely painful, difficult, and costly to replace it. Think CRM, ERP, CMS, BI, ILM—the list goes on. Once a system like that is up and running, once people have learned how to use it, once mountains of data have been stored in it and processed by it, once customers are interacting with it, once processes have been re-engineered around it, once a myriad of apps have been made compatible with it, once the IT folks have learned to baby it along . . . Talk about being locked in!

Lock-In: With Whom, Not Whether

But I’m here to tell you that, most of the time, “vendor lock-in” is a red herring, a bogeyman unleashed to persuade decision-makers to let the IT department prove that “anything they can do, we can do better.” Or, if not better, at least without vendor lock-in.

Now here’s the dirty little secret that engineers and IT departments never mention. The implementation and maintenance of any complex business system is going to join you at the hip—from day one—with your supplier, be it a vendor or your own development team. Choose your own team, and that’s who’ll have you locked-in.

And how great will that be? I should know. I spent the first half of my career designing and implementing complex information management systems with engineers and IT managers from California to Moscow. Here’s what I learned:

1. Complex business systems are never simple or inexpensive to replace.

Business complexity drives time and cost. I could provide dozens of examples, but this should be self-explanatory. Your goal should be to contain the complexity and focus on core competencies. Bringing the development of complex systems in-house is just the opposite. It is not the answer unless your organization has deep pockets, infinite patience, and a strong desire to reinvent the wheel. I am certain your customers would agree.

2. Internal development will almost always cost more over the life cycle of any project.

Any system costs money to architect, implement, QA, maintain, support, and upgrade. Depending on the complexity of the system, you may need to enlist the help of resources from several groups throughout your company in addition to footing the bill for ongoing project development and management. Like the Wars on Drugs and Terror, it is a commitment without end.

Vendors have built their businesses around the development and support of their products and they amortize the ongoing investment over many years and many customers. It takes a certain degree of audacity, bravado, and ignorance to believe one can build a better, more cost-effective mousetrap than those who have dedicated themselves to the task and who have satisfied a variety of needs for hundreds of customers.

3. Standards and opensource will not protect you from lock-in.

Some lock-in opponents assert that systems built on standards and opensource will somehow be superior to proprietary systems. At least you won’t be locked-in, right? They fail to understand that lock-in is a natural consequence of implementation and complexity, not a punishment for signing a bad contract.

It is one thing to discuss the merits of an open file format and quite another to apply them to complex business systems. For example, even if the internal engineering teams of several major financial institutions all began with the same standards and opensource code base, their in-house systems would very likely be incompatible and require substantial investments to swap, integrate, or rip and replace.

At DMG, we love opensource and open standards, but we also understand when and where it makes sense to leverage them.

4. Service-oriented architecture (SOA) will not protect you from lock-in.

I would argue that, at least for the near future, the principles of SOA may actually exacerbate lock-in as systems grow in size and complexity. The relationship and composition of services, not the services themselves, will determine a system’s manageability and it will require an expert to make sense of it all. Even then, I would question the system’s overall manageability.

Given the relatively small number of SOA-qualified developers and architects today, you’re going to be as locked-in to your internal SOA developer as you would have been to an outside vendor. If your organization is heavily invested in SOA and the architect of your critical applications asks you to jump, the correct response will be “How high?”

5. Under the covers, your company is not that different from the competition.

Every manager thinks her business is unlike anything else in the world. Quite frankly, if you have seen one major retailer, bank, hospital, or publisher, you’ve pretty much seen them all. There are differences, but virtually none that would warrant the ground-up development of, say, a point-of-sale application, analysis tool, image-management application, or publishing system when plenty of suitable, configurable alternatives exist.

Commercial solutions for fairly standard activities such as business intelligence and content, resource, and storage management evolve over time from the feedback of dozens of customers and hundreds of suggestions for improvement. Chances are excellent that if your requirements can’t be met by available commercial products, your business is either way, way out front or way stuck in the past. Of the more than 100 companies I helped during my engineering career, most fell into the latter group, mired in puzzling, inefficient, and often arcane business processes that should have been replaced—not recreated—in the digital realm.

6. Homebrewed systems are typically well behind the maturity curve.
   

   I enjoy a challenge. But the notion that I could assemble an in-house engineering team to develop a complex application over the next 12-24 months that would stack up to a mature commercial product is pure fantasy. Take Documentum and FileNet, for example. They have been around for 18 and 26 years, respectively. I worked for one of their competitors during the late 90s. Armed with a thorough understanding of their product architectures and an engineering team that numbered close to 180 people at its peak, we managed—over the course of four years, mind you—to develop only a fraction of Documentum’s and FileNet’s core capabilities. Eventually, our company—backed by some very forgiving investors—decided to pursue a different market with less mature products.

   Complex systems take time to develop—a lot of time. Once the first release is installed, the engineering team is forced to divide its efforts among bug fixes, patches, and product enhancements (or else recruit more engineers). By managing user expectations and beginning with a reduced feature set, you can certainly complete a first release in a reasonable amount of time. But after that, you will forever be behind the eight ball and well behind the maturity curve. Engineering proposals for in-house solutions rarely include an objective analysis of the opportunity costs, especially the ongoing loss of business productivity and competitive advantage as you waste valuable engineering resources trying to keep the monster you’ve created up on its feet.

7. It takes more than engineering to develop a usable product.

Earlier I wrote that “you may need to enlist the help of resources from several groups throughout your company.” Too many companies get blindsided by this one when they choose to develop complex applications in-house. The last software development team I worked with included programmers (Mac, Linux, and Windows), database experts (Oracle and SQL Server), user interface designers, information architects, artists, technical writers, QA engineers (familiar with dozens of business applications), project and group managers, subject matter experts, and internal/external stakeholders. Now, remember your company’s mission? Assuming you even have all these people, don’t they have something better to do?

8. Techies believe they can do a better job than other techies.

Techies love to play with knobs and dials—I call them tweakaholics. Regardless of their actual level of expertise and competency, they tend to believe they can build a better mousetrap than their fellow techies. Consequently, they enjoy re-inventing the wheel, or at least finding a way to make it a little rounder, at the expense of their employers.

9. Techies hate documentation.

Some techies spend hours online crafting tome-sized blog posts and kudos to fellow techie bloggers. If only they could channel that urge for self-expression into readable documentation and meaningful code comments. Wise companies spend a good chunk of their budgets on professionally written and edited documentation. They understand its impact on employee and customer perception (of quality and usability) as well as future product development and support.

Undocumented or poorly documented projects fail the “hit by a bus” test. That is, if engineers are not properly documenting their work, it will be expensive and time-consuming (and occasionally impossible) to bring their successors up to speed. Poorly documented products and processes lock us in to their creators. Oops, did I say “lock in” again?

Call me a cynic, but I perceive supplier lock-in as a form of job security. I would rather be locked-in to a vendor with deep pockets and a strong desire to build a mutually profitable long-term business relationship than locked-in to Joe IT job-hopper who could be gone tomorrow, taking much of my company’s knowledge of its [internally developed] business systems with him.

There had better be a damned good reason for wanting to bring the development of a complex business system in-house, and the threat of vendor lock-in isn’t it.

This entry was posted on Saturday, February 16th, 2008 at 6:32 am and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.