This paper has been written in support of the Higher Education Users Group (HEUG). The HEUG is an organization of Higher Education institutions using PeopleSoft/Oracle products.
The paper is a collaborative effort of the HEUG’s Technical Advisory Group (TAG).

This is a publication of the Higher Education User Group, Inc. (“HEUG”) and was prepared by the HEUG’s Technical Advisory Group. It is offered in the spirit of professional sharing among higher education PeopleSoft users with the goal of helping them better migrate to Oracle Fusion. While it may include statements about the
HEUG’s interpretation of Oracle’s intent or product development plans, many factors can materially affect the nature and timing of Oracle’s product releases. The HEUG
Technical Advisory Group has made its best assessment, but there are no guarantees from the HEUG that we are right, nor does the HEUG accept any responsibility for the decisions made if we turn out not to be right.
Thus, as a condition of your reading and using our
, we require that you to agree to the following: In no event will you hold the Higher Education User Group, Inc. or its officers, directors, employees, agents, or volunteers (including the volunteers who serve on the
Technical Advisory Group) responsible for any decision made by individual institutions in their respective planning processes made after reading the information contained herein.
Each institution’s situation is unique, and must be evaluated within its own context.
If you agree, please proceed. If you do not, stop and send this document back to us.
2 of 51 pages

T ABLE OF C ONTENTS ................................................................................................................................................................ 3
P URPOSE & I NTRODUCTION ...................................................................................................................................................... 4
E XECUTIVE S UMMARY .............................................................................................................................................................. 4
SECTION 1: PLANNING & PREPARATION ......................................................................................................................... 6
T HE C HANGING E NTERPRISE A PPLICATIONS L ANDSCAPE ............................................................................................................... 6
K NOW T HYSELF ....................................................................................................................................................................... 6
U NDERSTANDING Y OUR C URRENT E NVIRONMENT ......................................................................................................................12
W HY S TART M OVING TO F USION N OW ? ....................................................................................................................................14
SECTION 2: APPLICATION ARCHITECTURE AND DEVELOPMENT ................................................................................... 15
M OVING F ORWARD WITH E-B USINESS S UITE , SOA, AND F USION M IDDLEWARE .............................................................................15
D EVELOPMENT T OOLS AND P RACTICES .....................................................................................................................................19
SECTION 3: APPLICATIONS TECHNOLOGY ..................................................................................................................... 28
S TEP 1: E STABLISH AND E XECUTE A N E-B USINESS S UITE U PGRADE P LAN ...................................................................................28
S TEP 2: B EGIN A DOPTING S ERVICE -O RIENTED D EVELOPMENT P RACTICES ...................................................................................29
S TEP 3: I MPLEMENT C ORE F USION M IDDLEWARE I NFRASTRUCTURE ............................................................................................30
S TEP 4: E XTEND I NFRASTRUCTURE WITH K EY F USION I NTEGRATION C OMPONENTS ........................................................................32
S TEP 5: I NVESTIGATE AND I MPLEMENT D ATA H UBS ...................................................................................................................36
S TEP 6: E XTEND I NFRASTRUCTURE WITH F USION A PPLICATION D EVELOPMENT T OOLS ...................................................................37
S TEP 7: E MBRACE F USION M IDDLEWARE C OMPONENTS WHICH ONLY INDIRECTLY SUPPORT A PPLICATIONS .......................................38
SECTION 4: EXAMPLES .................................................................................................................................................. 40
E XAMPLE 1: R OADMAP FOR “M OUNTAIN C AT ” S TATE U NIVERSITY ” .............................................................................................40
E XAMPLE 2: R OADMAP FOR “B IG B EAR ” U NIVERSITY ................................................................................................................44
SECTION 5: ABOUT THE TECHNICAL ADVISORY GROUP ................................................................................................ 48
A UTHORS ..............................................................................................................................................................................48
2006-2007 TAG M EMBERS ................................................................................................................................................48
APPENDIX A: FUSION READINESS SCORECARD ............................................................................................................ 49
ENDNOTES .................................................................................................................................................................... 50
3 of 51 pages

This paper is the third in a series of publications from the Higher Education User Group’s Technical
Advisory Group. Its purpose is to provide an E-Business Suite perspective, similar to the previous TAG publication entitled: Roadmap from PeopleSoft to Oracle Fusion for Large Higher Education
Institutions , of June of 2006. The target audience for this paper is information technology professionals in higher education institutions who believe that Oracle’s Fusion Applications will play a role in the future of their enterprise. We intend this paper as a resource in their technology planning, architectural decision-making and software design. Specifically , this paper lays out strategic guidelines and tactical advice to assist HEUG member institutions currently running Oracle’s E-Business Suite with planning for the new generation of applications and middleware.
Much of the material presented in the Roadmap from PeopleSoft to Oracle Fusion for Large Higher
Education Institutions sets forth a foundation which is applicable to Oracle E-Business Suite. The discussion found in Section 2 entitled “Applications Architecture and Development” is a high level view of Service Oriented Architecture and event-driven design and need not be repeated in this paper.
The reader is, however, strongly encouraged to read those sections of the previous paper in conjunction with this document.
Oracle’s “Fusion” is many things to many people. At present it refers to an architecture, a stack of middleware products and to the next generation enterprise applications suite.
Oracle states that “Fusion Architecture is a … technology blueprint that details the linkage between enterprise applications, middleware and … infrastructure technologies.” Fusion Architecture is the application and infrastructure architecture upon which the Fusion Middleware and the next-generation
Fusion Applications are based.
Fusion Middleware is a family of applications support software that embodies the core principals of
Fusion Architecture. This middleware includes portals, process management, applications infrastructure, developer tools and business intelligence tools. True to its role as middleware, Fusion
Middleware promises to allow customers to build business processes for several different applications using APIs and service-enabled integration points and to adopt and manage service-oriented architectures in computing environments that contain many different types of hardware and software.
The Fusion Applications will be a new enterprise applications suite that incorporates elements from the existing collection of application offerings (e.g. E-Business Suite, PeopleSoft Enterprise, JD
Edwards Enterprise one, Siebal, etc.) At the "Halfway to Fusion" presentation in January 2006, Oracle executives offered a definition of Fusion applications:
1.
They will be based on a superset of the functionality delivered by Oracle, PeopleSoft and JD
Edwards;
2.
They will be built on an open, standards-based, commercially available development platform;
3.
They will be designed as business intelligent applications;
4.
They will be service & event enabled, model driven-component isolated, and easier to integrate with existing applications with fine-grained control over business process orchestration; and
5.
They will be scalable and secure, taking cost and risk out of deployment. 1
In January of 2006, Oracle announced that the Fusion Applications requirements had been established, the toolset had been built, the middleware had been built and the data model had been defined. At present a suite of Financial and Human Resources application modules are set for release in 2008.
4 of 51 pages

It is clear that the Fusion Applications are imminent. Current versions of the Oracle E-Business Suite contain relatively substantial service oriented and event-driven integration points, as well as some important Fusion middleware components. Later releases will more fully integrate the Fusion
Middleware technology stack and will incorporate more Fusion Applications features and functionality.
There will be some challenges to upgrading to the Fusion Applications. For example, custom development will have shifted completely from Forms and Reports to JDeveloper. The implications of this shift, alone, will be quite profound for some institutions. Fortunately the upgrade path to Fusion
Applications includes versions of Oracle E-Business Suite that, to varying degrees, include the infrastructure, components, and tools of Fusion Middleware; these infrastructure elements, components, and tools provide substantial opportunities for E-Business Suite institutions to start the process of discovery and planning for the upgrade to the Fusion Applications.
The previous TAG paper, The Roadmap from PeopleSoft to Oracle Fusion…, was written with the stated intention of providing a basic framework of steps and guidelines for adopting Oracle Fusion
Architecture, Fusion Middleware, and ultimately the Fusion Applications. Despite the paper’s initial focus on PeopleSoft customers, the framework and guidelines were generalized enough that E-
Business Suite institutions can easily adapt them to their particular situation. The high level steps outlined in the main paper are:
1.
Establish an overall approach to adopting Oracle Fusion;
2.
Explore service oriented architecture and event-driven application architecture;
3.
Make incremental changes in your infrastructure.
A significant topic that E-Business Suite customers face in planning their upgrade to Fusion
Applications is the role of various Oracle technical development tools. Oracle is a provider of both application development tools as well as their applications. These development tools have been used as foundational elements of not only the E-Business Suite, but also third-party vendor supplied solutions and custom-developed applications. For each of these various application development tools that an institution has used for custom applications or E-Business Suite extension, either of the following will apply:
1. The development tool will continue to be supported when Fusion Applications arrive and will be an integral part of the Fusion applications’ underlying technology, (e.g.: XML Publisher);
2. The development tool will continue to be supported when Fusion applications arrive, but will be incompatible as a means of delivering extensions that are tightly integrated with the
Fusion Applications, (e.g.: Oracle Forms).
The message of this paper is that, despite the fact that the Fusion Applications themselves will not be available for some time, it is possible to start planning for the upgrade. Indeed, those who start to take prudent steps to investigate and to begin implementing some of the Fusion Architecture and
Fusion Middleware offerings will go far toward informing and easing their ultimate deployment of the
Fusion Applications Suite.
While a detailed discussion of all of the functionalities noted above is regrettably beyond the scope of this paper, it is clear that substantial Fusion and Fusion-like functionality is available today , and that even in E-Business Suite there is ample opportunity to begin exploring service-oriented and eventdriven architecture, as well as some very specific Middleware components such as XML Publisher.
5 of 51 pages

The concept of Service Oriented Architecture (SOA) is not new; however, its increasingly widespread use is newer phenomenon. Oracle is not alone in recognizing this trend for its enterprise applications suite software offerings. Suppliers of Enterprise Resource Planning packages including SAP, Sage
Group, SSA Global, and Lawson Software/Intentia International AB have all announced substantial
SOA initiatives. According to Gartner Research, by 2008, SOA will be a prevailing software engineering practice, ending the 40 year domination of monolithic software architecture." In addition,
Gartner projects that "by 2008, more than 75 percent of then-current application packages either will be natively SOA or will expose SOA interfaces through a wrapping layer of interfaces."
This paper adopts the basic assumption that your institution has made a determination that emerging technology trends as expressed in current and future versions of the Oracle E-Business Suite can and will yield value to your institution and that the same emerging trends will enable Oracle to produce more responsive and cost-effective systems in the future in the form of Oracle Fusion Applications.
With the announcement of Fusion Architecture, Fusion Middleware and Fusion Applications, all HEUG member institutions are faced with significant change with respect to their enterprise applications suite software and associated infrastructure. In order to prepare for that change, each institution must answer some basic questions.
The TAG recommends that institutions ask the following additional three questions to assist in formulating their individual roadmaps:
1.
How quickly do we intend to embrace Oracle Fusion?
This question speaks to the overall approach your institution will take in upgrading to the
Fusion Applications; that is, what is the extent to which you will adopt Fusion Architecture and
Fusion Middleware in the period before the Fusion Applications are released.
We have defined three groups of institutions: o “Wait and see” – Institutions that will do business as usual, and which will make no short term commitments to Fusion Applications or Middleware; o “Dip a toe” - Institutions that will proceed relatively slowly and take small steps toward Fusion without committing the institution to the overall adoption of Fusion
Applications. These institutions will entertain the possibility of deploying some
Fusion Technology components in an incremental approach to gain short term, strategic benefit; and o “Dive right in” – Institutions that will commit firmly to the Fusion Applications and
Technology, pursue short term opportunities to adopt Fusion Technology within their enterprise applications suite environment, and will define a service-oriented applications strategy with the goal of upgrading to the Fusion Applications as rapidly as possible.
Do not necessarily classify yourself as belonging to any one of the above groups simply because that group most nearly approximates the way you normally do business with respect
6 of 51 pages

to Oracle upgrades. There may be significant drivers that will place you in a group to which you normally do not subscribe.
2.
What is your timeframe for upgrading from E-Business Suite to the Fusion Applications?
This question speaks more to the execution of the actual upgrade to Fusion Applications as opposed to your embracing the newer technology offerings in version of the E-Business Suite prior to the Fusion Applications. There are a number of factors that may influence where on the overall Fusion Applications timeline you will fall such as: the actual release schedule of the Fusion Applications, your current applications release level, ongoing applications support, the business drivers and the technology needs of your institution, the extent to which your institution has customized the E-Business Suite, staff training, and other system dependencies.
The release schedule for Fusion Applications Suite is currently set for 2008. According to
Oracle, this Suite will include Financials, Human Resources, Projects, Procurement, and
Manufacturing. 2 The exact schedule for release of the Fusion Applications modules and Suite is of course subject to change; as such, the question of timeframe must be revisited and honed as the release schedule becomes clearer.
Oracle has announced that two versions of the E-Business Suite will be eligible for a direct upgrade to the Fusion Applications, and this should have some bearing on when you will upgrade. The versions eligible for direct upgrade to Fusion Applications are Release 11.5.10
(released in November of 2004) and Release 12 (anticipated for general release in spring of
2007). Given this fact, there are only two basic upgrade scenarios, both of which assume a minimum of Release 11.5.10. In a nutshell, the scenarios are: Upgrade directly to Fusion applications from Release 11.5.10 or Upgrade to Release 12 from Release 11.5.x, and later upgrade again to Fusion Applications.
Current Support Policies
The question of ongoing support for the E-Business Suite is an important question in this context. While support timelines remain speculative, a discussion of Oracle’s support policies might be helpful here. As a part of the announcements surrounding Fusion, Oracle announced a “Lifetime Support” policy. The Oracle Lifetime Support policy “provides access to technical experts for as long as you license your Oracle products, and consists of three support stages: Premier Support, Extended Support, and Sustaining Support.” 3
Premier Support lasts for five years; Extended Support is a three-year period in which nearly all of the features of Premium Support remain, for an additional fee beyond existing licensing and maintenance. Thereafter, Sustaining Support begins.
There are some significant exclusions in Sustaining Support. Sustaining Support does not include: new updates, fixes for newly reported bugs, security alerts and patches, new tax, legal, and regulatory updates , new upgrade scripts, certification with new third-party products/versions, or certification with new Oracle products.
At a practical level, running the Oracle E-Business Suite in the absence of tax, legal, and regulatory updates may create an unacceptable level of risk. Perhaps the most significant example of this is the Human Resources Payroll module. Sustaining Support probably will not be viewed as a viable option, and you will need to move to a supported platform before you reach that point.
Release 11.5.10 was generally released in November of 2004. Based solely on Lifetime
Support policies, E-Business Suite Release 11.5.10 will be eligible for Sustaining Support in the December 2012 timeframe. If Release 12 is delivered in the Spring of 2007 as anticipated, it will be eligible for Sustaining Support in the Spring of 2015.
In addition to “Lifetime Support,” Oracle has announced “Applications Unlimited.”
Applications Unlimited is Oracle’s plan to continue providing ongoing enhancements to current Oracle Applications beyond the delivery of Oracle Fusion Applications. Oracle’s commitment to continuing the current E-business Suite is evident in their statement that they
7 of 51 pages

