–

Professional background

MM: Let’s start with an introduction.

MB: My name is Mike Beckerle. Let me explain a little bit about my background. I joined in January of 2008. As the CTO, I’m responsible for product development of new products and technologies and the strategic direction for existing products.

I joined Oco from IBM, where I was involved in large-scale computing. The core of my experience comes from spending much of my career in developing large-scale parallel processing for commercial data processing workloads. The result of this work is now the core part of the IBM information server product. I was responsible for much of the scalability of that product.

I joined Oco because it was a very good fit with my background, and my experience is very relevant to Oco’s strategic direction. For example, during the dot-com era, I was involved in “SaaS,” at a startup called Fact City, although it wasn’t called that at the time. We did something that was fundamentally SaaS and quite similar to Oco’s solution in taking data in disparate forms and using it to construct a high-volume Web-accessed data service.

I decided that putting scalable commercial data processing and SaaS together would provide a great value proposition for the marketplace. I was thinking about launching this type of solution, and discovered that there was already a company doing it — Oco.

–

Corporate Background

MM: Why don’t you give us a quick background in terms of Oco and its core products?

MB: Oco creates “business intelligence solutions,” for its customers. I use the word, “solutions,” because the whole business intelligence marketspace is full of companies that sell tools, and what we do at Oco goes quite beyond tools. Let me go back briefly through the history, and then I’ll come back to the point about solutions and tools.

Oco was founded in 1999. The name, “Oco,” actually comes from the name of the founder—a gentleman named George O’Conor. He also had the vision that many traditional Business Intelligence processes were just too complex and difficult. He spent the first several years of the company’s existence developing the initial technology and testing it with a number of early customers.

Then about two years ago, the company accelerated and took in investments with the interest of ramping up growth significantly. Then of course the professional management team was brought in led by Bill Copacino as CEO.

So we have a great team, and we’re still executing on the same vision that was there originally– that is to make business intelligence far more consumable and much easier for companies to use at much lower cost.

–

–

Breaking points

–

MM: Could you give us a little bit of the history of business intelligence?

MB: Oco was formed to address the problems of existing BI tools, which were too difficult to develop and use. I can give you the historical perspective on that.

Back in the early 1990s, people started building data warehouses, because they didn’t have access to corporate information for the purposes of reporting and data analysis. They had lots of different operational systems, but they didn’t have systems that had data from all over the place gathered together.

These projects were originally pushing the relational database technology to the breaking point. Very large data warehouses were created, and every one of the vendors struggled to make these very large databases work.

But the software has matured now, allowing companies to put together quite, quite large data warehouses. There’s now an array of companies that offer BI tools. There’s also been some consolidation in the industry lately with SAP acquiring Business Objects and IBM acquiring Cognos and so forth.

Now there’s robust relational database software out there, and there are tools for accessing the information, but it has still been much too difficult. A recent report from Gartner estimates that still over 50% of these data warehousing or business intelligence projects fail.

–

––

MM: In large part, Mike, they fail for—I think—several reasons. One—the production data sources have data that’s somehow compromised or incomplete. Therefore, it requires a tremendous amount of reconditioning to make them usable, so companies can upload them into a data warehouse. Or—two—you simply have incompatible datasets from one system to another. And then I would suspect that there are probably some organizational issues around control of data, and therefore the difficulty of accessing various legacy or enterprise data sources. Does that sound about right?

MB: I would agree that the three things you’ve outlined are some of the factors why BI projects fail. I think that certainly there’s a data quality issue, which was the first issue you’ve raised. That’s still there, although with ERP packages that issue is lessened—but certainly is not gone. Companies still have ERP systems in addition to other point-solution systems, and large companies have multiple ERP systems. So they have the problem of reconciling them. But at least within any one system, there’s a sense of completeness of the information. There is still the issue of compatibility when you operate with multiple ERP systems.

There are problems that companies get into with master data management. They’ve got multiple ERP systems, and they have the same part or customer represented in several of them. And they don’t actually have them identified in the same way, which they don’t realize—and so forth. Those are significant problems in large enterprises.

This master data problem is one of the bigger challenges. At Oco, our key competency is reconciling data from multiple systems to address this problem.

–

–

Cross-integration of many system

MM: In fact, Mike—as we were doing the quick recap of the history of data warehouses… I think one of the things that had developed or emerged out of ERP and the data warehouses as they interact… A lot of the data that people need aren’t inside the organization. They’re outside the organization in suppliers and in trade partners.

MB: Well, that’s certainly the case. There’s information that’s down in the supply chain. But in fact, in the organizations we visit the systems that are facing the supply chains at customer sites are actually comprised of a variety of systems like warehouse management systems (WMS), transportation management systems (TMS), freight payment systems, customer relationship management systems (CRM), budgeting and financial planning systems, and so forth.

