It’s easy for our own strategy to be determined by what our suppliers are doing. If we become too dependent, we risk having our strategy set by our suppliers rather than having them support our strategy.
I’ve been thinking a lot here recently about how much suppliers can direct your business. Part of this has to do with a lot of the infrastructure work I’ve been doing, and when you take stock of how easy it is for too many critical functions of your business to dependent on vendors, it’s a bit worrisome.
I’ve been test-driving Boomerang, a new service for Gmail that finally allows you to schedule when email messages go out, and I got an email from the company apologizing for the service disruption they had yesterday. It didn’t affect me, but I’m sure it affected a lot of their user base.
There was a thread that I wanted to share with you, as it actually prompted this post:
Like many startups, we entrusted AWS [Amazon Web Services] with virtually our entire infrastructure, including both our production servers and most of our backup systems. We hoped that their systems were independent enough to see us through if something went wrong with one piece of the service, but today’s problems reminded us that data centers at that scale are very hard to make independent.
We should have had a better plan in place, and we’ll be making one. We’ll be working very hard to improve our redundancy in the upcoming few weeks, both because we want you to be able to rely on us to get your messages to the right place when they need to get there, and because mornings like this are making me bald and giving me wrinkles.
This is not a critique of the company, as I would have been just as surprised and bald as this particular CEO. And I don’t think it’s something such that we should stop trusting the company.
But note that users of Boomerang actually have a nested dependency – people who use Boomerang are also at the mercy of Google and Amazon Web Services and Boomerang. If either one of those three companies either have infrastructure problems or take a significantly different direction, the businesses who use them then have to react to someone else’s problems or strategic change.
Grounding Our Business Rather Than Keeping It In The Cloud
In a similar vein, I made an embarrassing infrastructure decision earlier this week. We’ve been working on getting a collaborative space for our team ready to go, and it’s been taking forever. I got impatient and set everyone up with a Backpack account, only to find that some of the critical features I love about Backpack are being phased out. It’s still a great service, but we had already set up a Mac server to host a lot of our business functions and it actually has some functions that work better for us than Backpack, anyway. We can save $24 a month and get the functions we want, and, if we wanted to, could start hosting our own webapps that do exactly what we want them to do.
So, rather than sticking with a SaaS (Software-As-A-Service) where we’re dependent on the vision of another company, we near-instantly switched to using the services on our server. It was an embarrassing stumble, but it happens.
You might notice that we’re still dependent on what Apple does, but, in an enterprise setting, the slower development rate of bigger companies is actually a boom, infrastructure-wise. You don’t get stuff set in place only to get an email that says they’re phasing out a critical function, and, even if you did, you don’t have to upgrade. Just ask all of the organizations who are still using Microsoft XP because their IT departments didn’t approve the move to Vista or Windows 7.
I’m still an advocate of SaaS and cloud hosting options for most small businesses because the financial and operational costs of creating your own infrastructure and solutions are too much to bear for many businesses, especially those in Stage 0-2. As long-term needs and processes emerge, though, there’s an availability to set the right pieces in place that actually fits your business, rather than having to adapt your business to the way cloud hosted solutions work.
Vendor Dependencies Have Different Weights
I’ve been frustrated by the fact that you can’t generate an email from a tag or list of people from either Highrise or Batchbook. You have to download a file and monkey with it in your email client to send the list, which is far from convenient. I recently found that CapsuleCRM does this brilliantly. (InfusionSoft does this – but you have to send an email from the software, rather than doing it via your regular email.)
However, CapsuleCRM is one of the newer players. As much as I want to support new startups and small businesses, we didn’t migrate to CapsuleCRM largely because I don’t want our operational people center to disappear if they don’t make it. They also are so new that it’s not clear where they’re going.
As a productivity and systems specialist, I like playing with new services and seeing what’s available. It also helps me advise clients about new options, as well. That said, there are some critical business functions that I don’t mess around with – people centers being one of them. It’s precisely why I’ll play with and use Boomerang but not switch the team to CapsuleCRM.
It’s A Strategic Decision – Like It Or Not
Choosing and using suppliers is a matter of strategy, even though most of us don’t think about it this way. If you make the decision to go with a solution because it’s cheaper on the front and gets you going, you’ve also accepted that you’ll have your business tied to a solution that may or not grow with you. You’re also opting to pay costs out over the long term without owning an asset.
At the same time, going through all of the soft and hard costs associated with rolling your own solution is also a strategic choice – and one which leads to folly if you start too soon. Far too many business design how their business will work in theory only to find that their businesses work much differently in practice. One of the key areas that gets away from people quickly is team dynamics, as the way one or a few people work as a team is often much different that the way many people work in a team.
Of course, the downside to building, deploying, and maintaining your own solution is that those activities require their own resources. If it breaks – whether you did it or not – you have to fix it.
And, since it’s a strategic decision, I can’t say what’s right for you in a general way. So I’ll leave you with some questions:
- What are the critical functions and processes of your business that would cripple you if a supplier failed or changed directions quickly? (Communications and utilities are prime example. No power and no phone = no business.)
- Can you get your data and processes out of a supplier quickly and easily if you see that you need a different solution?
- Do your suppliers have robust enough internal processes to troubleshoot service and deliverable problems? In other words, if their systems crash, will they be able to get back up and running on the solutions and services you’ve paid for?
- Which of your business’s functions and processes might make good candidates to develop and deploy your own solutions? Place special emphasis on scaling if you’re building your business to scale.
Affiliate Disclaimer: The links to Highrise, Backpack, and InfusionSoft are all affiliate links, so I’ll get a commission if you start using their programs based on my referral. These are products I regularly recommend to clients and friends and, as you can tell, encourage people not to use if they don’t work for them.
I always think it’s safe for businesses to diversify their risk… being too dependent on any 1 thing ain’t smart, whether it’s a supplier, a search engine, or 1 larger customer. You never know when the sky will fall
I saw a lot of threads after the the very public failure of AWS. One in particular was a health care company that monitors EKGs for patients who are at home, and then reports the information to patients doctors and such. When AWS failed, so did their entire reporting system. Most responses to this company were a mixture of concern for the patients and a very stern, ‘why would your CTO allow a health service to be solely dependent on AWS or any cloud system.’
I think the lesson from this is NOT that the cloud is a bad solution but rather, companies need to truly asses the risk of the cloud. even if they say they are up 99.5% of the time, well, there is still a .5% failure rate. There must be plans for this if you are a company whose user base depends on you 100% of the time. In the cloud, there are ways to have back-up plans, but it takes some thought and is not going to be the same answer across the board.
Think of it this way, when a power outage happens in your neighborhood there are various back-up plans based on the need:
– Family home: Candles and flahshlights
– Family with someone on a medical device: Battery and/or generator back-up
– Tech facility: UPS (Uninterruptible Power Supply, with ~20 minutes of life) with a generator that kicks in within 10 minutes and an e-mail/phone system that calls the key tech people
– Hospital: Full Battery back up and instant on generator to ensure zero down time
All of the above have the same exact situation on their hands with very different back-up plans. If your service is mission critical, then you must act like it and have a back-up plan that meets this need. If an outage is an annoyance, but not something that will stop your customers from getting things done in a timely fashion, then your back-up plan may be a simple page stating that the site is down for unplanned maintenance.
The cloud is not failing, it is growing and with it, there are some growing pains. These growing pains include businesses trusting in it too much with no plan for failure.
My $0.02 (as someone whose product is in the cloud).
Charlie Gilkey says
I love this reply, LoJo. Whether or not I stated it clearly, I agree – it’s not that we should avoid cloud-based solutions. Most of my business is in the cloud and it’ll stay that way, too.
It’s just that we need to understand the difference between abdicating our responsibility to ensure mission-critical functions and backup plans and using scalable, low-cost, and low-maintenance functions.
Setting backup plans in place is usually pretty boring and is overlooked, but dealing with a single- or multi-point failure is much, much worse. It doesn’t matter whether we’re talking of cloud services, caterers, or support staff. (No, the military didn’t teach me about redundancy of critical functions or anything. 🙂 )