“plan to make additional enhancements to the Oracle E-Business Suite beyond version 12.”
According to Oracle’s Applications Unlimited FAQ, Oracle is “currently in the planning stages details of the enhancements and how they will be delivered.” 4 So while 11.5.10 is the terminal release in the 11i line, customers will have a choice as to whether they will upgrade to Fusion applications or to Release 12. Since Oracle seems committed to providing further enhancements to Release 12 after its initial release, customers will have a fair amount of latitude in crafting a roadmap that best addresses their business drivers.
For a number of reasons discussed throughout this paper, the interim step of upgrading to
Release 12 might be thought of as integral to the overall upgrade to Fusion Applications.
Accordingly, whether you ultimately plan to upgrade directly from 11.5.10 or to first upgrade to Release 12 and then to the Fusion Applications, Oracle’s announcement of a “Lifetime
Support” policy clearly should not be viewed as something which will allow institutions to postpone the upgrade to Fusion applications for any significant period of time. “Lifetime
Support” is simply intended to help reduce enough of the sense of urgency occasioned by
Oracle’s announcements of Fusion to allow institutions to start planning appropriately, and to plan based on strategic opportunities as opposed to perceived exigencies.
Upgrade Paths
As previously noted, there are only two basic upgrade scenarios. Both scenarios assume a minimum of Release 11.5.10. The first scenario is to upgrade to the Fusion Applications directly from Release 11.5.10. Based on probable support timelines, this generally argues for an earlier adoption of Fusion Applications, and may be driven by the desire to minimize the number of upgrades necessary to get to Fusion applications. This scenario is probably feasible where your institution has made very few customizations or extensions. However, it will tend to argue for an earlier adoption of the Fusion Applications.
The second basic scenario is to upgrade to Release 12 from Release 11.5.x, and to thereafter upgrade to Fusion Application. Oracle has recently stated that the initial release of Release
12 will not be the terminal version of E-Business Suite; while there are no further details at this time, it is clear that there will be additional releases containing significant added functionality, and that these releases will be analogous to major point release to which E-
Business Suite customers are already accustomed.
Oracle has made its intentions clear with both explicit statements concerning ongoing development of Release 12, as well as through Apps Unlimited. Overall, Oracle seems committed to continue enhancing E-Business Suite. However, as a practical matter new functionality will start to tail off at some point as Oracle begins to concentrate more fully on the Fusion Applications. Unfortunately feature/functionality lists and hard timelines simply are not available at this time, and review of those in the context of your individual roadmaps must therefore remain an iterative process.
In any event, upgrading to Release 12 will generally relieve more pressing support issues and exposures, and will work better for schools that wish to wait a little longer before adopting
Fusion Applications. The desire for a longer timeline may be driven by a number of factors such as the need to port customizations and extensions, the desire to become better grounded in the new technologies, and/or the desire to adopt more mature versions of the
Fusion Applications.
Upgrades vs. enhancements to meet business needs
8 of 51 pages

In addition to ongoing support policies and your current release level, your business drivers should also be considered in your Fusion analysis and planning. As noted in the main paper, new functionality may be needed in order to meet ongoing business opportunities and requirements. An immediate need might be met through customizing or extending the existing E-Business Suite. In such a case, it will be best to attempt to write the customization or extension as a Fusion-like extension. Such a project could be used as a pilot for learning and validating Fusion Architecture and would also allow you to preserve the investment in that extension when it comes time to integrate it with the Fusion Applications.
The scope and type of enhancements that your school requires may lead you to determine that the new functionality is already offered by a later E-Business Suite Release such as
Release 12. You may determine that, rather than building the functionality required, an upgrade to Release 12 is warranted. In short, if your Institution is on Release 11.5.10 and requires functionality that is offered by Release 12, you may wish to consider adopting
Release 12 in the interim in order to implement the required functionality; this would tend to extend your timeline for adopting Fusion Applications, and might buy you valuable time for other upgrade activities.
On the other hand, assuming that the Fusion Applications will be a superset of the functionality provided by the various Oracle systems and the functionality you require will be included in the Fusion Applications, but not in Release 12 of the E-Business Suite, upgrading directly to the Fusion Applications may be indicated. Myriad scenarios are possible here, and while an in-depth discussion of all the possible decision points is not within the scope of this paper, you must consider your business drivers and opportunities whilst crafting your individual timeframes and roadmap.
Customizations
The extent to which your institution has customized or extended the Oracle E-Business Suite can have a significant impact on your timeline for adoption of the Fusion Applications. John
Wookey, Oracle’s Senior
Vice
President of Applications Development, stated in Oracle’s
Fusion Strategy Briefing entitled “Halfway to Fusion,” “For customers who customize, the reality is, on a case by case basis, this may cause some challenges… We [Oracle] recommend you retire customizations.”
If you have invested significant resources in customizing and extending the E-Business Suite, you will need to carefully map those customizations. It seems relatively clear that the following customizations will be in jeopardy: o Any significant effort expended in creating and integrating custom Oracle
Forms stacks with E-Business Suite using the Oracle Developer toolset; specifically, these are custom Forms and Forms stacks that make extensive use of the Oracle AOL foundation of menus, responsibilities, etc. Oracle has publicly stated that the Fusion Applications will deploy neither the Oracle
Forms 5 nor the AOL constructs used to support them. Despite the fact that
Forms will likely remain a viable technology for stand-alone applications,
Forms that are tightly integrated with the Fusion Applications will not be possible. The Fusion Applications toolset is founded upon JDeveloper using the Oracle Application Development Framework (ADF); there will be no onefor-one conversion utilities to port Forms to the new tools, though Oracle has stated that they will provide support in the form of technical notes, etc. o Just as any custom Forms stacks will be obsolete, any significant effort expended in modifying seeded forms through manipulation under the
Developer toolset will be obviated. Oracle has never recommended doing this, but there are times when this has been hard to avoid. o Any significant effort expended on extending the forms via CUSTOM.PLL;
CUSTOM.PLL is a Forms-based technology and will disappear with Forms in
Fusion Applications. In Release 11.5.10, Oracle has released Forms
9 of 51 pages

Personalization. This functionality is a nearly complete replacement for the
CUSTOM.PLL and may represent more accurately how changes will be effected in the Fusion Applications “forms;” it seems unlikely that there can or will be a direct upgrade from CUSTOM.PLL to the new forms for several reasons. Indeed, each modification will have to be reviewed in the new context to see if is still required, and the business reason for the customization will ultimately be the best guide when the time comes to assess whether a similar change is required to the new applications. o Any significant effort expended in developing and deploying custom Oracle
Reports using Oracle Reports; again, this is a part of moving away from the
Developer toolset. XML Publisher is the Fusion Middleware component that will be the heir to the Oracle Reports technology. Indeed, XML Publisher was originally developed as a technology within E-Business Suite, and true to
Fusion Architecture, is now available for stand-alone use .
Whether or not there will be conversion tools for Oracle Reports remains to be seen. o Any significant effort expended in creating custom Oracle Workflows. Oracle has made it clear that Oracle Workflow will not play a part in the Fusion
Applications. Seeded Workflows will be converted to Business Process
Execution Language, and the BPEL Process manager will be the sole process manager in the Fusion Applications. There will likely be no automated conversion from custom Workflows to BPEL. o Oracle has announced recently that the mod_plsql will not be supported in
Release 12. 6 The mod_plsql is a module on the middle tier that allows developers to use the PL/SQL Toolkit to render HTML pages from the database. The E-Business Suite extended the PL/SQL Toolkit significantly by adding session management and support for plugging such applications into Responsibilities, menus, etc.
By extension, the mod_plsql will not be supported in the Fusion Applications as well. Any significant effort expended in creating PL/SQL-based HTML applications that use the E-Business Suite framework for these types of applications will have to be reworked in some form, either to make them stand-alone applications or by converting them to Java-based applications.
The nature and scope of your extensions, modifications, and customizations will affect the level of effort and therefore time it will take to implement the Fusion Applications. However, the maturity of the release to which you are upgrading will also have an affect on time and effort required, and may well dictate whether your next upgrade (after reaching 11.5.10) is to
Release 12 or to the Fusion Applications.
Staff Skills
The pace at which your development staff is trained in the Fusion Architecture, Middleware and tools will also affect your timeframe. This is most especially true if you have a large number of customizations of the type listed above. This is of course the flip side of the customization coin. Obviously those institutions that have already trained staff in the use of
JDeveloper and allied tools and platforms will be more likely to be in a position to “Dive right in” where their customizations are concerned. Those that do not currently have this investment will need to think about training their staff if they cannot find another way to address the requirements their customizations addressed.
The level of effort and expenditures earmarked for training staff will tend to mirror whether the institution wishes to “Dip a toe” or “Wait and see.” The TAG recommends in all cases that institutions plan to set up and pursue at least some form of training program. At a minimum, select a few key senior developers to receive training with the goal of pushing out knowledge internally and organizing the development staff to deal with the new technologies and
10 of 51 pages

infrastructure. This includes development and DBA staff, and may include some key machine room personnel as well. The more you have customized your E-Business Suite in certain areas, the more you will probably rely upon your developers to have the requisite skills to port those customizations to the new technologies. Both the learning curve and the actual development will affect your timeline. The need to port extensive customizations may even influence a decision to upgrade to Release 12 to gain more time for discovery, training, and porting of customizations.
System integration and database constraints
The extent to which other databases and systems affect your ability to upgrade must also be considered. Many schools have implemented other often substantial Oracle database-driven software packages that can have a direct bearing on when and to what version of the database an institution can upgrade.
For example, many schools have implemented one or more of the following: SCT Banner,
Resource/25, FAMIS, BSR Advance, Resumix, and/or COEUS. In all likelihood there are also a large number of home-grown Oracle data warehouses and other Enterprise applications that need to be considered in the timeline. In some cases, schools have opted to install these additional applications in the same database as the E-Business Suite. In these cases, the upgrade schedule must be coordinated between Oracle E-Business Suite/Fusion Applications and the other Oracle-based applications such that all versions of software installed in any one given database version are all certified to run on the current version of the database and infrastructure. This is perhaps the most difficult case, and will require very close monitoring of releases of all products that will share a database instance.
The Fusion Applications approach to integration is a service-oriented, loosely-coupled approach. In a Service Oriented Architecture environment, resources are made available as independent services that can be accessed without knowledge of their underlying implementation. Loose coupling describes an approach where interfaces are developed with minimal assumptions between the sending/receiving parties, thus reducing the risk that changes in one application or module will force a change in another application or module.
This architecture has the potential to resolve many of the issues that might have led to the decision to tightly couple applications in the same database instance; whereas leaving the applications tightly coupled can and will generate dependencies which defeat many of the benefits of Service Oriented Architecture.
The TAG recommends that institutions with database instances supporting multiple Oracle applications should strongly consider whether such “tightly coupled” applications really need to be managed and run in the same database instance. A review of the benefits and efficiencies realized versus the ongoing dependencies, complexities, and analysis required should be undertaken and considered. This analysis should be applied to both the E-Business
Suite instance as well as any other Oracle database instance that supports multiple applications.
Some schools have other Oracle-based application suites in separate instances but have decided to try to keep them in relatively close lock-step in terms of database versions, shared infrastructure, etc. While not as rigorous as a “global instance” scenario, a disciplined analysis should also be undertaken in this situation.
Finally, there are always compatibility issues with reporting tools which impose requirements as to database versions for all of the various systems against which reporting is performed.
Given the importance of reporting, do not forget to inventory and assess your requirements and dependencies with respect to your third-party reporting tools. Indeed, reporting and analytics may be quite robust in the Fusion Applications. XML Publisher is touted as a tool that can be used by Business Analysts as well as developers. In the course of reviewing reporting requirements, institutions should set aside some time to review their overall reporting strategy and infrastructure and to determine if there is any value in migrating reporting requirements to use the native applications technology.
11 of 51 pages

3.
What is your vendor strategy for applications technology?
As noted in the previous paper, a school’s adoption of the Fusion Middleware stack will depend in part on its overall vendor strategy for its technology infrastructure. Some
Universities will prefer to rely heavily on a single or a small number of technology vendors, while others will prefer a best of breed approach regarding the selection of infrastructure software.
This may not be as much of an issue for E-Business Suite customers as it is for other Oracle enterprise applications suite customers. Oracle’s technology stack choice for Release 12 is the Fusion Middleware OracleAS 10g application server. While Fusion Applications will be released on an enhanced OracleAS 11g application server, the technology stack will remain very similar and therefore familiar. Even E-Business Suite Release 11.5.10 customers will no doubt find themselves somewhat familiar with the technology employed by the Fusion
Applications. In most cases a mature set of infrastructure/middleware software will be in place for E-Business Suite customers when they upgrade to Fusion Applications. This of course cuts in favor of simply adopting Oracle’s Fusion Middleware as deployed with later releases of E-Business Suite and the Fusion Applications.
However, Oracle’s Fusion Architecture should at once allow latitude for those who wish to cherry pick the best-of-breed infrastructure and middleware offerings, while providing a substantially complete technology stack for those who wish to deal with a limited number of vendors. Indeed it seems likely that other vendors will build Fusion and Fusion-like applications components and middleware.
Likewise, some Fusion Middleware alternatives may already be in use by existing E-Business
Suite customers. The example given by the previous paper is of a University that already has a mature identity management solution in place, thus will not consider switching that to the
Fusion alternative. While this is quite feasible, planners should be aware that such decisions will have an effect upon and provide potentially significant inputs into the overall timeline for upgrading to the Fusion Applications.
Since Fusion Applications will not be available for some time, Institutions should take some time now to analyze and document their current environment. Schools that have taken the time to address some of the issues listed below will be better able to define a path to upgrading their E-Business Suite applications to Fusion.
1.
Understand and catalog customizations and extensions. An accurate inventory of the enhancements you have made and the business reasons for the changes are essential. It is appropriate to develop a catalog of your business processes, data objects and transactional application code changes in a way that allows you to cross-reference them.
When faced with an upgrade from 10.7 to 11i, developers learned quickly how to use the updated versions of the Forms products to regenerate their forms extensions. From practical point of view the technology changed little. This will likely NOT be the case in Fusion
Applications. Institutions that have invested heavily in Forms-based extension to the Oracle E-
Business Suite will need to start planning to refactor their custom Oracle Forms stacks. As previously noted, JDeveloper will be the primary development tool, and the “forms” will be written using JDeveloper and Oracle’s Applications Development Framework (ADF).
Once an accurate catalog of all extensions and customizations has been developed, institutions will need to start planning how these will be ported to the new environment. Do not overlook the possibility that the functionality you have created is addressed in newer versions of E-Business Suite or in the Fusion Applications themselves. You will want to stay abreast of the features and functionality to be offered by the Fusion Applications to determine
12 of 51 pages

if there are any customizations or extensions that you can replace with these new functionalities. Indeed, you may wish to have a second look at the customizations and extensions to see if current functionality can be used to cut down on your customization catalog. Also, just as business needs change and give rise to new requirements, old requirements often roll off. Unless you look at the business reason for each customization or extension and query the users as to whether these features are still in use you may plan to port customizations and extensions that are either no longer in use or which can easily be replaced with delivered functionality.
2.
Understand and catalog your custom interfaces. An accurate inventory of your custom interfaces to and between systems should also be compiled. These interfaces are candidates for conversion to Web Services, and an accurate inventory will allow you to determine which ones might provide an opportunity for starting down the path to an overall adoption of a
Service-Oriented Architecture. As noted in the main paper, it will be beneficial to convert interfaces to web services because such service-oriented interfaces will be easier to transition to Fusion Applications in the future. Since web service invocation is in essence a welldocumented “contract” they can remain intact thereby reducing the effort of re-programming and testing inter-application integration.
3.
Understand and catalog your Oracle Open Interfaces. Oracle provides a relatively large number of “Open Interfaces” to E-Business Suite. With these Open Interfaces you can import transactions and data into the Oracle E-Business Suite. These Open Interfaces are usually comprised of a table or tables which are populated with one or more data records and a concurrent manager job to run new transactions and data into the base tables.
With the advent of Oracle E-Business Suite 11.5.10, a number of Web Services-based XML
Gateway interfaces have been added. This trend will only continue. Many of the existing
Open interfaces will be retrofitted; the TAG is in the process of trying to determine the schedule for retrofitting the Open interfaces to this model. Even if the Open Interfaces are not wholly retrofitted in Release 11.5.10 and Release 12 of the E-Business Suite, it seems likely that the this model should be substantially complete with the advent of the Fusion
Applications. You should compile an inventory of all of the seeded Open Interfaces that you are currently using.
4.
Develop a data purge and archive strategy. The move to Fusion will be simpler if the online transactional data is archived and purged from the online transactional tables. As a general proposition, archiving and purging is one of the most important things you can do to reduce upgrade downtimes and to ensure consistent online performance of applications once they have been upgraded. If your institution will be upgrading to Release 12 before the Fusion
Applications, you should consider performing an archive/purge before each upgrade.
Oracle provides data archiving and purge programs for E-Business Suite. An effort to define and implement an archive and purge policy will require both Functional & Technical resources, and will need to focus on both business and technical aspects. Make sure you have addressed information life cycle management concerns within your organization and do not overlook concerns centered on data retention and compliance issues in designing an appropriate archive/purge strategy. Also, do not overlook data that has likely accumulated in your Open Interfaces in addition to the data in the base tables.
Most modules have archive and purge capabilities, and these are usually documented in the individual User Guides. These include GL, AR, AP, PO, HR, FA, PA, Costing, and Cash Management.
There are also Notes on Metalink covering a number of the modules.
7 You should treat the archive/purge effort as a true development effort. You will wish to understand the limitations of each of the Archive/Purge program and test each thoroughly. For example, consider the following: crossproduct data dependencies are usually validated pre-purge; most of the archive and purge programs were written by different development teams, and there are a variety of different interfaces; Multi-org often requires multiple runs for each org; and archival data is generally not available for viewing without customizing. Release 11.5.10 now offers a unified view of the various archive/purge programs. Under Oracle Applications Manager (OAM), the “Applications Dashboard” contains a tab
13 of 51 pages

