Introduction
As the cloud discussion rages on — private vs. public clouds; on-premise vs. on-demand — there seems to be a bit of an outstanding debate about cloud economics.
In a series of articles, we will consider the range of issues for developers and end-users, and examine whether this is really a ‘deal’ for the end-user, as many propose.
Cost drivers
We have looked at a variety of application spaces such as Cloud Services, Enterprise Resource Planning, Business Intelligence, Warehouse Management, Trace and Track and various Demand chain applications, and have consolidated some of our learning on these.
In Figure One, we can see some of the cost drivers for both the developer and the customer. Development costs, which represent from 10% to 30% of the budget, are superseded by sales and marketing, which can be as high as 50% of costs.Most analysts spend a lot of time looking at development costs as a percent of the total revenue, since it represents some type of expectation (or not) of continued investment and improvement in the product. But as any software person knows, once you start releasing products, and those new revs start coming out, the investment is diffused over multiple code bases and releases. And firms that have made many acquisitions spend most of their funds on blending and integrating these products versus forging ahead with innovative development.
On the user side, two key issues drive costs. First are the upfront expenses of software, service and hardware. Many software firms not only get paid before the clients goes live, but ironically, some firms expect to start charging the 16% to 20% annual support even before clients go live!Users are feeling a bit ‘abused’ by such practices. Users also need to allocate or hire new staff to learn and support these new applications. Depending on the scale of the solution, this can be a large investment.
Sharing is good for you —
As our mothers often told us, sharing does not diminish us, it benefits us. SaaS is just one of those situations. SaaS pools many of the efforts generally done by the software firm or the end-user. Of course, the single code base is the most visible. But equally important is the connectivity and integration. Often, hundreds of integration points between software modules or trading partners — customers, carriers, service providers, and other SaaS applications — must be created. Each customer can do this for themselves, redoing the same work over thousands of companies, or they can pool this work and have all those pre-built connections as part of what they get for being a customer of the SaaS provider. Prego! (Of Course!)
It’s the same situation with the hardware. Using a SaaS vendor, the cloud hardware service takes care of many customers, with pooled expertise on the operations and maintenance of this environment, vs. each company purchasing their own hardware and hiring their own support staff.
The single code base simplifies the work of the software firm in development and maintenance.
These key cost drivers are removed for the software firm, and can be passed on to the customer. There is some discussion on whether end-users are actually deriving the value of this advantage, though. Deals vary. A rule of thumb is that over a five year period, you will wind up paying the same amount as the license fee, i.e. a million dollar software deal would cost about 15k a month. But, we actually haven’t seen this in practice. The monthly service charge usually starts out quite a bit less, and often users buy various services that upgrade them. Now we are comparing apples and pears (software and consulting).
Then after a few years, what happens next depends on the firm you deal with.1 Some IT execs seem to feel that they just keep paying and that is a bad thing, or that they could have ‘owned’ the software by then vs. having to continue to pay. But they are missing the Total Cost of Ownership (TCO) discussion that needs to be put into that equation in order to really get the right number.
In other words, though the cost of the software may equal the five year fees, there is a lot more they get for that fee than just the software. Other issues and costs are actually more critical:
- In the license deal, many firms are paying for more seats and more modules than they ultimately use.
- Buying more than you need drives up not only the original cost of the software, but also the maintenance cost which is calculated on the original sale — not on which modules you actually wind up using.
- The TCO model needs to be looked at in depth — not just the maintenance cost but all the hardware, consulting, and support costs.
- The cost of your own time.
- The cash flow/working capital and cost of cash.
When this TCO is examined in full, maybe the deal looks different.
But, my question, though, is: Who wants to own five year-old software products?
So much has changed in the last five years, and we can expect many cool things to become part of the tech landscape in the next five years. In five years, you would be on ‘old stuff’ if you owned it (as many users find themselves.) In fairness to most organizations, it costs a lot to make changes — in cash and time commitments — so many organizations do not want to upgrade. But what if you could take advantage of innovation sooner, incrementally as it is released, and avoid the big upgrade? You would be evolving in step with change, not trying to catch up later.
Business Flexibility and Change ─ Another way to look at things…
Another aspect of this whole discussion is the ability of the business to respond to change, to keep improving, absorbing new ideas, new customers, new partners, and ultimately, therefore, new enabling technologies to empower all that change. If you look at how many changes we have gone through in the last decade both in business practices and technology, you will see that most businesses have not been able to keep up with technology change. This problem hampers productivity and competitive position in the market.
If I ‘own’ the software, I have to keep buying into new architecture, ripping out old code and putting in new, dealing with new integrations — cross team, cross trading partners, from software module to module, to web, to mobile device, etc.
On the other hand, SaaS vendors have the capability to keep plugging in the new tools, the additional connections, etc. and making them available for all their customers. If you were a customer of a perpetual improvement platform, you would just absorb those changes. Or at least they would be available to you and your ‘vested interest’ in sticking with the old technology would be gone.
It seems that flexibility and agility enablement are some of the items not fully considered in the SaaS/On-demand vs. On-premise discussion. Agility is the ability to access and absorb change easily and rapidly. Accessing change is having those opportunities (technology tools) available.And absorbing change is influenced by how well you can handle the inhibitors or obstacles. Legacy code that has to be replaced, investment in hardware that you are depreciating, and support staff who have to be trained on the old tools, become obstacles to change; whereas a low tech footprint, and a staff that has been incrementally changing as the services have evolved, I think, represents a much lower inhibition threshold. With low upfront investment and low ‘change factors,’ adoption is easier, and speed to benefit increases for the end-user.
One more point we need to make about access to technology in the cloud: as we have discussed in previous articles (see Cloud Series ), it is the use of a single code base that radically changes the development challenges and costs for the tech firm.This is important in terms of focus, cost of support, and time to market. I have been spending quite a bit of time hanging out with SaaS/On-Demand players in the last few years, but especially lately. There are some interesting practices and culture in this single code based universe. If you think about this a bit, you realize that the single code base crowd has the innovation acceleration advantage.Their developers actually yield higher output per dollar because the whole development team is sharing architecture concepts, tools, and knowledge based on the tool sets and frameworks they developed — and only those. So that messy gravity of dealing with additional platforms is not part of their day. You don’t see the torn jean troupes sitting around scratching their heads at theirs or their customers’ tools or software or environments that they might not be too familiar with.
I think this is the biggest genius in the whole game of On-Demand — the innovation acceleration advantage — which customers can be a part of, too. Plex recently told us about their socially networked user community that assists each other, but more importantly engages directly with Plex on enhancements that can materialize into the solution extremely quickly. There are no other user groups competing for developers’ time — the A&D users group vs. the CPG users group, etc.
I see this focus being passed on to customers. SaaS vendors are not alone in that, though. And I wish that more buyers could appreciate this value.Many of our domain experts in the Supply Chain space, who intensely live within that domain — Demand, Warehouse, Global Trade Management/Transportation, etc., live and breathe their work and their world, and can move with the speed to provide customers the needed leap forward.
We like NetSuite, Plex and Epicor, to name a few in the ERP space, because they have a pretty happy customer base that has a lot of benefits for a modest investment. I wish this stuff was around during my ERP buying days!
Customers are going to decide upon the economics of the deal as well as the completeness of the solution in meeting their needs.2 Although these other issues may seem like intangibles, they are not, when you are implementing and then living with the solution, over time.
In subsequent articles in this series, we will look at issues such as sales activities expense, consulting and alternatives to services, the marketing ‘experience of on-demand,’ and other topics related to cloud economics.
_________________________
See also Cloud Economics Part 2 – The End of the Entourage and Cloud Economics Part 3 – The Cloud of Clouds.
_________________________________________
To view other articles from this issue of the brief, click here.