Tuesday, 16 December 2014

OBIEE Projects - Solution Process

Sixth and last chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution outlines implementation steps to achieve a first production rollout of a revised OBIEE repository fulfilling client's needs. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

What did we do until now? Coming from a concrete defect description and a list of nonexistent OBIEE functionalities we implement a prototype to show the client that OBIEE fulfills his requirements. At the same time we analyze previous supplier's OBIEE repository, elaborate a turn-around plan based on proven OBIEE implementation principles and provide a detailed effort estimation for further tasks (phase 6 described below). Time frame to accomplish phase 1 up to 5 is just a few days of work.

We start to build a running OBIEE solution utilizing gathered topics in prior phases. Of course that's not just configuring the OBIEE repository, we create detailed design documents and establish coding standards. Don't wonder that we introduce coding standard in a software which is just configured. You may ask "Is it really necessary?" - Yes, it is. Additionally it's crucial to:
  • Create a new OBIEE repository. Changing the previous one will take much more time and the risk of failure increases.
  • Use existing data warehouse tables for your OBIEE logical model even if they should be changed to get an optimized or correct data model. Tables are only changed if it's absolutely necessary. OBIEE is able to handle such a situation and changing OBIEE configuration later causes not too much effort. Data warehouse tables changes can be done after first rollout. We avoid to generate data warehouse process change effort at this point, because focus is still to have the first OBIEE repository running after at most two or three weeks.
Of course we identify and define an optimized data warehouse model for OBIEE in parallel, but corresponding tasks are fulfilled later. In general the current phase occurs near to important project milestone. So it's perhaps necessary to implement an interim solution. Don't care, OBIEE is flexible enough to do so with very reduced extra cost.

When first production rollout is achieved we apply regular process cycles to the project. In parallel we solve errors identified across the complete BI and DWH stack in prior phases and start to consider new or changed business requirements as we have now a sound basis to release the full power of OBIEE. During all the time we stay in close contact to business users to verify functional and nonfunctional requirements continuously.

Is it possible to recognize aberration early?
Situations as described in this OBIEE project series shouldn't occur, but they do. You can follow some rules to avoid and recognize such trends, especially when projects will be in development phases for months:
  • BI projects must be independent from other IT projects. Don't force them to be just sub-projects of any other software launch.
  • Perform rollout extreme having two week cycles for delivering new or changed functionality to end users.
  • Support and evolve agility between IT and business (see our presentation Self Service BI with Oracle BI)
  • Create know-how early (see article OBIEE End User Training Concept).
Why? Because proper OBIEE structure supports agility and high reactivity.

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Monday, 15 December 2014

OBIEE Projects - Criteria for Fast Success and Assessment

The fifth chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution covers criteria for fast OBIEE project success and outlines our OBIEE repository assessment approach. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

Till now we just described preliminary work. Starting point was to understand client needs and giving a preview of what we will deliver by creating a prototype at low cost. Next goal is to deliver a technically executable Oracle BI system on the existing client data warehouse. Effort is estimated within previous turn-around approach phase. Again, don't focus business requirements at present to avoid failure. Focus is to create a running OBIEE solution observing standard IT success criteria: correctness, stability, performance, fault tolerance and ability for cost-saving modification.

Those criteria having specific characteristics in OBIEE build the basis for Oracle BI repository analysis and further development. A good starting point is a really bad OBIEE repository example:

Bad OBIEE repository

It really makes no sense to go into detail when seeing such a OBIEE repository implementation. It's not faked and we saw such implementations several times. No criterion mentioned above is met. As OBIEE expert you just need to open it and your validation is finished. The following OBIEE basic criteria are not or only partially observed.

OBIEE Physical Layer
OBIEE physical layer represents data warehouse physical, multidimensional data model. Data model is created by using Aliases. Aliases must be used to apply join definitions, build instances, avoid circle joins and fast replacement of tables. We already saw duplication of database tables instead of using aliases.

Of course data types like DOUBLE or DATETIME should be set to INT and DATE if applicable from a business perspective due to usability reasons. A proper OBIEE physical layer design allows project initialization and start without data warehouse tables.

OBIEE Business Model and Mapping Layer (Logical Layer)
OBIEE logical layer isn't just a copy of physical layer although a lot of developers seem to think it is. You should create a logical, multidimensional model consisting of logical tables perhaps combining several physical sources (which represent one logical entity), figures within facts and dimensional hierarchies (one per dimension). Only a full dimensional hierarchy model enables correct level setting, aggregation, time series, drill and multi star queries.