called “Critical Activities”). This tab displays all of the disparate E-Business Suite archive/purge programs, and allows you to monitor the programs from a single administrative dashboard.
Adopt an enterprise-wide identity management strategy. As noted in the PeopleSoft version of the roadmap paper, institutions with a mature identity management environment will be well positioned for the implementing Fusion Applications. While it will probably be possible to run
Fusion Applications without a standalone identity management environment, the existence of such an environment will only help simplify the administration of and compliance with your organization’s security policies. This would be a good time to start a process of understanding the strengths and weaknesses of your institution’s identity management environment. Create a catalog of your current identity management applications/directories as well as the gaps and issues you have with your current environment. This catalog will position you to evaluate a more robust Identity Management solution and potentially implement that solution as a part of the overall Fusion Applications adoption timeline.
In general the TAG recommends that schools take time now to begin positioning themselves for the transition to the Fusion Applications. Some of this work is unglamorous, but by doing it in advance, you will be able to decrease the cost and size of your Fusion upgrade project.
The previous paper addresses the question “Why start moving to Fusion now?” The paper posits the notion that the Applications Unlimited/Lifetime Support program is not an opportunity to avoid the inevitable upgrade, and goes on to list several reasons why institutions will wish to embrace and start down the path to Fusion Applications now. The statements made in that paper are general in nature and are applicable to the E-Business case. This document does not repeat that material here, but the reader is encouraged to read the referenced material.
Some institutions may be tempted to do as little as possible now and hope that simpler and clearer paths exist in the future. The result of waiting will simply be to shorten the timeframe that the institution has to learn about Fusion applications and to implement appropriate changes to their current E-Business Suite. The TAG believes universities are better served by making small thoughtful steps towards the Fusion Applications now.
Though Oracle E-Business Suite customers might not yet have a clear picture of their applications’ futures, there are some key components that are in fact known today and can be incorporated now into an effective transition plan. The opportunity exists for E-Business Suite users to gradually evolve their application structure toward services, and their technology stack toward Fusion Middleware.
These steps will allow institutions to prepare for the next generation of applications without overly committing their institution to any one path or to any one solution.
Oracle’s Application Strategy team has indicated that they expect the development teams to begin to leverage additional Fusion Middleware components in the subsequent E-Business Suite releases. For example, XML Publisher was originally developed with E-Business Suite in mind, and a number of modules are currently using this tool. XML Publisher will begin to be used to an even more significant degree in Release 12. It will be the premier Reporting tool for the Fusion Applications. Starting to understand this functionality and beginning to adopt it in your own development organization can only have the effect of helping to ease the transition from E-Business Suite to the Oracle Fusion
Applications Suite.
14 of 51 pages

The previous paper has discussed Service Oriented Architecture (SOA), and the basic features and benefits of using services and standards to build event-driven, loosely-coupled applications. This discussion is at a high level and rather than repeat the analysis set out there, the reader is invited to read that paper for this excellent discussion.
With E-Business Suite Release 11.5.10, Oracle has taken some significant steps toward adopting a
Service-Oriented, Event-Driven Architecture, and has incorporated at least one Fusion Middleware component into its technology stack. These enhancements represent a significant opportunity for those institutions that wish to “Dive right in” or “Dip a toe.” Indeed, even the “Wait and see” adherents who are at Release 11.5.10 can easily boast that they are making use of Fusion
Architectural components without doing much at all. For those institutions that wish to “Dive right in,”
Oracle has certified OracleAS 10g Application Server for use as a secondary application server for
Release 11.5.10 for certain, specific purposes. 8
Road to Business Process Orchestration
Prior to E-Business Suite Release 11.5.10, E-Business Suite had few features that truly looked like services or business events. Workflow and Alerts might be thought of as providing the underpinnings for an event-driven architecture; “Event Alerts” could be defined, and could be configured to run
PL/SQL programs when the event fired. The “event” was based on a database trigger behind the scenes. The PL/SQL program run by the Alert could, in turn, launch an Oracle Workflow using the
Workflow API; a workflow could then be run asynchronously with the business process that triggered the event. This capability was in essence the harbinger of some of the capabilities of the Oracle’s
Business Event System released in Release 11.5.10.
The Oracle Workflow Business Event System is an application service that leverages the Oracle
Advanced Queuing infrastructure to communicate business events between systems. The Business
Event System consists of the Event Manager and workflow process event activities.
The Event Manager contains a registry of business events, systems, named communication agents within those systems, and subscriptions indicating that an event is significant to a particular system.
Events can be raised locally or received from an external system or the local system through Advanced
Queuing. When a local event occurs, the subscribing code is executed in the same transaction as the code that raised the event, unless the subscriptions are deferred. The Business Event System can be used in the following ways:
1.
Non-invasive customization of packaged applications - Analysts can register interesting business events for their internet or intranet applications. Users of those applications can register subscriptions to those events to trigger custom code or workflow processes.
2.
Message-based system integration - Subscriptions can be configured to implement point-topoint messaging integration wherein messages will be sent from one system to another when business events occur.
3.
Business event-based workflow processes - Sophisticated workflow processes can be built that include advanced routing or processing based on the content of business events.
4.
System integration messaging hubs - The Business Event System can serve as a messaging hub for complex system integration scenarios. The Event Manager can be used to "hard-wire" routing between systems based on event and originator. Workflow process event activities
15 of 51 pages

can be used to model more advanced routing, content-based routing, transformations, and error handling.
5.
Distributed applications messaging - Applications can supply, generate and receive event message handlers for their business entities. For example, message handlers can be used to implement master/copy replication for distributed applications.
Oracle Workflow Business Event System is a significant addition to the capabilities of Oracle E-
Business Suite to perform “loosely coupled” event-driven tasks. Since it is an extension of existing
Workflow capabilities, it can be readily understood and implemented in your institution by developers and other staff who have previously worked with Alerts and Workflow.
Oracle has exposed more than 800 integration points as business events using this functionality, and this promises to allow customers to more fully integrate and extend internal and/or external application systems with existing E-Business Suite processes and events, while allowing customers to define new processes and events. The existing integration points are centered on major E-Business
Suite flows. Documentation for Workflow Business Event System can be found in the Oracle Workflow
Developer's Guide, starting with Release 2.6.1; the E-Business Suite 11.5.10 embedded Workflow
Release is Workflow Release 2.6.4. 9
It should be noted that the Workflow Business Event System is integral to the integration of Oracle E-
Business Suite and Business Process Execution Language for Web Services (BPEL). There is a growing need for integration between Oracle BPEL Process Manager and Oracle E-Business Suite. The
Business Event System within the Oracle E-Business Suite has been positioned to provide the mechanism for customers to build integration with other applications and systems such as Oracle
BPEL Process Manager in an easy, non-invasive manner. 10
It is important to note in this context however, that Oracle has recently announced that Oracle
Workflow will not be a part of the Fusion Applications. It seems that while BPEL is currently being used to provide integration services between different systems, and Workflow is used as a process manager within the E-Business Suite, the BPEL Process Manager’s role will expand in Fusion applications to embrace the role currently played by the Workflow engine in E-Business Suite. The seeded process flows currently distributed as Oracle Workflows will be ported by Oracle. However, there will not be a one-for-one, automated upgrade for Oracle Workflows.
While the future direction of the Oracle Business Event System is not entirely clear, it seems likely that as a part of Oracle Workflow, the seeded Business Events will be ported over to BPEL by Oracle, and any custom Business Events will have to be manually ported by the customer. It seems likely that
Business Events will survive in some form, but if the current Workflow-based version is used extensively, there may be some substantial porting required when moving to the Fusion Applications.
Given this state of affairs, consider using these capabilities in Release 11.5.10 and Release 11; the functionality is useful and certain gives a preview of an event-driven architecture; pay close attention if you use this functionality with respect to how it will be transposed/ported to the new Fusion
Applications when the time comes.
Integration
In addition to the Workflow Business Event System, E-Business Suite Release 11.5.10 leverages XML
Gateway to offer a method for accessing services within Oracle E-Business Suite. XML Gateway provides XML messages for both inbound communication and outbound communication with Oracle E-
Business Suite. Over 150 XML Gateway messages exist in Oracle E-Business Suite, from Invoices to
Credit and Debit Memos to Purchase Orders, and the majority of the Oracle XML Gateway pre-built messages delivered with E-Business Suite is mapped using Open Application Group (OAG) standards.
Any of these Oracle pre-built message maps may be re-mapped using the XML Gateway Message
Designer. Oracle XML Gateway creates or consumes XML messages based on the Workflow Business
Events System, and every XML Gateway message can be accessed as a Web service. Additionally,
XML Gateway utilizes Oracle database tables/views for creation of outbound messages and the open interface tables for consumption and semantic validation of inbound messages.
16 of 51 pages

While the number of inbound interfaces is currently relatively limited, this functionality is very significant to institutions that make use of the Oracle Open Interfaces. It seems to indicate that the model going forward will be to continue use of Oracle Open Interfaces, to map them through XML
Gateway and to expose them as Web services. New interfaces will likely be constructed in this fashion as well.
The XML Gateway/OAG message maps can now be discovered using the Oracle Integration Repository.
In addition to these interfaces there are many ways of getting information into and out of the E-
Business Suite, including the traditional Open Interfaces. In the past, these have been documented in an assortment of places, including product-specific manuals, the eTRM, and other sources such as
Metalink Notes. It was all rather fragmented, and often incomplete. The Integration Repository is intended to compile all of those sources into a single place.
The
Integration Repository was initially intended to catalog service endpoints available via Service-
Oriented Architecture; it has since grown into a comprehensive reference for all of the E-Business
Suite's business service interfaces, including Web Services, Service Beans, PL/SQL Procedures,
Java Classes, XML Gateway Messages, EDI Messages, Open Interfaces, Concurrent Programs, and Business Events.
The repository can be browsed by product family, drilling down into specific modules, or by
Standards. Either way, you can discover and drill down into specific APIs.
Once you drill into a specific API, the implementation details of the API are documented, including function names, parameters, and rules.
The Release 11i version of the repository is available as an online reference hosted by Oracle. 11
In Release 12 the Integration Repository is expected to be part of Rapid Install, and the repository will be automatically updated with appropriate content as patches are applied to the instance.
Reporting
XML Publisher is a Fusion Middleware component that has been included in recent releases of the E-
Business Suite. XML Publisher allows end-users with tools such as Microsoft Word and Adobe Acrobat to create templates for reports and business documents containing E-Business Suite data. XML data is extracted during concurrent programs execution and is merged with the templates, generating output in a variety of formats, including PDF, HTML, RTF, EXCEL (HTML), or even text for use with EFT and EDI transmissions. In addition to the potential of this tool to allow your end-users to create simple reports for themselves, there are advanced options for integration with email systems, faxes, WebDAV,
FTP, HTTP, barcodes, and more. 12
Users of the E Business Suite will find XML Publisher behind many reports in modules such as
Purchasing and Human Resources. XML Publisher is integrated with the scheduling manager and more and more layout templates are being made available across the various E-Business Suite modules. XML Publisher is positioned to be the reporting solution for E-Business Suite Release 12 and the Fusion Applications, and it is available today in 11i.
User Interface
Forms Personalization has also been released, and is a replacement for most of the functionality offered by use of the CUSTOM.PLL for coding non-intrusive extensions to the E-Business Suite Forms stack. CUSTOM.PLL is a library that is tacked onto the Forms stack, and it contains hand-coded directives based upon Forms names and Forms event triggers. Forms personalization is much more declarative in nature, and is probably a good preview of things to come in the Fusion Applications.
Forms Personalization allows the following declarative changes to Forms: Remove fields from the display, Re-label fields, buttons, and tips, Change field default values, and Link forms and pass context. Changes can be restricted to certain users, responsibilities, or custom conditions.
Oracle Forms technology will continue through Release 12, and will be abandoned with the release of the Fusion Applications. While strictly speaking, Forms Personalization performed in the E-Business
17 of 51 pages

Suite forms may not translate to the new Fusion forms stack, it seems likely that some form of Forms
Personalization and/or OA Framework Personalization will be provided for in the Fusion Applications.
Oracle has previously released Oracle Application Framework (OAF or OA Framework) Personalization which allows HTML-based OA Framework applications to be personalized in much the same way as
Forms Personalization. The OA Framework, upon which E-Business Suite is currently founded, is considered by Oracle to be an early form of the Fusion Applications platform. 13 Early versions of
Oracle’s various self-service HTML applications were based upon PL/SQL page generation; Oracle has recently announced that all of these applications have been moved to the OA Framework. Likewise,
Oracle has announced that all of the Oracle HTML applications based upon individual JSPs are also actively migrating to OA Framework. Oracle has also openly stated that all new HTML development will use the OA Framework.
The Oracle Application Framework (OAF) is clearly the precursor to the Applications Development
Framework (ADF) employed by the Fusion Applications. Both OA Framework and ADF applications employ a Model-View-Controller design pattern that organizes applications according to the data model and business logic (Model), the user interface (View), and page flow (Controller). Both OA
Framework and ADF are J2EE based and feature industry standards such as XML, HTML, Java, JSP,
SQL and Web Services. Indeed, most of the components with which OA Framework applications are developed are components of ADF.
The personalization framework for the Fusion Applications will likely have an analog to OA Framework personalization in E-Business Suite. Use of Forms Personalization and/or Framework Personalization now can:
1. Promote “hands-off” extension to the current Oracle modules, whether they are written in the “Professional Java Interface” or using the OA Framework;
2. Promote extensions that can be relatively easily replicated in the future as required; and
3. Give developers an opportunity to become familiar with this functionality before its ultimate expression in the Fusion Applications.
While any extension to the Oracle Forms should be considered closely and carefully, in situations where small extensions are required, the Personalization functionality may provide a bridge to help get institutions to the Fusion Applications.
Middleware
Oracle Application Server 10g is certified with 11.5.10 for certain purposes. Specifically, if customers wish to use or explore Identity Management, Oracle Integration, Oracle Portal, Discoverer, and Web
Cache, installing and integrating OracleAS10g may be worthwhile. Oracle Integration, alone, offers
BPEL Process Manager and a host of connectors to various systems, and presents probably the single greatest touch point to integration and orchestration for both later releases of Oracle E-Business Suite and the Fusion Applications.
It should be stressed that under Release 11.5.10, OracleAS 10g Application Server must be run as a separate Application Server in addition to the standard Oracle 9i Application Server. This can only be described as an integration of the OracleAS 10g Application Server with the current infrastructure. 14
It should also be noted that the use of OracleAS 10g application Server for the purposes certified will likely entail additional licensing fees beyond the base Release 11.5.10 and Release 12 installs.
However, it offers an opportunity for in-depth discovery of the Fusion Middleware stack well in advance of Release 12 and the Fusion Applications. Of course, OracleAS 10g application server will be the sole application server platform for Release 12; this will afford institutions that prefer to wait ample opportunity to eventually explore Fusion Middleware in advance of the Fusion applications themselves.
In addition to the features and functionality offered by an early adoption of OracleAS 10g Application
Server, Oracle has released the “Oracle JDeveloper OA Extension” for customers with OA Framework
5.10.. OA Framework 5.10 is included with E-Business Suite 11.5.10. 15 As noted previously OA
18 of 51 pages

