E-Business Suite Roadmap to

Oracle Fusion Applications

for Higher Education Institutions
November 27, 2006

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 HEUGs Technical Advisory Group
(TAG).
Copyright 2006 by the Higher Education User Group, Inc.
All Rights Reserved.

2 of 64 pages
 PLEASE READ OUR DISCLAIMER

This is a publication of the Higher Education User Group, Inc. (HEUG) and
was prepared by the HEUGs 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 HEUGs
interpretation of Oracles intent or product development plans, many factors can
materially affect the nature and timing of Oracles 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 E-Business Suite Roadmap to
Oracle Fusion for Higher Education Institutions, 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 institutions 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.

3 of 64 pages
 Table of Contents

TABLE OF CONTENTS......................................................................................................................... 3
PURPOSE & INTRODUCTION................................................................................................................. 4
EXECUTIVE SUMMARY........................................................................................................................ 4

SECTION 1: PLANNING & PREPARATION.....................................................................66

THE CHANGING ENTERPRISE APPLICATIONS LANDSCAPE..........................................................................66
KNOW THYSELF.............................................................................................................................. 66
UNDERSTANDING YOUR CURRENT ENVIRONMENT...............................................................................1212
WHY START MOVING TO FUSION NOW?........................................................................................... 1414

SECTION 2: APPLICATION ARCHITECTURE AND DEVELOPMENT................................1515

MOVING FORWARD WITH E-BUSINESS SUITE, SOA, AND FUSION MIDDLEWARE.......................................1515
DEVELOPMENT TOOLS AND PRACTICES............................................................................................ 1919

SECTION 3: APPLICATIONS TECHNOLOGY...............................................................2828

STEP 1: ESTABLISH AND EXECUTE AN E-BUSINESS SUITE UPGRADE PLAN.............................................2828
STEP 2: BEGIN ADOPTING SERVICE-ORIENTED DEVELOPMENT PRACTICES..............................................2929
STEP 3: IMPLEMENT CORE FUSION MIDDLEWARE INFRASTRUCTURE......................................................3030
STEP 4: EXTEND INFRASTRUCTURE WITH KEY FUSION INTEGRATION COMPONENTS..................................3232
STEP 5: INVESTIGATE AND IMPLEMENT DATA HUBS...........................................................................3636
STEP 6: EXTEND INFRASTRUCTURE WITH FUSION APPLICATION DEVELOPMENT TOOLS..............................3737
STEP 7: EMBRACE FUSION MIDDLEWARE COMPONENTS WHICH ONLY INDIRECTLY SUPPORT
APPLICATIONS............................................................................................................................. 3838

SECTION 4: EXAMPLES.........................................................................................4040
EXAMPLE 1: ROADMAP FOR MOUNTAIN CAT STATE UNIVERSITY......................................................4040
EXAMPLE 2: ROADMAP FOR BIG BEAR UNIVERSITY........................................................................4444

SECTION 5: ABOUT THE TECHNICAL ADVISORY GROUP...........................................4848

AUTHORS.................................................................................................................................. 4848
2006-2007 TAG MEMBERS......................................................................................................... 4848

APPENDIX A: FUSION READINESS SCORECARD.......................................................4949

Endnotes.................................................................................................................................... 5050

4 of 64 pages
Purpose & Introduction

This paper is the third in a series of publications from the Higher Education User
Groups 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 Oracles 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 Oracles 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.

Executive Summary
Oracles 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;

5 of 64 pages
 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.
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 papers 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).

6 of 64 pages
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 event-driven architecture, as well
as some very specific Middleware components such as XML Publisher.

7 of 64 pages
 Section 1: Planning & Preparation

The Changing
Enterprise Applications
Landscape

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.

Know Thyself

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

8 of 64 pages
 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 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 Oracles 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

9 of 64 pages
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 Oracles plan to continue providing
ongoing enhancements to current Oracle Applications beyond the delivery of
Oracle Fusion Applications. Oracles commitment to continuing the current E-
business Suite is evident in their statement that they plan to make additional
enhancements to the Oracle E-Business Suite beyond version 12. According
to Oracles 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, Oracles 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 Oracles announcements of Fusion to allow institutions
to start planning appropriately, and to plan based on strategic opportunities
as opposed to perceived exigencies.
Upgrade Paths

10 of 64 pages
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

11 of 64 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, Oracles Senior Vice President of
Applications Development, stated in Oracles 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 one-for-one conversion utilities to port Forms to the

12 of 64 pages
 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 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.

13 of 64 pages
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 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

14 of 64 pages
 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.
3. What is your vendor strategy for applications technology?
As noted in the previous paper, a schools 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. Oracles 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 Oracles Fusion Middleware as deployed with later
releases of E-Business Suite and the Fusion Applications.

15 of 64 pages
 However, Oracles 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.

Understanding Your
Current Environment

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 Oracles 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 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.

16 of 64 pages
 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 well-documented 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: cross-product 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

17 of 64 pages
Applications Manager (OAM), the Applications Dashboard contains a tab 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 organizations security policies. This would be a good
time to start a process of understanding the strengths and weaknesses of
your institutions 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.

Why Start Moving to

Fusion Now?
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.
Oracles 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.

18 of 64 pages
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.

19 of 64 pages
Section 2: Application Architecture and Development

Moving Forward with E-

Business Suite, SOA,
and Fusion Middleware

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 Oracles 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.

20 of 64 pages
 2. Message-based system integration - Subscriptions can be configured to
implement point-to-point 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 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 Managers 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

