Align with Business Goals

---

As discussed in Chapter 2, a data warehouse or business intelligence deployment should be carefully aligned with business goals. As you develop a universe, compare how this universe helps achieve the business goals. Sometimes, companies build new reporting solutions simply because the data is available or because a certain report always existed. However, old reports may no longer be meaningful in today's business climate.

The process of determining universe requirements will vary depending on whether your implementation is based on an existing data warehouse, a new data warehouse developed with BusinessObjects universes, or a transaction system.

Existing Data Warehouse

Just because information is in the data warehouse or data mart, that doesn't mean it needs to be in the universe. For example, data warehouses may contain dimension histories seldom used by end users. Likewise, data warehouses may contain only raw data elements that require a bit more intelligence in the universe. Likewise, just because users haven't specifically asked for something in a JAD session, that doesn't mean it shouldn't be in the universe. As an example, let's assume your company has a goal for on-time delivery performance. REQUESTED_DELIVERY_DATE and SHIP_DATE may be columns in an ORDER_FACT table. In evaluating how this universe is aligned with the company's business goals, a good universe designer will know to add an object called Days Late that calculates the difference between the requested delivery date and actual ship date. Users may not know what SQL functionality can be added to database columns. A universe designer must be well versed in SQL reporting capabilities that can make the universe more robust.

I have worked with SQL-certified consultants who could create tables, optimize indexes, and input volumes of data quite efficiently. If I gave them a report request, it would take hours and days to get the desired results. The consultant may have been technically brilliant but was business-dumb. This mixed skill set can be a challenge in identifying the best universe designer in a company (refer to Chapter 3 for a discussion on project roles). It's often a DBA who has the SQL technical skills. A universe designed by a DBA with little knowledge of the business may be technically robust but lack the business functionality required. Universes designed by power users trained in SQL may have more robust business functionality, but with incorrect joins or objects that result in slow queries. Therefore, it's important that both a DBA and a power user review the initial universe.

New Data Warehouse

If you are building a new data warehouse or data mart in conjunction with your BusinessObjects implementation, ideally your development efforts are already driven by business goals. Requirements gathering in the development stage will drive the fact table design as well as the universe design. As discussed in Chapter 13, many of the issues at this stage will be where to put the intelligence-in the fact table or in the universe.

Transaction System

When your universe is based on a transaction system, some of your universe design choices will depend not only on the business goals and user requirements, but also on minimizing the impact on the source system. While users may want to search on customer name, a nonindexed field, such queries can cripple the source system (thus many organizations implement a data mart or data warehouse). If your company is not quite ready for a data warehouse, a quick alternative is to replicate the tables in the transaction system to a read-only instance of a database. This will better support detailed operational reporting requirements, without adversely affecting transaction processing. Even with this approach, a good designer needs to evaluate which business goals the universe is fulfilling. To follow on our supply chain example, customer phone numbers and contact details exist in the transaction system. This information is necessary for processing orders but useless for measuring on-time shipments. (If you are building a customer support system, then perhaps you need these details.) In building a user-friendly universe, the administrator must constantly evaluate objects that fall into the category of 'I might need it one day.' In an initial universe, defer adding the object to the universe.

Deployments against a transaction system generally fulfill the operational needs of a company but not the strategic goals of the business, as the data is not aggregated. If the goal of the deployment is to provide a Windows- or Web-based, flexible, operational reporting environment, then your universe may indeed re-create fixed reports that exist in the source system. Another benefit of this approach is that the OLTP truly becomes the data entry/processing system, without detailed queries slowing down data inputs.

Lastly, if you are using WebIntelligence (WebI), administrators can now use Auditor to track how often universe objects are used. Prior to and without WebI, some companies use the SDK to create a small application that tracks universe, object, and report usage. You may still find scripts to do this in various discussion groups and system integrator web sites, although Business Objects has never officially provided a solution for tracking full client usage.

---