–

Enterprise software

MB: Multi-packaged software has a huge issue—the combinatorics of the QA problem in the enterprise software market. The problem is that you have to support the software on every platform imaginable, and it has to connect to every version of every other package of software imaginable.

MM: And not to mention the desktop clients.

MB: Yes. The desktop clients, as well. The problem here is that the combinatorics of the testing space are just huge. Function points aside—just testing the basic 50 functions across it is difficult. You end up in a space where your cost of creating and testing and delivering that software in a robust way is really expensive. The cycle time to deliver new releases is long, and the upgrade cycles become tedious and difficult. So the quality of the software fundamentally is lacking.

MM: Let me come back to my basic proposition. If 50 or 100—it’s really a talking point whether it’s 50 or 200—but when a tenth of 1 percent of the function points deliver 95% of the value, what’s the value of a magic quadrant analyst thing that says, “Completeness of vision and ability to execute?” if all you have to execute on is 50 or 100 function points.

Isn’t the baseline by which to compare and contrast enterprise software and/or SaaS a baseline of value in tangible, tactical, strategic or transformational? And isn’t the offsetting axis—the Y-axis or counterpoint—isn’t that time to value fast, moderate or slow?

So doesn’t that form, essentially, the value proposition of software in general, and SaaS in particular, which is, “I’m going to deliver tactical value in days or a week,” and as a function of that, I can deliver strategic value in days, weeks or maybe a month. And because the SaaS—as you were talking about it—the SaaS platform you can’t drive innovation almost on a weekly basis…Thereby, you’re driving innovation into an operation or supply chain 10-, 15- or 20-times faster than these big 2- or 3-year build-outs on enterprise applications.

MB: I’d tend to agree. You get acceleration from the fact that as a SaaS vendor, you get to select a platform and stick with it, and are able to focus on adding value for your customers. And the fact that there isn’t a very difficult software deployment at the base of all your customers means that you can roll out new functional value for them in a much more straightforward and easy way. To me, the case is so compelling.

The point you made about the magic quadrant, I’d claim that in some sense, the defenders of the magic quadrant would agree, but that all rolls up into a completeness of vision.  It’s a good vision if you recognize that most of those function points aren’t needed.

–

–

50,000 function points for what?

MM: I’d like to address one issue, there, Mike. As a CTO of a SaaS company, I’m sure you’ll have some things to say about this.

When I look at an enterprise application—whether it’s a supply-chain management system or ERP system—generally most of these enterprise applications have anywhere from 20,000 to 50,000 function points in them. Would you concur?

MB: Yes. Very large and complex systems.

MM: Very robust. Okay. Then when we look at the deployment of those systems, the core user of those systems barely uses 200 of the function points.

MB: Correct.

MM: Then if you look at what 95% of the value is that most users generate from that system, it boils down to maybe 20 to 50 function points.

MB: I would agree.

MM: If you’ve got 50,000 function points and 50 are delivering 95% of the value, what do you call the other 49,950 function points?

MB: Well, some of them are legacy — right? They’re there because of the way you got to what you’re selling today.

MM: What do you call it in economic terms?

MB: Low leverage. That’s what I’d call it.

MM: I would call it, “massive overhead.” Massive costs.

MB: Yes. But I wouldn’t even blame it on the function points, interestingly enough. To me, if you have a functional aspect of your system and it’s debugged and documented and so forth, then the cost of continuing to deliver that function in a new version of your product is not that high.

MM: But you know that when you come up with a new module or a new extension of it, oftentimes that’s the source of the bug. A previously well-behaved documented debugged piece of code all of a sudden becomes the errant citizen in the new release.

MB: Well, I would say that that’s true because of the…

MM: Bad architecture?

No. Not necessarily even because of bad architecture. One of the reasons I work in a SaaS company is because I could no longer see a need for multi-platform packaged software any more.

MM: Exactly.

–

–

Webification of BI

MM: Then in history of business intelligence, the Web came along—and some things began to change. Could you quickly reprise us in terms of what changed how as a function of the Web, in the space of business intelligence?

MB: The Web changes everything. The Web changes some things directly and some things indirectly. One of the interesting forces in the database world and the data processing world is that the Web introduced a whole new realm of data to be handled.

The whole world of e-commerce introduced a need to understand e-commerce marketing, and to understand click-streams and how people were using the Internet and so forth. That created a number of new opportunities for people to try to process and understand the wealth of data, and to understand the customer behavior.

The companies that successfully handled Internet advertising have become the masters of this—Google and so forth. That’s the way that the Internet raised the stakes on this kind of marketing.

There’s also the absolutely direct benefit that the Web introduced—a new way to get information to people—in a way that is really much more appealing.

You’re able to get rid of many of the hassles and costs associated with software installation, if you can just give people a website to visit to get the information they’re looking for. People really like this model. It has all of the graphical capabilities that they’ve become accustomed to with their Office and installed desktop software.

That is an immediate thing that people latch on to: “Can’t I just have this on a web page, please?” Of course there is no reason that they can’t. There are a lot of companies like Oco making that happen now.

The Web also changes the way that the service, the calculations, and the data preparation can all be handled. Now, and throughout the history of data warehousing—going back to the mid-’90s, there was an awful lot of outsourced data warehousing. Lots of companies outsourced their data warehousing to big companies like Acxiom that specialized in data warehouse hosting, particularly for target marketing and related applications.

The Internet basically makes this idea a lot more attractive to companies—and in particular, attractive to companies with smaller budgets. It’s not just the big companies that can consider leveraging database and business intelligence technology, but in fact, everybody now can.

People are reluctant in some cases, because they fear, “Oh, gee, my precious data is going outside of my firewall.” But once people are satisfied that their data’s going to be handled securely, there are tremendous advantages.

One data-warehousing consultant I know said it pretty well, “All companies outsource the way their money is handled. That’s certainly precious to them. Why not data?”

MM: I think it’s because there’s a career track associated with it.

–