Data Governance, Videos, Data Science, Data Warehousing, Business Intelligence, Article, Snowflake, Blog

Why “born in the cloud” matters



January 3, 2018

If you've worked in or around the enterprise software industry for any significant period of time, then you've seen a lot of technical evolution over the years. What most people don't see is how those technical evolutions play out behind the scenes with software vendors. It usually begins with some kind of start up (which I'll call David) that really shakes up the "established" vendor (which I'll call the Goliath), with a disruptive innovation. Goliath will usually start by downplaying David and reassuring prospects and customers that he's Goliath. It's only when Goliath is losing deals to David that it catches the attention of the R&D budgets inside the Goliath. Then Goliath begins to innovate or considers acquiring David.

The move to the cloud is so disruptive that it can literally make Goliath irrelevant overnight. Think carefully about what an Enterprise Software Vendor has to address in order to transition from an on-premise history to a cloud future.

First they would have to deal with a new sales compensation model. This is because sales commissions for a cloud subscription is typically far less than an on-premise license. So some sales reps are going to resist selling the cloud solution to you. This means that a transition to the cloud isn't just a tweak to a software vendor's product offering. It usually requires them to literally split their sales organization in half, in essence competing on the same business. You need to be highly aware of this when inviting a sales rep into your business. I have seen sales reps keep their cloud solution under wraps from customers for this very reason.

Additionally they will need to split their R&D budget. It's convenient to imagine that Goliath could just divert all its effort to a cloudified architecture. But existing legacy software maintenance contracts act as a pair of golden handcuffs, which make such a transition near impossible for enterprise software vendors to pull off. This means that R&D budgets need to now play a dual role. First, supporting the predictable revenue streams from the maintenance agreements, and second ensuring the platform is future proof. (cloud ready) This dual role creates a huge dilemma for enterprise software companies. Do they secure the future, or maintain the present? The inevitable answer is... both. The once well funded R&D for the solution stack has to innovate with a shared budget between cloud and on-premise.

Along with a split R&D budget, they would have to split their solution architecture. See, to combat the downsides of a split R&D budget, enterprise software vendors will usually revert to retrofitting their on-premise software to a multi-tenant service. The consequences of this are nuanced. Each vendor's stack will have varying levels of tolerance to this kind of tinkering. At any rate, roadmaps do begin to diverge between the on-premise solution and the software as a service (SaaS) solution. As time goes by this gap widens leaving Goliath with another problem. How to get on-premise clients to the cloud version... yet another R&D expenditure.

The support problems related to a split solution architecture combined with the pace of SaaS sales cycles, inevitably creates a division within the Support team. The cloud support group now splits up the support budget as well, so instead of supporting one platform, the software vendor is forced to fund two. Thus customer support issues begin to arise.

This tangled web of problems has me usually asking whether the solution is born in the cloud or not. And the answer to that question REALLY matters. If you're looking for a new solution and you're taking your company to the cloud, you need to weigh the baggage your cloud vendor is bringing along. Are they starting the journey? If so, you might be in for a long bumpy ride. It doesn't mean your vendor isn't capable of the task, but don't assume that throwing the cloud buzzword around will translate to actual capacity to support the benefits of a cloud architecture. Know up front that if they're in the cloud as the result of a legacy transition, they have a sharded organization. What the legacy vendor does have on their side is breadth, so take your time to determine if that br eadth is legitimately part of their cloud solution. I wish I could say that software vendors were open about what is included in their cloud platform vs their on premise platform, but this is all part of the sales dance.

If you're starting with a clean slate on a solution purchase. Then born in the cloud is significant. You don't want to start a multi-year effort carrying the costs of the vendors tangled legacy. Consider the fact that a born in the cloud vendor, will have a single Architecture, Support, R&D, and Sales team which your dollars are supporting. If you choose to work with a legacy vendor make sure your vendor has made the transition, so your dollars are well allocated and you stay competitive.

Intricity often helps it’s customers evaluate the right fit for a variety of cloud vendor solutions. If you would like to see how Intricity approaches such an engagement click here, and as always you can reach out to Intricity to talk with a specialist.

Related Post

What is a Partition?

Understanding the concept of database partitioning can be significantly illuminated by the historical context of hard drive defragmentation.

Learn More

The Narrow Case for Data-to-Information Company Acquisitions

The rumors about Salesforce acquiring Informatica bring up some interesting observations from past acquisitions of this nature.

Learn More

CI/CD for Data Projects

Despite its prevalence in software development, CI/CD is less common in data projects due to differences in pace and cultural perception. Discover the importance of implementing CI/CD in...

Learn More