OBIEE Project Organization

How does a typical OBIEE implementation organized? Having to be SOX compliant where the there are
seperation of duties and roles and responsibilities clearly defined.. here is what I have seen in many
typical implementations.

Remember we are talking about OBIEE implementations and not an Oracle Pre Built Analytics
implementation. Can this be useful for OBA implementation. Certainly, Yes.
Data Warehouse Overall responsibility for a project’s
Project Manager /Team successful implementation. Defines, plans,
Lead schedules, monitors, and coordinates the
activities of the team.

Business Analyst(s) Research and possess business knowledge of

all relevant systems, knowledge of business
reporting and analysis needs, assisting
in development of business requirements
definition.

Data Analyst Evaluation and documentation of existing

data. Gathering and documenting the
technical and business meta data about the
data as well as providing insight into the data
itself. Can be a stakeholder in development
of business requirements defintion.

Metadata Administrator Identifying, documenting, and administering

the metadata repository. Working with
business users, data analysts, data modelers
and IT staff to gain consensus on standard
definition of common data attributes,
developing and maintaining the corporate
data model, identifying and documenting
data sources, and maintaining the meta data
repository.This role can be a very good
complimentary skill for the data analyst.Data
Analyst and Meta Data Administrator roles
can be combined for one resource depending
on the project size and budget.

Data Warehouse Defining overall data warehouse

Architect architectures and standards, definition of
data models for the data warehouse and all
data marts, selection of infrastructure
components including hardware, DBMS,
networking facilities, ETL software,
performing applications design and related
tasks, performance tuning.Concentrate on
getting a resource who has been a seasoned
 DBA/DB architect rather than an OBIEE
architect.

ETL Developer Develop and maintain ETL applications, data

cleansing functions, load automation, data
acquisition functions and others. Often the
source system extract functions will be
developed by the applications support teams
assigned to the various transaction
processing applications.Use in house person
as an ETL Developer so he/she can
accomplish things faster.

System Administrator Maintaining hardware reliability, system level

security, system level performance
monitoring and tuning, and automation of
production activities including extract and
load functions, repetitively produced
queries/reports, etc. Ensuring that
appropriate disaster recovery functions such
as system level backups are performed
correctly and on an accepted schedule.In an
OBIEE implementation, this role becomes
crucial during initial development and
deployment. Better get a seasoned OBIEE
System Administrator for your first OBIEE
implementation.

Database AdministratorInvolved in physical database design of

the data warehouse or data marts. Monitors
and tunes DBMS performance, administers
end-user access and security at the DBMS
level, ensures that DW data is appropriately
protected via database backup and related
strategies.Let this be filled by an inhouse
personnel so that he follows the
organization’s standards in database
development and creates policies that
pertains to the database maintainence.

Business Intelligence Need a seasoned consultant for this

(BI) Architect role.Develops the repository, merges the
repository, performance tuning and enforcing
repository best practices. Works in
conjunction with System Administrators for
migration, deployment and performance
tuning of repositories.

Business Intelligence Develops data access queries and uses

(BI) Developer OBIEE tools like Answers, builds
dashboards and help in development of
complex ad hoc queries and analyses. Works
in conjunction with data analysts for
developing dashboards and other end user
solutions.Works with business analysts and
acts as a liasion between technical
departments and business
departments.Trains the power users of your
respective businesses along with business
analysts.

Help Desk First point of contact for all data warehouse

and data mart related questions, customer
queries, system statuses.

Having recently found some time to delve into “What does it

takes for my client to move away from existing Business
Objects Universes to adopting custom OBIEE repositories”, I
thought of developing a strategy that I can adopt and share
that with you all out there trying to accomplish the same.. Of
course my client is the first one to review or may be I will be
reviewing with you so we can discuss further and I can submit
a refined strategy to my client.
First of all, as of this writing, lets make sure that we are on the
same page that there is no automated tool that was developed
to move a BO universe and convert that into a OBIEE
repository. With this premise set, we need to walk through
various features that are supported in Business Objects and
lets see how we can convert them into OBIEE.

For a brief introduction on what Business Objects tools are and

compare them against OBIEE tools:

Business Objects
OBIEE Tools/Terminology Comments
Tools/Terminology
MUD is not exactly a server but a store of
CMS (Central MUD (Multi User
your repositories where you can check in
Management Server) Development)
and check out your repositories
Universe Repository
Designer Administrator
– Physical Layer
Business Modeling and
Semantic Layer
Mapping Layer (BMM)
Universe Connections to Physical Layer Connections
Data Sources to Data Sources
Dont you think ‘finally’, we have some
Presentation Layer Presentation Layer
coincidence with BI naming conventions
Joins Foreign Key Join, Complex
 Join
