July 13th, 2012 by Mark Rittman
In the previous two postings in this three-part series, we’ve looked at the Oracle BI Applications product roadmap, and what new features and components the 11g release is likely to use. In this final posting, we’ll try and answer a question that we often get asked by customers and BI Apps developers – what can we do now to prepare ourselves for upgrading to the BI Apps 11g? As a quick refresher, here’s the links to the other postings in the series:
- Looking Towards the BI Apps 11g Part 1 : Oracle BI Apps 11g Product Roadmap
- Looking Towards the BI Apps 11g Part 2 : Oracle BI Apps 11g Technology Innovations
- Looking Towards the BI Apps 11g Part 3 : Preparing for Oracle BI Apps 11g
In the previous posting on the BI Apps product roadmap, we talked about how Oracle plan to support both Informatica PowerCenter, and Oracle Data Integrator, as data integration tools for loading the BI Apps data warehouse. Current plans are for the first converged release of BI Apps 11g that covers both Apps Unlimited and Fusion Apps sources to use ODI as the data integration tool, with support for Informatica to come later in the twelve month period. As there aren’t plans for migration tools to move you from Informatica to ODI, and Oracle have said that they won’t make customers move from Informatica to ODI, what does this mean for customers and developers using the current 7.9.x series of products?
My view is that if you’re currently using Informatica to load the BI Apps (as everyone will be), there’s little point in planning a move over to ODI. If you’ve got lots invested in customisations, your development team know Informatica well, so forget about ODI and just extend what you’ve got – you’ll be able to automatically upgrade and migrate your current Informatica repository and mappings to the 11g release, and support for Informatica as an ETL tool will be continuing for as long as we all care about it. The only reasons I’d have for planning a move to ODI would be if your existing BI Apps 7.9.x setup clearly needs to be junked and re-done; possibly because you’re on an old Siebel Business Analytics release, you’ve not brought any ERP content in anyway, and your plan is to start from fresh with the 11g BI Apps release – at this point, it’s probably going to be easier and cheaper to go with ODI and you can also use the tool, and skills, for other DW and data integration projects in your organisation.
As a developer, you could use this dual-support for ODI and Informatica as an excuse to learn ODI, but realistically unless your organisation uses the 11g upgrade to completely re-implement your BI Apps system (leaving behind all existing customisations, historic data and so on) you won’t get to use it on an ODI project. That said – ODI is clearly the tool, outside of the BI Apps, that Oracle see as strategic for their data integration needs, so it’s a very useful skill to have and one that we’re training all of our developers up on.
Of course if you’re not currently a BI Apps customer, but you’re planning on moving to BI Apps 11g some time in the future, then I would recommend using ODI over Informatica for your new installation, with a few caveats. ODI clearly will be the data integration tool that Oracle will put most effort into with regards to the BI Apps, in terms of their own development work, first opportunities for integration and so on, but beware of the “small print” when looking at what ODI will cover in terms of modules, target databases and so on; it wouldn’t surprise me, for example, to find that ODI is supported as the data integration tool for BI Apps 11g but only initially with Oracle Database as the target platform, or only for the mainstream ERP/CRM modules but not the industry vertical applications. So if you do plan to use ODI from the get-go when support for it arrives in BI Apps 11g, make sure it covers your source and target platforms and your choice of modules, and also expect to be a bit of a “pioneer” in terms of working through the BI Apps-specific kinks in ODI at least for the first few releases.
So apart from decisions around ETL tool strategy, what else can customers and developers do to best prepare themselves for an upgrade of their 7.9.x BI Apps system to 11g, once this becomes possible? Most of the recommendations are around the customisation process, and are really general “best practices” in this area that hopefully you are following anyway:
- Where possible, try and make as few customisations as possible to your BI Apps system, as it’s moving these customisations through the upgrade process that takes the most time
- If you have to make customisations, keep them as simple as possible, doing as many customisations as possible in the dashboard and RPD and only if really needed, the OBAW and ETL process.
- When creating ETL customisations, follow the “best practices” of adding extra columns as X_ columns, keeping custom version of mappings in their own custom folders, follow the naming standards and make sure you maintain key columns like INTEGRATION_ID, ROW_WID and so on – doing this keeps everything separate, and it makes it easier to follow the upgrade guidelines that Oracle publish with each new release.
- When you make customisations, ensure you document them; not only what you did but why you did it, and make sure the documentation covers changes to the RPD and catalog as well as the Informatica mappings. The main reason why I see BI Apps systems that are effectively impossible to upgrade is because there’s been no prior control over the customisation process and no documentation, and therefore there’s no way of working out what needs to be brought through to the upgraded system or how to recreate the customisations (or indeed, if they need to be recreated at all)
We covered the BI Apps customisation process in a couple of postings a few years ago, and the process has changed since the Siebel Analytics days; but if you’ve customised your system in at least the standard way, separating customised mappings into their own folders and documenting everything including the business logic behind them, you’re in a much better starting position than many customers.
The other thing you can do to prepare for Oracle BI Apps 11g is to get yourself onto the 18.104.22.168 release as soon as possible (or 22.214.171.124 when it comes out), upgrading yourself step-by-step through releases until you get to there. The 126.96.36.199 release uses OBIEE 11g as the platform, uses Fusion Middleware (application roles) security, and given that release dates are always a bit flexible you’ll not be dependent on moving to the full BI Apps 11g release to start making use of OBIEE 11g platform technology such as better pivot tables, mapping, Oracle BI Mobile and Oracle Exalytics.
As a short-cut you could just upgrade your BI platform to OBIEE 11g but not upgrade your BI Apps, but if you’re planning to adopt BI Apps 11g in due course anyway, you might as well make a start now on the full upgrade path.
So there we are; over the past three days I’ve tried to answer a few questions we’re getting from customers and developers over the BI Apps product roadmap, and what we can do now to get ready. Keep an eye on the blog for more news and analysis around the BI Apps 11g as the converged release comes on-stream, and contact us now if you’d like any help with upgrades, implementation or training around the Oracle BI Applications.