Define and implement logical separation of dimensions and facts. We know that OBIEE is able to handle attribute fields in logical facts tables (but this functionality shouldn't be used, because several restrictions in design and implementation flexibility come along with it). Coming from a logical perspective a fact table has no attributes and no keys. Logical facts tables hold data to be aggregated. That's it, nothing to be discussed about it! Of course, physical fact tables provide attributes and figure columns.

OBIEE Presentation Layer
Few configuration is normally done in OBIEE presentation layer. But don't forget to set implicit fact column, because there is no direct binding between subject areas and logical tables (the reason why OBIEE is able to perform cross subject area navigation). Dimension and fact ordering should follow optimized usability aspects.

Subject area granularity should follow business usage. Don't create subject areas providing a lot of presentation tables which aren't used together. Utilize multilingualism only if really needed. Field names are set in OBIEE logical layer.

General Topics
Based on these criteria we start to build a new OBIEE repository (see next and last chapter of OBIEE project series). General topics like security model beyond standard model which isn't sufficient for enterprise usage (access to OBIEE components, subject areas and data), cache management and coding standards aren't yet covered. But they need to after first rollout is done.

Just to let you and what we already saw sometimes: OBIEE server cache isn't purged when server is restarted :-)

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Thursday, 11 December 2014

OBIEE Projects - Turn-Around Approach

In the fourth chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution we describe our approach to achieve a fast turn-around concerning clients expectations regarding OBIEE. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

As shown until now we just know what's going wrong for ourselves and we have an overview of items to solve. It's very important to understand the full band width of expectations on OBIEE from a client perspective. Thus we do the following:
  • First step is to get a clear picture. We organize a workshop to understand all needs users have concerning Oracle BI as tool. Simultaneously we produce a positive perspective on what's possible with OBIEE.
  • Second step is to build a prototype to show and prove promises given in first step. We present missing functionalities recognized during workshop and first contact sessions on existing client data warehouse. We always use original client data and existing database tables to illustrate the flexiblity of an elaborated OBIEE implementation process. Additionally we analyze the current OBIEE repository and data warehouse implementation in detail. On that basis we provide a project specific plan for a solution without errors.
Effort for first step is 1-2 days. Second step requires 1-3 days investment. It's crucial to focus only questions concerning OBIEE functionality, because missing functions are the root cause for customers' issues. Mentioned business requirements can be set on a list, but they are not discussed or explicitly gathered at that point of time. Of course, business requirements are very important. But usually described tasks are done near to major project milestones, projects risks are located at tool level and you have to achieve a turn-around. Thus we request to be set into the project lead position for all steps covered by this OBIEE project series.

To complete turn-around chapter please have a look to the following OBIEE prototype example which can be build in less than one day. It gives an idea how OBIEE repository layers are structured. Applied criteria are described in fifth chapter of our OBIEE project series.

OBIEE prototype

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Wednesday, 10 December 2014

OBIEE Projects - Typical Error Scenarios

The third chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution outlines typical error scenarios we recognize during our first contact with OBIEE project teams requesting support as shown in chapter 2. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

At first we ask different users and stakeholders to describe the current situation. Response is often very impressive:
  • Even simple reports are very labor-intensive.
  • All figures in OBIEE Answers (or newer Analysis ;-) ) need to be created by users themselves, because supplier says that's the only way to create calculations.
  • Detailed data is not available dynamically.
  • Star schema combination isn’t possible.
  • Excel is much more powerful than OBIEE Answers.
In the end normal business users cannot build any report although - to be honest - they just request for standard BI functionality. Stop the project would be understandable. So, our next step is to find out the reasons. But already after first interviews it's certain to say without a deeper analysis:
  • For item 1-3: OBIEE configuration is technically wrong and previous developers didn't understand OBIEE multilevel calculation logic.
  • For item 4: OBIEE is at least incomplete configured.
  • To solve item 5 users typically need some expert training. Please have a look to our presentation Tricks with Oracle BI Answers and training class OBIEE Analyses Insights.
To get a full picture of the situation we take a first look into OBIEE repository configuration for just a short time. Image shows a section of presentation layer from a German OBIEE project acting as basis for our series:

Bad OBIEE presentation layer example

Our assumptions are confirmed just verifying such a small section. It's a really nice example for a bad OBIEE repository presentation layer implementation:
  • There are technical names at GUI level.
  • No business structure is applied (dimension attributes are mixed).
  • No time dimension or figures are available.
It's obvious after the first analysis why OBIEE cannot work as it should. We will see the whole OBIEE repository configuration in one of the following series articles. As next step we describe our turn-around approach. For now we just know what's wrong, but customers need to be sure that it's worth to go ahead with OBIEE.

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Tuesday, 9 December 2014

OBIEE Projects - Suspect Requests

The second chapter of session Success with Oracle BI? Typical Error Scenarios and their Solution discusses the way how clients describe their issues when trying to manage their current project situation. Please follow our OBIEE project series presenting our process for solving typical OBIEE project issues:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

