Inside Enterprise Software and Cloud Computing (CXOTalk #286)

Inside Enterprise Software and Cloud Computing (CXOTalk #286)


Enterprise software, it is a big, big topic. Everybody seems to want to be an enterprise
software company and, certainly, if you work in an organization of any size at all, somebody
is spending a lot of money on enterprise software. Today, on Episode #286 of CxOTalk, we are
exploring the inner secret, secret secrets of enterprise software. By George, we have got two people who are
qualified to talk about, and they will even share, those secrets. Now, before I introduce them, I need to ask
you a favor, which is, right now, tell a friend to watch this show and be sure to subscribe
on YouTube; subscribe on YouTube. As we talk, there is a tweet chat taking place
right now on Twitter using the hashtag #CxOTalk. Let me introduce our first esteemed enterprise
software insider. He is Dave Kellogg, who is the CEO of Host
Analytics. He is a very, very experienced enterprise
software CEO. Dave Kellogg, how are you? This is your first time here. Thanks for being here. Hi. I’m great. Thanks for having me today. Dave, please tell us about Host Analytics. You’re the CEO, and so what do you do there? [Laughter]
A lot of people wonder that. No. [Laughter] I’m CEO of Host Analytics. We make cloud-based enterprise performance
management software. In plain English, that means we make software
for financial planning, budgeting, consolidation, reporting, and we sell to the office of the
CFO. Fantastic. You’ve been CEO of quite a number of software
companies, so very briefly just describe your background for us. Sure. The quick background, I started out in relational
databases in the ’80s, did object databases in the early ’90s, spent tens years with business
objects in the mid ’90s to early 2000s where I ran marketing, ran a database company called
MarkLogic–an XML database company–for about six years, did a year at Salesforce where
I ran customer service apps, and I’ve been here at Host for five years. Okay, great. David Dobrin is our second esteemed guest. He’s been an enterprise analyst for many years. David, like Dave Kellogg and myself, are members
of the Enterprise Irregulars Group. Dave Dobrin, how are you? I’m so thrilled that you’re here today. It’s a beautiful day, and it’s even better
being on this show. Thank you so much, Michael. Dave Dobrin, tell us also about your background
and the things you’re focused on. Well, I came to enterprise software in 1990,
working for an ERP company called QAD. I got to know that product pretty well, so
I went over to the analyst side and mostly evaluated ERP firms. Since then, I’ve simply been an analyst and
evaluated software, and I pretty much tried to keep up with whatever was hot, so I would
evaluate CRM systems when they came in and so on and so forth. Then I’ve gone back and worked for the software
companies as well. I have a fairly broad background in those
things. I’d say ERP and supply chain are maybe the
most important of those, but plenty of things. You’ve seen it both from the industry analyst
side and, of course, from the inside as well, inside the software vendor perspective. Yes, absolutely. Great. Now, I think, to begin our conversation, let
me turn back to Dave Kellogg. Dave, when we talk about enterprise software,
tell us what are we actually referring to? What do we mean? Sure. When I think of enterprise software, to keep
it simple, it’s software sold to businesses to run businesses, and that differentiates
it from consumer software, which is kind of built for people as individuals, not for people
working in corporations. When I break down the enterprise software
market, I always think of four primary buckets. I think of data and data storage, so database
related technology as kind of the foundation. I think of middleware as the next layer that
kind of ties everything together, again broadly defined. On top of that, I think of applications, whether
it be CRM, ERP, or EPM. On top of that, I would say analytics, a layer
of tools that helps you gather insight from all the stuff below. That’s how I think about enterprise software. Now, enterprise software, I think, is really
hard for people to understand. Part of that is because it’s like this enterprise
soup of alphabet and acronyms. Maybe, Dave Dobrin, can you kind of navigate,
explain just a little bit how the pieces fit together so somebody who is a buyer, who is
a user of enterprise software and not a developer, will kind of get it? Well, that’s a very interesting question. The answer is mostly that they don’t fit together. Corporations are very large entities. They have large numbers of departments, and
everybody wants software that serves them. If you’re in HR, you want HR software. If you’re in sales, you want sales software,
and so on and so forth. The simplest way of dividing up the alphabet
soup is to ignore the alphabet soup and think about which parts of the company are served
and say, “Okay, this is software for these guys.” That’s the simple way of thinking about it. Basically, look at it from the point of view
of some particular part of the business and just focus there. Absolutely. Even focusing there, you might have 10, 15,
or 20 different applications that are routinely used by some parts of that organization starting
with Excel, of course. One of the things that people don’t seem to
realize about enterprise software is that a medium size corporation will be running
700, 800 pieces of software, maybe more. I’ve seen as much as 3,000 or 4,000, so far
more pieces of software than there are even people in IT, which is pretty frightening. Thus, the amount of money that’s actually
spent on enterprise software. Yeah, because every enterprise software wants
at least $100 a month. Well, if your organization has 25 products,
that’s kind of a lot of money being spent on $100 a month per person. That’s a very significant portion of your
salary that’s going for software that’s supposedly supporting [you]. Dave Kellogg, you work for a software company,
and so maybe you have thoughts on this economic aspect that David Dobrin was just describing. Sure, I hear you. First, yeah, there’s no question to the acronym
soup problem. I think, for many years, the success formula
in enterprise software was to create a new category. Right. That’s kind of what proliferated to all these
categories, subcategories, and subcategories of subcategories. It made things very confusing. I do think I like David’s idea to look at
it more holistically and from the buyer’s viewpoint. In terms of the economics of it, most of the
software out there can prove a good ROI because it helps automate. Put it this way: If you can’t demonstrate
an ROI today, I think it’s pretty hard to sell enterprise software. I don’t think that was true 20 years ago. [Laughter] I think people bought more on faith,
return on information, and information for competitive advantage. But, I don’t know. I feel like the leap of faith days are beyond
us. I don’t know if Dave agrees or disagrees. I’m somewhat more doubtful, I must say. Michael has been very influential for me in
this. He has quoted numbers like 50% of enterprise
software sales fail. Really, if we’re talking about expectation
and not about actual return if everything works the way it’s supposed to, really, your
cost is twice what you’re calculating your ROI on. A lot of ROI numbers go away if you include
expectation. Also, ROI numbers tend to be demonstrated
before, not after. You can ask Dave Kellogg. What do you have in your software that proves
the ROI that you’re claiming that you have that monitors it over time? Probably not too much – not much demand for
it. What I’m going to say on this, first, I think
the cloud has changed a lot of what you said because there was the pre-cloud era where
you would sell these giant deals, and the vendor didn’t really care if the software
got used. We had shelfware. You can call me an idealist, but I think the
cloud and the need to renew the customer means that the vendor actually cares. A smart vendor actually cares, “Is the software
being used? Is it demonstrating value?” because once a
year it’s going to be up for a vote. To me, the fact that people renew is indicative
of the fact that they continue to get value for the software. I’d also deployment failures. Again, ERP, the massive deployments of the
’90s and early 2000s, those were extremely high-risk propositions. I think cloud has kind of turned what used
to be a heart transplant into knee surgery in terms of the degree of difficulty. Well, knee surgery has only about a 50% success
rate. There you go, so we agree. So, I wouldn’t use that if I were you. [Laughter]
[Laughter] I think you make good points, but I can hear
the software vendor in you. [Laughter]
I don’t really know about whether cloud deployments are more successful. Certainly, most cloud software is smaller,
which means they do last. Well, okay, and that certainly increases the
expectation that they’ll work, but it decreases the ROI. Hang on. Unless you buy the proposition that I do,
which is that, in the on-prem era, you bought a lot of functionality you didn’t need. To me, the basic cloud value prop is kind
of 80% of the functionality and 20% of the total cost. Bear in mind I’m not only a seller of software;
I’m a user of it. I actually bought Salesforce and Business
Objects in the early 2000s as a cloud buyer because the IT department wasn’t serving me
because marketing was kind of third in line or fifth in line on the IT stack. I don’t know. I think the cloud has made a lot of this stuff
better. I couldn’t agree more, and I sure as heck
hope it’s made things a lot better. [Laughter] The question is, what’s the ROI? I think it was unacceptably low in 1998. In fact, at my analyst firm, we did a study,
which demonstrated conclusively that it was unacceptably low. Of course, we suppressed it since no one wanted
to hear that. [Laughter]
[Laughter] But, the question is, is it acceptably high
enough now? That’s where I think the discussion is. The answer is probably that neither of us
has the data very much, but 100% it’s absolutely improved with the cloud. I guess the question is, when you’re looking
at ROI, software is a tool and it’s very difficult to disassociate the software product from
the business, the company, the process into which that software is embedded. And so, when you talk about measuring the
ROI of a software purchase, how do you do that? Wouldn’t you have to disassociate the software
from the context? I think it’s extraordinarily difficult and
one of the reasons why I express some doubt to David. I think you can claim lots of ROI. That’s why I’m asking him, how can we show
the ROI? It’s really hard. Yeah. The way that I recommend customers do this
is, rather than try and get an ROI number or an IRR number to say how much capital went
in and how much cash came back, to try and get concrete business objectives. It used to take us 20 days to close the books. We’d like to close the books in ten. It used to take us six months to run the budgeting
process. We’d like to run it in three. We used to be able to update the budget, in
my world, once a year. Now we want to update it 12 times a year. If a company places objectives and says, “These
are the things we want to do,” and the software helps them achieve those objectives, that’s
the way I’d look at it. Technically speaking, to get a real ROI number,
I’ve been a part of studies that do that but, boy, is it hard. Oh, yeah. Dave, I agree. But then, it’s not fair for you to say, “Well,
the ROI has improved.” I mean that is the correct way of doing it. Everyone should listen to you when you say
that. You have objectives. The software will enable the objectives. It’s a step change in something important
that you’re doing in the company. That’s a reason to buy software. But, don’t try to value it. It’s going to be really hard. And, recognize that the failure rate is high
on any strategic objective, not necessarily because of the software, and that the overall
cost is high. Many of the things that software companies
claim to be proof that they’re really okay about all this are renewal rates. Well, go think about your own renewal rates
on things. How many charges do you have today on your
credit card that are renewals of things you don’t really want or need, but you don’t have
the momentum to do it or too much chance to change? When was the last time you changed your bank
account despite the horrible service you’re getting from your bank? The fact that you renew is merely an indication
of minimum acceptable performance. It’s not an indication that you’ve achieved
the strategic goals that you set out for yourself. Can I just jump in here for a second? At the end of the day, isn’t the thing that
matters what Dave Kellogg was just saying, which is, okay, great, it’d be nice to prove
a theoretical ROI. But, if you’re buying accounting software,
isn’t the thing that matters is how fast can you close your books? Well, the thing that matters with accounting
software is, how well can you run your company with the information you have? To weigh on this one too, David, look; there
are people who say ROI, and they mean IRR. Right. Internal rate of return, what number. There are just people who speak about it more
broadly. I was kind of speaking of it more broadly. I’m not a big fan of the study that gets the
single number. I am a fan of getting measurable business
objectives. The thing I’d challenge you on, though, you’re
on the borderline of saying that companies are irrational, that they’re irrationally
renewing this software that doesn’t provide value. I think you’re right; there are times where
you want to move but you weren’t ready. I do believe there’s a loose coupling between
renewal and satisfaction. I don’t think software vendors should measure
satisfaction by renewal rates, right? Right. Because sometimes unhappy customers renew. Sometimes happy customers don’t renew. That was my input. I think, if you look at a pattern over time,
I mean they’re not going to keep renewing forever. Eventually, you do cancel that gym membership
you never used, don’t you? I totally agree. Dave, when you’re being reasonable, of course,
I agree with everything you say, as I always have. It’s when you start just doing the software
kneejerk reaction of, oh, look at the ROI; oh, look at the renewal rates. Sure. Great. But, you and I both know that it’s more complicated
than that. Yes, absolutely 100% they do eventually give
up on the software. No question. But, I’d say, just as often, they get sold,
they fail, they do lots of other things. Renewal rates are very high and the reasons
for nonrenewal very rarely include dissatisfaction. Who was the guy back in the ’80s or ’90s that
kept saying you could see software everywhere but in the productivity statistics? Do you remember that guy? Yeah, though now that’s changed. There’s a difference between being sensible–
Yeah. –and, therefore, reacting to un-sensible
things that are being said about software. I wouldn’t be in this business if I didn’t
enjoy software and I didn’t see a lot of potential for it. The reason I went back and worked for a software
company is, I wanted them to do more. I’m a little disappointed at how little software
does and how little people demand of it. They could get a lot more, and they could
do a lot more. I feel like I’m an advocate for that. But, I’m not trying to say there’s no productivity. The economists are pretty universally sure
that there is some productivity. However, it’s in a long discussion. Michael wouldn’t want me to get into it. Measurements of productivity don’t necessarily
work in a way that allows you to estimate software effectiveness. Let’s try a slightly different tack here. We were talking about cloud. Clearly, cloud is one of the great innovations
in enterprise software. And so, as you both look across the enterprise
software landscape, where do you see innovation? Historically, enterprise software has had
this reputation for being hard to implement, ugly to see, [and] difficult to use. Where is innovation happening right now with
enterprise software? What’s fascinating? I’m disappointed at innovation right now. I think that a lot of people are pretty much
sunsetting any innovative work on their original products, mostly because the technical debt
is so great on them that it’s not possible to pay them off. Yet, no one wants to start up a new ERP company. That would be too horrible for words. They’re kind of in a holding action. Also, some of the obvious things that happened
over the last ten years, like inventing a new category, don’t work anymore, so that
doesn’t work. For me, the real interest is in data. You have all this data, and no one does anything
with it. The people who seem to know what to do with
it are data scientists, and they’re horrible to talk to. Then everybody else just makes things up,
so far as I can tell. It’s like this small clan of people that know
everything and can’t communicate. Ditto with machine learning. I am spending a lot of time looking at both
of those areas but trying to fend off the same kind of thoughtlessness and lack of perspicacity
into what’s real about them that I certainly ran into with ERP in 1996. I think I’m a bit more sanguine here. First, I’m a big believer in the cloud, partly
because I started as a buyer of cloud software, as I mentioned earlier. I know exactly what it feels like. Literally, I was told by my IT department,
“You can have lead management in Italy in four years.” [Laughter]
I’m like, that’s great. Tell the next CMO that [laughter] because
they’re going to come fire me because I’m not managing leads in Italy. I’ve got to find somebody to help me manage
leads in Italy, and that’s how we ended up buying Salesforce was actually for lead management. That was my first introduction of the cloud
as a buyer. The cloud, I mean I think it’s easy to forget
how much time we used to spend buying servers, installing databases, worrying about rack
space, and even just rolling out to individual computers. Enterprise software in the ’90s, that was
really drudgery, right? Right. [Laughter] I don’t forget the pain. We still even have customers today who will
pay $25,000 for a study on how to do an upgrade from version 11.1.2.1 to 11.1.3.1, and that
upgrade will cost $150,000. The business value of that is, like, zero. Right. I don’t want to forget how much the cloud
has done for us in terms of, in some ways, letting us worry about other things. We don’t have to think about that anymore. Absolutely. Yeah. I totally agree, David. Frankly, to me, the thought that you would
ever buy anything that isn’t cloud-based, there better be some damn good reason for
it. The cloud offers obvious advantages. As far as I’m concerned, the world has just
moved there and, therefore, when Michael is asking about innovation, I don’t think of
cloud as an innovation anymore. It’s just the standard. Yeah, it’s all about timeframe to me. I don’t think it’s a recent innovation, but
I think enterprise software moves somewhat glacially. Last time I looked at the numbers, even salesforce
automation was still 50% on-prem, maybe 40% on-prem. To think about that, Salesforce was founded
18 years ago, and the market is still half on-prem, half cloud, that’s why I still think
of cloud as kind of both the past and the future because a lot of people haven’t gotten
there yet. Fair enough, Dave. Yeah. Absolutely, 100%. One other one I think is innovation, which
we’ll see how you weigh in on this one, is I remember when I went to college. There have always been great algorithms, but
we never had the data to run them against. I feel like, in the last five, ten years,
we actually have created– A lot of data. Yeah, we have data that we can go analyze. That’s where the innovation is. Yeah. That’s where the innovation is. It’s in the data. When I talk with CIOs and CMOs, the really
smart ones — I mean, they’re all really smart, but really the ones who stand out — they
are talking about, okay, how do we use data? How do we understand our business? How do we figure out; how do we use the data
that we’re collecting that we have of which 70% of it is lying fallow in our systems without
benefiting us? That’s where the magic is. I agree. That’s where the magic is, but it’s really
hard. It’s very hard to wrangle data. Every step of data management is as poorly
served today as enterprise software was by COBOL. I’m sorry if Dave is going to wince again
because I’m exaggerating. [Laughter]
[Laughter] Every bit of data analysis is just super hard
and for no particular reason. Two thoughts on that: One, I’ve always said
the next generation will see SQL the way we see COBOL. Yeah. I don’t think that raises eyebrows anymore. It used to. Yeah. A slightly different tack on data, but one
of the more interesting conversations I had with a data scientist the other day, she was
actually trying to pick a new job. Normally, when somebody is trying to pick
a place to work, I think about the company. I’m like, “Well, tell me about the companies. Who are the investors?” Of course, she was basing her selection on
the data set. Right. To her, it was all about what data will I
have that I’ll be able to analyze. It’s an interesting way to look at it. I was working on a bunch of innovation projects
for a software company that shall not be named. We were looking at what you could do with
ultra-fast databases. I talked to a guy who lives around the corner
from me. He teaches in the business school. He had come up with a very, very interesting
study of retail operations. I looked at the study. I said, “Well, geez, what could we do with
it?” and so on. It turns out that 98% of the time that he
spent on that study was on data wrangling. It was on getting the data, massaging it,
making sure it was okay, and so on and so forth. Then he runs data and, boom, he has the answer,
and it’s brilliant. Serve that. That’s what you need. Yeah. To me, we’ve gone from — I’m going to get
the soundbite wrong — a famine to excess. We have too much, right? There are too many data sources. I remember when I worked at Salesforce, I’d
go to meetings. We were in kind of Tableau hell because everybody
had absolutely beautiful charts, but they were all from different data sources, and
nothing actually compared. Right. It was impossible to analyze. I do think that’s a big problem. I do think companies are working on solving
that problem. I’m on the board of one company. I won’t mention the name. They’re trying to learn machine learning to
look at where other people found answers and then kind of follow the crowd at lunchtime
if you don’t know where the canteen is. I think it’s an interesting approach because
I do think what hasn’t worked is a single catalog, a single metadata model, [and] a
single data warehouse. We’ve died on that hill way too many times. No, it’s nonsense. Why should it work? The directions here are in more real-time
data analysis. If you have the same data and you can do it
faster, that helps. The other is to have data sets–or people
call them data lakes or whatever–that enable you to wrangle the correct data for the question
that you’re asking and ask that question in a way that allows you to get a reasonable
and true answer in a reasonable amount of time. Right now, it’s basically just not possible. I can tell you story after story about that. Let’s shift gears slightly. There’s a question from Twitter. Zachary Jeans makes a comment, an interesting
comment. He says, “Simon Sinek don’t buy what you do. They buy why you do it, and that proves what
you believe.” His question is, “Does this hold true for
enterprise software purchases?” I’ll broaden that and extend it to say, do
enterprise software companies have a soul? Put it this way. I think they’re born with a soul. I think, when they’re startups, they clearly
have a soul because somebody started the company for a reason. That reason is typically that they’re looking
at how people solve the problem and said, “I know a better way to solve it.” The vast majority of enterprise software companies
I know are started in that way. I think they’re born with a soul. I like the soundbite that they buy why you
do it. I like it because it means there’s an underlying
purpose. I’ll just speak for myself in my current job. I’m a huge fan of planning. I think companies don’t plan much about the
future as much as they should. I don’t think they plan very well. What’s the Eisenhower quote? Planning is indispensable. I’m going to mix it up. I’ll come back to it in a minute. There are lots of quotes on planning, but
no plan ever survives the first shot of battle, which is the need for continuous planning. At least, personally, I’ve always felt a mission
about what I do. I think most enterprise software entrepreneurs
do as well because it’s too much work, frankly, if you don’t have an underlying purpose. Well, I think part of his question really
gets to the heart of the matter, which is really the integrity of the companies that
you’re dealing with. If you don’t deal with a company that has
integrity, you shouldn’t deal with them. I set a pretty high standard for integrity. I think that why you do it, at least when
you say why you’re doing it, it should have some relation to the truth. That’s the first thing with buying enterprise
software. The second is why you do it with a large enterprise
software company often has very little do with what’s actually being done. People in marketing, people in sales, people
even in executive management have very little idea of what’s being built, why it’s being
built, or how it’s being built. You have to factor that into account as well. If I could weigh back on that one, first,
I remembered the quote. It was, “Plans could be useless, but planning
is indispensable,” which is a quote I love. I think you make a really good point, David,
on the whole integrity thing. I actually think there are two types of startups. I think there are ones run by people kind
of HP style. They see a technical problem. They want to solve it. I think there are, actually, because you can
make a lot of money doing this, profiteers and charlatans who are maybe less driven by
a vision and just trying to slap something together, raise a lot of venture capital,
and sell it to someone else. I don’t mean to sound jaded, but at least
when I look at a startup, I can tell you which bucket I think it falls into. Yeah, and I think more buyers should make
that the first cut, honestly. They would make their lives a lot easier. Also, frankly, the integrity of a large company
is much, much harder to establish and maintain, just as the culture is harder to establish
and maintain. You have to factor that into it. This notion of profiteers and charlatans,
I like that. As far as soundbites go, I like that one a
lot. [Laughter]
[Laughter] I have to remember that one. [Laughter] I have to add that in my little
notebook of soundbites: profiteers and charlatans. Anyway, I think it gets to the heart of customer
satisfaction. Why is customer satisfaction so hard for enterprise
software companies to achieve? Maybe I should direct that to Dave Kellogg,
since you’re CEO of a software company. Right. Sure. Why is it hard? First, there’s a number of reasons. First, corporations are not people; they’re
groups of people. You have a bunch of people around the table
with different opinions. They all want different things from the software. Oftentimes they’re not really in agreement,
either on how processes should work if you’re trying to automate process, or on what the
goals of the project are. One of the real complexifying factors in enterprise
software is knowing how to work with and understand enterprises, and that’s a big part of it. I think customer satisfaction is also hard
because people change jobs. You may start a project with one CFO and,
two years in, there’s a new CFO and he or she has a totally different set of objectives,
so you’re kind of shooting at a moving target. One of the funnier metrics I look at is kind
of the lifetime of the software versus the lifetime of the executive who buys it. [Laughter] What’s the mean lifetime of a CIO? It’s like three years. Some of these systems last ten. Twenty. You’re going to go through — yep. Yep, or 20. Yeah, to your point. I think the other thing that’s hard about
customer satisfaction is these are hard problems. They are sometimes quite mundane problems. ERP, to me, is a relatively mundane field,
but it’s very important and it’s very hard. I think those things contribute to making
customer satisfaction difficult. Dave Dobrin, from your perspective, you’re
looking at many different software companies. What are the attributes of software companies
who are able to achieve high customer satisfaction and overcome some of the challenges that Dave
Kellogg was just describing? High customer satisfaction, I think, is a
very rare commodity for all the reasons that Dave said. I think there are companies that somehow are
moved to becoming the standard at which Salesforce is perhaps the most obvious example. There, it’s a combination of a better technical
idea, utterly brilliant marketing, [and] very, very good management of the company. I could go on and on, expect that all my Salesforce
friends would be embarrassed, only they can’t be because they work for Salesforce. I think that the biggest single reasonable
reason for lack of customer satisfaction is underbuilt software. Dave is right. It’s really hard to build software correctly,
but it’s also really easy to be lazy about it. I always make jokes about the software guy
who went home at 5:00 on Friday, and that’s why the software works that way. If you’ve ever actually worked with a software
company, you know that’s pretty much the truth. Less of that and more feedback from the customer,
more understanding of what’s actually going on in the customer, all of those things could
improve customer satisfaction a lot. Why is the technology so difficult? Software companies, enterprise software companies
today have got the budgets. Many of them have the budgets to hire literally
the best and the brightest. They pay enormous amounts of money. They have the smartest people designing the
technology. When you say that the technology is not right,
what the hell are you talking about? [Laughter]
[Laughter] Well, Dave would know better than I would, but the answer is that smart people
aren’t necessarily knowledgeable people. One of my favorite biases is the Dunning-Kruger
effect where the person, the expert thinks that they know a lot more than their expertise
really allows them to make comments about. Dunning-Kruger is rife in all software companies,
especially on the development side. You get these guys, and they know what they’re
doing. Who cares what…? Ah, yes. The Duning-Kruger effect. How could I have forgotten? Dave Kellogg, how do you manage the technical
architecture, and how do you manage to avoid technical debt along the way? I’m assuming that the technical debt problem
that Dave Dobrin brought up earlier has to be one of the issues here too. Look; the only way to avoid technical debt
is to not build software, right? [Laughter] As soon as you sit down and write
code, you’re going to get a certain amount of debt in the software. I will echo David’s praises for Salesforce. One of the things I learned at Salesforce
was what they call a trust release. I think it’s one of the best ideas in enterprise
software, which is, every end releases, 3, 4, 5, the top brass would say, “We’re going
to do a trust release.” What a trust release means is all the project
managers, you go to that side of the room. We’re not going to listen to you for one release,
and the architects are going to drive the requirements for this release. If you can convince an architect that a new
feature actually retires debt, then you might get lucky and get a two-for. [Laughter] But, what’s going to drive this
release is cleanup because we know that an occupational hazard of being in the software
business is you’re always pressured for new, new, new, new, new, new, new, and you never
go clean up. That’s the way we manage it here. I think it was one of the best ideas I’ve
seen in 25 years in software. Fabulous idea. Fabulous. The whole allocation of innovation budgets
at software companies is all screwed up. It’s driven by large companies wanting to
retire technical debt that affects them. It’s driven by some marketing idea that’s
usually nonsense. It’s driven by job retention ideas that are
in development. The amount of money actually spent properly
is not great. I think Dave’s mechanism for getting a little
bit more of the money to be spent properly, whatever that means, is a really good one. We’ve only got a few minutes left. This time has been flying by. I think we need to talk about maintenance
and support. Maybe, Dave Dobrin, you can just set the frame
for us. We’re going to have to do this pretty quickly
because we’re going to run out of time. Okay. Right now, in any large company, maintenance
and support is supporting the company. You pay a dollar in support. Any large software company–I’m sorry for
interrupting–just to be clear. Any large company, 80% of their revenue is
coming from maintenance and support right now, maybe more. That means that every dollar you spend, what
they spend 50% SG&A, a dollar of your maintenance is going to their SG&A. Forty cents is going to SG&A. Thirty cents is going to this. Twenty cents is going to that. Almost none of the money that you’re spending
on maintenance, cloud or on premise, is really going for maintenance. What are you getting for it? Insurance, sort of. I think the first thing is to be realistic
about that. Dave Kellogg, any thoughts on this maintenance
and support issue? Sure. Look; from the vendor perspective, it’s all
about switching costs. It actually took the software industry quite
some time. In my opinion, I credit Ray Lane at Oracle
for being the first guy to go, “Hey, wait a minute. This 22% annuity is worth something.” Just prior to that, it was really viewed as
kind of a scrapheap. People would throw the contracts in the heap,
and you’d literally have customers not paying their support, getting support from the call
center. I think they discovered that there was a lot
of value in the annuity, and they try and drive that up. Obviously, David’s point is taken to heart. The way I try to solve that problem, my advice
to buyers is, find out what the company’s strategy is because he’s right. The average software company spends maybe
20%, 25% of revenue on R&D – maybe – sometimes 15%, once in a while 40%. But, it’s not a huge chunk of revenue. If you know where they’re going, that’s what
they’re going to be investing in. A lot of times, companies are not going to
place where the customer is because there’s a lot of bright, shiny objects where they’re
chasing some vision. They’re going to be investing in something
that you don’t really care about. It doesn’t solve the problem entirely, but
at least trying to get a real strategy statement and understanding what their typical customer
looks like because all vendors are pulled by their customers, if you look at those two
things, it’s going to help you figure out where the R&D money really goes. Yeah. The other thing to do is to develop an exit
strategy. [Laughter]
You assume that after a while it’s going to fit you less and less well. Figure out what you’re going to do with that
money and try to do something else. Don’t plan on using it forever. But, of course, that’s sort of like saying
[laughter], “Eat less fat and get drunk less often.” No one is going to listen when you say that. Advice for buyers then is to look at where
the software vendor is investing their R&D in order to figure out, are those investments
really going to be beneficial for, useful for, my business? Yeah, that’s my advice. Look; a lot of software vendors, particularly
the earlier stage ones, their current product is step-one in a broader vision. If you buy into that broader vision, great,
because that’s where the money is going to be spent. But, if you don’t, if you’re like, “No, I
actually just really like what you do. I don’t see what you do as a stepping stone
to five other things like maybe your investors do,” I’d worry that the money you’re giving
them is not going to be spent on enhancing the core product you bought. I’ll pick a concrete example. If you look at Zendesk, I think they’ve done
a good job staying focused on support. There’s an argument they could go focus on
a bunch of other industries, but they haven’t done that. If you’re a customer, I think they’re reinvesting
the money you’re giving them in better support. But, this is from the point of view of a CIO
or an IT department, for example, that’s buying enterprise software. What a pain in the butt you’ve just described
because it means that instead of simply evaluating the software, I need to evaluate the company
and the trajectory of the company. I just want to buy software. I’m not investing in their business. I’m not a VC, so what can I do? My belief is, CIOs today, they’re savvy. They evaluate companies too. I think, Michael, they’ve been doing it for
a long time. I know lots and lots of smart CIOs that they
know they’re not just buying a piece of software. You don’t buy enterprise software; you inject
it into your bloodstream. [Laughter] I want to know what I’m buying,
and I want to understand the company. I think there were some other strategies that
you could use, long-term. One is to team up honestly with all of your
competition in your industry and share information about the software, although that, I’m sure,
violates some contract that you have with one of the vendors. As a group, you have more power and, very
often, if you ask for something that all of you want, you’re more likely to get it. Also, you’re likely to make fewer mistakes
at the beginning because, if other people have had experience with these things, you
can help fix it. That would be one thing that you could do. Okay. As we finish up, what final advice do you
have to buyers of enterprise software? Dave Kellogg, I’ll ask you because, again,
you’re CEO of a software company. Yeah. My primary advice at this point is if you
haven’t done it already, break the suite mentality of the ’90s and the early 2000s. You don’t need to buy everything from one
vendor who sells everything. It’s 2018. I think you keep all your suppliers on their
toes by working with lots of companies as opposed to one strategic vendor who you marry. You can get best of breed cloud services,
and it’s not that hard to tie them together. I would say that would be my advice. Look hard at the cloud and try to break the
mentality of suite-ism or, from a functional level, I call taking one for the team, which
is, you’re buying software you don’t want because it’s the corporate standard. I don’t think you have to do that anymore. Can I just jump in, Michael, to say he’s completely
right? The value you’re getting from the smaller,
early stage companies is so much greater than the value you get from some following, a large
company that’s developing the same software four years later and is charging you way more
for it. It overwhelms any connection costs. There’s no reason for this suite mentality
anymore. It’s dead. It’s over. Just to play devil’s advocate with you guys,
what about software companies who provide suites and the argument that they would make
is that, as far as the vendor goes, you’ve got one throat to choke. You’ve got data that’s shared across the applications. You’ve got a consistent user interface. Basically, the arguments for the suite. What’s the cliché in finance? If you owe the bank a million dollars, it’s
your problem. If you owe the bank $100 million, it’s their
problem. The same with suites. If you’ve committed strategically and you’re
in tens, hundreds of millions with a major vendor, I actually think you’ve given away
power. Whereas, if you keep yourself diversified
across vendors, I think you keep more leverage. That’s my view. I think, first of all, I could take each of
your points one-by-one but let me just take the one where it says all the data is shared,
et cetera, et cetera. Look at either of the two major enterprise
software companies. They have bought innumerable other companies,
and they don’t integrate them. Actually, all three of the majors, they don’t
integrate them. There’s a sort of pseudo pretense integration,
but it isn’t at all real, and it doesn’t do anything. I don’t know where that argument went. As far as one throat to choke is concerned,
have you ever tried to choke an ogre? You can’t even get your damn hands around
its neck. [Laughter]
Okay. On that note, “Have you ever tried to choke
an ogre?” that is another one that is going into the permanent record of my soundbites
to use in the future. Unfortunately, all good things have to come
to a close, and we’ve run out of time. What a very, very fast 45 minutes it’s been. I want to say a thank you to Dave Kellogg,
who is the CEO of Host Analytics. Dave, thanks so much. I hope you’ll come back and do this another
time. Yep. Thanks for having me. I want to say an equally heartfelt thanks
to David Dobrin, who is a long-time industry analyst in the enterprise software business. Dave Dobrin, thank you for being here, and
I hope you’ll come back again as well. You’re welcome. Thank you. It was my pleasure. Everybody, you have been watching Episode
#286 of CxOTalk. Thanks so much, everybody. Have a great day, and don’t forget to subscribe
on YouTube and tell a friend, also. Do that. Thanks a lot. Bye-bye.

2 thoughts to “Inside Enterprise Software and Cloud Computing (CXOTalk #286)”

Leave a Reply

Your email address will not be published. Required fields are marked *