OBIBB – Interviews (Kurt Wolff)

It has been quite some time since the last interview in the series on this blog, but I think it has been worth the wait.  I have been able to ask Kurt Wolff some questions. He has taken his time to give some very interesting answers.

1. You are a well respected member of the Oracle BI community. Where could we know you from?

>:I was a member of the original core group that created nQuire, the BI product that eventually became “Siebel Analytics” then “OBIEE”. I worked with the dev team on defining product features, wrote and delivered training, supervised doc, and was the PM for the admin tool. Along with Ed Suen and others from the nQuire and Siebel teams, I helped develop the metadata and original web applications for the Siebel CRM analytic apps, then worked on the team that built that other ERP analytic apps using the data models and ETL licensed from Informatica. I have presented several times at Siebel and Oracle user meetings (Oracle Open World, ODTUG), with the focus on solving analytic problems with OBIEE and showing various tips and tricks. I’ve trained a lot of people on the product in various locations around the world, using training materials I created and which became more or less the standard Oracle curriculum. I’ve also had two blogs on OBIEE topics: while with Oracle I wrote the “Dr. Metadata” blog, and then after leaving Oracle, the KPI Partners blog. I recently gave a Masterclass on OBIEE at the Rittman Mead BI Forum in Brighton, England. I’ve also written an Advanced Metadata course that is given by the BI Consulting Group.

2. You are one of the founders of Oracle BI (EE) as we know the product now. What is your opinion about the new 11g release?

>:I don’t have an opinion yet as I actually haven’t seen or worked with it. I’m hopeful but also nervous and perhaps a bit skeptical about it, frankly. I don’t really know if there are any new features that are important to me in my current work or not. There may be features that help Oracle sell more product, but that’s different.

Over two years ago I submitted a list of 20 “little” enhancements that, as someone who on a daily basis worked developing analytic apps with OBIEE, I thought would be really beneficial. They were “little” in the sense that I thought the dev team could knock them all out in less than three weeks’ time. Seriously big impact with seriously little work.

Instead, we’re getting what appears to be a major re-write of the product, which raises questions in my mind about compatibility, unlearning, and new bugs. What I know about new features – well, they’re not so compelling. Sure, if you have a need to integrate Essbase with your other data, that’s good. But in my present situation, it’s irrelevant, and I’m planning on taking a lot of time to evaluate the new release before moving ahead with it. It strikes me that this is the obvious time to at least look at what alternatives exist. If the upgrade and re-learning are at all painful, or if knowledge gained working with previous versions is now irrelevant, switching now could make sense. No doubt there are many Oracle customers who are thinking the same thing, although it’s probably heresy to say it out loud. There are so many people who make a living being part of the Oracle ecosystem I think it’s going to be hard to find people who are willing to be outspoken and forthright in stating their true opinions about the 11g release.

 3. What’s your favorite topic, you share your knowledge about?

>:Over the years, I’ve developed my own approach to working with the product that I think simplifies working with it and makes it more understandable. The product has always suffered a bit, in my opinion, from being too much of a “black box” – the connection between the metadata objects, their properties, and the SQL generated by the BI server were often unclear in people’s minds. That’s where I like to shine some light.

I’ve written and presented on data modeling – ways to construct the Business Model layer to handle various analytical situations, such as parent-child dimensions or skip-level dimensions. I’ve also become very interested in ways to display data effectively. One technique I’ve been using in the past year has been to integrate OBIEE with easy to use visualization technologies outside the OBIEE stack, such as Google charts and maps. So I’ve also written quite a bit about that recently.

4. In my opinion, you did a very valuable Masterclass in Brighton last may. How did you experience this session yourself?

>:I was pleased with it, actually. From what I could tell, it seemed to be well received – at least I got quite a bit of positive feedback about it. On the other hand, maybe people who thought it was sub-par were just being polite and didn’t say anything. It was a challenge to prepare because I wasn’t sure what the appropriate level of content should be and what the OBIEE skill level of the audience was. There’s the fear that people will feel they didn’t learn anything new. There’s also the fear that no one will understand what you were talking about. I think I landed somewhere in the middle of these extremes, which is where I wanted to be. I also wasn’t sure, even, whether I had the right amount of content for a six hour class. But in the end, as I say, it seemed to connect with the audience and the amount of content was about right.

5. What part of the Oracle BI stack could get more attention form the Oracle BI Community?