Framework application development is the precursor of Fusion applications development, and is founded upon components that are an integral part of Oracles ADF, the cornerstone of their Fusion development paradigm. With this extension it is possible to extend E-Business Suite with new application modules using the OA Framework. These extensions should port easily to ADF.
Oracle has also released OracleAS Adapter for Oracle Applications and the E-Business Suite Adapter for JDeveloper. These adapters are distributed with the Oracle AS 10g Application Server, and allow developers to expose significant E-Business Suite functionality via Web services and other SOA-like extensions. The OracleAS Adapter for Oracle Applications supports all modules of Oracle Applications for versions 11.5.1 to 11.5.10. The OracleAS Adapter for Oracle Applications provides real-time and bidirectional connectivity to Oracle Applications through interface tables, views, application programming interfaces, concurrent programs, e-commerce Gateway, and XML Gateway. OracleAS
Adapter for Oracle Applications inserts data into Oracle Applications using interface tables, APIs, and concurrent programs. To retrieve data from Oracle Applications, OracleAS Adapter for Oracle
Applications uses views. In addition, it uses XML Gateways for bi-directional integration with Oracle
Applications. XML Gateway is also used to insert as well as receive Open Application Group Integration
Specification (OAGIS) compliant documents from Oracle Applications. 16
The adapters greatly enhance the programming benefits of JDeveloper in the E-Business Suite context by allowing developers to write OA Framework extensions and expose significant E-Business Suite functionality as services. Applications, enhancements, interfaces, and Web Services created using the tools and adapters for OracleAS 10g application server should port relatively easily to the Fusion
Applications.
Looking Ahead
As previously noted, substantial Fusion and Fusion-like functionality is available today , and that in E-
Business Suite there is ample opportunity to begin exploring service-oriented and event-driven architecture, as well as some very specific middleware components such as XML Publisher.
Release 12 will continue this trend. Whereas Release 11.5.10 is only certified for certain purposes on
OracleAS 10g Application server, Release 12 will be released on the OracleAS 10g Application Server platform. This will be an important step towards the Fusion Applications, and will bring with it strong incremental gains in terms of the middleware stack. For example, the BPEL Process Manager will be an integral part of the technology stack. However, the BPEL Process Manager will still be used primarily for integration between systems, and customers will likely have to wait for Fusion in order to see a truly integrated use of BPEL Process Manager within the applications suite. The Fusion
Applications will be released on a much enhanced version of the Fusion Middleware stack, and a more integrated use of the middleware stack will be evident; in the Fusion Applications for example, Oracle
Workflow will be replaced by the BPEL Process Manager for purposes of human workflows.
Fusion Architecture and Fusion Middleware are clearly much more than mere talking points. The
Fusion Architecture has been well defined. It has provided the guidance and underlying principals for the creation of the Fusion Middleware technology stack. Much of that technology stack has been integrated or enabled in current releases of the E-Business Suite. With the expected availability of
Release 12 in the Spring of 2007, Fusion Middleware integration with Oracle E-Business Suite will be substantially complete. The only milestone that remains is the transition to Fusion Applications. As such, the Fusion Applications are not only imminent, but some of their technological underpinnings are present, in some form, in your current environment.
Oracle has stated their direction, and has provided a great deal of material with which their new direction can be to discovered, explored, sifted, considered, and planned. Given these facts, the TAG recommends strongly that institutions begin planning in earnest for the move to Fusion Applications.
19 of 51 pages

The Tag has come up with tactical recommendations for development tools and practices for larger institutions with respect to the E-Business Suite Environment. Please note that the following tactical recommendations are intended to transcend the decision of what Release will be in place at the time that the Recommendation is implemented. A simple example is that a “Dive right in” institution may wish to create a new Web Service-based interface under Release 11.5.10, while other institutions may decide that they want to do this but defer that work until Release 12. It does not matter so much when you plan to implement these Recommendations, as there will naturally be some variability.
What is important is that you at least consider these Recommendations as a part of your individual plan.
Tactical Recommendations
The tactical recommendations set forth in the June 2006 TAG paper are generally applicable to E-
Business Suite. Specifically: o Write modular code designed to be reused, and reuse existing code.
At this juncture, many institutions will still be writing much of their Non-Forms code using
PL/SQL. While SQL and PL/SQL code are typically not object-oriented, you can write SQL and
PL/SQL code using an object-oriented approach. Begin to prioritize and apply PL/SQL best practices to polish applications.
PL/SQL code will not go away with the Fusion Applications. Oracle has stated many times that it will continue to support PL/SQL. Indeed, if you look at the JDeveloper Adapters, you will see that they are designed to make use of PL/SQL. The Web Services-based interfaces we have discussed elsewhere still make use of the underlying PL/SQL programs to perform the actual imports. Java programmers can easily access Oracle procedures within stored packages in the same manner as they would any Java Class – the JDBC Callable Statement class is built for just this purpose.
In order to be really useful however, any PL/SQL code you do write going forward should be as modular and reusable as possible. The days of monolithic code are gone, and you need to drive modularity and reuse into your coding practices today, even if the units you are currently writing are in PL/SQL.
The more you understand and implement Web Services, the better will be your feel for the level of modularity required to write units that can be effectively exposed as Web Services. A good rule of thumb, however, might be that the executable section of any procedure or function that you will expose as a Web Service should contain no more than 50 or 60 lines of code.
Consider creating libraries of functions and procedures in stored packages as you write new code. Embrace PL/SQL coding best practices, prioritize those practices, and encourage the use of those practices across your module teams. Consider taking the next step and start exposing some of your PL/SQL procedures as Web Services. The OracleAS Adapter for Oracle
Applications and E-Business Suite Adapter for JDeveloper will be invaluable in this regard since they can expose PL/SQL as Web Services.
o Understand the existing Integration Technologies in E-Business Suite.
Work towards insuring that development and infrastructure teams become familiar with the various integration technologies that currently exist within E-Business Suite. At present that generally means Release 11.5.10. Understand the additional capabilities that will be offered in Release 12. Integration technologies include XML Gateway, Web Services, the Business
Event System, Oracle Workflow, and the Integration Repository.
Understand how they are implemented and the tools, frameworks, and infrastructure used for implementing them. These include OracleAs 10g Application Server, JDeveloper, ASF,
OracleAS Adapter for Oracle Applications and the E-Business Suite Adapter for JDeveloper, the
BPEL Process Manager. Understand the Integration Services offered by Oracle Application
20 of 51 pages

Server as well. Begin thinking about how you can use these integration technologies in your institution, and what it will take to begin migrating to these technologies and infrastructure. o Learn about existing and emerging standards for web services.
Educate technical teams generally on common Web Service standards such as: eXtended
Markup Language (XML), Simple Object Access Protocol (SOAP), and Web Services Definition
Language (WSDL). Additionally, train your key developers and development managers in
JDeveloper, OA Framework, and ADF specifically, as well as in the use of XML and the creation of Web Services using Oracle tools. Encourage the use of these technologies in planning new functionality or application modules written to extend the functionality of E-Business Suite. o Consider training staff in “bridge” technologies such as Applications Express. This may provide a good alternative to creating further custom Oracle Forms stacks in institutions where there is not yet a lot of Java expertise but there is an immediate need for significant extensions. Generally speaking, Applications Express is a viable alternative and relatively easy for Oracle Forms developers to pick up; it might provide you with a bridge, and any application modules created using this technology should be reusable in the new environment.
Please note, in this regard, that this technology uses mod_plsql, which will not be supported under Release 12 and Fusion. Given that fact, any use of this tool would be to create standalone applications which, while they might access data in the E-Business Suite, have their own application framework to deal with issues such as session management and authorizations. It seems likely that you would need to run mod_plsql on a separate middle tier; all of these things would tend to increase your software footprint. While this remains a viable alternative, such issues do point out the fact that it may make sense to start ramping up on OA Framework and ADF sooner than later.
Strategic Recommendations o Plan to upgrade to at least Release 11.5.10 as soon as is practical. Anything less will leave you with few if any of the tools you will need to begin adopting these recommendations.
Release 11.5.10 is the minimal release level that is in the direct upgrade path to Fusion applications. More than that, however, the technology stack and applications code is relatively mature. This will give you the technology footing you will need to continue to explore and begin to implement some of the Tactical and Strategic Recommendations herein. An alternative might be to wait and upgrade to Release 12 when it is released. Either way, it is important, strategically, to get to a platform relatively quickly that will allow to start discovering and exploring the new technologies. o Stop coding Oracle Forms that are deployed as part of E-Business Suite.
The most recent announcements from Oracle make it clear that some of the applications in
Release 12 of the e-Business suite will continue to use Oracle Forms (Forms release 10.1.2).
Forms as a development tool will continue to be supported as a technology tool and improvements will be made with that tool. For example, Release 11 of Forms is currently under development. However the direction remains clear: the first version of the Fusion application will not include any use of Forms.
Many schools have developed custom applications with Forms technology; these are often deployed in the E-Business Suite as an extension. This is natural and convenient since custom form may use the framework of menus, responsibilities, and user access and management provided by the E-Business Suite.
The key issue is not that Forms themselves will not be supported anymore; rather, some of the core AOL foundational constructs upon which the e-Business suite Forms depend will no longer be part of the Fusion application. These include Forms templates, libraries, user exits, security, Flexfields, messages, menus, etc. Custom Forms-based applications cannot therefore be deployed where they currently are tightly integrated with and rely upon the on e-
21 of 51 pages

Business Suite Foundation. Forms applications that use their own methods for authentication, access control, menuing, etc. instead of the AOL foundation should not be affected by this change.
In a whitepaper entitled “ Exploring Upgrade Strategies to Oracle Fusion Applications,” Oracle states that “[m]any customers have… invested in stand-alone, or bolt-on, applications. These are applications written to satisfy unique requirements that are not met by the base application.” As with reports, Oracle is engaging in research projects to determine if any
“investment in automated conversion technology would create significant customer value by bringing these applications to the new platform.” While this is not very clear, it seems likely that Oracle is at least in part talking about Oracle Forms technology here.
There are two possible options for existing custom forms stacks that are tightly integrated with E-Business Suite:
1. Make them “standalone” applications with their own authentication, session management, menus, etc.; or
2. Rework the forms stacks using tools and techniques which will insure that they integrate with the Fusion Applications.
The former will probably not be your best longer-term solution, though it might serve as an interim waypoint if you cannot marshal the resources to effect the latter. Generally, the TAG recommends eventually moving custom Forms applications to the Fusion platform. The TAG also more specifically recommends:
1. In the absence of intelligence to the contrary, if you have a significant investment in
“bolt-on applications” written in Oracle Forms, you will be best served by assuming that this technology will not have an automated upgrade path. Stop developing custom applications using Forms.
2. Begin development of a plan to convert your tightly-integrated custom Forms to
Application Developer Framework (ADF) and JDeveloper. The timing of this would be concurrent with your upgrade to Fusion applications.
3. If you want to get a jump on the process of converting your forms stacks to Java technologies under Release 11.5.10 or Release 12, but prior to the upgrade to Fusion
Applications, you will be best served by developing the forms under JDeveloper as an OA
Framework extension. While this will entail converting the forms stack again at the time that they are moved to Fusion, the task should be relatively simple.
4. If the above step is not feasible then schools should develop plans to set up a parallel environment for running these Forms applications; such an environment would be intended to decouple your customs Forms from e-Business Suite foundation, and would entail building a custom foundation for supporting the custom Forms.
If you opt to move your Forms to OA Framework/JDeveloper or ADF under JDeveloper, review your documentation; if your documentation is not sufficient to create a new application from scratch, start documenting now.
You may wish to remain open to the idea of replacing your custom Forms stacks with delivered functionality if possible. For extensive custom forms stacks this seems unlikely, but for smaller enhancements there may be some opportunities.
There are of course risks in that it will require you to wait to make the decision to build or adopt new functionality. Fortunately, there is time, and in the interim documenting the business process and requirements that your custom Forms serve and deliver will be well spent. If you are very fortunate, the functionality delivered by your bolt-on Forms applications is delivered in some form either in subsequent versions of E-Business Suite or by the Fusion
Applications.
If you are in the process of adding substantial functionality to your applications, and you believe that you will need to maintain the programs after the first Fusion applications are
22 of 51 pages

available, it will be best to build these as applications or services outside of the Oracle Forms.
If you develop them with OA Framework and JDeveloper using well-defined Fusion
Architectural and SOA principles, you should be able to integrate them relatively simply into current and future E-Business Suite releases as well as the Fusion Applications.
If you are now adding significant functionality to the E-Business Suite, it seems likely that you have probably done this before as well. In those cases, you will have more than likely used the Developer toolset. Getting your developers up to speed on JDeveloper for the purposes of new functionality will also prepare them to rework your existing Forms stacks. Indeed, you may wish to move your timeline up for such development so that you can get a bit of a head start on what will be required to rework your existing custom Forms stacks.
If you currently have large custom Forms stacks that you have bolted-on to Oracle E-Business
Suite, but no immediate need for additional significant functionality, you should still consider ramping up on JDeveloper, OA Framework, and ADF with at least a core group of developers to determine what will be required to port these forms stacks to the new paradigm. Again, you will need excellent functional and technical documentation for these applications extensions so that they can be reworked as required. o Stop coding reports in Oracle Reports. Begin moving Reporting to XML Publisher. Oracle has stated in at least one Whitepaper that it is researching how “…reports can be brought forward into the next platform… and how complete that conversion of the code would be.” 17 Oracle seems to be clearly saying that Oracle Reports will not be a part of the Fusion Applications, and that there may be conversion tools to ease the conversion to the next platform. The extent to which a complete conversion can be performed remains an open question.
Oracle stopped using Oracle Reports to develop new reports for E-Business Suite modules several years ago and uses XML Publisher instead. XML Publisher for E-Business Suite is tightly integrated with the Concurrent Manager and the applications modules. 18 In Release
12 there are over 800 XML Publisher templates used by the E-Business Suite modules. The
TAG must recommend that institutions minimize or stop developing reports using Oracle
Reports. In 11.5.10, Oracle’s XML Publisher is available and is a viable reporting tool going forward.
New reports should be written using XML Publisher. Consider rewriting existing key custom reports in XML Publisher, especially if you have requirements for modification or enhancement. Oracle has provided whitepapers to help transition customers, including stepby-step guides for creating simple reports. 19
The ability to define and modify layouts using simple desktop tools such as Word and Excel may very well offer the ability to offload a certain amount of reporting design and implementation to functional resources. Even institutions that tend to produce simple
PL/SQL “reports” may find that the reporting capabilities of this tool are substantial enough to warrant review for their purposes. o Consider using BPEL for creation of human workflows to extend the E-Business Suite.
Both Release 11.5.10 and Release 12 support Oracle Workflow and Business Process
Execution Language (BPEL) as process engines. Oracle's use of BPEL at this time is mainly intended to help integrate other products (e.g. Siebal, PeopleSoft, etc).
If you already use Oracle Workflow, BPEL may not be the best choice for custom processes for
Releases 11.5.10 and Release 12. The net result of doing so would be two different worklists, two different sets of notifications, etc.; in short this may be confusing to your users.
However, institutions that have developed custom extensions using Workflow, and/or which customized seeded Workflows, should be aware that in the Fusion Applications BPEL will be the only Process Engine. In short, Oracle Workflow will not play a part in the Fusion
Applications.
The seeded workflows that are part of the E-Business Suite now will be converted as part of the creation of the Fusions Applications. However, customers who have created custom
23 of 51 pages

workflows will have to convert them to BPEL themselves. A conversion utility to convert
Oracle Workflow to BPEL is not on the drawing boards, and even if an automatic conversion of
Workflow to BPEL was feasible, it would likely result in some less-than-optimal BPEL.
Based on these emerging facts, the TAG recommends: o If you are not currently a user of Oracle Workflow, don't start now, but consider
BPEL instead, especially for any custom workflow needs; o If you are currently using only seeded Oracle Workflows, try and stay with them as opposed to creating custom Workflows and use Oracle's personalization and extensibility features; Oracle will convert the seeded Oracle Workflows to BPEL as part of the Fusion Applications upgrade, and you will have less work to perform. o If you currently use both E-Business Suite seeded Workflows and have a fair number of custom Workflows, you should begin to document the custom flows and any customizations you have made to the seeded flows. If you are the type of institution that likes or wants to “Dive right in” consider doing an OracleAS 10g
Application Server install for at least a development instance, and start to explore BPEL strongly with the stated goal of making some determinations as to what will be required to port your workflows to BPEL. If you are a “Dip a toe” institution, you may wish to wait until Release 12 to start working on this; at that time the OracleAS 10g Application Server will be an integral part of the middleware stack, and this will afford you the opportunity to start mapping your custom workflows to BPEL. Either way, you should have a plan with respect to how you will port your custom workflows. o Consider using BPEL for enhanced applications integration.
Use of BPEL for human workflow should not distract you from its value as an integration tool.
As previously stated, Oracle's use of BPEL at this time is mainly intended to help integrate other products. Both Release 11.5.10 and Release 12 support BPEL, and the BPEL Process
Manager can be used to quite easily and effectively create Web Services to expose program logic or data in your E-Business Suite and other data sources. o Use XML Gateway/Web services for any new interfaces.
As previously noted, E-Business Suite 11.5.10 delivers hundreds of interfaces in the form of
Web Services coupled with XML Gateway. If you have or receive requirements for new interfaces, determine if there are any existing interfaces in the Integration Repository that following the XML Gateway map/Web Service architecture discussed above. 20 For example, if you need to program an interface to accept PO Matched Invoices, consider using the published XML Gateway Map and “Process Invoice” Web Service.
If you do not have any imminent requirements for new interfaces, consider doing a proof-ofconcept project to define and use one of the new Web Service interfaces. You may already be importing transactions through the open interfaces that are addressed by one of the new interfaces, and it might be useful to try the Web Service interface in a test instance in order to
“Dip a toe” and get familiar with implementing one of these interfaces.
For more ambitious institutions, consider eventually employing the OracleAS Adapter for
Oracle Applications and E-Business Suite Adapter for JDeveloper to create a Web Serviceenabled interface. 21 This will be the model for Oracle interfaces going forward.
Whether you are working with an existing Oracle-mapped interface or a custom interface following this model you may wish to base it upon one of your current open interface data feeds. For example, if you are interfacing AP Invoices already, take the current data feed and map that feed to an XML document that represents the inbound Invoices. You can then use the output of this process as the input to an XML Gateway/Web Service interface. When you are finished, you will have the ability to convert your vendors one at a time, in a controlled fashion, to the new interface.
24 of 51 pages

