What Not to do on a BI Project Series – #3 Deploy Modules
This episode of What Not to do on a BI project is one that I’ve been seeing more and more of recently. This is partly due to greater and greater BI Apps penetration combined with the fact that many folks just don’t “get” the BI Apps.
What is a Module?
Modules we tend to think of as stand-alone or minimally integrated pieces of functionality. There may be some overlap, but not much. As such, they are generally independent from each other. With this independece comes a lot of freedom and flexibility. This allows you to deploy one module separately from another, even with separate project teams doing the migration. Its kind of like the MS Word Team can be separate from the MS Excel team, with only a little bit of overlap. In fact, Microsoft could deploy a newer version of one office app alongside MS Office – I think they did this with Visio and Project in the earlier days. In enterprise application terms, the deployment of an HR module is relatively separated from the Order module.
So, modules are mostly disconnected from each other, allowing them to be independently managed and deployed. An overlay of a module into a production system can be separate from everything else. This is good programming design – modularize and insulate your modules from others to try and make them as free-standing as possible to allow greater deployment options and flexibility.
BI is Soup
BI is about Integration, not isolation. BI is about gaining additional benefits when two pieces are put together and producing a third piece. It is about broad based information analysis – not isolated datasets.
As a general example, the concept of 360 degree view of the customer is what we’re after. This concept brings as much information as possible about a customer together into one place so that it can be used together to gain a complete profile of your customers. This may include information about their product & service orders & their history, warranty issues, payments, market analysis and competitive environment. Here, benefit is gained by going cross module – across Billing, Sales, Customer Care, and Marketing. We gain when we break up modules and treat them as the same system.
This is the exact concept that drives great BI. Smash apart modules and mix them together into an informational soup where each peice mixes with other pieces to produce something that has never existed before – new insights.
In BI, integration of information comes via tables and the supporting ETL and BI tool code on top of it. Modular thinking would lead you down the path of having separate ETL streams with separate database schemas and separate BI tool metadata. All of the common objects would be duplicated, with extra measures needed to ensure they do not get out of sync. If they do, then you have missed a great opportunity to fix (at least partially) the dreaded Multiple Versions of the Truth problem. Furthermore, you would then needlessly be dupliating data, increasing your source system impacts and reducing your batch window. Finally, doing so would cut off any chance of drilling around and integrating data.
For Oracle’s BI Apps, the use of Modular thinking is too easy – they are sold as modules, making the leap to modular implementations very short. But make no mistake -they are not modular. They are tightly integrated, leveraging substantial common code and data. Their goal is to have as many conformed dimensions as possible. Even their metrics have overlap: for example, Financial AP Metrics are part of both Procurement and Spend Analytics and Financial Analytics. Order Metrics are used in multiple places throughout the BI Apps. Trying to separate them into different code environments is not only counter-productive, its flat out difficult!
Projects vs Project
What does this mean for your OBI system and how you deploy it?
First, stop using the word module and anything similar to it. Stop having separate projects aligned to those modules. You are not doing Supply Chain, Financials and Order Management projects – you are working on 3 functional areas within you single BI project. “This release of BI contains new content for supply chain, financials and OM users.”
Align all of these into their own single work thread across all functional areas:
- Project Management – As you are deploying one BI system, you should have one and only one Project manager working from a single project plan.
- User Interface structure/high level layout and standards
- Development Standards & Best practices
- Object Naming standards
- Security Model
- Master Data Definitions (Data Governance)
- Deployments – One BI system has 1 deployment date at a time. Plan for quarterly major releases of the BI platform along with functional area specific reporting content.
- Overall data model architecture & common object design
- Testing process & Plan
- Database support
- Source System support
Drill down tasks will be needed for each functional area across the SDLC (e.g., Requirements). Try to link all of the requirements and data definitions into an integrated document with separate sections perhaps for each. Do not maintain full separate design documents, as each is in isolation of the larger picture.
A special word about deployments
Even if you don’t buy into the whole integrated BI thing, or simply aren’t ready, consider a planned and coordinated release schedule. BI deployments are very expensive. It takes weeks for each round of testing, regression testing, code migrations, ETL bugs, etc. Try to minimize the frequency of your migrations to cut down on the sheer overhead you have to endure for shorter deployments. Deploying separate projects one after another will require twice the deployment efforts – try to merge the deployments into a single deployment.
Additionally, the fewer parallel development efforts you have, with fewer rapid-fire deployments, the lighter your computing environment needs will be. If you have 3 parallel development efforts with close but different deployment timelines, you’ll need 3 stacks of environments to support them while they go through development and testing.
With a more coordinated, longer release window approach, your environment needs will lightened substantially. Ideally you should only need one DEV environment!