It’s always difficult to watch a friend suffer. Here’s a story I hear a lot lately:
A company is undergoing a transformation and have gotten to a place where they’re thinking about end-to-end service design. That’s when they remember that they’ve outsourced a lot of operational systems, meaning key bits of data that are required to run a responsive, agile business are owned by an outside vendor. When they go to the vendor to retrieve this data, little information is forthcoming free of charge, and it’s expensive just to get an estimate for data retrieval. Eventually, it turns out to be too expensive to move forward, so nothing is done. The transformation limps along wounded, and leadership blames “the agile” instead of the stingy outside vendor.
This story reminds me of the tales of slumlords who take advantage of their tenants’ inability to “just leave” instead of actually doing the job of a proper landlord. Vendors do as little as they need to meet their contractual obligation, knowing the price of pushing back is too great for their customers.
So what’s happening?
The Story of Transformation
In order to understand what’s happening with these vendors, we need to step back and look at what’s happening with transformations, in general. Digital transformation has concentrated on introducing a combination of lean and agile practices and various accompanying technology innovations, for example:
- Management and organisational practices, such as using Scrum and Kanban to organise teams, their work, and give visibility to progress and blockers
- Testing as a matter of course, and extensive coverage of those tests to minimise the combinatorial risk that accompanies change in ever-increasingly complex software
- Continuous build pipelines that automate that testing, as well as the deployment of not only software, but also the servers that sit beneath the software.
- Paired programming as a way to improve quality, by ensuring that communication happens continuously during the development process
These innovations have solved many of the problems with quality and delays that vexed the early decades of the internet age. With those problems solved, we’ve moved onto new ones, like how to connect the various parts of our business, and how to manage and get value out of all the data we’re creating. Transformation continues.
The Problem with Third Party Vendors
Transformation efforts have tended to concentrate on an organisation’s own delivery capability, which works fine for those that control their entire estate. However, in addition to building in-house, large organisations outsource projects because they lack the skills, capacity or desire to do the work themselves. They’ve largely relied on outside companies to manage various aspects of their business that seemed tangential, especially operations and customer service. If your transformation has hit the point where you’re dealing with the outsourced bits of your enterprise, you’re probably finding that the transformation playbook is missing a chapter.
This next part of the story may sound familiar:
The vendor says a lot of agile-sounding things, but what you actually encounter are outdated and poorly documented APIs (or none at all), and promises of functionality that turn out to be half-baked. Engagement during development is costly, coming in the form of oxygen-wasting “engagement managers” instead of knowledgeable technicians, and trying to code and test against their services is a nightmare.
What’s happening is that many of these vendors don’t follow modern practices in their own development, they’re just beginning to, or worse, they pay lip service to your new world view during the sales process only to fall short once they’ve made the sale. Change, as you know, can be costly. So instead of retooling their own technology and business practices to meet customer needs, vendors choose a strategy of entrenchment and “sweating assets.”
Should we expect better?
In 2018, the answer is yes. Good vendors recognise the need for change and recognise that change is now constant. However, slumlord enterprise vendors who maximise their profits by sweating their assets and minimising the effort they expend on your engagement need to go.
The security that comes with a brand name might look good up front, but they may be costing you in the long run, if they’re not able to follow through. As you transform, it’s time to start demanding more, and taking the opportunity to really change your organisation by looking for vendors that will help you meet not just today’s needs, but also the challenges ahead.
How do you spot a slumlord enterprise vendor?
Here’s a handy list of signs that you may be dealing with a slumlord vendor:
- Owns your data and charges dearly for you to get your hands on it
- Provides poorly documented (PDFs?!), poor APIs, or (clutch the pearls) file transfers
- Sends an engagement manager when you need tech help
- Treats quality problems in their software as “known issues”
- Won’t talk to you about developing solutions to specific problems
- Offers you costly upgrades with extra features you don’t need
- Says the “known bugs” are fixed in the update, but it’s not free
There are a couple of options when you run into these issues with third parties.
The first is preferable, and I’ve seen it work– bring them along on your journey by showing them that improving development practices is about moving forward, not moving on. A good and useful vendor will work to actively achieve your goals with you.
Unfortunately, the preferable option isn’t always possible with some vendors. The reality is you may not need them, or they may not want to change, and if your partner isn’t willing to grow and change with you, as in life, it may be time to move on. Re-thinking the rules of engagement with vendors may seem costly, but the price of ignoring this need will be even more costly in the long run. The greater cost will inevitably come along when your competitors, who’ve already done the work of re-thinking the rules of engagement get ahead, while you flounder in the old world.
If you’re re-thinking your vendor, getting a bad feeling about them, or looking at a new one, here are some considerations that can help you figure out your next steps. These considerations are by no means comprehensive — figure out what works for your organisation with your dev team, and watch your transformation flourish:
|Consideration||What works||What doesn’t|
Access to your own data
|No hassles. Always available, no hidden charges, no exceptions.||No APIs, Poorly documented APIs, just anything that’s not 100% automated.
Paying to get information about your data
Paying to get your data
Where APIs will be used. Verify all claims.
|A technical lead who will work with the product on your side has positively assessed claims about functionality.
Documentation is online and fresh.
|Sparse documentationPDFs are a sign of outdated practices.|
Your team should be able to write tests independent of the vendor’s production environment.
|Your technical lead has assessed the effort required to stand up a test environment.
The vendor is working with you to make things easier, like providing sandbox environments, testing stubs, and generally being helpful.
|Your vendor is insisting on “end-to-end” testing that really means testing their product.
Monolithic architectures that make testing difficult
|Monitoring & Alerting
You need to understand what’s going on with the service you’re paying for at all times.
|Your team has access to monitoring and alerting for service, availability, usage, etc.
If your vendor doesn’t already provide it, they’re working toward it, and not giving you the feeling that there’s something to hide.
|Opaque (504) error messages when things go wrong
You have to contact them to find out what’s going on.
No monitoring or alerting, no plans to provide it.
A named, technical, point of contact will be available throughout development.
|You have a name, a face, and can talk to this person over Slack, Skype, hangouts, what-have-you. This person isn’t a middle-man, can write code, and explain why things are the way they are.||Non-technical “engagement managers” as your team’s main point of contact.
Charging you to find out how much it will cost to answer a question
Specifications should be available to inform projects of limitations and scalability, and are proveable
|Your team is comfortable that they are able to test for production against upper performance limits without interfering with the production environment.
They work with you on problems that may not be their own.
|Your vendor’s response to this one isn’t “trust me” and an appeal to an SLA in a document somewhere.
You have to prove the problems are yours not theirs.