o Small customizations and enhancements may be done using existing customization tools and infrastructure.
Oracle offers a variety of ways to customize and extend the E-Business Suite. These include
Custom PLL, Function Security Setup, Data Security Setup
,
Workflow, Alerts, Framework
Personalization, Descriptive Flexfields, Profile Options and Custom Profile Options, Forms
Folders, and Forms Personalization.
With the exception of custom.pll, small customizations or extensions that are required now may be best accomplished using these traditional techniques. Many of these methods will have, at a minimum, some analog in the Fusion Applications; in some cases there may be a direct upgrade path. You should prioritize use of current constructs based on their portability to the Fusion Applications. For example, customizations performed using XML Publisher will be easy to port to and integrate with the Fusion Applications. Likewise, since Oracle has announced that the Fusion Applications will be based upon the E-Business Suite data model, it seems likely too that Descriptive Flexfields will survive as well.
Custom.pll, on the other hand, seems a dead end. Using Forms Personalization and OA
Framework Personalization will, at a minimum, familiarize development staff with the declarative approach to “forms” extension that will likely have an analog in Fusion
Applications.
Despite the overall recommendation that small customizations may be done using existing customization practices, strive to begin thinking in service-oriented, event-driven terms.
Review even small customizations for the possibility of a quick win under the new technologies. Oracle Workflow lends itself particularly well to event-driven and looselycoupled design, and as such you might find an immediate use for the Business Event System or something similar. Even if you use workflow in a more traditional way, it will be relatively highly portable to the Fusion Applications.
Beyond the realm of Oracle customization tools as such, you might create smaller customizations that are based on small, modular and reusable code in the form of well defined database objects and PL/SQL units. Such small customizations will also be more likely to port relatively easily to the Fusion Applications. In this context, consider the use of
Oracle Alerts or database triggers to run discrete, well formed tasks. Separate the PL/SQL code from the event handler; that is, do not embed the PL/SQL logic in the trigger, but rather separate it so that it can be used by a different triggering event later. Database triggers can be replaced with more sophisticated event triggers in the future and remain viable and portable to the new platform.
As your institution progresses to Release 12, and the full Fusion Middleware technology stack becomes available, consider reworking and porting small customizations to Web Services and true event-driven units. This work will not be in vain; most development is iterative in nature; moving towards Fusion Architecture, Middleware and Applications need not be any different, and may perhaps be best realized in this fashion. If Service Oriented Architecture is
“evolutionary” as many of the pundits suggest, perhaps the best way to reach for it is to evolve current code and techniques as well. o Medium to Large sized customizations and enhancements should be done using JDeveloper and J2EE
Fusion Applications will be founded upon J2EE; specifically, the ADF framework under
JDeveloper will form the basic development tools. At present, development for E-Business
Suite under ADF is not practical; the correct choice for J2EE development under E-Business
Suite is OA Framework.
OA Framework is founded upon J2EE, and most of the technologies and components used in
OA Framework are also present in ADF. Indeed, OA Framework is based on a “Model-View-
Controller” framework, as is ADF. ADF is, in fact, and evolution of OA Framework. As such it should be relatively easy to port applications written as OA Framework extensions in
JDeveloper to ADF extensions under JDeveloper.
25 of 51 pages

o Stop Developing mod_plsql applications
As previously noted, mod_plsql will not be supported in Release 12 and it seems more than likely that it will not be supported in Fusion Applications. All HTML based applications or extensions that you have written using the HTP/HTF packages and functions (the PL/SQL
Toolkit) will not longer be supported directly under Release 12 or the Fusion applications.
The issue is very similar to that of the Forms. If you have stand-alone PL/SQL Toolkit HTML applications that perform their own authentication/authorization, have their own menuing systems, etc., and the applications do not specifically require support from tools such as the
ICX packages that are currently provided by the E-Business Suite, these applications should be fine. You will likely need to arrange to run the mod_plsql on another middle tier somewhere, but this is not difficult.
However, if your PL/SQL Toolkit applications are tightly integrated with the E-Business Suite and make use of the ICX framework for session management, authentication, authorizations, function security and other basic services, you will need to either make these applications stand-alone applications or port them to the appropriate Java technology. If you are upgrading to Release 12 and these applications are critical to you, this will entail porting them to OA Framework and later porting them to ADF when you upgrade to Fusion. If you will skip
Release 12, you will probably port these applications to ADF applications.
Java Development Recommendations:
The previous TAG paper covers the following summary recommendations in a little more detail, and all of them apply to E-Business Suite customers. Please read this section of that paper if you want a little more detail.
Since Java and JDeveloper are the future for the Fusion Applications, the TAG believes that it is in the best interest of HEUG institutions to begin investigating and integrating Java into their enterprise development strategies now.
For organizations with little in-house Java development experience, knowledge of the language and a new development tool may appear to be significant obstacles. While there is no need for immediate or wholesale changes to your current practices, we recommend the following summary steps in a gradual, measured approach to incorporating Java into your enterprise development tool belt: o Encourage your developers to include Java in their professional development plans. o Develop expertise through small Java pilot projects. o Investigate JDeveloper as your Java Integrated Development Environment (IDE). o Use OracleAS Adapter for Oracle Applications and E-Business Suite Adapter for JDeveloper.
Many schools have been leveraging Java within their environment for years and may have questions about which Java tools they should embrace. Should they plan to continue using their current toolset, or should they adopt the Oracle Java tools and runtime environments? We believe the following guidelines should assist these schools: o Follow standards and avoid proprietary features.
To the extent possible, try to limit the use of the proprietary functions for any application that you may eventually move to the Fusion toolset. The more standards-based that your applications are, the smoother a transition to the Fusion toolset will be. o Consider making JDeveloper your primary Integrated Development Environment for Java.
As stated above, JDeveloper will be the primary development environment used by Oracle for the development of its next generation applications. Even if you already have another IDE in place at your institutions, JDeveloper appears a logical choice as an IDE if you anticipate
Fusion Applications being heavily customized used at your institution.
Fusion Applications will be built with Oracle 11g development tools using Application
Development Framework (ADF) under JDeveloper. This version is anticipated to include significant enhancements to the currently available versions of the development tools. Our
26 of 51 pages

recommendation is to have your developers begin using current versions for pilot projects in order to become acquainted with Oracle tools and to plan more complex projects. This will allow your developers to gain experience on the fundamentals and later to take advantage of enhanced integration between the development tool and the Fusion Applications architecture. o Learn about the Oracle Applications Framework.
If you are going to develop extensions or port applications prior to the upgrade to the Fusion
Applications, you will want to learn Oracle Applications Framework. While the Fusion applications will be based upon Oracle’s ADF, ADF itself is built upon a foundation that includes an evolution of Oracle’s Applications Framework (OAF). Eventually your developers will need to develop expertise in ADF so they can support the Fusion Applications; however training developers in OA Framework earlier will give you a head-start on the process and allow you to create application extensions for Release 11.5.10 and Release 12 that will port easily to Fusion Applications later. It will also allow you to gain a better feel for what will be involved in eventually porting existing forms stacks to ADF. You might consider porting some forms stacks to OA Framework as a proof of concept and as a means to ramp up generally on the technologies.
Learn about Oracle Application Developer Framework (ADF). o Take a deliberate, strategic approach to considering your alternatives.
There is no immediate need to change your approach. But as you consider new projects, also consider your overall direction, skill sets, and durability needs. As your knowledge of the
Oracle development technologies and applications infrastructure deepens, you’ll be able to determine if and when making a switch makes sense.
Fusion applications will be based upon Oracle’s ADF. ADF will run under any J2EE compliant
Java environment, but it is unique in the services that it provides to programmers. Eventually your developers will need to develop expertise in ADF so they can support the Fusion
Applications; additionally, ADF itself is evolving as Oracle moves towards the Fusion
Applications, and it will likely undergo some changes in the interim. Gaining some knowledge and experience with ADF and remaining current with the technology in the next few years is a good plan.
27 of 51 pages

In the section below, we have laid out seven steps that institutions can take with regards to their applications technology infrastructure to help prepare them for the eventual implementation of Fusion
Applications. We have tried to present this material in a step-by-step fashion so that it is easy to understand, but we recognize that each University will have its own requirements and factors that will determine exactly what steps they take and in what order they take them.
Earlier in this document (page 6) we characterized three approaches for adopting Fusion: “Wait and see,” “Dip a toe,” and “Dive right in.” Each of these approaches will result in a very different roadmap.
For example:
 The “Wait and see” schools will probably only choose to execute steps #1 and #2 below.
 The “Dip a toe” schools will be more aggressive and they will also execute step #3 and parts of step #4.
 The “Dive right in” schools will likely pursue most of the steps listed below.
