We recently had a debate on the Universe design process within our team.
Scenario: We have a highly normalized (3NF) database which has about 1000 tables with almost 10-12 subject areas.
The debate is that once section including the some IT and business users argue that they prefer a Single BO universe so that it will help them to do adhoc reporting, myself and some IT guys were on the other side of the table were we argued on multiple universes based on the subject areas even we said the it should be design in Kernel approach where one core universe with necessary dimensions and it gets linked to the other universes. Most of the reports are across subject areas.
Experts, please do give us and insight which method we should follow and what will be the pros and cons of each method.
Subject area universes make the most sense. But, the right answer is to group subject areas that really go toghether. For example, Bookings, Billings and Backlog are 3 subjects that go together. But, it makes no sense to also put in Purchasing in the same universe.
Yes you are absolutely right, can you suggest me some valid reason to argue on this I can talk to the Business users technically but I need some Plain English points to debate on this. I cannot go and tell the IT head and argue that what he is telling is ridiculous :-). The reality is that some IT vendors have suggested him and business users that they can do it in the so called Single universe.
Seems there are no actual reporting requirements defined…
Having worked with and sufferred the one universe fits all approach, I can advise that you are much better off seperating it into separate subject areas.
Working with 3nf databases is not really ideal when working with BO, IMHO, as I find it works better with a proper dimensionalised DW.
Some of the problems, i have experienced, with having one size fits all can be summarised as follows:-
Make the universe difficult for people to understand, especially new starters, too many objects too much complexity.
Leads to many objects being created and not then used by the users.
Can hinder concurrent development, as it makes it more difficult for more than one developer to work on the universe at one time.
Increases universe load times and upload times.
Leads to the ‘bolt on’ approach which increases complexity until the data model gets too difficult to understand.
I’m not really a fan of linked universes either as I think that linking DPs on the report is a bettter option, although each case must be looked at individually.
The bolt-on approach is a reactive environment where you have to keep tinkering with the universe because the user doesn’t have a clear set of reporting requirements initially for you to design your universe against. Adding an extra column is a minor change, a couple of tables and a new class and objects is a bolt-on.
It’s not a formal method, more a description of what you end up having to do in a reactive work environment.
I suggest the big universe approach. I specialize in Oracle Financials development, Oracle Financials has well over a 1,000 tables and that is what I recommend for Oracle Financials. Most of the 1,000 tables aren’t used and even fewer have meaningful data, so if your application is similar, the number of tables in the universe will be a lot less.
There are several advantages to one big universe:[list=1:c5a5faa7c2][:c5a5faa7c2]You can union together very disparate data. Power users will often want to combine data that you think is totally unrelated[:c5a5faa7c2]It’s clear what is available and what isn’t. The users don’t have to search 8 universes to see if some minor subject area is there are not[*:c5a5faa7c2]Users can be inspired by seeing what their reporting options are. For example, a power user for Sales might be inspired to create reports that include items due to be received on PO’s if he can see purchasing data. If he/she can’t, he/she is less likely to think of it[/list]
With a lot of tables that can be used in multiple ways, it is vital that you alias each table for each use. If you create what I call a “table cloud”, you quickly reach the point where the universe is impossible to maintain because you don’t know all the impacts of a single change.
This issue has come up several times before. Searching on “design methodology” will find a few of them. The consensus seems to be that universes with hundreds of tables are a bad idea.
A super-large universe becomes extremely difficult to unit test. It will take much less time to develop and unit test a bunch of small universes than one super-large universe.
Do you have reporting requirements for a single report that needs to pull data from these 1,000 tables? Wanting one massive universe is another way of saying that defining reporting requirements is too difficult.
Who is going to explain to new users which objects they should and shouldn’t be using?
Querying two universes in a report and linking the data providers is always a possibility. If users start doing this a great deal, then I would think about making a larger universe by copying and pasting.
There is no reason you can’t have a number of small universes for specific subject areas and a few larger that combine some of these subject areas for the power users.
Another reason against one big all-containing BO universe -> access rights
How would you define the access rights for some small part of this big universe to one group of users and access rights to another part of the universe to another user group?
When you have more smaller subject-oriented universes then you can grant/revoke access rights to users/group of users more easily.
Well on the schema - legacy - that I’m currently working on they are, well nearly 700 of them. Its fine in your situation as you understand the Oracle financial data structure, but is more difficult when going in somewhere for the first time when working with structures of this size.
Then can often get frustrated when, especially when using OLTP, that contexts and incompatables means they cannot run the query in one go, anyway.
I agree with this to a certain extent, but surely with adequate business process knowledge they would turn to the ‘Purchasing’ universe for such data and link the DPs.
Agreed, but should general / non power users cope with the complexity?. I think the compromise suggested by nathanebht of having different universe(s) for power users could be a good idea.
Then we get into row and object security, not pretty…
I think the best implementations of BO - imho- come with clear reporting requirements and adequate training, both in the use of the tool and required business knowledge to do a particular job…
Thanks for all your inputs. I’ll collate all the necessary points and give a presentation to the stake holders.
We also have a reporiting requiremnts in place.But someone has misdirected the stake holders with the idea of all-in-one universe. Anyway we are going to fight for the multiple universe approach.Wish me good luck
Absolutely. If you don’t know the application well and you are dependent on information transfer from developers who are busy with their own work, it is hard to build any universe correctly. I try to stick to Oracle Financials work because my knowledge of the table structure makes me so valuable.
The way I design my Oracle Financial universes, this doesn’t come up. Each top level class is its own context and the user gets an error message whenever he/she cross classes. The challenge is to add all of the most important foreign key references to each class.
I never underestimate people’s ability to know only their little corner of the world.
For the most part, I disagree. The way I structure my Oracle Financials universes, a non-power user is only going to be interested in a couple of top level classes, so it is easy to train them to focus on those and ignore the rest.
I am not a big fan of security. I have seen time and time again that whenever you try to implement some security rule, some case comes up where you need to break the rule. If you think it is important to have a Purchasing universe with just purchasing information, then I would suggest creating a big poweruser universe and then creating subject area universes from that by hiding all the non-purchasing classes.
Clear reporting requirements - I have just given up on ever getting those. My experience with requirements is summed up in a post I made I while back:[quote:98e8c10c14=“Dennis W. Disney”]To make life simple, let’s say there are three types of data warehousing projects:
“Same Data, Different Delivery” data warehouses, where you are taking data that is available now and delivering it through a different means. For this type of project, your goal is to re-create the existing reports, mapping the data from the old system to the new system
“This new system means we need new reports” data warehouses, where a new ERP/CRM/etc. implementation is replacing the existing ERP/CRM/etc. Again, you are mainly re-creating reports, but you have to figure out what the equivalent of “POD SCH QTY” is in the new ERP/CRM/etc. system
“We’re implementing a new system and we have no idea what reports we need” data warehouse, where you are implementing a brand new system and there are no existing reports.
What you will discover is that no one wants to talk to you long enough to actually tell you what the REAL requirements are. For types #1 and #2, the users are going want to give you only the existing documentation on existing reports, even if the documentation is out of date and they don’t use those particular reports. For #3, the reports they want are a lot like pornography - they can’t define it, but they’ll know it when they see it.
[/quote]
Hi Dennis, thanks for all your comments, this is turning into an interesting debate… 8)
True, can’t argue with this one…
Seems like nearly everyone that contributes to this board comes up with statements like this time and time, again. This is the key reason, IMHO, why a lot of data wareouse projects are doomed before they start. Even the question of let us know your top 20 business questions is very often met with a stony silence .
LOL - good analogy couldn’t have put it better myself…
What I have read on the forum, the linked universe has several disadvantages. But logically thats the approach to look forward to (if implemented correctly), can anyone tell me what is the roadmap for linked universes in BO?
Its better to have the multiple universe based on the subject area or facets. Having 1000 table in one universe will have impact when you try to do refresh structure of the universe or do import. We have a universe called GLMIS will take a day to do refresh structure after showing all the magic…(Obiviously hang for a long time).
While designing report its hectic to go through all the classes and pull out the objects for the report requirement if the universe have the make up of classess and objects for 1000 table…
So its better to have the universe on Subject Areas…
Your mileage may very. I am currently at a client that I built a Oracle Financials universe for 5 years ago. It covers GL, AP, AR, Order Managment, Purchasing, Inventory, WIP, Pricing, Bills of Materials, Requisitions, Employees, Labor Hours, Item Costing, Receipts and Service Equipment. 166 tables, 698 aliases, 3122 objects. It works very well for them and they are very happy with it. They are so happy with it that 2 years later they had me build a similar universe for a sister division. For the power users, everything they want is one place. Right now, they are having me add more to the universe.
The biggest challenge in working with it is that some contractor did an “Arrange Table” and then saved the changes. They have re-laid out a couple of the contexts, but most of the tables within a context scattered hither and yon.
In my opinion it depends on the sophistication of the end users as to what the best approach is.
A lot of the benefit of BOBJ is that end users are able to create their own reports without detailled understanding of complex data structures. In most environments this means keeping universes small and focussed to the job they are intended to do so that end users with limited understanding of the data structures will be able to safely generate reports.
However, this will vary from site to site depending on the end users and the extent of decentralisation which is employed by the client in terms of report writing.
Cindi Howson - in her excellent referrence guide recommends a couple of hundred objects per universe as a starting point, although its always a case of horses for courses
(BOB member since 2006-07-21)
(BOB member since 2002-06-25)
(BOB member since 2005-01-06)
Don’t think I could have put it clearer myself, Mark!
(BOB member since 2003-11-27)
(BOB member since 2007-06-18)