Integrated information for policy-managed decisions

MM: It seems that as your solution evolves to include WiFi Max networks and 3G phones—such as the iPhone—these mobile Internet connected devices become points of control of an entire industry, almost like the channel changer for a TV; it’s becoming the control system for these very sophisticated applications.

MB: I think of the world of mobile devices as a great way to give freedom to people who otherwise have to be slaves to the careful tending of systems and so forth. In that sense, they’re very freeing.

If you take the kinds of monitoring and management application that people want as a business intelligence solution and simply display it to them on a mobile device, you’re not going to be doing them any favors. You’re just changing the location at which they have to do a piece of work, where they look at a screen, make a business decision and so forth. It might give them some location freedom, but there’s a lot more potential out there for the activity you have to do, from the mobile perspective—to be a higher level of monitoring. You automate the decision-making at the lower level.

Today, let’s say you’re looking at a sales margin inventory kind of report. You say, “Gee. Here’s a product that I have very low inventory of, and I happen to be selling a lot of it. Gee. It’s selling at high margins. I guess I should reorder that.”

Of course, the system should just reorder that for you.

Today, people struggle just to get all that information on one line. So they can see that the problem is actually there. The next generation of systems will be ones directed at business rules that will help people automate the solutions. It’s what we call “operational business intelligence,” where triggers and tripwires and things of that sort can notice characteristics of the data in the enterprise, and can take actions.

Then from their favorite mobile device, people can make sure that the decision-making that’s happening for them is not going off the rails for some unforeseen reason. Instead of having to switch every switch on the train, you just have to see that the trains are all moving in a reasonable way.

I think the future will lead to integrated information properly displayed for human decision-making, to support of that human decision-making.

MM: And eventually, I guess, we get into policy-managed processes that basically report back to you that, “Hey. I did this. Is that okay?”

MB: Once you have integrated information, the sky is the limit with what you can do with it. Integrating the information and presenting it in a reasonable model for people has been the bottleneck and remains the bottleneck today.

MM: Well, that sounds like a great place to conclude. Thanks very much.

Decision making versus predictive analysis

MM: Mike—traditionally, again, I come from a background of database marketing, specifically, dealing with really large data stores. The fact is that most relational databases and most business intelligence tools are not really good about drilling down on a what-if heuristic. Then, modeling—if I have these demographic or psychographic factors in my database, how many people does that represent?

The notion of being able to drill down into very specific sets, and almost do a little simulation in terms of the ability to access that group by e-mail, direct mail or whatever? That typically gave rise to specialized analytic databases, to specifically a deal with that kind of ability to drill down.

Could you just give us a quick reprise of both of those database strategies—and then get into the compare-and-contrast of them?

MB: I think the simplest way to understand it is that the relational databases were originally designed around transactional processing—the kinds of things that an ERP system needs to do. They are row-oriented. You’ll have a customer table and a customer buys something. So you put an order into the order table and there’s one row for each order, or probably each line in each order.

The whole approach is organized around the notion that there are entries—which are rows. They’re created in response to transactions. Transaction processing is the primary activity.

Then people started trying to use this to do data warehousing, where the workload is much more analytical, answering questions like ”find all the customers with these characteristics,” and so forth. And this required organizing the data in certain ways to support analysis and decision making versus transaction processing.

At first, people took the databases that were organized around transaction processing, and started trying to use them in different ways—to index them differently and so forth.

Then, many databases that centered around decision support entered the market. Teradata was really the first one. But there have been many since then that have entered with decision-support workloads in mind. There continues to be all kinds of interesting innovations in the database market.

The relational database market is around 30 years old. It should be mature by now, but every year there seems to be new innovations in the relational database space. I’m always astounded that there continues to be new entrants. There’s a whole slugfest among new entrants for who will have the crown of the TPC— the Transaction Processing Council benchmarks. The TPC publishes benchmarks, and they label them Benchmark A, Benchmark B. They’re down to Benchmark H now. This is a decision-support benchmark. It’s really quite a good benchmark, because it measures not only how good the database is, and how fast the database can answer the question—but how expensive it is at doing that based on a cost and a cost-performance type of metric. It’s interesting that these small vendors are continually displacing each other on the top of the heap for that benchmark and it illustrates the continuing innovation that is occurring.

The columnar or column-oriented databases are databases that are organized in order to be able to handle these decision-support workloads optimally. There are quite a few of them on the market now.

But Michael, you asked the question about “what if,” analysis, as well. The columnar databases and the decision-support optimized databases are very good at answering questions like, “find people that have these interesting characteristics.” One needs to feed a very complex SQL query to find them, and these databases can very rapidly extract and produce that result set.

But there’s a big difference between this type of query and predictive behavior addressing questions like, “If this was true, what would happen then?” These kinds of things get you into the world of data mining and predictive modeling. These types of things are—to my knowledge— not yet embedded in the databases.

–

Critical success factor: Data model architect

MM: That almost reminds me of a conversation I had with a data warehouse architect. She was building a data warehouse for an executive information system for Bank of America. She would talk about sitting down with a fairly senior marketing executive and saying, “What are the business decisions that you make in the course of a day?” And then, “What information do you need in order to make a fully-informed decision?” And, “Where do you go for that information?”

Of course, there are green bar reports here and a conversation here and a fax here. In the course of doing that, she’d talk about identifying the most important—the number 1 or number 2 most important—business decisions that an executive would make. Then doing a map of logical but physical data sources, so as to be able to identify what the data items were that needed to be collated into information that then supported an action or an insight.

That kind of describes what you’re talking about in terms of this top-down optimization strategy or top-down problem-solving sort of thing.

MB: My expectation is that a large percentage of the projects that have been successful have had practitioners working on them in the model that you just described. Here at Oco, we’ve really taken that notion and turned it into an art form. We sit down with a business for one or sometimes two days and go through a systematic approach to define the key problems they need to solve. We call this approach a profiling session.

We design the solution and figure out the data resources that are going to be required and so forth. We have a quite robust methodology we go through. It’s a precise recipe.

–