Inside Enterprise Software and Cloud Computing

Michael Krigsman: 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.

David Kellogg: Hi. I'm great. Thanks for having me today.

Michael Krigsman: Dave, please tell us about Host Analytics. You're the CEO, and so what do you do there? [Laughter]

David Kellogg: 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.

Michael Krigsman: Fantastic. You've been CEO of quite a number of software companies, so very briefly just describe your background for us.

David Kellogg: 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.

Michael Krigsman: 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.

David Dobrin: It's a beautiful day, and it's even better being on this show. Thank you so much, Michael.

Michael Krigsman: Dave Dobrin, tell us also about your background and the things you're focused on.

David Dobrin: 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.

Michael Krigsman: You've seen it both from the industry analyst side and, of course, from the inside as well, inside the software vendor perspective.

David Dobrin: Yes, absolutely.

Michael Krigsman: 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?

David Kellogg: 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.

Michael Krigsman: 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?

David Dobrin: 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.

Michael Krigsman: Basically, look at it from the point of view of some particular part of the business and just focus there.

David Dobrin: 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.

Michael Krigsman: Thus, the amount of money that's actually spent on enterprise software.

David Dobrin: 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].

Michael Krigsman: Dave Kellogg, you work for a software company, and so maybe you have thoughts on this economic aspect that David Dobrin was just describing.

David Kellogg: 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.

David Dobrin: Right.

David Kellogg: 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.

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: Well, knee surgery has only about a 50% success rate.

David Kellogg: There you go, so we agree.

David Dobrin: So, I wouldn't use that if I were you. [Laughter]

David Kellogg: [Laughter]

David Dobrin: I think you make good points, but I can hear the software vendor in you.

David Kellogg: [Laughter]

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: 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]

David Kellogg: [Laughter]

David Dobrin: 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.

Michael Krigsman: 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?

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: 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?

David Dobrin: Well, the thing that matters with accounting software is, how well can you run your company with the information you have?

David Kellogg: To weigh on this one too, David, look; there are people who say ROI, and they mean IRR.

David Dobrin: Right.

David Kellogg: 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?

David Dobrin: Right.

David Kellogg: Because sometimes unhappy customers renew. Sometimes happy customers don't renew.

David Dobrin: That was my input.

David Kellogg: 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?

David Dobrin: 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.

David Kellogg: 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?

David Dobrin: Yeah, though now that's changed. There's a difference between being sensible--

David Kellogg: Yeah.

David Dobrin: --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.

Michael Krigsman: 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?

David Dobrin: 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.

David Kellogg: 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."

David Dobrin: [Laughter]

David Kellogg: 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?

David Dobrin: Right.

David Kellogg: [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.

David Dobrin: Right.

David Kellogg: 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.

David Dobrin: Absolutely.

David Kellogg: Yeah.

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: Fair enough, Dave.

David Kellogg: Yeah.

David Dobrin: Absolutely, 100%.

David Kellogg: 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--

David Dobrin: A lot of data.

David Kellogg: Yeah, we have data that we can go analyze.

David Dobrin: That's where the innovation is.

David Kellogg: Yeah.

David Dobrin: That's where the innovation is. It's in the data.

Michael Krigsman: 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.

David Dobrin: 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]

David Kellogg: [Laughter]

David Dobrin: Every bit of data analysis is just super hard and for no particular reason.

David Kellogg: Two thoughts on that: One, I've always said the next generation will see SQL the way we see COBOL.

David Dobrin: Yeah.

David Kellogg: I don't think that raises eyebrows anymore. It used to.

David Dobrin: Yeah.

David Kellogg: 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.

David Dobrin: Right.

David Kellogg: 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.

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: Right.

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: 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?

David Kellogg: 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.

David Dobrin: 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.

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: This notion of profiteers and charlatans, I like that. As far as soundbites go, I like that one a lot.

David Kellogg: [Laughter]

David Dobrin: [Laughter]

Michael Krigsman: 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.

David Dobrin: Right.

David Kellogg: 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.

David Dobrin: Twenty.

David Kellogg: 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.

Michael Krigsman: 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?

David Dobrin: 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.

Michael Krigsman: 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]

David Dobrin: [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…?

Michael Krigsman: 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.

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: 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.

David Dobrin: Okay. Right now, in any large company, maintenance and support is supporting the company. You pay a dollar in support.

Michael Krigsman: Any large software company--I'm sorry for interrupting--just to be clear.

David Dobrin: 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.

Michael Krigsman: Dave Kellogg, any thoughts on this maintenance and support issue?

David Kellogg: 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.

David Dobrin: Yeah. The other thing to do is to develop an exit strategy.

David Kellogg: [Laughter]

David Dobrin: 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.

Michael Krigsman: 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?

David Kellogg: 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.

Michael Krigsman: 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?

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: 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.

David Kellogg: 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.

David Dobrin: 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.

Michael Krigsman: 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.

David Kellogg: 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.

David Dobrin: 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]

Michael Krigsman: 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.

David Kellogg: Yep. Thanks for having me.

Michael Krigsman: 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.

David Dobrin: You're welcome. Thank you. It was my pleasure.

Michael Krigsman: 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.