These systems provide functionality not found in ERP systems and therefore sit next to them—so companies always have many disparate, systems where important data resides and needs to be integrated for analysis and other purposes. There still needs to be some cross-system integration of this information. ERP systems in some sense have not quite lived up to their billing of consolidating all of this information. It remains important to be able to reach across different systems as well as across multiple ERP systems to be able to provide the visibility that companies need.

You mentioned the organizational barriers. Those are really quite significant as well. I’ll mention a couple of significant problems there. These are good examples for contrasting the way we approach these issues at Oco versus the way others in the industry have historically gone after these problems.

Historically, people will set out to put the data from their whole organization into the data warehouse. They’re trying to get data — all the data — in one place and also must cleanse that data—an enormous task. It’s an open-ended business intelligence activity that will enable the company to utilize the data warehouse…someday.

In other words, they’re building the data warehouse without already knowing exactly what they want to get out of it. They want to get whatever can come out of it.

–

–

–

Digital sail boats: Hole in the water in to which one pours money

–

MM: It sounds like a recipe for a very expensive digital sailboat.

MB: That’s what a lot of these projects are. That’s what has caused much of the difficulty and the high failure rate. There have been many successful data warehousing projects, but certainly a recipe to success is having some specific focus and purpose.

Many more benefits can accrue, but a lot of organizations simply run out of patience with the project before it has really gotten to the point where it’s delivering results.

At Oco, we do something quite different. I call it the top-down approach. We basically pick a business problem that is causing pain to the organization, and we identify a way of presenting the information to the business users in a way that we collectively believe will help them solve the problem.

We create this solution by bringing our best practices and knowledge of specific functions and industries to bear. Then we work top-down from this solution design to what specific data and related information sources need to be integrated to solve that problem.

So our integration work isn’t open ended. We know when we are done integrating.

–

–

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.

–

–

Mind-mapping best practices

MM: Does the methodology derive from any particular established profiling methodology?

MB: No, it doesn’t. It was developed internally with the input of some very experienced people who have a track record in handling complex business processes.

We do a lot of things that would probably be familiar to many database practitioners. We conduct a database dimension analysis. There are some unique aspects to our approach. The way we structure it makes it very efficient, as well as very effective, at capturing what’s needed for the business people, as well as identifying the sources of the information.

MM: Is there a corresponding data diagram or an entity-relationship diagram or some other kind of high-level visual abstraction of the transformation of business data into intelligence?

MB: We actually do have a set of proprietary diagrams we use. We use a mind-mapping tool in a very powerful way, that maps the transactional data needed to solve the defined problem and all the business dimensions that would be useful in analyzing, what we call slicing and dicing, that data.

And of course we bring a point of view on best practices, key metrics, the ideal reporting and analytic frameworks that are the best way to gain insight into a business area. We developed these with very notable experts in each functional or industry area where we work.

So we bring a very thoughtful and complete starting point to the table on day one, and we work with our customers to modify these solution templates to meet specific perspectives or needs that they have. We avoid turning it into a full-up custom solution, though. So we get the best of both worlds—a world-class solution as a starting point and the tailoring of that solution to specific customer preferences and needs.

We don’t publish our diagrams obviously, because they contain a lot of our intellectual property, but customers that go through the profiling process obviously get to see and benefit from that analysis.

–

–

Data cubes got it started

MM: Again, we were in the middle of reprising the development of business intelligence. You’d talked about the early days of data warehouses and then how ERP started to move through a lot of corporations, normalizing a lot of that data, giving rise to the need for a master data management as a way of harmonizing data among systems.

Then I think you were about to launch into the emergence of business intelligence tools or technologies such as Business Objects or Cognos or Microstrategy or things like that.

MB: These tools, and the companies around these tools, emerged over time. There was a big flurry of tools companies that came into existence around this idea called OLAP or On-Line Analytical Processing. Its central idea was something called “Data Cubes” which allow you to analyze and manipulate data. They give you many different ways of looking at data and organizing it along different dimensions that you need to look at it. You could look at items by vendor, by price or by profitability or also by geographic region, organizational roles or hierarchy, etc. The “cube” notion comes by analogy to being able to turn a cube around in your hands to look at it from different perspectives.

These tools have been implemented in a variety of ways. In the early days, people had to summarize the data to a considerable degree in order to get these tools to perform very well. As computing power and storage has become less expensive, people have discovered that you really no longer need to summarize the data. In fact these tools become a lot more useful if you can actually drill all the way down to the lowest level of detail.

You can drill down all the way to the details, and observe issues associated with the data at finer granularity.  Then you are using the tool to figure out what’s causing the problem and how to solve it. This results in a much more flexible, robust, and efficient solution with much faster response times.

–

–

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.

–