When seeking to upgrade one must assess first the current version of applications that they are on. There is an immediate path for Siebel Analyics 7.5.x (specifically 7.5.3), Siebel Business Analytics 7.7.x and 7.8.x, Siebel Life Sciences 7.8.x and of course OBIA 7.9.x. But more important than determining if your current version of Siebel Apps or OBIA has a direct upgrade path is to consider why you would conduct a migration/upgrade to the latest verion in the first place. This really, in my opinion, boils down to a business decision. But as Oracle states in its OBIA upgrade documentation perhaps one of the following reasons are compelling enough for your organization:
1. You are already upgrading your ERP system
2. A desire to rock n’ roll with Oracle BI 11g’s platform latest and greatest features
3. There is a need for OBIA’s latest db support, language support, and other features
4. Cost savings due to end-of-life support maintenance to support your existing legacy in-place ERP, DB, or ETL (Informatica) versions.
5. The business requirements just demand the best, latest, and greatest version and all that it can offer. The future is for the taking.
Really Dude, What are my options?
I think it boils down to an executive decision. Either conduct the upgrade of OBIA and go full bore and get all of the benefits or conduct the platform upgrade to Oracle BI 220.127.116.11 (or the latest version) just to ensure that your team gets the new platform features. Either of those decisions get your team on the latest version of Oracle BI to leverage and learn Fusion Middleware and all that surrounds Oracles roadmap for integration. It’s a good train, get on it.
Of course, there are implications to both. The former option is clearly more resource and time intensive. You’ll be setting up the latest Oracle BI foundation/platform infrastructure in either case. However, if your team does not have solid Oracle BI (OBIEE) resources in house, I highly recommend getting some outside assistance from a Oracle partner that specializes in BI. I think of a Oracle BI novice resource as one that has not yet implemented Oracle BI Apps although there are some clear levels of skill here which can vary that opinion.
Upgrading Oracle BI Applications with either approach should not be taken lightly. Proper planning should take place but again it is highly recommended to bring in an Oracle BI partner for this process. Because you don’t know what you don’t know and there are many hindering or costly factors which can affect an OBI upgrade which could be mitigated by bringing in that helping hand and guidance of a partner.
A platform upgrade for Oracle BI Apps or a simple Oracle BI platform/custom built solution have about the same level of difficulty regarding installation and configuration. Clearly, depending on the complexity of a custom built OBIEE solution (i,e,: number of data sources, subject areas, and dashboards/reports), factors such as re-modeling, post-configuration updates, regression testing, etc. can take just as long as a platform update of your Oracle BI Apps implementation. The benefit of doing a platform upgrade for OBIA is that you get a quicker win than doing a full OBIA implementation upgrade which would include installation of the DAC and Informatica toolsets, and the process that goes along with full loading and testing the ETL and custom modeling work.
Oracle’s upgrade document goes into some detail on the technical changes from upgrading OBI Applications. I won’t do so here as the main point to draw on is that Fusion Middleware changes everything. So, get a resource, stick him/her in the basement with a few books, the Oracle product docs, a few VM Images, and access to Oracle E-Delivery and let em rip into FMW. You’ll need someone on your team that at least has begun to understand the basics of FMW or be prepared to get some outside help.
In the End – Parallel Test ’til the Cows Come Home
I’ve seen clients wanting to run OBI 11g over there existing OBI 10g environment infrastructure on the same servers. This makes parallel testing tough but still possible. But, no matter the challenge, parallel running of the OBI 10g and 11g environments (dev, UA, prod, etc.) to compare and contrast a stable previous version environment against the newly upgraded environment is paramount to the project’s success. This process alone can take multiple weeks to complete. Start the buy-in from the business/end-users early on in the project to ensure they have set time aside for this invaluable and crucial part of the project. Without regression testing or without the end-user/business interaction it will be difficult to truly state that the migration/upgrade was a success. And, yes, automated regression testing does have a place here but many are still leery of that when it comes to BI, just remember that.
So, to wrap it up, I feel better having written this post as experience with several upgrades has shown me what works and what doesn’t. There is a lot more detail than what I have shared, clearly. But the above should give you some indication to the right approach to upgrading and a few reasons why to upgrade and even then options in which type of OBIA upgrades are possible. Key buzzwords to recap are planning, partner assistance, and parallel testing.
- Patching FMW
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Imagine there are over one hundred logins in the source server and you need to migrate them all over to the destination server. Wouldn’t it be awesome if we could automate the process by generating the scripts for the required tasks?