Slumlord Enterpise Vendors -- Are They Holding Back Your Transformation?

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 reached 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. They find that the data required to run a responsive, agile business is 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 taking a hard look at the vendor.

This story reminds me of those stories you hear about slumlords who take advantage of their tenants’ inability to “just leave” instead of actually doing the job of a proper landlord. Some vendors do as little as they need to meet their contractual obligation, knowing the price of pushing back is too great for their tenants.

With a little knowledge, you can quickly sort out which vendors are compatible with your new thinking.

So what’s happening?

In order to understand what’s happening with these vendors, we need to step back and look at what’s happened with transformations to date.

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. Building specialised software is risky and it can be hard to justify the costs.

So, 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 that change is now constant and are willing to do it with you. 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 continuously work with you on 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:

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 and that there are benefits for the both of you. A good and useful vendor will work to actively achieve your goals with you.

Unfortunately, that’s not going to be possible with some vendors. The reality is they may not want to change. 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.

Remember: someone’s always out there innovating. Make sure it’s you, and make sure your vendors aren’t slowing you down.

If you’re re-thinking your vendor choices, 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 together with your dev team, and watch your transformation flourish:

Accessing your data
What works What doesn't
No hassles; always available, no hidden charges, no exceptions No APIs, Poorly documented APIs, just anything that's not 100% automated.

Paying to get your own data

Paying to get information about your data
APIs & Customisation
What works What doesn't
Verify all claims; a technical lead who will work with the product on your side has positively assessed claims about functionality

Openness to this process

Documentation is online and fresh		 Non-technical representatives during this process

Sparse documentation

PDF documentation is a sure sign of outdated practices
Testability
What works What doesn't
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 collaborative		 Your vendor is insisting on "end-to-end" testing that really means testing their product for them

Monolithic architectures that make testing difficult

"Trust us, we've tested it"
Monitoring & Alerting
What works What doesn't
You 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/coded error messages when things go wrong

You have to contact them to find out what's going on.

By monitoring they mean an "service is up" web page

No monitoring or alerting, no plans to provide it
Development Support
What works What doesn't
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
Performance
What works What doesn't
Specifications should be available to inform projects of limitations, scalability, and are verifiable

Your team is comfortable that they are able to test outside of 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

When you're having problems, you have to prove the problems are yours, not theirs