Later in the document (Section #4) we provide examples of two hypothetical universities and how they might apply this roadmap at their institution. Hopefully those hypothetical examples will help illustrate the type of planning that your University should do in anticipation of adopting the Fusion applications and technology.
The first step to planning for the adoption of Fusion Applications and technology is to update your
University’s plan for E-Business Suite upgrades. Each school must determine when they will adopt E-
Business Suite Release 11.5.10 and/or E-Business Suite Release 12. The timing of these upgrades will influence when and how they begin the move to Fusion technology.
Important points regarding your upgrade plan are:
You must get to E-Business Suite Release 11.5.10 or beyond in order to start leveraging
Fusion Middleware.
Oracle has announced that Release 11.5.10 and Release 12 will have direct upgrade paths to Fusion Applications. Any institution that wants to start implementing some Fusion
Middleware with their Oracle applications will need to be on Oracle E-Business Suite 11.5.10 or beyond.
E-Business Suite Release 11.5.10 is the terminal 11i release, though there will be further minor 11.5.10 maintenance releases. E-Business Suite 11.5.10 offers some opportunities to discover and start using Fusion Middleware.
If you wish to start leveraging more SOA capabilities than Release 11.5.10 offers out of the box, you can set up a stand-alone OracleAS 10g Application Server to start exploring some of the capabilities certified under 11.5.10.
Release 12 and its dot releases may or may not be the final release of E-Business Suite; however, Release 12 will be the first release deployed on a dedicated Fusion Middleware
Application Server. The Fusion Applications themselves will be released on an enhanced version of the Fusion Middleware application server in the form of the OracleAS 11g application server platform.
28 of 51 pages

Overall, the TAG recommends that schools should plan to keep relatively current with E-
Business Suite releases in order to provide themselves the most flexibility for taking advantage of the ongoing enhancements to E-Business Suite moving towards Fusion applications. Oracle’s plan is clearly to provide as many Fusion capabilities as products as possible – a strategy that will make the ultimate transition to Fusion applications less costly and disruptive.
An Upgrade to E-Business Suite Release 12 will make sense for nearly every school.
Though E-Business Suite Release 11.5.10 will be supported for some time, E-Business Suite
Release 12 should offer substantial value to most institutions that will upgrade to the Fusion
Applications.
Release 12 will be deployed with the OracleAS 10g Application Server. Since this will be the platform used for the Fusion Applications, this version of the application server, the development tools, and Fusion Middleware bundled with the Application Server will be closer to the versions that will ultimately be deployed with the Fusion Applications. This offers some significant benefits from the standpoint of discovery, and generates some efficiencies from the standpoint of ultimately porting any customizations to the E-Business Suite to Fusion
Applications..
An upgrade directly to Fusion Applications from E-Business Suite Release 11.5.10 might be accomplished relatively easily if virtually no customizations have been made to the E-Business
Suite. However, the profile of institutions which make few customizations would seem more synonymous with the “Wait and see” profile. Strong requirements for functionality far beyond that which is currently available or which will become available in Release 12 would likely drive such a decision; such a decision would almost necessarily have to be taken in the absence of any significant customizations to the E-business Suite.
No matter which camp your school falls into, upgrading to a version of E-Business Suite beyond 11.5.10 will probably make sense. It will provide enhancements to your E-Business
Suite infrastructure, extend the life of your current E-Business Suite investment, and will provide you more time to consider and execute your Fusion Applications upgrade strategy.
While there is some debate in the IT community about whether all the advantages of SOA will ever materialize, there are no arguments about the value of Web Services. Virtually everyone close to systems design and application development agrees that XML and web services are key technologies that can lead to significant productivity and functionality gains.
We recommend that universities continue to increase their use of Web Services even with their existing E-Business Suite applications. Under Release 11.5.10, there are limited opportunities for doing so; strictly speaking, the only real out-of-box opportunity is the use of the OAG Web Servicesbased interfaces.
Some use of these interfaces should be attempted, even if simply as an exercise in understanding and implementing this model. The use need not necessarily be a production effort but could be a pilot or training effort.
We recommend that universities begin to implement practices in their coding today that will promote reuse of code in the future; even if you are currently coding almost exclusively in PL/SQL, you can begin to organize function and procedure libraries for common tasks that can later be wrapped with
Java code and executed in discrete, modular units and as Web Services.
Beyond the OAG interfaces and beginning to promote coding practices that will support modularity and reuse, perhaps the most important thing institutions you can do at this level is understand Service
29 of 51 pages

Oriented Architecture and begin to familiarize yourself with both the general concepts behind it as well as the oracle Fusion Middleware components and tools that will implement it.
Consider a pilot at the earliest opportunity to produce and publish simple but strategic Web Services.
This can be done relatively easily with BPEL Process Manager. You may choose to do this early on in your adoption of Release 12; however, the BPEL Process Manager is a standalone tool outside of the
E-Business Suite, so you don't need to wait until Release 12. You can use BPEL Process Manager and other Oracle Integration connectors with Release 11i today; again, under Release 11.5.10, this would most likely entail installing a stand-alone Oracle AS 10g application server, and use of BPEL Process manager would be certified under the citification for Oracle Integration.
The Oracle BPEL Process Manager is a Business Process Execution Language engine that runs in any
J2EE Application Server, though typically Oracle 10gAS (OC4J), JBoss, WebLogic or WebSphere. Oracle
BPEL Process Manager publishes business processes in the form of Web Services. These business processes can be very complex, composed of many steps, service invocations, loops and decisions points. However, these processes can also be extremely simple, entailing no more than a single service call. The BPEL Process Manager can create, publish, and run services implemented in Java or
PL/SQL; such services can effectively access and poll database tables, FTP servers, and the File systems for events.
This functionality alone gives institutions the tools necessary to create a multitude of simple, foundational services that have traditionally been done using PL/SQL and “built-ins.” In addition to the BPEL Process manager, JDeveloper has an exceedingly simple wizard-based, declarative method for creating Web Services from PL/SQL code. The functional result is identical to the BPEL Process manager Web Service though some of the implementation details vary. Either way, publishing a simple Web Service using BPEL Process Manager and/or JDeveloper would also be beneficial and would not entail an inordinate investment of resources.
We are not recommending that schools undertake a massive project to wrap services around all E-
Business Suite functionality. Instead, we are recommending that schools strategically pick functionality to expose as services. You should pick services that will bring value to other applications on campus, and will provide improved integration of their enterprise systems. For example, if your institution has very complex validation requirements for charging instructions, you might wish to expose those validations in such a way that external applications can access and make use of those validations. It seems likely that such validations will have been written in PL/SQL.
It is relatively trivial to create a service that will expose the validations for use as a Web Service.
Enhancing the service to add exception processing and to add additional validations is similarly quite simple. Once the service has been created you may be surprised by the number of uses you will find for it, including the possibility of enhancing any ASP solutions you may currently offer your users and the ability to leverage the service in new customizations and extensions.
Once an institution has upgraded their systems to Release 11.5.10 or later, they will be in a position to start a gradual step-by-step process of adopting Fusion Middleware products. We suggest that schools start by implementing the three Fusion Middleware products listed below. The decision to deploy these three products is likely to be a “no-brainer” for most schools because these products are provided at no incremental cost to E-Business Suite customers. Additionally, these products can be deployed with little disruption to end-users.
1.
XML Publisher
Oracle has made a clear commitment to XML Publisher as a long-term report development tool. This will be the Fusion Applications reporting tool. As such, it will be the heir to simple
PL/SQL “reports” and to Oracle Reports. Any school that is considering Fusion Applications in the future will be well served to begin using XML Publisher immediately.
30 of 51 pages

Some reasons schools may want to implement it include: o If schools start to write new reports in XML Publisher, it should make the transition to
Fusion applications easier, because not all of their work would have to be redone.
Indeed, getting familiar with XML Publisher now will help to train your developers for the task of porting your custom Oracle Reports and those older PL/SQL reports.
If you write a report in XML Publisher today, and you want to continue to use it with
Fusion applications, only the data processing portion of the report may need to be changed. For example, if the underlying tables change somewhat, the query can be adjusted and the results plugged into the existing template. A tip here might be to base the XML Publisher select on a view. When the time comes to change the select, you can change the underlying view and never have to touch XML Publisher at all. o End-Users can become familiar with XML Publisher, which might be of benefit during and after the transition to Fusion applications. o XML Publisher does not have to replace any existing E-Business Suite infrastructure.
It would just be an additional tool available to application developers / business analysts. Note, schools will benefit the most in the long run if they leverage XML
Publisher as much as possible, particularly for new reports, and minimize the use of
Oracle Reports. o The license for use of XML Publisher within an E-Business Suite applications environment is provided with no additional fee.
2.
Oracle Enterprise Manager
Oracle Enterprise Manager (EM) is a comprehensive systems monitoring and management tool. While the integrated Oracle Applications Manager (OAM) is and excellent management tool from the standpoint of the E-Business Suite, OEM goes further and has functionality that goes beyond the application-centric capabilities of OAM.
Oracle has stated that Oracle Applications Manager will continue to be available in Release
12 of the E-Business Suite, but that it will eventually be merged into Oracle Enterprise
Manager 10g Grid Control where Oracle’s comprehensive Applications Lifecycle Management offerings will reside. 22
It is clear that OAM will be merged into EM; the best intelligence at this time is that the merger will be complete by the time Fusion Applications are released and that the much expanded
EM will be the management tool for Fusion Application.
Your institution can get a jump on this shift right now. With E-Business Suite 11.5.10, Oracle has developed a plug-in that allows the environment to be managed by OEM. While the free version of this plug-in will by no means supplant OAM, it is worth a look, particularly if you are already using EM.
Oracle will eventually release the OEM-based Application Management Pack for E-Business
Suite following closely upon the release of Release 12, and much of the functionality will be backward compatible with 11i. 23 If your institution has not begun looking at EM as a management platform by that time, adoption of EM and the more comprehensive Application
Management Pack for E-Business Suite in the Release 12 timeline will likely pay dividends both in terms of enhanced applications and infrastructure management and by potentially easing your upgrade to the Fusion Applications.
Schools will want to consider OEM for the following reasons: o This change will be behind the scenes and should not affect end-users or developers in any way. The primary impact will be to infrastructure support teams. o OEM does not replace any existing Oracle infrastructure. It is an additional tool available to infrastructure support team members that provides extensive management capabilities.
31 of 51 pages

o Many institutions already use OEM to manage their Oracle database environments.
Extending it to manage their E-Business Suite environment as well may be practical and appropriate. o OEM will allow one management console for the database, web server, process schedulers, application servers and other Oracle E-Business Suite infrastructure components. Enterprise manager has offerings for a variety of Operating Systems and third party products (e.g.: load balancers, storage, etc.) that are commonly used in conjunction with E-Business Suite. From one single management point, system administrators will be able to start, stop, and monitor key application and infrastructure components. This should make system administrators more efficient and lead to improved system availability and performance. o The more limited plug-in for Oracle Enterprise Manager is available with E-Business
Suite 11.5.10 for no additional license fee.
We strongly urge all institutions to adopt XML Publisher as soon as they reasonably can. The benefits of adding the tool are clear, and they outweigh any possible disadvantages. We can think of no scenario where it would be in an institution’s best interest not implement XML Publisher. Some institutions may choose to use it less than other institutions, but every institution should include it within their E-Business Suite tool suite.
We also recommend that institutions adopt OEM, but recognize that there may be reasons that an institution chooses not to deploy this product. For example, some schools may already have a systems management infrastructure in place, and therefore a migration to OEM may not make sense within their infrastructure.
Some universities may want to roll these changes in with their upgrades, while other universities may want to stagger their release. The exact schedule is not critical. The key point is that by adopting these infrastructure components, universities can take their first steps toward Fusion on an incremental basis.
The implementation of OEM and XML Publisher are the simplest steps for each E-Business Suite customer to take to move toward Fusion. The next steps are will depend in part on an institution’s unique priorities and the existing infrastructure on their campuses.
Service-oriented applications require middleware that can manage, orchestrate and deliver services.
Institutions that want to take the next step in preparing for the transition to Fusion Applications should consider deploying the appropriate Fusion integration components in the next few years. By deploying these products in advance of the Fusion Applications, an institution can adopt a more incremental approach to the adoption of Fusion and service oriented applications in general.
Unlike the products listed in the previous step XML Publisher and OEM, the Fusion Middleware products for enterprise integration will likely require new licensing and maintenance fees. These fees may be a barrier to some schools adopting these products. We believe that if a school is truly interested in the advantages of service-oriented applications, they can make a compelling business case for the acquisition and deployment of these middleware components.
Some of the components discussed below can be configured to run on Oracle 9iAS Application Server and are therefore available directly to E-Business Suite Release 11.5.10 customers. As stated above another avenue for early adopters would be to set up a stand-alone version of OracleAS 10g
Application Server, which includes many components that are currently certified for use with Release
11.5.10. Eventually, all of these components will be available in Release 12 when the OracleAS 10g
Application Server is deployed as the sole technology stack application server.
32 of 51 pages

Here we have created a list of individual Fusion Middleware products that we believe represent incremental opportunities for universities as they prepare for Fusion Applications prior to adoption of
Release 12. We have tried to sort the list in order; that is, the products that appear at the top of the list are the ones that we think schools should consider first. The order is not fixed though, so each school can determine their own deployment strategy based on their unique requirements and situation.
1.
Oracle Web Services Registry
The OracleAS 10g application server provides a Universal Discovery Description and
Integration (UDDI) Web Services registry in which Web Service provider administrators can publish their Web Services for use by Web Service consumers. Web Service consumers can use the UDDI inquiry interface to discover published Web Services by browsing, searching, and drilling down in the UDDI registry to select one or more Web Services from among those registered to be used in their applications for a particular enterprise process.
While a registry is not an absolute requirement to support Web Services, we believe that institutions will be best served by establishing a directory before they begin to expand the use of Web Services. If not, they may find that development teams will adopt multiple techniques for documenting and presenting their services, and the overall services environment will become unnecessarily confused. The existence of a registry early on in your Web Services strategy will help establish standards and avoid unnecessary confusion.
The services registry is a relatively simple piece of infrastructure and doesn’t pose many challenges for deployment or operation; given the proliferation of Web Services, some form of service registry will be required for most institutions whether or not the Fusion Applications are adopted.
There are very few issues concerning the implementation of Oracle Web Services Registry.
Since it cannot be run under versions of the technology stack current under Release 11.5.10, it cannot be run with 11.50.10 without resorting to a stand-alone OracleAS 10g application server. Additionally, there are a multitude of Web Services Registries available, and some schools may already have one or more registries in place. Because the UDDI standard is so well established, it is likely that Fusion Applications will work seamlessly with just about any registry product.
Oracle Enterprise Services Bus (Oracle ESB)
Oracle Enterprise Services Bus is a component of Oracle’s ’Integration’ product suite; as such it is certified for use under Release 11.5.10 though the use of this product prior to Release
12 will have to be accomplished through installation of a stand-alone OracleAS 10g application server.
The Oracle ESB provides messaging, routing, and data transformation services between applications and systems in a Services Oriented Architecture. Essentially, the Oracle ESB is a flexible, scalable delivery mechanism to transport information to disparate systems. For example, if a person’s name changes in the Student Administration system, Oracle ESB can handle the routing, delivery and transformation to assure that the changes are properly transmitted to other systems in near-real time.
The ESB is a key piece of middleware that facilitates loose-coupling of service consumers and providers. Consider the situation where a service is running on one particular server. If that service needs to be moved to a different server, calls to the original location will fail if consumers aren’t aware of the change. This kind of tightly-coupled, point-to-point communication could quickly become a headache in a large-scale enterprise with hundreds or thousands of services.
By attaching services to the Enterprise Service Bus, the consumers are decoupled from the actual service providers. Consumers send service requests to the ESB, and the ESB is responsible for routing the request to the correct destination. Service virtualization is only one feature of the Oracle ESB. Content-based routing allows the ESB to route requests to
33 of 51 pages

different services based on the data contained in the request. The ESB can also transform or convert data from a request into the appropriate format or protocol for a variety of different services and platforms.
Reasons that you may want to implement the Oracle ESB: o It is likely that the Fusion Applications will rely on the availability of a service bus to coordinate the distribution of information across applications. While it may be possible to use other vendors’ products for this purpose, conjecture suggests it’s likely that Oracle’s ESB will have some advantages for shops that will have a large presence of Fusion Applications. o Release 12 of the E-Business Suite will provide enhanced services support, and will be deployed on the OracleAS 10g application server platform for which ESB was designed. The ESB could therefore be leveraged with Release 12 applications even before you move to the Fusion Applications. o An Enterprise Service Bus is a fundamental component in an effective Service
Oriented Architecture. Attaching services to the ESB is a great way to build flexible, loosely-coupled integrations. o Services from a wide variety of platforms and development tools could be attached to the ESB. If an organization has a diverse collection of systems and organizations that offer services in a standards-compliant way, these services can be attached to the bus to provide shared access, management, and monitoring.
Issues concerning the implementation of Oracle ESB: o The implementation of a service bus may be a “which comes first, the chicken or an egg” scenario. It may be that the infrastructure team puts the service bus in place, and no applications immediately use it. If schools do not commit to making the service bus a fundamental part of their integration approach, they risk underutilizing this key infrastructure component and overlooking the features and benefits it provides. o Out-of-the-box usage of a service bus will not exist for most vended applications (in the short run); therefore each school will have to develop the appropriate interfaces for their applications to leverage the service bus. o There is a general concern that service bus architecture generally (not just Oracle’s, but all service bus products) could introduce latency and performance bottlenecks into enterprise systems. Oracle technologists are aware of these concerns. The TAG believes Oracle understands that customers will not be receptive toward of systems or technologies that do not perform well, especially under high-volume transaction loads.
2.
Web Services Manager
Identity Management has typically been focused on securing and managing user-toapplication interactions. However, there is a growing need to manage interactions between the applications themselves. Web Services provide a standard and simple way to connect applications over the internet, but they require management of security and other runtime operations to work effectively.
The Web Services Manager (formerly Oblix CORESrv) provides Web Services security and policy support. The Web Services Manager can allow security and policy logic to be externalized from applications, and can lead to a more efficient environment.
Why you may want to choose to implement Oracles Web Services Manager (OWSM): o Your university is making progress on deploying Web Services and your applications can be constructed to externalize some security, policy and audit capabilities.
34 of 51 pages

o A single enterprise approach to managing web services will be better than trying to manage scattered islands of services.
Issues concerning the implementation of OWSM: o Most universities will want to develop experience with Web Services before deploying this infrastructure. o Oracle Web Services Manager is available with Oracle Application Server 10 g
Release 2, so the only way to start using this product prior to Release 12 will be to perform a stand-alone install of OracleAS 10g Application Server.
3.
Oracle BPEL Process Manager
Oracle BPEL Process Manager is a design tool and run-time environment to model and deploy business processes. BPEL Process Manager is Oracle’s “process orchestration” technology and central to their strategy for delivering service oriented applications. Business Process
Execution Language (BPEL) is an officially recognized standard.
Oracle has also added constructs to handle human interaction and workflow management within their BPEL Process Manager, even though the official BPEL standard does not include these capabilities. These capabilities should not be over-emphasized to the detriment of
BPEL Process Manager’s role as an integration tool.
Reasons you may want to implement Oracle BPEL Process Manager: o Your school has existing integration problems or issues with interfaces between systems. BPEL Process Manager includes a suite of integration connectors or adapters that enable the integration of all kinds of technologies and data formats, from flat files and XML documents to database tables and web services. For example, BPEL Process Manager can be used to watch for files in a directory on a server, load them, convert them into XML documents, and send the data directly into database tables or make calls to web services. o Your school is aggressively implementing service oriented applications. The BPEL
Process Manager is a tool you can use to design business flows that link a collection of services into a cohesive process that can be easily altered. o Your school would like to establish a cross-application workflow engine (which leverages services). o BPEL Process Manager will definitely be leveraged as part of the Fusion Applications. o BPEL Process Manager will allow you to begin the shift of application implementation closer to business analysts and business process owners.
Issues concerning the implementation of Oracle BPEL Process Manager: o The full potential of BPEL Process Manager as a process modeling and automation tool will not be apparent until organizations have made a shift toward services and event-driven development that can be leveraged by process-oriented thinking and design.
BPEL Process Manager and Process Designer will be deployed as a part of the technology stack under Release 12; they can be deployed as a part of the certification matrix for installing a standalone version of OracleAS 10g Application Server with 11.5.10.
The products above are all strategic to Oracle’s future vision, and will contribute significantly to the functionality and features of the Oracle Fusion Applications. These products represent a “sweet spot” where Oracle plans to be a leader, and where they believe the value of their products will stand out in the market place. That said, Oracle claims that components will be
“hot pluggable,” which means that customers should be able to substitute alternative solutions in place of each Oracle product. While this may be true, it seems likely that in the
35 of 51 pages

integration product space, Fusion Applications owners will want to rely on the Fusion
Middleware to assure smooth functionality, performance and support. 24
Oracle's Data Hub products synchronize information from multiple enterprise systems in a single central location. Data hubs provide a consistent view of data including transformations and standard service interfaces. There are currently Data Hubs available for customer, financial and product information. Unfortunately, the currently available Data Hubs do not include a lot of data that is pertinent to universities. Oracle has indicated that future Data Hub products are likely to address this gap.
A partial preview of Data Hub technology is available to institutions running later versions of
11.5.x. The current Customer Data Hub is based on Trading Community Architecture (TCA) and uses the customer data model of Oracle E-Business Suite. 25 Oracle’s TCA models parties, people, corporations, groups, customer, contacts, employees, and suppliers. It models their accounts, locations, classifications, and preferences. Historical as well as current status is maintained. TCA models all the complex relationships between all the entities in a “trading community.”
When the user of any application module performs an action that makes a database update, the update is made to the relevant table or tables in the central database. The updated information is then available at once to any other application that may need it. The TCA operational data provides a complete, accurate, real-time view of activities, finances, customers, services, suppliers and partners. In short, TCA enables a system of record or a single version of “truth” throughout the operational applications.
Data Hubs promise to extend the TCA model to include transformation, service interfaces, and
APIs that will allow an institution to share and integrate E-Business Suite/Fusion Applications data with other best-of-breed and bespoke applications. If Oracle makes good on its promise to provide additional Data Hubs that are more relevant to higher education, Data Hubs could potentially play a significant role in the upgrade to Fusion Applications.
For example, if Oracle provides a “person” Data Hub it would have a standard person repository with appropriate service definitions wrapped around it. This means Oracle itself as well as developers could begin to leverage the hub for functions like analytics, reporting, and system interfaces.
Oracle could accomplish this relatively easily given that the E-Business Suite Human
Resources “person” is currently already incorporated into the TCA model. Purchasing Vendors are also slated to be brought into the TCA fold. Since the E-Business Suite provided its data model as the starting point for Fusion Applications, it seems likely that Oracle would provide support for the hub and would use the same schema and services for the Fusion applications.
As a result, any applications at the University which leverage the data through the Data Hub would not be affected significantly by the upgrade to Fusion Applications.
The TAG believes that when Fusion applications are released, they will strongly leverage Data
Hubs. In particular, we believe that the services and schemas that are available in Data Hubs will be leveraged directly by the Fusion Applications. If this proves to be true, then institutions that have begun to make greater direct use of hubs will find that they are an effective way of decoupling the data from their current applications, which will lead to an easier transition to
Fusion Applications.
While current Data Hub offerings are not necessarily central to the concerns of higher education, the TAG strongly recommends that schools monitor developments in this area, and seriously consider deploying and using the appropriate data hubs in advance of the Fusion
Applications.
36 of 51 pages

Oracle Fusion Applications will be built in Java using the Oracle development tools. Ultimately, any school that is committed to the Fusion Applications will need to embrace this tool set. This will include implementing the various tools, training staff, and putting in the necessary operational processes to support application development.
The tools that will need to be deployed will include:
JDeveloper
Oracle’s Interactive Development Environment (IDE). In addition to traditional Java tools, it will include visual interfaces to reduce coding, version control, debugging, etc.
Oracle Application Framework (OAF)
OA Framework is not a Fusion Application Development Tool. However, it is an interim step towards Fusion Applications and may provide value where an institution wishes to start converting Oracle Forms-based extensions or other modules to J2EE-based applications that can later be relatively easily ported to the Fusion ADF framework. It will also offer value to institutions which must add significant functionality or extensions to the E-Business Suite prior to upgrading to the Fusion applications.
OA Framework is the development and deployment platform for Oracle Applications 11i webbased modules such as iExpense. It will continue to be used by Oracle as the E-Business
Suite development framework in Release 12.
OA Framework is based on the J2EE Model-View-Controller (MVC) design pattern. The MVC design pattern decouples data access and business logic (Model), data presentation (View), and user interaction (Controller). The MVC design pattern provides a host of design benefits.
It separates design concerns such as data persistence, presentation, and control, decreases code duplication, centralizes control of the application, and renders the application more readily modifiable.
OA Framework also features industry standards such as XML, Java/JSP, SQL and Web
Services. OA Framework provides several benefits including sophisticated personalization/extension capabilities, high productivity for both end-users and developers, and improved performance. OA Framework is closely tied to Oracle Applications AOL, so you'd be using it only if you are working on an Oracle Applications 11i module based on the OA
Framework.
Since ADF is based in great part on OA Framework, and since Oracle has written many of their application modules using OA Framework and is actively converting many more for Release
12, it seems certain that applications and extensions written under OA Framework will be relatively easy to port to ADF-based applications.
Application Development Framework (ADF)
Under Release 11.5.x and Release 12, OA Framework will continue to be the development framework Oracle recommends for custom development and extensions to the E-Business
Suite. ADF is not as mature in terms of adapters that provide specific support for development of extensions under the E-Business Suite. However, ADF and JDeveloper will continue to evolve and will likely be built out to E-Business Suite extensions as well as Fusion
Applications extensions.
ADF will be the framework used for the Fusion Applications. It is founded upon the same
Model-View-Controller (MVC) design pattern as are OA Framework extensions. Any development under Releases 11.5.x and Release 12 OA Framework will need to be ported to
ADF at the time that you upgrade to Fusion Applications. However, once an application or extension has been factored using the MVC design pattern under OA Framework, migrating
37 of 51 pages

from OA Framework to ADF should be relatively straightforward. This is especially true given that the “Model” portion of the design will change very little in terms of business logic. Oracle has stated that there are no current plans for automated conversion tools, but has pledged support for porting efforts in terms of whitepapers and other collateral.
As ADF matures and Fusion Applications extensions are added, it will provide a complete J2EE application framework for extending the Fusion Applications. ADF is currently available as part of Oracle Application Server (OC4J), or independently for use with other J2EE-compliant application servers. It will be beneficial to continue to monitor the progress of ADF and to deploy it to developers well in advance of the Fusion Applications upgrade so that they may develop some familiarity with ADF.
OracleAS Adapter for Oracle Applications and E-Business Suite Adapter for JDeveloper
These adapters offer a multitude of benefits for connecting to, using, and programming for E-
Business Suite and they will be updated when appropriate for Fusion Applications. The
OracleAS 10g Adapter for Oracle Applications offers bi-directional, multi-modal, synchronous and asynchronous connectivity to the Oracle Applications. Oracle Application Server 10 g E-
Business Suite Adapter provides customers the ability to build enterprise business flows within the Oracle E-Business Suite which span legacy systems, disparate applications, and other third party systems. These adapters make the tasks of accessing the E-Business Suite and integrating it with the Fusion Middleware much easier and more straightforward and should be considered indispensable pieces of the development toolbox.
Oracle BPEL Process Manager
This was mentioned above under “Step #4.” Oracle BPEL Process Manager is a design tool and run-time environment to model and deploy executable processes that connect and orchestrate activities by and between applications. It also offers human workflow capabilities.
BPEL Process Manager is Oracle’s “process orchestration” technology and central to their strategy of delivery service oriented applications.
The time table on which a school chooses to embrace these tools will depend on their Java development strategy. See Section 2 of this document for guidelines relating to when to use Java for development.
There are dozens of Oracle products that each University could choose to implement. Many of these provide functionality that will only indirectly support the Fusion Applications. Universities may choose to deploy some of these Oracle products so they can meet needs on their campus, and get the added benefit of integration with the Fusion Applications.
For most of these products, unless you have a compelling reason to have a single vendor provide your entire infrastructure, a best-of-breed approach could be an effective implementation strategy.
Therefore a school could move completely to the Fusion Applications, and never deploy any of these products.
While this document suggests adding these additional components as “Step #7” of your roadmap to
Fusion, there is no reason you could not adopt these tools earlier, later, or not at all. The exact timing will depend upon the needs of your institution. We have listed these last in the roadmap because we are not yet convinced they are integral components of the Fusion applications. These products groups include:
1.
Business Intelligence
38 of 51 pages

Due to the large number of product acquisitions that have been made by Oracle in the last two years, Oracle’s business intelligence strategy is confusing. They offer a suite of tools and applications to provide warehouses, analytics, dashboards, activity monitoring, extract transform load (ETL), reporting and other common business intelligence functionality.
Some institutions will choose to leverage Oracle business intelligence options for their Fusion
Applications. Some tools (e.g. the Discoverer reporting tool) are applicable across Oracle and non-Oracle applications. Other products (e.g. analytics) may only be applicable for Fusion
Applications.
2.
Identify Management and Directory
Many schools are already pursuing Identity Management (IdM) solutions for their campuses.
Oracle has been aggressive in acquiring IdM companies and offers a full suite of products. An
IdM solution will be important part of the middleware to support Fusion Applications, but you could choose to substitute a non-Oracle product.
3.
Collaboration Services
Oracle will likely provide integration between their Fusion Applications and the Oracle
Collaboration Suite. The landscape for these tools is very competitive and Microsoft has a large market share. We believe Oracle will support integration with Microsoft products to the best of their ability, but history has shown that technical issues can sometimes limit integration with Microsoft products.
4.
Oracle Web Cache
Oracle Web Cache provides load balancing, caching and other performance related functionality for web applications. Schools without load balancing solutions may choose this product.
39 of 51 pages

This section provides sample “roadmaps” for a pair of fictional universities of moderate to large size.
The criteria for evaluation are based upon the Fusion Readiness Scorecard shown in Appendix A. Any resemblance of these imaginary plans and strategies to the overall direction, plans, strategies, tactics, schemes, or designs of any real institution, college, or school, whether located in the Northeast region of the United States of America or elsewhere, is purely coincidental.
Background on this example University: o Financial systems are currently in E-Business Suite 11.5.10. Corporate Culture: Main Street o Mountain Cat State University (MCU) has an Institutional Culture that, for the purposes of the
E-Business Suite has tended to be “Dip-a-Toe.” They have tended to upgrade their E-Business
Suite to relatively recent releases, but have always remained off the “bleeding edge.” They have just recently completed an upgrade to E-Business Suite 11.5.10. Support
Requirements: Limited Exposure. o MCU has customized very little. Customizations tend to be minor and are made according to
Oracle’s published techniques for extending E-Business Suite. When possible tries to retire customizations at upgrade time. Support Requirements: Limited Exposure. o MCU’s organizational growth trends toward expansion. This has led to additional institutional initiatives designed to further this trend. MCU’s operating model tends to be towards focusing on specific initiatives at any given time; organizational growth has not, as yet, reached a level that would justify significant increases in IT budgets, and MCU’s business strategy is usually one of moderate change. MCU has therefore determined that in order to have resources free to meet numerous and pressing business initiatives, MCU would like to execute as few major Oracle upgrades as possible in the next few years. If they can skip an upgrade, they will. Operating Cost: Focus. Business Strategy: Moderate Change.
Organizational Growth: Expanding. Business Initiatives: Numerous. o MCU’s application functionality and information management to support the numerous business initiatives is deficient today and will require enhancement. Pressing business needs will force the acquisition or development of software in the short and long term. The school cannot “freeze” its systems and wait for next generation applications. Would like new software and enhancements to fit as a well as possible into long term application plans.
Application Functionality: Deficient today in some areas. Information Management:
Enhancement Required. o MCU is considering moving to Fusion applications in the future, but cannot commit until overall cost of conversion, cost of ownership, and capability of the applications is known. This tends to fit well with MCU’s focused operating model. Operating Model: Focus. o Whether or not Fusion Applications are embraced, expects to have many non-Oracle applications within its portfolio. This will leave MCU with a relatively complex software footprint, and may increase risk somewhat in terms of overall support requirements. Support
Requirements: Between Limited Exposure and High Risk. Software Footprint: Moderately
Complex. o MCU’s overall approach is still to buy applications instead of building them from scratch. That said, MCU expects to do more application development in the future, either as part of open source initiatives, or as part of point solutions.
40 of 51 pages

o MCU is a large user of various Oracle databases; the Oracle middleware stack is comprised of the standard Oracle 11i tech stack. In terms of Oracle products, MCU’s support requirements tend towards limited exposure with a very manageable software footprint. Support
Requirements: Limited Exposure. Software Footprint: Manageable. o MCU does not currently have a Java development platform in place. MCU realizes that Java development will be part of application portfolio in the future, so would like to select a single
Java application development platform on which to base development. This decision is driven by a desire to keep its development software footprint and support requirements manageable and low-risk from the start. Support Requirements: Limited Exposure. Software Footprint:
Manageable. o Plans to have .Net as part of application development portfolio. Would prefer to minimize duplication of infrastructure across .Net and Java environments. For example, would prefer to run one Enterprise Service Bus, not two. While the use of .Net potentially increases support requirements, and will impact the manageability of the software footprint, MCU deems those incremental differences well worth the added functionality/capability/choice. Support
Requirements: Limited Exposure. Software Footprint: Manageable. o Would prefer to have a limited set of infrastructure providers, but does not want to be overly committed to one vendor. This of course is driven overall by the desire for limited risk in support requirements and to keep the software footprint manageable. Support
Requirements: Limited Exposure. Software Footprint: Manageable o Like most public institutions, is under significant financial pressures. Ongoing operational funding for administrative systems will not increase in the foreseeable future; in fact, there is pressure to decrease ongoing expenses. One-time expenditures may be possible, but must be justified in business terms. There are numerous business initiatives to lock in what looks like expanding organizational growth; the overall operating model is focused, and to the extent that IT can assist with the business initiatives, it must do so in a focused fashion, which limits the number of IT initiatives. Operating Model: Focus. IT Initiatives: Limited.
High-level Roadmap
“Mountain Cat” State University” tends to be a “Dip-A-Toe” institution, though some things may begin to shift due to favorable changes in Organizational Growth. Overall, MCU currently has a manageable software footprint and tends to have relatively low risk index in its support requirements. MCU’s current software is sorely lacking in required features and functionality, however, and as a result enhancements are required now.
An analysis of Release 12 reveals that new functionality required is not contained within the applications themselves. To solve their needs, they will likely buy some and build others. They have determined that when they build, they will build in a manner consistent with being able to easily upgrade to Fusion Applications. SOA and Web Services seem the clear industry direction, and buying and building according to this model will preserve their options.
The fact that MCU has an immediate need for development and is a heavy user of Oracle databases and the E-Business Suite weighs very heavily in favor of adopting JDeveloper as their Java development tool. It is clear that the OracleAS10g Application Server is a significant deployment platform for Service Oriented, event-driven, Java-based applications and extensions; moreover, it is clear that Oracle has a strong commitment to integrating with .Net both at the level of the database and at Fusion Middleware layer. Not only can .Net developers easily access Oracle databases, but
.Net-based services can be accessed from J2EE services, and J2EE services can be accessed from
.Net-based services. The OracleAS10g Application Server Enterprise Services Bus specifically integrates with .Net, and Oracle specifically tests on an ongoing basis with .Net products to confirm interoperability.
MCU’s plan calls for adopting Fusion Applications in 2012. To prepare for these applications, MCU will implement various middleware components over several years. By the time they get to Fusion,
41 of 51 pages

MCU expects to have a robust services-based infrastructure which is in use across many applications and ready to be leveraged by the Fusion Applications.
2007
2008 o Premier Support for E-Business Suite started in November 2004; Premier Support ends in November of 2007 and Extended Support begins; o Consider addressing pressing business needs with new custom modules; o Begin to extend use of Oracle Enterprise Manager from its current Oracle-only use, to also oversee E-Business Suite to the extent possible; o Begin using XML Publisher for new reports in the E-Business Suite. Also convert some existing reports to XML Publisher; o Continue to perform smaller enhancements and extensions as required E-Business
Suite application using Oracle’s recommendations for extending and enhancing the
E-Business Suite; techniques include Form Personalization, OA Personalization,
Form Folders, Descriptive Flexfields, and Oracle Workflow; o Train a core group of developers in Java generally and in core tools specifically; engage these developers with respect to selecting a strategic Java development platform; o Select a strategic Java development and runtime platform including supporting Web
Services infrastructure (e.g. services directory) and application server; o Select a messaging infrastructure (an Enterprise Service Bus); o Begin looking at applications that will be purchased to meet pressing business needs with the goal of having a prioritized short list at the end of the year; o Perform routine maintenance on E-Business Suite in the form of regulatory patches and maintenance packs. o Acquire and deploy the strategic Java development and runtime platform; o Acquire and deploy a messaging infrastructure (an ESB); o Begin development of new modules using Java development platform and tools; o Begin acquiring and deploying non-Oracle software to meet pressing business needs; o Begin Identity Management (IdM) project; o Continue to extend use of Oracle Enterprise Manager to also oversee E-Business
Suite by adopting the 11i backward-compatible Release 12 management pack; o Begin looking at Open Interfaces and pilot a project to use one of the Web Service interfaces in a test instance to learn how to use these interfaces; o Map existing Open Interfaces to Web Service based interfaces that exist; pilot a project to convert to one of the Web Service-based interfaces with the goal of providing a proof of concept for one of the live interfaces; begin considering how this interface will be rolled out; o Continue to use XML Publisher for new reports and for porting old Oracle Reports and PL/SQL “reports;” o Roll out use of XML Publisher to a core group of business analysts as an alternative to other reporting tools used in the organization; o Continue to enhance and extend E-Business Suite with smaller seeded extension capabilities, but also begin to pilot extensions through Java and OA Framework applications; and
42 of 51 pages

2009
2010
2011
2012 o Perform routine maintenance on E-Business Suite in the form of regulatory patches and maintenance packs. o Complete Identity Management project; o Begin rolling out Web Service-based interface; continue converting open interfaces to the new model; o Continue acquiring and deploying non-Oracle software to meet pressing business needs; o Acquire and deploy Web Services management infrastructure components o Use Java tools to create and deploy a Web Service that exposes significant strategic functionality and/or data in E-Business Suite; select a strategic service that can be consumed and used to great effect by the applications acquired to meet pressing business needs as well as the custom modules written in-house; o Continue to use XML Publisher for new reports. o Continue development of new modules using Java development platform and tools; o Acquire and deploy a financial data hub. o Perform routine maintenance on E-Business Suite in the form of regulatory patches and maintenance packs. o Begin upgrade activities; upgrade a development instance to current Fusion
Applications release with the stated goal of giving the applications to Functionals for testing and gap analysis; o Give upgraded instance to development teams to determine what it will take to port various application extensions to Fusion Applications from E-Business Suite
11.5.10. o Begin porting of custom developed applications and extensions to Fusion
Applications; o Perform routine maintenance on E-Business Suite in the form of regulatory patches and maintenance packs. o Begin upgrade activities o Run multiple upgrades against test instances to determine timings o Continue porting custom modules, extensions, and interfaces to Fusion; o Perform routine maintenance on E-Business Suite in the form of regulatory patches and maintenance packs. o Extended Support for Release 11.5.10 ends November 2012; Sustaining Support begins. o Upgrade to Fusion Applications.
43 of 51 pages

Background on this example University: o Big Bear University (BBU) has an institutional culture that has tended towards “Dive-Right-In.”
While BBU has managed to stay somewhat directly off the bleeding edge of E-Business Suite releases, BBU has engaged in a relatively large amount of development work across many of its releases; this development has specifically included working closely with Oracle on significant enhancements and on additional E-Business Suite applications. On a module-bymodule basis, BBU has been an early adopter of a number of modules including Grants, Web
Requisitions and Internet Procurement, Internet Expenses, etc. Institutional Culture: trends towards Early Adopter. o BBU has just recently completed an upgrade to E-Business Suite 11.5.10 CU2. Support
Requirements: Limited Exposure. o BBU’s software footprint is relatively complex. In terms of Oracle products, BBU’s support requirements tend towards limited exposure with a very manageable software footprint. BBU uses E-Business Suite for HR / Payroll / Finance / Procurement. The Oracle middleware is comprised of the standard Oracle 11i tech stack. There are many other Oracle databases on campus, as BBU has a site license for the Oracle database. For example, BBU has developed a custom data warehouse that runs on an Oracle database. SQL Server and open source databases are present as well to a limited degree. Additionally, BBU has begun using ASP providers for several other applications including Expense Reporting and Requisitioning. Each of the APS solutions has interfaces into and out of E-Business Suite and/or other database systems. BBU has some 600 core E-Business Suite users, but there are as many as 5000 to
6000 casual users when the various self-service and ASP solutions are considered. Software
Footprint: Moderately Complex moving towards Complex. Support Requirements: Limited
Exposure. o BBU has kept fairly current with E-Business suite upgrades. Since they run the Oracle Payroll application, each year they are required to apply at a minimum, an HR Family Pack (e.g. HR
RUP H) to support calendar year-end activities. When important new functionality is present they will also upgrade to the most recently released maintenance release (e.g., 11.5.8 to
11.5.10). BBU’s upgrade activities typically take place between July and November. o BBU has created a number of extensions and customizations to the E-Business Suite. These include
1.
Custom Oracle Forms and applications built using Oracle Forms that are “bolted on” to the E-Business Suite via the FND framework;
2.
Custom PL/SQL to perform a numerous support tasks such as importing and attaching images to various E-Business Suite documents, extending Oracle’s Direct
Deposit capabilities, etc.
3.
Custom PL/SQL to perform a variety of support tasks associated with importing data into the E-Business Suite via the Oracle Open Interfaces; these documents include
Purchase Orders, Invoices, Expense Reports, and GL Journals; additionally, new
“people” are imported from a person “hub” located outside of the E-Business Suite and some of these people are given authorizations in E-Business Suite using Oracle
FND user APIs.
4.
Custom Reports to serve a variety of business requirements;
44 of 51 pages

5.
Custom.pll extensions to influence the way the forms work and to support a relatively complex set of charging instructions.
6.
Custom Self-Service Web Applications that are bolted on to the E-Business Suite using ICX extensions and the AK Dictionary.
7.
Custom workflows to manage certain business processes such as managing vendors;
8.
BBU has created at least one Web Service which is used by one of its ASP solution providers to validate its charging account segments. This Web Service uses a standard Web Service interface, but was not built using Oracle technology: a service was created that wraps a set of PL/SQL package calls.
9.
BBU has created a number of other “services” used to perform a variety of export tasks associated with getting current data to BBU’s growing number of ASP solution providers; these exports include charging instructions, vendors, user data and authorizations bound for the external systems, shipment locations at the University, etc. These services are batch processes and are performed by a non-Oracle
Middleware product; this product performs queries and calls against views and
PL/SQL functions and packaged procedures, formats data, and transmits it to the
ASP solution provider as agreed. BBU is making increased use of this model for transmitting and receiving data to and from the E-Business Suite, and is using Web
Service standards wherever and whenever possible to perform this communication.
10.
In making extensions to the E-Business Suite, BBU has conformed strongly to
Oracle’s recommendations for extending the E-Business Suite; BBU has rarely strayed from those recommendations and has found that maintaining such extensions is relatively easy. Support Requirements: Limited Exposure. o BBU’s Business Strategy tends to be between Moderate Change and Highly Dynamic, and the
Operating Model tends towards being somewhere between Focused and Differentiated.
Certain lines of business are currently expanding, and institutional initiatives are usually numerous. Operating Cost: Focused to Differentiated. Business Strategy: Moderately
Dynamic Change. Organizational Growth: Expanding somewhat. Business Initiatives:
Numerous. o BBU’s application functionality and information management is becoming deficient today and requires enhancement. Pressing business needs have forced changes in specific business processes and enhancements, and extensions to the E-Business Suite have been made in the short- and are also planned for the long-term. Application Functionality: Deficient Today in some areas. Information Management: Enhancement Required. o BBU will move to Fusion applications in the future, but is in the initial stages of discovering the capabilities of the applications as well as the implications of the change to the current systems. IT Initiatives: Limited. o BBU has and expects to have many non-Oracle applications within its portfolio. BBU’s approach has often been to build applications from scratch where packaged solutions do not exist or meet its needs. However, it has also worked with vendors such as Oracle on substantial extensions and modules, and has started to use ASP solutions for certain strategic areas. BBU expects to do more point solution application development in the future, and has begun to adopt and deploy Service Oriented Architecture as a part of those longer term plans. Support Requirements: Between Limited Exposure and High Risk. Software
Footprint: Moderately Complex. o BBU does not currently have a Java development platform in place for the E-Business Suite.
However, BBU does have a Java development platform in place under a well-formed department that builds applications for the Web in the non-E-Business Suite space. BBU realizes that Java development will be part of E-Business Suite development in the future, and if possible would like to select a single Java application development platform on which to base development at the University. This decision is driven by a desire to keep its
45 of 51 pages

development software footprint and support requirements manageable and low-risk from the start. Support Requirements: Limited Exposure. Software Footprint: Manageable. o Would prefer to have a limited set of infrastructure providers, but does not want to be overly committed to one vendor. This, of course, is driven overall by the desire for limited risk in support requirements and to keep the software footprint manageable. Support
Requirements: Limited Exposure. Software Footprint: Manageable
High-level Roadmap
BBU’s plan calls for adopting Fusion Applications by 2012.
2007
2008
2009
2010
2011
2012 o General Release of Release 12.0 in early 2007 o BBU determines to remain on the 11.5.10 releases until Release 12 is stable
(probably waiting until Release 12.1) o BBU performs their annual upgrade by applying HR Roll Up Patch issued in July to their 11.5.10.2 applications. o BBU begins investigating what is required to port customizations and extensions to the Fusion Middleware that is used by Release 12; o Cease development of Oracle Reports-based solutions, begin using XML Publisher
Instead. o BBU performs annual upgrade in summer on the next point release of 11.5.10. o After the upgrade install stand-along Oracle AS10g application server and integrate with 11.5.10 tech stack. o Cease development of any Forms-based and mod_plsql-based applications that will be tightly-coupled with the E-Business Suite, begin using OA Framework instead. o First Fusion general release occurs in 2008 o In early 2009 BBU begins gap analysis and functional review of the current general release of R12 (R12.1?); o Determine which custom applications will be phased-out by use of Release 12 or other vendor supplied solutions. o Complete porting of mod_plsql-based self-service applications to OA Framework architecture. o Begin testing and migrating enhancements and customizations to Release 12; o Upgrade to Release 12.1 in the July-November time frame o BBU performs their annual upgrade by applying HR Roll Up Patch issued in July to their Release 12.1 applications. o Complete Porting of all custom Oracle Reports-based customizations to XML
Publisher. o Complete porting of Forms-based applications to OA Framework architecture. o BBU performs annual upgrade in summer on the next point release, (R12.2?). o Begin investigation of BPEL as a replacement for custom Oracle workflows and business events. o Premier Support for Release 12.0 ends (Does not apply to BBU)
46 of 51 pages

o In early 2012 BBU begins gap analysis and functional review of the current general release of Fusion (Fusion 2 or 3) o Determine which custom applications will be phased-out by use of Fusion 3 or other vendor supplied solutions. o Complete Porting of all OA Framework-based Applications to ADF. o Begin testing and migrating enhancements and customizations to Fusion 3; o Upgrade to Fusion 3 in the July-November time frame
47 of 51 pages

The Technical Advisory Group (TAG) is the HEUG product area group (PAG) responsible for the Oracle technology products affecting enterprise systems. Members are selected by the HEUG Board, and serve three year terms.
One of the charges of the TAG is to communicate to HEUG member institutions on pertinent technical issues. In 2006-2007 the TAG plans on publishing several white papers to accomplish this goal.
The TAG holds monthly conference calls and responds to issues generated by member institutions.
Traditionally, the TAG meets twice a year with Oracle strategists. TAG members also meet as needed with these strategists to discuss open issues and gather appropriate information for TAG activities.
If you have further questions about the TAG and/or this document, please contact us at tag.pag@list.heug.org
.
The primary author of this white paper was:
 Shane Anderson, Yale University (Technical Advisory Group member)
The primary reviewer of this white paper was:
 Kari Branjord, University of Minnesota (2006-2007 HEUG Vice President - Technology)
 Paul Czarapata, Kentucky Comm. & Tech. College Sys (2006-2007 Chair)
 Chris Rigsby, University of Minnesota (2006-2007 Vice Chair)
 Beverly Allen, California Institute of Technology
 Shane Anderson, Yale University
 Richard Ashwell, DePaul University
 Rob Brennan, University of Western Ontario
 Jack Duwe, University of Wisconsin-Madison
 Kristal Jackson, University of Central Florida
 Lisa Kiracofe, James Madison University
 Todd Langille, Dartmouth College
 Criss Laidlaw, Williams College
 Tomas Milowski, Oregon Health and Science University
 Gary Milligan, Nova Scotia Community College
 Aaron Neal, Indiana University
 Tony Neaton, Griffith University
 Corey Pedersen, University of Utah
 Tina Thorstenson, Arizona State University
 Teresa Wimmer, University of Virginia
 Bill Wrobleski, University of Michigan
48 of 51 pages

Oracle Roadmap to Fusion Presentation at Oracle Open World, 2006; Author: Jesper
Andersen, SVP, Applications Strategy
49 of 51 pages

1 See: Oracle Fusion Strategy Briefing - Halfway to Fusion, January 18, 2006 at: http://www.oracle.com/applications/fusion-webcast-2006.html
2 See: John Wookey at January 18, 2006 "Halfway to Fusion" presentation. See: : http://www.oracle.com/applications/fusion-webcast-2006.html
3 See: Oracle Lifetime Support: http://www.oracle.com/applications/lifetime-support.pdf
4 See Applications Unlimited FAQ at: http://www.oracle.com/applications/applications-unlimited-faq.pdf
5 Quoting John Wookey at January 18, 2006 "Halfway to Fusion" presentation “We are leaving [Oracle
EBS] Forms and PeopleTools behind.” Quoting: Thomas Kurian: “We are using a completely new toolset based on JDeveloper, BPEL, and open standards.” Please see: http://www.oracle.com/applications/fusionwebcast-2006.html
6 See: http://blogs.oracle.com/schan/2006/11/08#a938
7 Please refer to MetaLink (examples) Note: 138264.1 General Ledger Archive/Purge FAQ, Note:
144431.1 Fixed Assets Archive/Purge FAQ, Note: 136919.1 General Ledger Archive/Purge Setup and
Usage. Examples of Product User Guide references to Archiving and Purging: AR 11.5.10 User Guide
Chapter: 11 Archive & Purge, GL 11.5.10 User Guide Chapter: 11 Maintenance, AP 11.5.10 User Guide
Chapter: 10 Resource Management
8 Please see Metalink Note : 186981.1 available here: http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=186
981.1
9 See, for example: http://downloadeast.oracle.com/docs/cd/B19306_01/workflow.102/b15853/T361836T361840.htm#I_defevsub ; see also the material at: http://www.oracle.com/technology/products/ias/workflow/wf_info.html
10 See, for example, the whitepaper entitled Oracle E-Business Suite to BPEL and Back in 3 Easy Steps : http://www.oracle.com/technology/products/applications/integration/BPEL-BES4Apps.zip
11 Data Sheet: http://www.oracle.com/technology/products/applications/integration/irep%20datasheet.pdf
the online Integration Repository is available at: http://irep.oracle.com/index.html
Please also see the article here: http://blogs.oracle.com/schan/newsItems/departments/extendingApps/2006/05/16
12 For an excellent technical resource for XML Publisher, please see: http://blogs.oracle.com/xmlpublisher/
13 See, for example, “Extending Apps, Forms Personalization - Get It While It's Hot!
” at http://blogs.oracle.com/schan/newsItems/departments/extendingApps/2006/07/18#a442
14 See: In-Depth: Using OracleAS 10g with E-Business Suite Release 11, http://blogs.oracle.com/schan/2006/05/01#a87
15 The JDeveloper release that contains this extension is available at metaLink as Patch 4725670,
“ 9IJDEVELOPER WITH OA EXTENSION ARU FOR 11i10 RUP3”
16 Please See Online User’s Guide Documentation: http://downloadeast.oracle.com/docs/cd/B14099_19/integrate.1012/b16498/intro.htm#CHDICDAC
17 See: Exploring Upgrade Strategies to oracle Fusion Applications, An Oracle Product Strategy White
Paper, January 2006.
18 Please see: Oracle XML Publisher presentation at: http://www.oracle.com/technology/products/xmlpublisher/docs/XMLPOAUG06.ppt
19 See for example, Publishing Concurrent Requests with XML Publisher, An Oracle White Paper January
2005 at: http://www.oracle.com/technology/products/xml-publisher/docs/XMLEBSRep.pdf
and Check
Printing using XML Publisher, An Oracle White Paper June 2005 at: http://www.oracle.com/technology/products/xml-publisher/docs/CheckPrintingXMLP.pdf
20 The data sheet is available at: http://www.oracle.com/technology/products/applications/integration/irep%20datasheet.pdf
. The
Repository itself is not deployed 2with 11.5.10 as such, but is available online at: http://irep.oracle.com/index.html
50 of 51 pages

21 Please see the Oracle E-Business Suite Technology Blog at http://blogs.oracle.com/schan/newsItems/departments/extendingApps/2006/07/24 and the tutorial at: http://www.oracle.com/technology/products/integration/adapters/pdf/adapter-Tutorial1-
InvokingOracleApplicationsAPI.pdf
22 See materials at: http://www.oracle.com/technology/products/applications/admin/index.html
, most particularly the presentation called Oracle E-Business Suite: System Management (Oracle OpenWorld
2005).
23 Please see: http://blogs.oracle.com/schan/newsItems/departments/release12/2006/10/17#a833
24 Indeed, it is clear that in some cases Oracle will need to sacrifice some of the interoperability of its products to support ongoing enhancements; for example, in the Fusion Applications, human workflows will be processed by the BPEL Process Manager. It seems unlikely that this functionality will be available in the BPEL implementations of other vendors. As such, Oracle’s BPEL Process manager will be somewhat more tightly integrated with the Fusion Applications that the ideal might otherwise dictate. This does not mean that other BPEL products could not be used for other purposes, but such a configuration would increase an institution’s software footprint and probably unnecessarily contribute to complexity and support requirements.
25 See, for example: http://www.oracle.com/data_hub/ebs.html
and http://searchoracle.techtarget.com/qna/0,289202,sid41_gci1042388,00.html?bucket=NEWS
51 of 51 pages