>:If you take the “stack” all the way to the database, I’ve become a big fan of materialized views in Oracle as the way to create aggregate tables. MVs offer several methods to control when they are refreshed. We refresh daily, in most cases, and MV refreshes basically run on autopilot. I turn query re-write off and include the MVs in metadata as normal aggregate tables. (Parenthetically, will say that I never use the “aggregate persistence wizard” that is included in the admin tool…)

In OBIEE itself, session variables (and “report variables”, the technique for temporarily overwriting session variable values) are also important tools that can help you accomplish all kinds of things in the physical layer of the repository.

The third thing that pops into my head is to not forget that you can hand-craft some queries using logical SQL that the Answers UI won’t produce. Unfortunately, in later versions of OBIEE, some things you could do with logical SQL in earlier versions no longer work. Maybe those bugs are fixed in 11g. One can hope. The fact that the BI server could execute logical SQL was one of its features that really set OBIEE apart from the other BI technologies out there. I don’t think it’s been given the importance and support that it should have been given.

For creating flexible applications, don’t overlook the column selector, view selector, and narrative views. You can perform all kinds of magic with these.

 6. You have some great opinions on RPD design. What are the do’s and don’ts ?

 >:This is a pretty broad question! One of the considerations is whether you are trying to design something that will support ad hoc queries by users in Answers or whether you are designing for users who will only interact with the metadata via what queries and prompts are in dashboards. In the former situation, you have to be careful that all combinations of columns in a query produce something that doesn’t look like an error and result sets that are valid. In the second case, you can create metadata that supports only certain pre-defined queries. You don’t have to worry about all the “loose ends”. In either case, you have to be sure that the underlying data model supports the queries. For example, will an inner join always work, or will it cause you to lose rows? If outer joins are needed, you have to construct the metadata so that they will only come into play when columns requiring the outer join are included in the query.

But here are some fundamental rules I follow. Start with a logical fact table. As a general rule, don’t include columns in the logical fact table that are not aggregatable. Avoid a design that will produce dimension table to dimension table joins in the physical SQL. Don’t be afraid to create new aliases in the physical layer when multiple join rules exist. I use the time series functions, but they can be slow to execute. Oftentimes, it’s better to create aliases and joins to support custom time aggregations (e.g. a 13 week total). Those people who remember the old time series wizard will understand what I mean.

I sometimes see questions posted asking how to do such and such in the metadata to solve a particular analytical problem. It seems to me that many people would benefit by asking, first, how you would solve the problem with SQL. If you can do that, then you can usually construct the metadata to produce the right SQL. If you have no idea what the correct SQL would be, then you’re probably not going to solve the metadata problem.

7 .You must have done a great deal of projects in the past. What are the key elements to run a successful Oracle BI EE projects?

>:I’m sure everyone who was asked this question would say things like get executive support for the project, define requirements carefully, and set expectations carefully. I agree, but would add a few things. 

First, get access to all the data! You cannot build anything without data, and in real life people often don’t seem to understand that. (Ever had a request for a “demo” without having any data?) Get the connection information (tnsnames, odbc dsns, etc.) and userids (with passwords) that will allow you to read the data as well as to create tables and materialized views (and to update, delete from, drop, and insert into tables).

When gathering requirements, focus on measures first. What are the key measures and what are their definitions? It’s amazing, but sometimes organizations have sets of measures that are used (they show up in reports in tables and graphs) but no one knows how to define them! So get the base measures defined and mapped. (This fits with my approach in building metadata: start with the logical fact table.)

Dimensions are usually easier to understand, but there can be missing dimension tables. By this I mean that words that appear in reports as row headers, which look like dimension attributes, are actually supplied by the reporting logic. It may take effort to get someone to explain what the report logic actually is. Build dimension tables when needed. (Materialized views, here too, are a great strategy for getting a set of distinct values for a dimension table). The essential dimension table is the period table. Create a period table at the proper periodicity. I have yet to see any project that did not require a period table. Having a period tables is good; not creating one is bad. Yet having a period table is sometimes controversial. It shouldn’t be. It should be automatic. 

When you have dimensions, attributes, and measures defined and know how to map them to their sources, make sure everyone agrees on the column names that will be used. This is a “say it now or forever hold your peace” moment, as far as I’m concerned. 

Before giving access to the data, you’ll need to understand the security requirements. If certain users can see only data with certain values, it usually boils down to creating and populating session variables that will filter result set queries, then applying the filters to the appropriate dimension and fact tables by group.

