Daily Business Intelligence
An important element in the marketing message around Apps release 11i10 is what is referred to as Daily Business Intelligence. It is the result of Apps picking up database features such as Materialized Views and working with Server Tech on bringing BI and OLAP to the operational database. This by the way is now a major trend in Oracleâ€™s BI architecture with OLAP and Data Mining engines embedded in the 9iR2 and 10g Database Server.
Instead of having the operational database bear the weight of frequent data-unload to the data warehouse as well as suffering from a time-delay between operational events taking place and the moment at which they become available in the data warehouse (the analytical database) for reporting, Daily Business Intelligence aims for delivering analytical capabilities right from the operational database. Materialized Views can be used for pre-aggregations â€“ and through the query rewrite technology, such Materialized Views need not even be exposed to the BI Applications â€“ to speed up reporting. Of course the operational database will have the additional load of the analytical reporting, but with materialized views, embedded engines, some of the SQL Analytical Functions etc. this load may very well be a minor issue.
An important benefit of this way of doing BI is that there still is a link from the aggregated, consolidated data back to the underlying operational data, the actual business transactions. Daily Business Intelligence essentially allows drilling down from consolidated figures to operational events.
A Dutch logistics company, PLD I believe, recently implemented Daily Business Intelligence and were live within 8 weeks!
Java/J2EE Technology and HTML User Interfaces
John expressed a great faith in the developments around HTML user interfaces. Oracle Apps “bets the bank” on Java Server Faces (JSF), Oracle 10g JDeveloper ADF (Application Development Framework) and UIX 3.0. He is convinced that DHTML user interfaces, fueled by JSF components, will allow Apps to develop User Interfaces almost as rich and information dense as Oracle Forms (or other rich GUI) user interfaces.
John suggested that Oracle Apps, thanks in part to their own frameworks and libraries of reusable components, achieve similar developer productivity on both Forms and the Self Service Style technology stack (HTML, Java/J2EE).
This is yet another very strong indication for me that JSF, ADF UIX and ADF are serious stuff and deserve a lot of our attention! John made it clear that: ADF will be very important, Apps is confident that the tools development teams meet the agreed release schedules (without telling what these are) and before too long, serious pilots with the ADF technology can be started. What I conclude from this: Oracle Apps will be using ADF in anger – but is not doing so at this moment. They keep close tags on ADF progress, work with the Tools group to improve ADF and are soon to be starting pilots with that technology. ADF cannot already be considered part of the Self Service Technology Stack.
John gave me two main reasons for wanting to have all of the E-Business Suite on the Self Service Style technology stack:
- The appearance of two very different User Interfaces (Oracle Forms and HTML) works against Oracle in salesdeals. Not because an individual end-user will have to work with both types of User Interfaces – typically and Apps users either exclusively works with Self-Service Style applications or with the applications based on Oracle Forms technoloy. It is just that in a multi-day demo that provides potential customers with a complete overview of the E-Business Suite, customer representatives tend to get confused by the two UI styles they are exposed to – or at the very least it gives Oracle an offset compared to competitors with a more ‘integrated’ UI
- Hiring new development resources. Oracle Apps hires scores of new developers that, fresh out of university, are not only completely untrained in Oracle Forms but apparently also have strong unwillingness to be trained in such a perceived as proprietary tool.
Note that these two motives are not technoloy driven. He does not suggest anything is wrong or lacking in Oracle Forms. These are business motives that drive this decision – and the upcoming technology (JSF, ADF) allows him to act on these motives.
Oracle Designer and Oracle Forms
Oracle Apps makes use of Oracle Designer for Database Design and Generation. They have never actually used Designer for Forms Generation, although they invested a lot of time in trying to do so. John indicated that there are currently no plans for moving from Oracle Designer to another tool for DB Design and Generation; he was not aware of a useful alternative.
When asked about the position of Oracle Forms within Apps, he started by stating that Oracle is an open company where open discussion is not only allowed but even encouraged. And that this question when asked will prompt different responses from different people. His position was the following:
Given the need Apps feels for a single technology stack combined with the fact that the Self Service technology stack before too long provides similar productivity and a user interfaces almost as rich as the more traditional Oracle Forms based stack, he is convinced that Apps will start migrating all of its Forms modules to the Self Service – HTML-Java/J2EE – technology stack.
The road-map for that effort looks something like the following:
- Apps Technoloy performs testing on the target technology, such as ADF and ADF UIX 3.0
- Three or Four pilot projects are performed on representatives from distinct parts of the E-Business Suite; he mentioned for example the I-Store (maximum need for personalization), HR, some Core Financials Functionality)
- When these pilots are deemed successful, a migration plan will be developed and executed for all Modules
He did not give a specific timeframe for the above plan. He indicated that the next major release cycle for Apps (at this moment, Oracle is announcing and will soon be releasing the 11i10 release) will be on the current technology stack. After that, when ADF has matured somewhat and the tests and pilots have been successful, a migration effort will commence. To me â€“ and this just my own impression â€“ this means that within 2-3 years we will see an Apps release in which the first modules that are currently implemented in Oracle Forms technology will be re-released as Java/J2EE based modules. I assume that the complete migration away from Oracle Forms will not be completed within 5-7 years, but that is just guesswork.
John made it clear that:
- There will be no automated migration path from Forms to Java/J2EE. As Oracle statements in its SoD on Development Tools, the architectures of the two technology stacks are plainly too distinct to seriously consider such a migration path.
- Oracle Apps will publish guidelines, hints and maybe smaller scale utilities for customers to migrate their customizations and extensions on Oracle Apps away from Forms and into the Java/J2EE stack. He stressed that this migration knows no â€˜silver bulletâ€™ solution and will mainly be a manual operation.
Apps will use this opportunity to also redesign some of the functionality. John gave the example of HR that was redesigned over the past few years when it was refocused to a largely Self Service style module.
The case of a recently started project for the development of an Airline Loyalty System is quite telling. Given the required functionality and the end-user audience for this system and the fact that the development team was quite comfortable with Oracle Forms technology, Forms was a serious option for developing this Module. The system was scheduled to go live in 2006 and have a lifespan of up to 10 years. The timeframes were reason for Apps to decide on the Java/J2EE toolstack for developing this application, rather than Forms!
It seems clear that a path that some people apparently expect, the merger of Forms into JDeveloper including automated conversion of FMBs to a more OO paradigm, is not on the horizon. Forms has its own space, will sit in that space for at least 5-7 years to come and has a more uncertain future after that time. More integration with JDeveloper, let alone a full fledged automated migration path, is not to be expected.