21 of 64 pages
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.
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

22 of 64 pages
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 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 Oracles 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

23 of 64 pages
 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 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 bi-
directional 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,

24 of 64 pages
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.

Development Tools and

Practices

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

25 of 64 pages
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 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.

26 of 64 pages
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 stand-alone 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.

27 of 64 pages
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-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.

28 of 64 pages
 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 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

29 of 64 pages
 Reports. In 11.5.10, Oracles 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 step-by-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 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

30 of 64 pages
 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-of-concept 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 Service-enabled 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.
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

31 of 64 pages
 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 loosely-coupled 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.
o Stop Developing mod_plsql applications

32 of 64 pages
 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

33 of 64 pages
 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 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 Oracles ADF,
ADF itself is built upon a foundation that includes an evolution of Oracles
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).
Fusion applications will be based upon Oracles 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.
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, youll be able to determine if and when
making a switch makes sense.

34 of 64 pages
 Section 3: Applications Technology

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.

Step 1: Establish and

Execute An E-Business
Suite Upgrade Plan
The first step to planning for the adoption of Fusion Applications and technology is to
update your Universitys 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

35 of 64 pages
 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.

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. Oracles 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.

Step 2: Begin Adopting

Service-Oriented
Development Practices

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 Services-based interfaces.

36 of 64 pages
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 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

37 of 64 pages
possibility of enhancing any ASP solutions you may currently offer your users and the
ability to leverage the service in new customizations and extensions.

Step 3: Implement Core

Fusion Middleware
Infrastructure

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.
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,

38 of 64 pages
 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 Oracles
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.
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 institutions best
interest not implement XML Publisher. Some institutions may choose to use it less

39 of 64 pages
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 institutions unique priorities and the existing infrastructure on
their campuses.

Step 4: Extend
Infrastructure with Key
Fusion Integration
Components

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.
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

40 of 64 pages
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 doesnt
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 Oracles 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 persons 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 arent 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 different

41 of 64 pages
 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 its likely that Oracles 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 Oracles, 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-to-application 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.

42 of 64 pages
 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.
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 10g 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 Oracles
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 Managers 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.

43 of 64 pages
 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 Oracles 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 integration product space, Fusion Applications
owners will want to rely on the Fusion Middleware to assure smooth
functionality, performance and support. 24

Step 5: Investigate and

Implement Data Hubs
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 Oracles 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-

44 of 64 pages
 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.

Step 6: Extend
Infrastructure with
Fusion Application
Development Tools
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
Oracles 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

45 of 64 pages
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 web-based 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 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.

46 of 64 pages
 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 10g 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 Oracles 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.

Step 7: Embrace Fusion

Middleware
Components which only
indirectly support
Applications

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
Due to the large number of product acquisitions that have been made by
Oracle in the last two years, Oracles 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.

47 of 64 pages
 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.

48 of 64 pages
 Section 4: Examples
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.

Example 1: Roadmap for

Mountain Cat State
University

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 Oracles published techniques for extending E-Business
Suite. When possible tries to retire customizations at upgrade time. Support
Requirements: Limited Exposure.
o MCUs organizational growth trends toward expansion. This has led to
additional institutional initiatives designed to further this trend. MCUs
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 MCUs 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 MCUs 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

49 of 64 pages
 the applications is known. This tends to fit well with MCUs 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 MCUs 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.
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, MCUs 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. MCUs current software is sorely lacking in

50 of 64 pages
required features and functionality, however, and as a result enhancements are
required now.

51 of 64 pages
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.

MCUs 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, 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.

52 of 64 pages
2007 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 Oracles 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.

2008 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

53 of 64 pages
 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
o Perform routine maintenance on E-Business Suite in the form of
regulatory patches and maintenance packs.

2009 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.

2010 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.

2011 o Begin upgrade activities

o Run multiple upgrades against test instances to determine
timings

54 of 64 pages
 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.

2012 o Extended Support for Release 11.5.10 ends November 2012;

Sustaining Support begins.
o Upgrade to Fusion Applications.

55 of 64 pages
Example 2: Roadmap for Big
Bear University

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-by-module 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 BBUs software footprint is relatively complex. In terms of Oracle products,
BBUs 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). BBUs
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 Oracles 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,

56 of 64 pages
 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;
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 BBUs
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 Oracles 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 BBUs 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 BBUs 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.

57 of 64 pages
 o BBU has and expects to have many non-Oracle applications within its
portfolio. BBUs 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
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
BBUs plan calls for adopting Fusion Applications by 2012.

2007 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.

2008 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

2009 o In early 2009 BBU begins gap analysis and functional review of

58 of 64 pages
 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

2010 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.

2011 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.

2012 o Premier Support for Release 12.0 ends (Does not apply to BBU)
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

59 of 64 pages
 Section 5: About the Technical Advisory Group
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.

Authors

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)

2006-
2007 TAG
Members

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

60 of 64 pages
 Tina Thorstenson, Arizona State University
Teresa Wimmer, University of Virginia
Bill Wrobleski, University of Michigan

61 of 64 pages
 Appendix A: Fusion Readiness Scorecard

Source: Oracle Roadmap to Fusion Presentation at Oracle Open World, 2006; Author: Jesper
Andersen, SVP, Applications Strategy

62 of 64 pages
Endnotes

63 of 64 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/fusion-webcast-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=186981.1
9
See, for example: http://download-
east.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 Users Guide Documentation: http://download-
east.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/xml-
publisher/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
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,
Oracles 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 institutions 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