Implied in what I’ve just been saying is this: you need to create a dimensional model of the information. This is something quite different from focusing on generating a set of reports. You will be shown reports as part of the requirements. What you want to do is translate the reports into their dimensional components, then include those components in the dimensional metadata model. If you have all the dimensional components in the metadata model, you can reconstruct all the reports (or come close enough). By the way, if you are given reports as part of the requirements, set the expectation that users won’t get the exact same thing from OBIEE, but that all the essential information will be there. In fact, if you take the time to understand how users actually use the reports, the essential information can often be made more accessible to them.

While on the topic of requirements, here’s another thing I’ve found: requirements are usually sketchy, and the people producing them often don’t know much about OBIEE, BI in general, dimensional modeling, good data visualization practices, good dashboard page design, or even what information can matter most to their organization. Ask questions, but don’t be surprised if you get really bad answers. Document the answers, though, because 9 times out of 10, those giving you the answers will come to know that their answers were wrong and, strangely, they may get amnesia at that same moment.

Remind yourself frequently that the whole process is highly iterative.

8. I know one of your passions is Oracle BI EE. What are your other passions, if any?

>:Lots of passions! Like many others in this field, I’m drawn to topics that go beyond BI tools and mechanics into questions about how people actually make decisions. This includes data visualization, but it goes beyond that. It includes how you get people to re-think strategies when the data is clearly telling them that the strategies aren’t working. The human capacity for self-deception is amazing. Look at other aspects of human behavior to see dramatic examples of this. After all, there are people who believe that the Grand Canyon was the result of only a few thousand years of erosion. Talk about the human capacity to ignore data! In personal life, I’m someone who likes to move (run, cycle, sail, canoe, or ski), cook, play acoustic guitar. I love baseball (the Minnesota Twins, especially) and being in the outdoors and my family, first and foremost. I’m a certifiable “tree hugger” (environmentalist), too, I guess.

9. Is there anything else you would like to share with us?

>:I currently work at a company based in Minneapolis called SPS Commerce. SPS is at its core an EDI out-sourcing service that a few years ago decided to add value to its offerings via BI and committed to OBIEE as its BI technology. So I’ve been spending the last two years building analytic apps based on EDI documents (purchase orders, invoices, shipping notices, and point of sale reports). From what I can tell, these projects are nearly “done”. I may be looking for other interesting projects in the not too distant future, and at this stage, with the kids grown, I’d like to find ways to incorporate work with longer-term travel.

10. Who would you like to be next in this series and why? What would you like to ask him/her? 

>:I’d really be curious to know what some of the original nQuire team is doing and if they have thoughts about where BI is headed. Larry Barbetta and Ed Suen were visionary and brilliant. But maybe they’re on to other things.

Beyond them, once someone has had a chance to do some serious work with 11g, I’d be interested to hear what he/she has found out. That person, ideally, would have previously developed some serious analytic applications with Oracle BIEE and gone through the process of migrating them to 11g. I’d like to know what that migration was like and why doing the migration was worth it, other than to be “current”. Hopefully, also, that person can offer true independent judgment. It’s a tall order. The people who will really dig into 11g will probably be making a living by being a part of the Oracle ecosystem and won’t want to risk being critical. Or at least will be very careful about what they say.

One question I’d ask is whether the product has drifted too far in the direction of supporting mainly Oracle-owned technologies. One of the product’s original strengths was the fact that it was “database neutral” and supported a large number of commercial and open source relational databases. I’m hoping that continues, but I wonder. Some BI gurus originally thought Oracle would eventually end up killing the product when it bought Siebel (its previous record in BI wasn’t so great). Maybe they were right; maybe they couldn’t have been more mistaken. It would be interesting to know what the opinion on that is now.

There’s some language being used around this product that strikes me as having come from previous products that were desperately seeking ways to differentiate themselves in the BI marketplace. So when I hear “enterprise performance management” (“EPM”) or “balanced scorecards”, I react the same way as when I hear, on Mad Men (a hit US television show), the creative advertising executive Don Draper come up with “It’s toasted” as a slogan for a cigarette brand (when all brands toasted their tobacco). Maybe someone can set me straight.

I would like to thank Kurt for the time he has take to share his thoughts. Although the atmosphere around the new release of Oracle BI 11g seems to be somewhat euphoric, it’s a good thing to stay critical.

I hope I will be able to get the answers from one of the other members of the original nQuire team.