Customer requests nearly always seem to be quite simple in the beginning. Just two examples what clients ask for in OBIEE projects already taking about 6 months up to 3 years implementation time:
  • Oracle BI query performance is completely unacceptable: generated SQL queries are slow and SQL code covers several pages.
  • Business wants to use Oracle Smart View for Office: users want to use Excel pivot tables and they need the ability to calculate their own figures.
What's really amazing at this point - without talking to the customer in detail - is the fact that the client wants to have a new supplier to solve the issues, because the current one already failed several times. If issues described would be the root cause then solving would be easy. Assume that the client has a structural problem in his current OBIEE solution. Coming from the examples you can say:
  • OBIEE performance is more a structural factor than a detailed one, e.g. to find a missing database index isn't really difficult or time-consuming for an expert. If already simple queries from a business perspective are slow and OBIEE generates several pages of SQL code for these queries then the probability for a wrong OBIEE configuration and a crude data warehouse design is very high. By the way, a real expert will deliver a system with good performance from the beginning. He tells you what to do to achieve acceptable OBIEE performance beforehand.
  • It's the same for using OBIEE Smart View as described above. OBIEE pivot functionality is really good and calculation of your own figures within OBIEE is a standard functionality. So, if the client solution doesn't provide such functionalities then there is at least an OBIEE training gap or in the worst case Oracle BI is configured that bad that it cannot unfold its power.
To summarize, we didn't talk to the client concerning any details till now. Already such requests are suspicious, because the issues described don't fit into a state-of-the-art OBIEE configuration. The next part of our OBIEE project series will describe how we manage the first contact with business users and stakeholders. Series content is based exemplarily on the second example above.

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Monday, 8 December 2014

OBIEE Project Success - Introduction

We recently presented at the German Oracle User conference DOAG 2014 on two OBIEE topics. We decided to share the details of session Success with Oracle BI? Typical Error Scenarios and their Solution to the OBIEE community in a series of blog posts:

1. OBIEE Project Success - Introduction
2. OBIEE Projects - Suspect Requests
3. OBIEE Projects - Typical Error Scenarios
4. OBIEE Projects - Turn-Around Approach
5. OBIEE Projects - Criteria for Fast Success and Assessment
6. OBIEE Projects - Solution Process

All information we provide comes from our real OBIEE projects. We win about 50 percent of our new clients having issues when introducing Oracle BI with other parties as they know we provide real expert OBIEE solutions. We describe the whole solution process from the first contact via our assessment and change process up to the rollout of a state-of-the-art OBIEE implementation.

When having a look to BI market and surveys concerning Oracle BI (OBIEE) we often read statements like:
  • "Oracle BI was the wrong decision!"
  • "It's really cumbersome to work with."
  • "OBIEE has low flexibility and development is very expensive."
What a bad rating! We would agree with each client when he stops using OBIEE. We would rather recommend to quit their OBIEE projects. But are such statements really the truth?

When clients ask us to take over OBIEE projects described by this series they often think about stopping the projects with Oracle BI due to the same reasons respectively statements. To let you know in the beginning, not one of our clients in such a situation stopped his OBIEE project. As far as we can say based on our experience all such bad rated OBIEE projects have the same origin or reason for failure.

Therefore our OBIEE session mentioned above and the series articles cover the work with OBIEE as tool. We do not deal with issues on BI requirements engineering which would be a separate interesting topic to discuss. That's it for the first article. Please look forward to our next article coming in a day or two. If interested then please have a look to OBIEE Client Success and Typical Issues and Solving OBIEE Issues which highlight related questions.

Any questions? We provide Oracle BI expert support & coaching regarding all relevant OBIEE topics like architecture, security, configuration, reporting and mobile.

Saturday, 6 December 2014

Oracle BI Analyses Insights - Private Class

Hopefully you are already informed about our OBIEE expert class Oracle BI Analyses Insights for End Users showing Oracle BI users what's the real power of OBIEE. In November we had the chance to deliver the training at a customer site in Munich as a private class. It was very exciting for our official Oracle BI Expert Trainer and managing director Gerd to see how the training concept empowers a client's users when discussing internal questions from his own application in addition to the OBIEE expert training topics.

Scheduled class feedback is already very impressive. Learn more about our OBIEE expert knowledge when reading the feedback from the attendees:

"Very substantiated knowledge and a great many interesting tricks which I will try out soon. Some topics I solved myself much more laborious. I will change such solutions now."

"Absolute recommendation!! Reason: very use-oriented."

"High level. Excellent expert knowledge."

We appreciate if you are interested in our OBIEE expert event. Please contact us for more details via +49 (0) 8709 / 915 202 or training@ga-itbs.de.