The Agile Road to a Successful Data Warehouse
Building an Enterprise Data Warehouse from Oracle eBusiness Suite is not an easy task. Most organizations, who are newly implementing Oracle eBS, undergo tremendous changes in business processes. Building the EDW concurrently with the Oracle implementation is possible, but carries many risks. More often than not, the EDW team learns of a significant business process change much too late, when development of that data mart has already been completed. Drastic design changes at such a late stage leave insufficient time for testing which invariably results in poor quality of data and severe design compromises. Data quality is the most critical component of success of any data warehouse effort. When your EDW project must go live concurrently with an Oracle eBS implementation, an agile, customer focused approach is highly recommended.
The other crucial factors for the success of an EDW from Oracle eBS or, for that matter, any data warehouse / business intelligence effort are:
- Thorough knowledge of the business processes
- Good understanding of reporting and analytic requirements
- A best-practice design
- Good coding practices
- More than adequate testing
- User training and communication
The next obvious question is: How do you know if your DW/BI effort has been successful? David Wells and James Thomann of TDWI describe three “types” of success and their definitions as they relate to data warehousing:
- Economic success - the data warehouse has a positive impact on the bottom line.
- Political success - people like what you’ve done. If the data warehouse isn’t used, it’s obvious that you failed politically.
- Technical success - this is the easiest to accomplish. However, don’t overwhelm your users with too much technology. Success also means that the chosen technologies are appropriate for the task and are applied correctly.
(Source: “Data warehouse quality management,” presented by Dr. James Thomann and David Wells at The Data Warehousing Institute’s Fourth Annual Implementation Conference). More on measuring DW quality.
More often than not, organizations that have sustained data warehousing / business intelligence projects for more than twelve months spend considerable amount of money into this effort. The consequences of a failed DW/BI project are not only in those millions of dollars sunk into the project, it is also in the lost opportunities, wasted resources and unfulfilled potential of the technologies and tools.
Often, faced with escalating costs and development time, companies put a financial cap. This forces the DW/BI group to narrow its scope and focus to the most immediate and urgent initiatives while losing sight of the initial and long term goals.
To minimize these risks, DW/BI projects within the IT department should learn from a customer focused approach that traditional software companies like Oracle or SAP employ. These product companies talk to customers and research the market to gain a detailed understanding of not just the functional needs and desired product features, but also of the adoption and usage patterns of their product. They keep their product development costs competitive by identifying common customer needs and building the simplest set of features that can cater to the largest group of customers. Additional functionality and options usually come in later releases and in tiered offerings for customers willing to pay a premium those higher value features.
Data warehousing and business intelligence initiatives can succeed by adopting such a user-focused approach. The initial scope of the EDW must be managed well - one that the team can confidently deliver within a short time (ideally, in less than three months). The project team should be able to identify their highest value customers (users) and their critical needs which will then form the core set of requirements or “user stories”. Additional functionality is “released” at a regular schedule. Every release should include an enhanced set of features, additional subject areas, data enhancements and bug fixes to the previous release(s). This process needs to be consistent, measurable and reliable. It keeps the business sponsors and the users continuously interested and engaged in the development of the data warehouse, thereby ensuring political and economic success.
David Chu discusses a practical development approach for data warehouses in this article in DM Review. You can use many tools to manage your agile initiative. I have personally found Microsoft Solution Framework extremely suitable for successful DW / BI projects. The other agile project management software I liked is TargetProcess.
Whether or not you use a tool to manage your DW/BI initiative, it is imperative that project teams secure the involvement of the “customer” at the very beginning and sustain that involvement during all phases of development and testing. The “Business Analyst” or “Scout” should ideally be a step ahead of the development group, engaging with the user to secure and prioritize requirements for the next release even before the current release is delivered. Just as critical is the need to adhere to a definite architecture and be a “pure-player” within that framework. Kimball’s DW Bus Architecture with conforming dimensions and Inmon’s Corporate Information Factory have both achieved tremendous successes, but trying to merge the two or get the best of both architectures is a treacherous endeavor.
Another practice that I find extremely useful is to get periodic reviews of the data warehouse and BI framework – with the customer (user) to ensure business objectives are still being met and internal assessments within the development team to ensure that best practices and standards continue to be followed in the architecture of the DW, coding of the ETL processes and the design of BI interfaces. These reviews strengthen the relationships with the users and help maintain the strong customer focus throughout the entire project while, at the same time, build a good sustainable standard of development that can help maximize the chances of success.









Some neat stuff there in the blogs.
Food for thought on a future article:
- The need for common Business Rules and Corporate-Standard Metadata to help maintain those rules - how this avoids what seems to be a common problem.
In Kronos and other companies I’ve seen, different users of data will request reports to be written or filtered in different ways. This produces what I once called the Vending Machine scenario of reporting, where anyone with a budget or requirement can push a few buttons and get THEIR version of a report.
As a result, numbers are different for the same supposed criteria, and reconciliations and confusion are the major end-product, not competent decisions.
Nice reads, though, and good real-world concepts/advice. I’ll get around to posting a reply, once I can think of something grand to say, instead of something silly like that “Robbins” character
Thanks,
T.
Leave your response!