No specific naming conventions used in
Classes Folders
OBIEE
Hierarchies Hierarchies
Objects Objects

I will try to keep adding more to this as I encounter new terms

in my BO to OBIEE migration project.

Lets talk about the “Filters” feature available in BO and see

how they corelate in OBIEE. There is atleast some consensus
in this regard in all the different web pages that I have read..:)

1. Pre Defined Filters

2. Custom Filters
3. Prompts Filters
4. Advanced Filters

For a brief explanation of what these filters are.. please use

the following link

To do a similar comparision between these BO and OBIEE

filters:

Business Objects
OBIEE Filters Comments
Filters
Pre Defined Pre Defined Filters are defined in Universe using Designer tool
Shared Filters
Filters where as Shared Filters are created using answers tool
Dashboard
Prompts Filters
Prompts
Custom Filters Filters
Advanced Filters Filters
Lets see how the pre defined filters are when you open up in
Designer

See the first pre defined filter “Select Supplier Number” and
when you try to edit the filter in BO Designer, this is what you
can see
Now, lets look at Shared Filters in OBIEE. ‘Shared filters’ here
are nothing but ‘Saved Filters’ in ‘Shared folders’ of your
Presentation catalog folders and these filters as in Business
Objects can be applied across all your answers requests.

Lets see how many of them are available in Financial Module

of OBI applications analytics package. wow… this concept has
been extensively used by Oracle..
Now lets look at what “Current Fiscal Period” filter looks like.
This is nothing but a regular filter saved in a shared folder so
that you can reuse across all your reports/answers.

So, we covered both “Shared Filters” and regular “Filters” in

one shot..
If you want to know how to create a filter in OBIEE; try
Googling it. One that was interesting I came across is

http://obiee101.blogspot.com/2008/07/obiee-protect-filter.html

Moving onto Prompts, in Business Objects prompts are created

at the report level where as prompts in OBIEE are created at
the dashboard level. Can we not create prompts at dashboard
level in Business Objects (BO)? Answer is Yes but I am just
giving you a common practice of most how it was frequently
used. Think of a WebI report and a prompt at the report level.
This is the scenario we will cover first.

See the region marked 1,2, 3 in the above pic.

Region 1 in above pic –> Enter organization is the prompt

description and the black marked area in 1 region is what the
default value that is being passed to this prompt.

Region 2 in above pic–>List of values for the organization that

can be populated from the database when you click ‘Refresh
Values’ on top of region 2.

Region 3 in above pic–>Values chosen from List 2 that you

want to pass to the organization prompt.

Once you click “execute query” , these values that you see in
region 3 are passed on to the BO server for execution.
Enough said about the BO prompt, lets look at a dashboard
prompt that comes with OBI Applications Analytics as we saw
before.

See the dashboard prompt above .. when you click on .. next

to each text box for each of the different columns which are
part of this prompt. You can choose your values just like as
you did in Business Objects (BO).

This below picture shows how you can select your values for a
dashboard prompt..
 Hope this discussion helps and please comment down if you
want to share yout thoughts …

OBIEE Logical Table vs Logical Table Sources – Best Practice

Posted on February 26, 2009 by idelatorre| 2 Comments

The difference between Logical Tables, Logical Table Sources (LTS) and the physical tables that
compose a Logical Table Source, here are some basic guidelines that have helped me get this concept
to seat more clearly in my mind.
 BMM Layer - Logical Table and LTS

Logical Tables like organization in the picture on the left are used to create drill down paths or
dimensions like Dim_Organizaition.

Usually when you drag and drop a column from a table that is not currently being used in your
logical table, the physical table containing such column gets added as a new Logical Table Source
(LTS) such as UofA on the image on your left. This most usually is not the result you should be
aiming for, in general, when a the column you are adding to a Logical Table comes from the same
system of record you have been using you should just rename the LTS to reflect the name of the
system of record in the same fashion we renamed ours to UofA and then go edit the sources for this
LTS.

The confusion often stems from having what I would call “Logical Table Source” Sources
(LTSS). The image below depicts them for UofA, you can acces this dialog by double clicking any
LTS.
 BMM - Logical Table Source Properties and LTSS

Physical Table FRS_GL_ACCOUNTS is a “Logica Table Source” Source (LTSS) for Logical
Table Source UofA. The rationale again is that UofA represents a system of record (source) that
brings in information from more than one physical table to build our organization logical table.