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.
Today I heard that John Wookey now has overall lead for all of Oracle Apps. Mr. Ron Wohl, previously his boss, apparently is away on sabbatical leave. In hindsight, I have come close to the sun….
See post about this article on Gengmao’s Little Niche
See post on this article on The Future of Forms – Eat Your Own Dog Food December 22, 2004 John Garmany (Burleson Consulting)
Great informational article…more of this
all for now.
(For reference, see this post on
http://www.javafree.com.br/home/modules.php?name=News&file=article&sid=2122)
… não tem espeto de pau!!
Veja como a Oracle utiliza os frameworks de desenvolvimento Java em seus próprios produtos para o mercado de Aplicações Corporativas altamente transacionais – o eBusiness Suite.
when will the next version of oracle apps be made available.. v11 has been out for some time.
Joe
Very interesting article… It’s amusing that Oracle have been stressing for years that
Forms will remain part of the development toolset in Apps.. I guess it boils down to there
not being a viable alternative until ADF and JSF.
I’ve been using ADF/UIX on and off since it first came out and it’s interesting to see
it being used in anger now. If it’s implemented well and allows for Pluggable L&F then
it really will allow clients to develope a corporate look and feel throughout their ERP
and Back Office as well as using Portal etc….
If this doesn’t occur, then Oracle will lose out signifcantly to Axapta, where integration
with the desktop will be seamless (aparently)
What will really blow the doors off proper Apps customisation and integration is when
OC4j becomes the host for the applications tier… Bring it on!
Chris
We can but hope that Oracle SCM will come back in some form one day. At the moment, things don’t look good. Two of the three pro-OSCM Oracle employees you mention are no longer with the company, and the remaining members of the Oracle SCM team are focussed on internal Apps support only. The existing version of Oracle SCM is still fully supported, of course.
The day that new development on Oracle SCM stopped coincided with Microsoft’s announcement about their new “Team System” replacement for Visual SourceSafe. I’m pretty sure it was a coincidence, but it served to highlight that development lifecycle support is still a really important competetive area. I thought that future releases of Oracle SCM would be the basis of a strong Oracle offering in this area (some of the stuff that was being developed internally was very cool: integrated bug tracking, task tracking and version control). Oracle SCM also had a great selling point that you mention: it’s used by Oracle to version control the huge amount of code that comprises the Oracle database.
There are a number of fundamental architecture issues with Oracle SCM 6i/9i that were, for the most part, resolved in the “7.x” releases that we use internally. IMHO, part of the problem with Oracle SCM was a failure to release a “7.x” version externally. For a long time, the team were focussed on providing a hosted version control solution (a bit like SourceCast) that never really took off. In the meantime, a lot of customers started using 6i/9i and because most of the development effort was on “7.x”, customers were not seeing a lot of improvement in the 6i/9i code base.
It seems that now, the strategy is to support existing Oracle SCM customers fully, but concentrate new functionality (in JDeveloper) around third party version control systems like CVS and Subversion. The rapid change in direction was a bit of a surprise to many (myself included: I was responsible for the Oracle SCM integration in JDeveloper, so it had a bit of an impact on my priorities).
See response from Steve Muench in his weblog…
Also interesting: an interview by Tim Anderson with Ted Farell (Architect and Director, Application Development Tools Division, Oracle Corporation). Ted Farell sais – among many other things -: “We do have solutions today. One of our consulting departments has built a product called JHeadStart, and that will allow you to draw a business flow diagram and it will generate a Java application for you. ”
What he says about the next release of JDeveloper (10gR2 I believe, due in November or so) is encouraging:
Brian: if Oracle SCM (or at least an enhanced version of it) is used by such critical and humongous environments such as Oracle ST and Oracle Apps, would not such a product be a much sought after tool for the rest of the world? At some point I believe msrs. Fisher, Bradshaw and Thomas were ready to take on the world (primarily ClearCase) for doing SCM at the Enterprise Level. Do you what happened? Is there any chance of a ‘return with a vengeance’ of SCM at Oracle?
Excellent and insightful article. From our point of view (in tools development), Applications are indeed our biggest customers.
I know a little about the way that Apps and ServerTech (development tools now come under servertech too) organize version control. Most of ServerTech is now using a tool called ADE. This is a front end interface to version control which originally used a ClearCase back end. These days, most products in the ServerTech division are using ADE with an Oracle SCM back end.
Likewise, Applications have a frontend SCM interface called Arcs. They’re in a process of migration between the existing back end for Arcs and using Oracle SCM too.
The big, obvious benefit of both Arcs and ADE is that you can replace the back end SCM system without having a major impact on your developers.
Finally, it’s worth mentioning that Oracle SCM has effectively reached the end of the line in terms of new feature development. The version of Oracle SCM we use internally (much improved from OSCM 6i/9i) will likely never be released as an external product. Much of the development of Oracle SCM in the UK has been wound up. The remaining members of the Oracle SCM team in the UK are now actually part of the Applications division, working directly on Arcs.