ORACLE METHOD

EASIPATH MIGRATION
METHOD HANDBOOK

Release 1.0.2
February, 2006

EasiPath Migration Method (EMM) Method Handbook

Release 1.0.2
Copyright 1998, 2006 Oracle. All rights reserved.
Authors:
Steve Buchan, Bruce Dehner, Ritchie Edwards, Barbara Kaup, Jim Lange,
William Matson, Jan May, Joe Mychaleckyj, Janet Price, Stephanie Race,
William Sebastian
Project Editor: Teresia Haase
Editors:
Linda Goosens, Paige Root, Mary Sanders
The Programs (which include both the software and documentation) contain proprietary
information; they are provided under a license agreement containing restrictions on use
and disclosure and are also protected by copyright, patent, and other intellectual and
industrial property laws. Reverse engineering, disassembly, or decompilation of the
Programs, except to the extent required to obtain interoperability with other independently
created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find
any problems in the documentation, please report them to us in writing. This document is
not warranted to be error-free. Except as may be expressly permitted in your license
agreement for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using
the Programs on behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation
and technical data delivered to U.S. Government customers are commercial computer
software or commercial technical data pursuant to the applicable Federal Acquisition
Regulation and agency-specific supplemental regulations. As such, use, duplication,
disclosure, modification, and adaption of the Programs, including documentation and
technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle
license agreement, and, to the extent applicable, the additional rights set forth in FAR
52.227-19, Commercial Computer SoftwareRestricted Rights (June 1987). Oracle USA,
Inc., 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or
other inherently dangerous applications. It shall be the licensee's responsibility to take all
appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of
such applications if the Programs are used for such purposes, and we disclaim liability for
any damages caused by such use of the Programs.
The Programs may provide links to Web sites and access to content, products, and services
from third parties. Oracle is not responsible for the availability of, or any content provided
on, third party Web sites. You bear all risks associated with the use of such content. If you
choose to purchase any products or services from a third party, the relationship is directly
between you and the third party. Oracle is not responsible for: (a) the quality of third-party
products or services; or (b) fulfilling any of the terms of the agreement with the third party,
including delivery of products or services and warranty obligations related to purchased
products or services. Oracle is not responsible for any loss or damage of any sort that you
may incur from dealing with any third party.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation
and/or its affiliates. Other names may be trademarks of their respective owners.

100

Preface
T

he EasiPath Migration Method Handbook provides an overview of the

various project approaches, phases, processes, and tasks of the
EasiPath Migration Method (EMM).
The material in this book allows project managers and team members to
better understand the full scope of an EasiPath Migration Method effort
and to plan and execute EMM projects. Specifically, this book includes an
overview of EMM; a discussion of the various approaches to EMM work;
overviews; and diagrams of the phases, processes, and tasks within EMM.
This handbook, and the EasiPath Migration Method itself, are part of
Oracle MethodSM Oracles integrated approach to solution delivery.

Oracle Method

Preface i

Audience
The EasiPath Migration Method Handbook is written for project managers
and their teams. Project managers will use this handbook during the
planning and scheduling of an applications migration project.
Development team members can use this book to gain a more thorough
understanding of the entire EasiPath Migration Method effort before or
during project execution.

How the Manual Is Organized

This handbook describes all of the EMM phases, processes, and tasks. It
includes Introduction and Key Concepts chapters, followed by four
chapters describing each phase of EMM. Each phase chapter consists of
two main sections: an overview of the phase, and a description of the
approach to accomplishing that phase. The phase overview section and
the approach section provide the following information:
Phase Overview:
Objectives
Critical Success Factors
Prerequisites
Processes
Key Deliverables
Approach:
Tasks and Deliverables
Core Task Dependencies
Core and Optional Task Dependencies
Staffing
Following the phase chapters, there are nine chapters describing each
process in EMM. Each chapter consists of two main sections: a process

ii Preface

EMM Method Handbook

overview, and a section discussing all the tasks and deliverables in the
process. The process overview section provides the following information.
Process Flow
Approach
Tasks and Deliverables
Objectives
Key Deliverables
Key Responsibilities
Critical Success Factors
References and Publications
The task and deliverable descriptions provide the following information
for each task in the process.
task name
a brief description of the task
deliverable name and a brief description of the deliverable
deliverable components
responsible role
Appendix A: Appendix A provides the work breakdown structure (WBS)
for EMM.
Appendix B: Appendix B provides a description of the roles used in
EMM.
Glossary: The Glossary contains definitions of the terms, abbreviations,
and acronyms used in EMM.

How to Use this Manual

The EasiPath Migration Method Handbook contains general and detailed
information about using EMM for application migration projects. Use this
book in conjunction with the EMM deliverable templates. Together, the
book and the templates provide a complete guide for planning and

Oracle Method

Preface iii

executing an application migration project. Although designed

specifically for Oracle Applications, EMM is release independent. It
supports all current and future releases of Oracle Applications and does
not contain release specific information.

Conventions Used in this Manual

We use several notational conventions to make this handbook easy to
read.
Capitalization
Names of tasks, deliverables, processes, and phases are always given in
title capitals. For example, Upgrade Project Environments task, Future
Process Model deliverable, Business System Testing process, and
Transition phase.
Abbreviations and Acronyms
Occasionally, it is necessary to use abbreviations and acronyms when
adequate space is not available. The Glossary lists the meanings of the
acronyms and abbreviations used in the handbook.
Suggestions
We provide you with helpful suggestions throughout the handbook to
help you get the most out of the method. We highlight these suggestions
with an illuminated light bulb. Here is an example of a suggestion:
Suggestion: Verify your backup and recovery plan with your
hardware and software vendors.
Attention
We sometimes highlight important information or considerations to save
you time or simplify the task at hand. We mark such information with an
attention graphic, as follows:

iv Preface

EMM Method Handbook

Attention: Since project team training occurs simultaneously

with this task, some recommendations (or decisions) from
training may be implemented in the mapping environment. In
this case, these training inputs become predecessors to this task.

Oracle Method

Preface v

Related Publications
Other related books include:
Key Oracle Applications product manuals:
Release Installation Manual release specific
Release Upgrade Preparation Manual release specific
You may also refer to the following Project Management Method (PJM)
suite of reference books:
PJM Method Handbook
PJM Process and Task Reference
You may also refer to the following Application Implementation Method
(AIM) suite of reference books:
AIM Method Handbook
AIM Process and Task Reference
If significant custom software development will occur during your project,
you may want to reference the following Custom Development Method
(CDM) components:
CDM Quick Tour
CDM Classic Method Handbook
CDM Classic Process and Task Reference
CDM Fast Track Method Handbook
CDM Fast Track Process and Task Reference
CDM Fast Track Techniques Handbook
CDM Fast Track Addendum
CDM Standards and Guidelines Library

vi Preface

Volume 1 Requirements Modeling using Oracle Designer

EMM Method Handbook

Volume 2 Design and Generation of Multi-Tier Web

Applications

Volume 3 Building Systems using ORACLE8 Programming

Tools

Volume 4 - CDM Standards

Your Comments are Welcome

Oracle Corporation values and appreciates your comments as an Oracle
EMM practitioner and reader of the handbook. As we write, revise, and
evaluate our documentation, your comments are the most valuable input
we receive. If you would like to contact us regarding this or other Oracle
Method manuals, please use the following email address:
email: emminfo@us.oracle.com

Oracle Method

Preface vii

Table of Contents

PART

CHAPTER 1

Overview
Introduction to EMM................................................................................................1-1
What Is EMM? .............................................................................................................1-2
Migration Versus Upgrade..............................................................................1-2
EMM Project Phases ..........................................................................................1-2
Processes in EMM ..............................................................................................1-5
EMM Project Deliverables ............................................................................. 1-10
Estimating an EMM Project.......................................................................... 1-11
Managing an EMM Project PJM............................................................. 1-16

CHAPTER 2

Key EMM Concepts ..................................................................................................2-1

Overview...............................................................................................................2-2
Summary of the Migration Process ...............................................................2-2
Determining an EMM Project Approach.....................................................2-4

PART

II

CHAPTER 3

EMM Phases
Migration Assessment.............................................................................................3-1
Overview.......................................................................................................................3-2
Objectives ..............................................................................................................3-2
Critical Success Factors ....................................................................................3-2
Prerequisites.........................................................................................................3-2
Processes ...............................................................................................................3-3
Key Deliverables .................................................................................................3-4

Oracle Method

Contents ix

Approach......................................................................................................................3-6
Tasks and Deliverables.....................................................................................3-6
Core Task Dependencies ..................................................................................3-8
Core and Optional Task Dependencies .................................................... 3-10
Staffing................................................................................................................ 3-14
CHAPTER 4

Update and Test.........................................................................................................4-1

Overview.......................................................................................................................4-2
Objectives ..............................................................................................................4-2
Critical Success Factors ....................................................................................4-2
Prerequisites.........................................................................................................4-2
Processes ...............................................................................................................4-4
Key Deliverables .................................................................................................4-5
Approach......................................................................................................................4-8
Tasks and Deliverables.....................................................................................4-8
Core Task Dependencies ............................................................................... 4-10
Core and Optional Task Dependencies .................................................... 4-12
Staffing................................................................................................................ 4-16

CHAPTER 5

Transition.....................................................................................................................5-1
Overview.......................................................................................................................5-2
Objectives ..............................................................................................................5-2
Critical Success Factors ....................................................................................5-2
Prerequisites.........................................................................................................5-2
Processes ...............................................................................................................5-3
Key Deliverables .................................................................................................5-4
Approach......................................................................................................................5-5
Tasks and Deliverables.....................................................................................5-5
Core Task Dependencies ..................................................................................5-6
Core and Optional Task Dependencies .......................................................5-8
Staffing................................................................................................................ 5-10

CHAPTER 6

Production....................................................................................................................6-1
Overview.......................................................................................................................6-2

x Contents

EMM Method Handbook

Objectives ..............................................................................................................6-2
Critical Success Factors ....................................................................................6-2
Prerequisites.........................................................................................................6-3
Processes ...............................................................................................................6-3
Key Deliverables .................................................................................................6-3
Approach......................................................................................................................6-4
Tasks and Deliverables.....................................................................................6-4
Core Task Dependencies ..................................................................................6-5
Core and Optional Task Dependencies .......................................................6-6
Staffing...................................................................................................................6-7
PART

III

CHAPTER 7

EMM Processes
Business Requirements Review (RR).................................................................7-1
Process Flow ........................................................................................................7-2
Approach..............................................................................................................7-3
Tasks and Deliverables.....................................................................................7-4
Objectives ..............................................................................................................7-4
Key Deliverables .................................................................................................7-5
Key Responsibilities ..........................................................................................7-5
Critical Success Factors ....................................................................................7-6
RR.020 Review Current Business Processes (Optional).................................7-7
RR.030 Develop Future Process Model (Optional)...........................................7-9
RR.060 Gather Business Volumes (Optional)................................................. 7-12
RR.070 Review Business Requirements Scenarios (Core)........................... 7-14

CHAPTER 8

Requirements Mapping Update (MU)...............................................................8-1

Process Flow ........................................................................................................8-2
Approach..............................................................................................................8-3
Tasks and Deliverables.....................................................................................8-4
Objectives ..............................................................................................................8-4
Key Deliverables .................................................................................................8-5
Key Responsibilities ..........................................................................................8-5
Critical Success Factors ....................................................................................8-6
MU.005 Identify New Release Changes (Core)..................................................8-7

Oracle Method

Contents xi

MU.011 Upgrade Project Environments (Core) .................................................8-9

MU.020 Remap Business Requirements (Core).............................................. 8-11
MU.030 Remap Business Data (Core) ............................................................... 8-13
MU.040 Review Integration Fit Analysis (Optional).................................... 8-15
MU.070 Review Reporting Fit Analysis (Core)............................................... 8-17
MU.090 Confirm Integrated Business Solutions (Core) ............................... 8-19
MU.100 Update Process Narratives (Core)...................................................... 8-20
MU.110 Revise Application Setups (Core)....................................................... 8-23
MU.120 Revise Security Profiles (Core)............................................................. 8-26
CHAPTER 9

Migrate Application and Technical Architecture (MA) ...............................9-1

Process Flow ........................................................................................................9-2
Approach..............................................................................................................9-3
Tasks and Deliverables.....................................................................................9-7
Objectives ..............................................................................................................9-7
Key Deliverables .................................................................................................9-8
Key Responsibilities ....................................................................................... 9-10
Critical Success Factors ................................................................................. 9-13
MA.020 Perform Architecture Impact Analysis (Optional)........................ 9-14
MA.110 Define Technical Prototype Subprojects (Optional)...................... 9-16
MA.140 Update Application Architecture (Optional).................................. 9-18
MA.160 Update Technical Architecture (Optional)...................................... 9-21
MA.180 Identify New Performance Risks (Optional)................................... 9-23
MA.190 Update System Management Procedures (Optional)................... 9-25

C H A P T E R 10

Migrate Custom Extensions (ME) ..................................................................... 10-1

Process Flow ..................................................................................................... 10-2

xii Contents

EMM Method Handbook

Approach........................................................................................................... 10-3
Tasks and Deliverables.................................................................................. 10-4
Objectives ........................................................................................................... 10-4
Key Deliverables .............................................................................................. 10-5
Key Responsibilities ....................................................................................... 10-5
Critical Success Factors ................................................................................. 10-6
ME.010 Perform Customization Impact Analysis (Optional).................... 10-7
ME.020 Estimate Custom Extension Migration (Optional)......................... 10-9
ME.030 Update Design and Build Standards (Optional)..........................10-12
ME.050 Identify Custom Database Changes (Optional)............................10-15
ME.060 Identify Module Design Changes (Optional)................................10-16
ME.100 Implement Database Changes (Optional)......................................10-18
ME.110 Update Custom Modules (Optional)................................................10-19
ME.120 Create Migration Routines (Optional).............................................10-20
C H A P T E R 11

Data Migration (DM)............................................................................................. 11-1

Process Flow ..................................................................................................... 11-2
Approach........................................................................................................... 11-3
Tasks and Deliverables.................................................................................. 11-4
Objectives ........................................................................................................... 11-4
Key Deliverables .............................................................................................. 11-5
Key Responsibilities ....................................................................................... 11-5
Critical Success Factors ................................................................................. 11-6
DM.020 Perform Data Impact Analysis (Optional)....................................... 11-7
DM.050 Perform Migration Data Mapping (Optional)................................ 11-9
DM.060 Design Manual Migration Strategy (Optional)............................11-10
DM.070 Design Migration Programs (Optional)..........................................11-12
DM.080 Prepare Data Migration Test Plans (Optional).............................11-14
DM.090 Develop Data Migration Programs (Optional).............................11-16

Oracle Method

Contents xiii

DM.100 Perform Data Migration Unit Test (Optional)...............................11-18

DM.110 Perform Migration Business Object Test (Optional)...................11-19
DM.120 Perform Data Migration Validation Test (Optional)...................11-20
DM.130 Install Data Migration Software (Optional)..................................11-21
C H A P T E R 12

Documentation (DO)............................................................................................. 12-1

Process Flow ..................................................................................................... 12-2
Approach........................................................................................................... 12-3
Tasks and Deliverables.................................................................................. 12-3
Objectives ........................................................................................................... 12-4
Key Deliverables .............................................................................................. 12-4
Key Responsibilities ....................................................................................... 12-5
Critical Success Factors ................................................................................. 12-5
DO.100 Update User Reference Manual (Optional)...................................... 12-6
DO.110 Update User Guide (Core)..................................................................... 12-8
DO.120 Update Technical Reference Manual (Optional)..........................12-10
DO.130 Update System Management Guide (Optional)............................12-11
DO.140 Update Online Help Text (Optional)...............................................12-13

C H A P T E R 13

Business System Testing (TE)............................................................................ 13-1

Process Flow ..................................................................................................... 13-2
Approach........................................................................................................... 13-4
Tasks and Deliverables.................................................................................. 13-4
Objectives ........................................................................................................... 13-5
Key Deliverables .............................................................................................. 13-5
Key Responsibilities ....................................................................................... 13-6
Critical Success Factors ................................................................................. 13-7
TE.010 Develop Test Strategy (Core).................................................................. 13-8
TE.020 Update Unit Test Scripts (Optional)..................................................13-10
TE.030 Update Link Test Scripts (Optional)..................................................13-12

xiv Contents

EMM Method Handbook

TE.040 Update System Test Scripts (Core) .....................................................13-14

TE.050 Update Systems Integration Test Scripts (Optional).....................13-16
TE.055 Update User Acceptance Test Scripts (Core)...................................13-18
TE.070 Perform Unit Testing (Optional).........................................................13-20
TE.080 Perform Link Testing (Optional).........................................................13-21
TE.085 Test Pre-Upgrade Steps (Core).............................................................13-22
TE.091 Test Software Upgrade (Core)..............................................................13-23
TE.092 Test Post-Upgrade Steps (Core)...........................................................13-24
TE.093 Perform Post-Upgrade Reconciliation Testing (Core) ..................13-25
TE.096 Review Upgrade Test Results (Core).................................................13-26
TE.100 Prepare Key Users for Testing (Core).................................................13-27
TE.110 Perform System Testing (Core) ............................................................13-28
TE.130 Perform Systems Integration Testing (Optional)............................13-30
TE.135 Perform User Acceptance Testing, Test System (Core).................13-32
TE.140 Perform User Acceptance Test,
Production System (Optional)...........................................................................13-34
C H A P T E R 14

Training (TR)............................................................................................................ 14-1

Process Flow ..................................................................................................... 14-2
Approach........................................................................................................... 14-3
Tasks and Deliverables.................................................................................. 14-3
Objectives ........................................................................................................... 14-3
Key Deliverables .............................................................................................. 14-4
Key Responsibilities ....................................................................................... 14-4
Critical Success Factors ................................................................................. 14-5
TR.010 Prepare Training Strategy (Core).......................................................... 14-6

Oracle Method

Contents xv

TR.050 Prepare Project Team Training (Core)................................................. 14-7

TR.060 Train Project Team.................................................................................... 14-9
TR.070 Develop User Training Materials (Core)..........................................14-10
TR.080 Prepare User Training Environment (Core)....................................14-12
TR.090 Train Users (Core)...................................................................................14-13
C H A P T E R 15

Production Migration (PM).................................................................................. 15-1

Process Flow ..................................................................................................... 15-2
Approach........................................................................................................... 15-4
Tasks and Deliverables.................................................................................. 15-4
Objectives ........................................................................................................... 15-5
Key Deliverables .............................................................................................. 15-5
Key Responsibilities ....................................................................................... 15-6
Critical Success Factors ................................................................................. 15-7
PM.010 Prepare Transition Strategy (Core) ..................................................... 15-8
PM.030 Develop Detailed Transition and
Contingency Plan (Core) ....................................................................................... 15-9
PM.035 Perform Pre-Upgrade Steps (Core)....................................................15-10
PM.040 Upgrade Production Environment (Core) ......................................15-12
PM.045 Perform Post-Upgrade Steps (Core)..................................................15-13
PM.050 Revise Application Setups (Core) .....................................................15-14
PM.070 Verify Production Readiness (Core).................................................15-15
PM.080 Commence Production (Core) ............................................................15-17
PM.090 Audit Production System (Optional)...............................................15-18
PM.100 Measure System Performance (Core)................................................15-20
PM.110 Maintain System (Core)........................................................................15-22

xvi Contents

EMM Method Handbook

PM.120 Refine Production System (Core).......................................................15-23

APPENDIX

EMM Work Breakdown Structure......................................................................A-1

How to Read the Work Breakdown Structure...................................................A-2
EMM Work Breakdown Structure ........................................................................A-6

APPENDIX

EMM Roles .................................................................................................................B-1

Role Descriptions ...................................................................................................... B-2
GLOSSARY

Oracle Method

Contents xvii

PART

Overview

CHAPTER

Introduction to
EMM
T

his chapter discusses the overall content and structure of Oracles

EasiPath Migration Method (EMM).
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update
Migrate Application and Technical Architecture
Migrate Custom Extensions
Data Migration
Documentation
Business System Testing
Training
Production Migration

Figure 1-1

Oracle Method

EasiPath Migration Process Overview

Introduction to EMM 1 - 1

What Is EMM?
EMM is Oracles life-cycle method and toolkit for migrating from one
Oracle Applications release to another. This toolkit was designed initially
for organizations migrating Oracle Applications to address the year 2000
challenge. However, it is applicable to any Oracle Applications migration.

Migration Versus Upgrade

An upgrade is limited to installing a newer release of the application
software and does not include changes to the technical architecture. It can
include revising business processes and updating (or eliminating) custom
extensions.
A migration is any change that transforms your hardware and/or
software architecture to a new state. Therefore, a software upgrade is a
type of migration, but is limited in scope and impact. A migration can
include moving to a new hardware environment (upgraded or new
computers), operating system, network environment (including the
number of tiers), or user interface environment (character-mode,
SmartClient, or internet computing model) in addition to an application
software upgrade.

EMM Project Phases

EMM projects are conducted in phases that provide quality and control
checkpoints to coordinate project activities that have a common goal.
During a project phase, your project team will be executing tasks from
several processes. The figure below illustrates the relationship between
phases and processes.

1 - 2 Introduction to EMM

EMM Method Handbook

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update
Migrate Application and Technical Architecture
Migrate Custom Extensions
Data Migration
Documentation
Business System Testing
Training
Production Migration

Figure 1-2

Phases in EMM

A description of each EMM Phase follows:

Migration Assessment
During Migration Assessment you analyze the impact of application
release changes and propose steps to complete the upgrade project using
the following information sources:
current production system documentation, supporting technical
architecture and administrative environment including Oracle
Applications, customizations, and application interfaces
new application release documentation, emphasizing Oracles
product Release Installation and Release Upgrade Preparation
manuals, which summarize functional and technical changes from
prior releases
business and system goals and objectives of the organization as
related to the upgrade including plans for process change, enabling
new application functionality, replacement of customizations,
retirement of legacy systems, and application and technical
architectural changes
Update and Test
During Update and Test the project team performs tasks to establish a test
environment, configure and test new application processes, and assess if
the test results achieve the functional business objectives and
requirements. The team will also update or build customizations, custom

Oracle Method

Introduction to EMM 1 - 3

data migrations, interfaces, and the application and technical architecture

as part of the completed solution.
It is important to distinguish between the standard data migration steps
documented in the Release Installation and Release Upgrade Preparation
manuals and the supplementary steps unique to your project. Such
supplementary steps are required to support custom interfaces or
migration of custom data.
Transition
During Transition the project team establishes the fully configured and
migrated production environment and deploys the upgraded applications
environment into the organization. All elements of the upgrade must come
together to transition successfully to a final production environment.
During this phase, end users are trained on new release functionality. The
technical team updates the production environment by executing the
standard migration steps including pre- and post-upgrade steps. Custom
migration steps are also executed, if required, to convert data and
implement changes to application interfaces.
In a phased approach, Transition may consist of multiple deployments
where subsets of the applications may be deployed to various
geographical sites and/or business units over time.
Transition is a demanding experience for the end users who may have to
maintain multiple systems until production is declared. Preparation and
planning in advance are key to facilitating the transition process while
minimizing the disruption to the business.
Production
Production begins immediately with the production cutover. It marks the
last phase of the upgrade project and the resumption of the system support
cycle for the new release. System performance is assessed and the
upgraded system is tuned to achieve performance objectives. Other system
refinements may be necessary to achieve a stable production system.

1 - 4 Introduction to EMM

EMM Method Handbook

Processes in EMM
The overall organization of EMM is expressed by a process-based systems
development method.
A process is a cohesive set of related tasks that meet a specific project
objective. A process results in one or more key deliverables. Each process
is a discipline that usually involves similar skills to perform the tasks
within the process. You might think of a process as a simultaneous subproject within a larger development project.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update
Migrate Application and Technical Architecture
Migrate Custom Extensions
Data Migration
Documentation
Business System Testing
Training
Production Migration

Figure 1-3

Processes in EMM

This section describes the following EMM processes:

Business Requirements Review
Requirements Mapping Update
Migrate Application and Technical Architecture
Migrate Custom Extensions
Data Migration
Documentation
Business System Testing
Training
Production Migration

Oracle Method

Introduction to EMM 1 - 5

Business Requirements Review (RR)

Business Requirements Review updates the business needs impacted by
the upgrade project. You document changes in business processes
between the current and new release of the application.
For simple upgrades, you perform enough work to confirm that no
significant impact on business processes has occurred. Complex projects
can require substantial evaluation and updating of the business processes
due to significant changes in the businesses environment.
Updating business requirements may be required due to any of the
following reasons:
You have customized the current release to meet business process
requirements identified during the initial implementation.
Oracle may have added features to the new release that address
some of the same business needs.
You may wish to implement new release features as part of the
upgrade project.
You may implement a new delivery format of Oracle Applications
such as the web-enabled user interface.
You may incorporate business process improvement objectives.
Requirements Mapping Update (MU)
Requirements Mapping Update evaluates the changes in the new
applications release against the business requirements defined in the
Business Requirements Review process. New release features may alter
the way that you use the applications to run your business. Any
requirements that cannot be satisfied with standard application features
represent gaps that must be addressed to fully meet business needs.
Application changes that can create gaps are:
new or enhanced functionality that impacts customizations and
non-standard application interfaces
new features requiring additional setup data
application interface changes such as improved Electronic Data
Interface (EDI) support or additional Application Program
Interfaces (APIs)

1 - 6 Introduction to EMM

EMM Method Handbook

 current application customizations that must be modified to work

correctly with the new release
new functionality that must be customized to meet business
requirements
Migrate Application and Technical Architecture (MA)
Migrating from an existing production environment to a new release of
Oracle Applications may provide an opportunity for deploying on the
latest technology. The new technology may include changes to:
application architecture
technical architecture
This process evaluates the incremental impact to the existing architecture
as a result of the migration. Systems architects can evaluate the impact of
the proposed release migration by examining the current implementation
deliverables and identifying the fundamental drivers of the migration
project and the new release technical changes. Major technical
prototyping to verify or support architecture design changes is scheduled
and performed in this process.
Migrate Custom Extensions (ME)
This process defines the tasks and deliverables to update customizations
for compatibility with new Oracle Application releases or to replace the
customizations with new application functionality.
Working together, technical and business analysts update the design
documents impacted by the new release. A simple upgrade may not
require custom software work. Design changes to existing custom
extensions will require modifying existing modules or coding new
modules. New customizations may be required if new application
functionality does not meet business requirements.
Migration projects focus on updating the documents and programs
created during implementation of the current production environment.
Migrate Custom Extensions does not describe how to define, design, and
code new custom extensions from the beginning.

Oracle Method

Introduction to EMM 1 - 7

Data Migration (DM)

Data Migration defines the tasks and deliverables required to migrate
current system data to the new Oracle Applications tables. An Oracle
Applications upgrade is based on the use of Oracles standard data
migration tools, which automatically migrate application data to new
table structures.
For a simple upgrade project, standard Oracle data migration tools may be
sufficient. Some projects also require additional steps to be performed,
such as:
populating new tables or columns associated with new or changed
application functionality
reclassification of data to correspond to new or changed application
setup data parameter options
migration of data currently stored in descriptive flexfields to
standard attributes supported in the new release
migration of data in custom tables to standard tables provided in
the new release
migration of data in custom tables to modified versions of the
custom tables
cleanup of production data values before running Oracles
standard data migration tools
The tasks in EMM intentionally do not address new conversions of data
from legacy systems. For example, if you decide to implement online
requisitions in Oracle Purchasing for the first time and you have
requisition data in a legacy database, the EMM Data Migration tasks do
not describe how to convert the data.
Suggestion: If you wish to implement new Oracle Applications
for the first time or convert data from a legacy system, consider
incorporating processes and tasks from Oracle's Application
Implementation Method (AIM).
Documentation (DO)
The Documentation process begins early in the project and updates
existing documentation created during implementation of the current

1 - 8 Introduction to EMM

EMM Method Handbook

application environment. If documentation does not exist, it should be

developed.
Documentation changes may be caused by:
new or changed application functionality
modified business processes
new, modified, or deleted custom extensions
changes in application or technical architecture
Much of the migration project documentation is based on other project
deliverables, such as customization design documents. The
documentation team can be most efficient when changes to original
documents are clearly identified.
Business System Testing (TE)
Business System Testing focuses on verifying that new application release
functions meet business objectives. You will be updating unit, link,
system, system integration, and user acceptance test scripts from the
current application implementation and re-executing those tests in a test
environment.
Business System Testing also tests the overall technical upgrade prior to
production migration. This may consist of three parts:
running the standard Oracle upgrade utility (AutoInstall)
including pre- and post-upgrade steps (required)
data migration and custom module migration, which must be
synchronized with the AutoInstall process to produce the new
production environment (optional)
application and technical architecture changes such as migration
from character or SmartClient to web-based (optional)
The AutoInstall utility provided with the new application release is
designed to automatically migrate current production data to the new
applications release tables. Successful completion of data migration is
accomplished if pre- and post-AutoInstall steps are properly performed
and custom extensions have been addressed.

Oracle Method

Introduction to EMM 1 - 9

A complete system test (and systems integration test for interfaces) should
be performed to make sure functionality that did not change between
releases continues to work correctly in the new environment. Users will
also perform a user acceptance test to confirm that the upgraded system
meets their expectations and satisfies all business requirements.
Training (TR)
Training educates the project team so they can perform the required
analysis and prepares both users and administrators to assume the
responsibility of running the migrated system. It includes materials
focused on changes in the use and administration of the system. Training
may need to address human interface changes such as migrating from
character or SmartClient to web-deployed access. You may need to
develop training components for new application functionality or new
applications.
Instructors and courseware developers orient their material toward
changing roles and jobs, and not toward application products.
Production Migration (PM)
Production Migration moves the company, system, and people to the new
application release. The Production Migration process encompasses
transition to production readiness, production cutover, and postproduction support.
During Production Migration, the project team deploys the upgraded
applications into the organization. This transition depends on all other
processes that included tasks to update business processes, migrate
production data, refine or create new custom extensions, build data
migration programs, update documentation, enhance application and
technical architecture, and develop training materials.
When the upgraded system is stabilized, regular maintenance and system
refinement resumes.

1 - 10 Introduction to EMM

EMM Method Handbook

EMM Project Deliverables

An EMM task can be associated with only one process and only one
phase. A task is a unit of work that results in a single deliverable or the
revision of an existing deliverable. The deliverable may or may not be
tangible. In EMM, there are five task and deliverable combinations. Each
is discussed below.

Deliverable Generated by a Template

This is a deliverable generated from a template. Design Manual Migration
Strategy (DM.060) is an example of this type of deliverable. As you
perform this task you complete the template Manual Migration Strategy.
When this document is reviewed and approved this task is complete.

Deliverable with a Supporting Document

Sometimes the end product of a task cannot be represented by template.
For example, the end product of Perform System Testing (TE.110) is
successfully system tested applications. The template provided for this
task records the testing results associated with the applications.

Deliverable Updated by the Master Tracking Workbook

During the initial implementation documents are produced which will be
updated based on new information recorded in the Master Tracking
Workbook. Update Design and Build Standards (ME.030) is an example.
Additions to the standards are determined during the migration project
and documented in the Design and Build portion of the Master Tracking
Workbook. The completed worksheet is used as an addendum to the
original Design and Build Standards.

Deliverable Generated from the Master Tracking Workbook

A worksheet in the Master Tracking Workbook can contain enough
information that it functions as a task deliverable. In this case, it does not
update any previously created document. For example, the completed
Perform Architecture Impact (MA.020) worksheet is the task deliverable.

Oracle Method

Introduction to EMM 1 - 11

Deliverable without a Document

Some deliverables have no associated documents. For example, Train
Project Team (TR.060) is based on the training activity and the result is a
trained project team. There is no associated deliverable template or
worksheet for this task and the task does not require that either be created.

Estimating an EMM Project

Before starting an EMM project, the first questions to ask are: How much
will it cost? and When will the system be ready? Estimating provides
answers to these questions.
The most reliable approach to estimating is to calculate a bottom-up
estimate. A bottom-up estimate can only be developed from a work
breakdown structure that contains all of the tasks to be performed, with
project roles mapped to tasks, and defined role percentages for task
participation. The tasks and role mapping then provide the infrastructure
for documenting the estimating factors that influence each task.
Estimating factors are subsequently used in estimating formulae for each
task, which compute specific work estimates for each task. The individual
task estimates roll up to the overall project estimate.
An application upgrade project estimate may be produced for an
organization based on the following approach. It is designed to gather
information about the organizations environment and strategy for the
application migration. The initial estimate is completed at a high level
and is used for initial budgeting and planning purposes. These initial
work products should always be re-examined after the Migration
Assessment phase of EMM, as the quality of the information gathered will
make for a more accurate overall estimate.

Assess the Organization Profile

This step focuses on the organizations management, organization,
existing systems, business environment, history with Oracle products,
services and support, and migration priorities.
1. Review organization contacts including:

1 - 12 Introduction to EMM

EMM Method Handbook

 VP, Information Technology or Director, Information

Technology
VP, Business Development
VP, Finance
VP, Manufacturing or Manufacturing Systems Manager
Business Line Managers
2. Review engagement history.
3. Review business and user profiles.
4. Review existing plans for the upgrade.
5. Review client priorities relative to the upgrade.

Review EMM with the Organization

Introduce EMM to the organization and include a cursory review of the
factors that will drive the level of effort.
Business Processes: Compare how business is done today utilizing the
system to be upgraded versus how new features are likely to impact
business processes. Estimate the amount of time required to design and
implement process changes and train users. Identify opportunities to
implement Application features to meet business process improvement
goals.
Customizations/Interfaces: Analyze existing customizations, interfaces,
and application extensions to determine applicability to the new release
environment. Develop preliminary estimates to migrate existing custom
extensions with or without changes and develop new ones if necessary.
Data Migration: Analyze existing production data integrity and the use of
custom tables to determine the level of migration effort not automatically
performed by Oracles standard migration tools.
Architecture: Compare the current application and technical architecture
with new release characteristics and determine what changes will be
made. This could include a migration from character or SmartClient to
web-deployed.

Oracle Method

Introduction to EMM 1 - 13

Conduct Organization Interviews

This step focuses on gathering specific information about the current
business and systems environment including plans for the future.
Develop questions before each interview and document the interview
results. The following list details the company positions that may be
involved in the upgrade project and the recommended interview topics.
VP, Information Technology or Director, Information Technology
review business objectives and resource/time drivers
review legacy system retirement plans
review application and technical architecture plans relative to the
new release, as well as current/planned infrastructure investment
discuss skill sets that will be required for the upgrade project
VP, Business Development
define executive management objectives and priorities relating to
the upgrade project
discuss critical success factors, risks and contingencies, and time
frames for the upgrade
discuss resource impacts on business operations and the role of
external consulting services providers
VP, Finance
review financial systems migration plans, business drivers, and
integration issues with non-financial systems
review web-deployed readiness and contingency planning for the
upgrade project
review applications architecture plans relative to new release
requirements and current/planned infrastructure investment
VP, Manufacturing or Manufacturing Systems Manager
review manufacturing systems migration plans, business drivers,
and integration issues with non-manufacturing systems

1 - 14 Introduction to EMM

EMM Method Handbook

 review web-deployed readiness and contingency planning for

system implementation
Business Line Managers and IT Team from initial implementation
review the list of new release functionality by module to estimate the
probable impact on business processes
review current custom extension documentation to determine the
disposition of each extension for the upgrade (delete, migrate
unchanged, or migrate with changes)
develop a preliminary estimate of resources and time required for
custom extension migration
review legacy interfaces for potential inclusion into the Oracle
Applications solution

Developing a Recommendation
Obtain answers to the following questions:
What are the business objectives for the applications upgrade?
What is the business and IT vision regarding the upgrade solution?
What is the scope of the project and how does it relate to the overall
vision?
Who will participate in the project and what roles will they play
(employees, consultants, third-party partners)?
What are the key business factors influencing the project (business
benefits, timing or budget limitations, organization changes)?
Which applications are installed and which applications will be
upgraded?
What sites will be involved?
Will a phased deployment approach be employed? If so, in what
sequence will the applications be implemented?
When will work commence? When should work finish?
What experience does the client organization have regarding the
technology that will be used?

Oracle Method

Introduction to EMM 1 - 15

 Will a program management approach be used (for larger complex

upgrade projects with multiple deployment phases) or will a
standard project management approach be employed?
Developing the Plan/Estimate
Develop the project scope, suggested approach, and preliminary budget
before creating a detailed work plan. Use an iterative approach where you
define different project scenarios at a summary level and then estimate
each in detail.
Use the EMM Core tasks as a way to seek the most straightforward plan.
Use optional tasks only if the core tasks are not sufficient to meet project
objectives.

Managing an EMM Project PJM

The goal of Oracles Project Management Method (PJM) is to provide a
framework in which all types of projects can be planned, estimated,
controlled, and tracked in a consistent manner. This consistency is
required in todays business environment where projects may involve
application upgrades, custom development upgrades, and new
application implementations in order to satisfy business needs.
There are two dimensions to PJM. The first concerns what work needs to
be done to manage and support a project. This dimension is addressed by
processes within PJM. The second is when those management and
support tasks should be performed in the project life-cycle. This
dimension is addressed by life-cycle categories.

PJM Processes
All PJM tasks are organized into five processes to help project managers
understand what project management tasks need to be performed for a
successful project. The PJM processes are:
Control and Reporting This process contains tasks that help you
determine the scope and approach of the project, manage change,
and control risks. It contains guides for you to control the Project
Management Plan and to report progress status externally.

1 - 16 Introduction to EMM

EMM Method Handbook

 Work Management The Work Management process contains

tasks that help you define, monitor, and direct all work performed
on the project. You also maintain a financial view of the project in
this process.
Resource Management This process helps you provide the
project with the right level of staffing and skills, and the working
environment to support the project.
Quality Management The Quality Management process directs
you to implement quality measures to make sure that the project
meets the clients purpose and expectations throughout the project
life-cycle.
Configuration Management This process contains tasks that
help you store, organize, track, and control all items produced by,
and delivered to, the project. The Configuration Management
process also calls for you to provide a single location from which all
project deliverables are released.

PJM Life-Cycle Categories

Each task within PJM is also assigned to a PJM life-cycle category. Each
category is then integrated into a project plan that shows when the project
management and support tasks should be performed. The PJM life-cycle
categories are:
Project Planning Tasks in this category encompass the definition
of the project with respect to scope, quality, time, and cost. Project
planning tasks also determine the appropriate organization of
resources and responsibilities to conduct the project.
Phase Planning This category consists of tasks that update
project plans and procedures for the phase.
Phase Control Tasks in this category execute concurrently with
the phase execution, and perform project monitoring, directing, and
reporting functions during the phase.
Phase Completion These tasks conclude and secure sign-off of a
phase.
Project Completion Tasks in this phase result in the satisfactory
conclusion of the project and settlement of all outstanding issues
prior to shutting down the project.

Oracle Method

Introduction to EMM 1 - 17

The following figure illustrates the relationship between PJM processes

and life-cycle categories:
Project Management
Life-Cycle Categories

Project
Planning

Project
Management
Processes

Project
Completion

Phase Management
Planning

Control

Completion

Control and Reporting

Work Management
Resource Management
Quality Management

Configuration Management

Figure 1-4

Project Management Life-Cycle

The next figure shows PJM and its relationship with EMM. PJM life-cycle
categories are integrated into the project plan at the appropriate project
and phase levels. Project planning and completion categories are
performed once at the beginning and end of a project, while phase
planning, control, and completion are performed once for each phase of
the project.
PJM defines dependencies so that project management tasks do not appear
on the critical path. Below is a high-level representation of an integrated
PJM and EMM approach:

1 - 18 Introduction to EMM

EMM Method Handbook

Initial
Phase

Intermediate
Phases

Final
Phase

Project Planning

Phase Planning

Phase Control

Control
Execution

Control

Control

Execution

Execution

Phase Completion

Project Completion

Figure 1-5

Managing an EMM Project

For more information on PJM, refer to the Oracle Method Project

Management suite of reference books:
PJM Method Handbook.
PJM Process and Task Reference.

Oracle Method

Introduction to EMM 1 - 19

CHAPTER

Key EMM Concepts

T

his chapter describes the key concepts the EasiPath Migration Method
is based on. It is organized into the following sections:
overview
summary of the migration process
determining an EMM project approach

Oracle Method

Key EMM Concepts 2 - 1

Overview
EMM may be used to address any Oracle Application forward-release
migration scenario. EMM is not release specific; however, it is designed to
be used with standard Oracle Application release-specific product
documentation such as Release Upgrade Preparation and Release
Installation manuals. Used together, these tools provide guidance and
productivity aids for any Oracle Application migration project.
EMM scales from the simplest project to large and complex migrations.
EMM distinguishes between core tasks, which must be performed for any
Oracle Application migration project, and optional tasks. Most migration
projects require substantially less time and resources than application
implementations. EMM supports large, complex migrations through
optional processes and tasks. In some cases entire EMM processes are
optional while in other cases processes include both core and optional
tasks.
If your project includes major new requirements and mapping, you must
make additional changes to the project workplan as these tasks are not
included in the scope of EMM.
documentation such as Release Upgrade Preparation

Summary of the Migration Process

The EMM migration process includes two categories of tasks core and
optional. Core tasks are required in all cases and include the standard
application installation and migration tasks documented in the new
Release Installation and Release Upgrade Preparation manuals.
Optional tasks include steps addressing unique requirements for a specific
migration project. Such project specific steps deal with customizations,
custom interfaces, application or technical architecture changes, and
business process changes due to new application functionality.

2 - 2 Key EMM Concepts

EMM Method Handbook

In their most simple form, standard Oracle Applications migrations

consist of installing the new release based on recommendations included
in the Release Installation manual and performing the steps documented
in the Release Upgrade Preparation manual, including:
executing pre-upgrade steps prior to running Oracles standard
data migration tool
running Oracles standard data migration tool
executing post-upgrade steps after running Oracles standard data
migration tool
How Does a Migration Differ from an Implementation?
EMM is specifically designed for application migrations. Prerequisite
tasks in the migration method depend on output deliverables from the
initial implementation. Some tasks in the migration method are required
(core) and some are optional. For example, migrating the infrastructure to
support a new release is mandatory; defining new business processes is
optional.
The following table summarizes the major differences between
implementations and migrations:

Project
Characteristic

Implementation

Migration

Starting Point

Legacy or manual systems

Existing production Oracle

applications system

Expectation

New and substantially

different system

Essentially the same system with

improvements

Time

Usually 6 to 36 months

Usually 3 to 9 months

Cost

Variable depending on scope

Usually 5% to 50% of implementations

Risk

Relatively high

Moderate relative to implementations

Oracle Method

Key EMM Concepts 2 - 3

Project
Characteristic

Implementation

Migration

Staffing

Substantial applications,
business, and technical
expertise required for a
relatively long period of time

Fewer people and less advanced

expertise unless migration involves
implementing new application
features and technology

Estimating

Driven by information
requirements for business
functions

Driven by changes from current to new

Oracle Application release

Scope
Determination

Based on business
requirements

Wider range of needs from simple,

such as Year 2000 compliance, to
complex

Table 2-1

Migration Versus Implementation Projects

Preparation

Determining an EMM Project Approach

Application migration projects range from simple to very large and
complex. EMM addresses this by designating tasks as either core or
optional.

2 - 4 Key EMM Concepts

EMM Method Handbook

Core and Optional EMM Tasks

The core tasks in EMM define the minimum set of steps necessary to
migrate to a new release of Oracle Applications. You may also need to
include several other tasks in your project depending on your specific
circumstances. For example, if you are adopting a new user interface
technology supported by the new release, EMM includes a full set of
technical architecture tasks to support the analysis, design, and
deployment of the required hardware, software, and networks. If your
current implementation includes interfaces to third-party or legacy
systems, you can incorporate EMM tasks to help you examine, update, and
test those interfaces to work with the new release.
A good test during project planning is to walk through the core tasks and
assess if they will be sufficient to meet the organizations needs. If not,
begin considering optional tasks. This planning process should help
create a streamlined project approach.

Optional
Tasks

Figure 2-1

Oracle Method

Core
Tasks

Optional
Tasks

Core and Optional Tasks

Key EMM Concepts 2 - 5

Task Selection Guidelines

Use the guidelines below to determine which optional EMM tasks to
include in your project.
Process Changes or Improvements
If you plan to take advantage of new product functionality, or your project
objectives include changes or improvements to your business processes,
you should include the following tasks:
RR.020

Review Current Business Processes

RR.030

Develop Future Process Model

If you exclude these tasks and you discover required process changes as
you are remapping business requirements, you should update your
process documentation during mapping.
Interfaces
If you have interfaces to third-party or internally-developed systems or
have built interfaces between Oracle Applications installed in separate
databases, you should include the following tasks:

2 - 6 Key EMM Concepts

RR.060

Gather Business Volumes

MU.040

Review Integration Fit Analysis

ME.010

Perform Customization Impact Analysis

ME.020

Estimate Custom Extension Migration

ME.030

Update Design and Build Standards

ME.050

Identify Custom Database Changes

ME.060

Identify Module Design Changes

ME.100

Implement Database Changes

ME.110

Update Custom Modules

ME.120

Create Migration Routines

MA.140

Update Application Architecture

DO.120

Update Technical Reference Manual

TE.020

Update Unit Test Scripts

EMM Method Handbook

TE.030

Update Link Test Scripts

TE.050

Update Systems Integration Test Scripts

TE.070

Perform Unit Testing

TE.080

Perform Link Testing

TE.130

Perform Systems Integration Testing

Customizations
If you have built custom programs to extend the functionality of the
applications including custom reports, database triggers, and complex
descriptive flexfields, you should include the following tasks:
ME.010

Perform Customization Impact Analysis

ME.020

Estimate Custom Extension Migration

ME.030

Update Design and Build Standards

ME.050

Identify Custom Database Changes

ME.060

Identify Module Design Changes

ME.100

Implement Database Changes

ME.110

Update Custom Modules

ME.120

Create Migration Routines

TE.020

Update Unit Test Scripts

TE.030

Update Link Test Scripts

TE.070

Perform Unit Testing

TE.080

Perform Link Testing

DO.100

Update User Reference Manual

DO.120

Update Technical Reference Manual

DO.140

Update Online Help Text

Data Migration
If you have custom database tables or need to populate new tables or
columns available in the new release with data from your legacy system,
you should include the following tasks:
RR.060

Oracle Method

Gather Business Volumes

Key EMM Concepts 2 - 7

DM.020

Perform Data Impact Analysis

DM.050

Perform Migration Data Mapping

DM.060

Design Manual Migration Strategy

DM.070

Design Migration Programs

DM.080

Prepare Data Migration Test Plans

DM.090

Develop Data Migration Programs

DM.100

Perform Data Migration Unit Test

DM.110

Perform Migration Business Object Test

DM.120

Perform Data Migration Validation Test

DM.130

Install Data Migration Software

Complex Architecture Changes

If you are implementing multiple-organization features or plan to change
any part of your database design or hardware infrastructure, you should
include the following tasks:
RR.060

Gather Business Volumes

MA.020

Perform Architecture Impact Analysis

MA.110

Define Technical Prototype Subprojects

MA.140

Update Application Architecture

MA.160

Update Technical Architecture

MA.180

Identify New Performance Risks

MA.190

Update System Management Procedures

DO.130

Update System Management Guide

Additional User Testing

If you would like a formal user acceptance test of the new applications just
prior to production cutover, include the following task:
TE.140

2 - 8 Key EMM Concepts

Perform User Acceptance Test, Production System

EMM Method Handbook

Production Systems Audit

If your project includes an assessment of how well the newly migrated
production system meets business objectives set at the beginning of the
project, include the following task:
PM.090

Audit Production System

Planning Suggestions
If you are not sure whether you need any of the optional tasks, keep them
in your workplan with work effort estimates of zero (0). You can then
create filters in your project management tool to hide zero effort tasks in
reports.
As your project progresses, you can reevaluate the need for the tasks you
initially exclude. You may wish to perform some of them as check tasks by
reviewing the handbook descriptions and template content to verify that
you are not missing an important element.

The Role of Oracles Standard Application Migration Tools

The central focus of an Oracle Applications migration is Oracles standard
migration tools. These tools automatically install application software
and migrate production data in the production database instance.
Oracle Applications product documentation such as Release Upgrade
Preparation and Release Installation manuals describe pre- and postupgrade steps, which must be performed in concert with Oracles
migration tools. In addition, you may need to update existing
customizations and migrate data in custom tables. You should integrate
the special steps for these activities into the standard pre- and postupgrade steps.

Factors to Consider
When deciding on an approach for your migration project, consider the
following dimensions:

Oracle Method

Key EMM Concepts 2 - 9

 Scope/Complexity Scope and complexity include the project

objectives, business functions, deployment sites, and applications to
be migrated. Will the project consist of only application migrations
or include initial implementations of new application features,
third-party interfaces, or new technologies? Complexity of the
application migration varies based on the following:
specific current and future release level of Oracle Applications
number of sites and currencies
degree of customizations in the current software release
extent to which non-standard interfaces have been used to
interface Oracle Applications to legacy systems
degree of architecture change planned with the migration
the need for custom data migration software
an organizations technical resources
condition of the current application environmentspecifically,
the degree of conformity with Oracles Optimal Flexible
Architecture (OFA)
current production data clean-up requirements
Cost/Time/Quality These dimensions take into consideration the
balance between cost, implementation speed, and quality of the
final solution.
Risk Risk is the potential of an adverse condition that will
impact the project or the organization.
Resources Resource constraints affect the practicality of certain
project approaches.
What Drives the Level of Effort?
Oracles standard migration software and Release Upgrade Preparation
manuals are designed to make standard migrations reasonably
straightforward. A simple migration does not include customizations,
implementation of new features, special data conversions, non-standard
application program interfaces, or technical architecture changes.
In more complex cases some or all of the following factors may be present:

2 - 10 Key EMM Concepts

EMM Method Handbook

 New Release Functionality Implementation of major new release

functionality including changes to business requirements and
mapping may require an AIM/EMM hybrid approach. To the
extent that application functionality has changed in a particular
product, the project effort will be more complex. The number and
magnitude of new features varies greatly with each release.
Multiple Installations/Multiple Sets of Books/Multi-Organization
Implementation of multiple installations may be desirable for
customers with multiple business units with very different business
requirements. Implementations with multiple sets of books are
driven out of the need for one customer to have multiple charts of
accounts, currencies, or calendars. Implementations configured as
Multi-Org are applicable for organizations planning to share
customer and supplier records among business or operating units,
while separating the physical and financial accounting of business
processes.
Multiple Sites and Multiple Deployment Considerations
Determine if the transition into production needs to occur for all
organizations and/or sites at the same time or if a phased approach
should be used. For large, multi-national organizations it is
impractical to migrate all sites at the same time. If a phased
implementation is planned, decide which applications will be
migrated in each phase for each site. Phasing deployment of an
applications migration adds complexity to the project.
Customizations Examine all customizations to standard
functionality in light of new application features. Determine
whether to migrate each customization unchanged, migrate with
changes, or eliminate the customization and use standard
functionality.
Non-Standard Interfaces It may be necessary to change existing
application interfaces for changes in the new release. This may be
caused by new standard application interfaces or changes to
existing standard application interfaces.
Technical Architecture Change Migrating to new technology
such as Oracles internet computing model, new database features,
or other changes to the technical architecture may be desired during
migration.

Oracle Method

Key EMM Concepts 2 - 11

 Data Migration Oracles standard migration tools require

accurate production data. Data errors can be introduced into the
new production system, which may go undetected until migration
testing begins. Correction of such data errors can require
considerable time and resources.

2 - 12 Key EMM Concepts

EMM Method Handbook

II
PART

EMM Phases

CHAPTER

Migration Assessment

his chapter describes the Migration Assessment phase of EMM. The

goal of the Migration Assessment phase is to analyze the impact of the
application release changes. The Migration Assessment phase results in
proposed steps to migrate to the new release.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 3-1

Oracle Method

Context of EMM Migration Assessment Phase

Migration Assessment 3 - 1

Overview
This section provides an overview of the Migration Assessment phase.

Objectives
The objectives of the Migration Assessment phase follow:
Obtain a clear understanding of the business processes, functions,
and information requirements of the current operating environment;
ask the question where are we?
Define the detailed function, data, and operational requirements
that the new application system must support; ask the question
where do we want to be?
Map business requirements to new application capabilities and
develop solutions to gaps; ask the question what will it take?

Critical Success Factors

The critical success factors of the Migration Assessment phase follow:
thorough knowledge of the changes in the application functionality
and current system customizations
active participation by team management and knowledgeable user
and technical representatives from the business areas affected by
the project
access to documentation related to the existing business processes
and systems affected by the project

Prerequisites
Prerequisites for the Migration Assessment phase follow. You should use
these prerequisites, if they exist, prior to beginning the project. If they do
not exist, you will need to identify other documentation that conveys the
same information or collect the information by interviewing staff members.

3 - 2 Migration Assessment

EMM Method Handbook

Prerequisite

Source

Architectural Strategy

MIS Department

Business Requirements Mapping

Forms

Implementation Team

Existing Reference Material

Project Library

Existing System Architecture or

Technical Configuration Documents

MIS Department

Future Business Strategy

Executive Management

Original Customization
Documentation

MIS Department

Training Material Standards and

Guidelines

Implementation Team

Table 3-1

Migration Assessment Phase Prerequisites

Processes
The processes used in this phase follow:

Oracle Method

Process

Description

Business Requirements Review

Review current business

processes and determine the
impact of new release
functionality and architecture
changes.

Requirements Mapping Update

Determine new release changes

and compare against current
business requirements,
identifying gaps. Propose
solutions to gaps.

Migration Assessment 3 - 3

Process

Description

Migrate Application and

Technical Architecture

Perform architecture impact

analysis and identify areas of
application architecture
requiring investigation by
prototyping.

Migrate Custom Extensions

Assess the impact on

customization that will not be
automatically migrated. Prepare
the resource estimates for
updating existing
customizations.

Data Migration

Assess the impact of the new

release on data that will not be
migrated by Oracles standard
data migration tools.

Training

Train project team in the new

features of the applications.

Production Migration

Prepare migration transition

strategy.

Table 3-2

Migration Assessment Phase Processes

Key Deliverables
The key deliverables of this phase follow:

3 - 4 Migration Assessment

Deliverable

Description

Future Process Model

The future process model consists of

event catalogs, process listing, process
descriptions, process flow diagrams,
and optional process step catalogs for
each business process changed as a
result of the upgrade project.

EMM Method Handbook

Deliverable

Description

Business Requirements
Scenarios

Updated or newly prepared formal

statements of detailed business
requirements, the source of these
requirements, how the requirements
will be satisfied, and what prototyping
steps must be planned to prove design
concepts.

Release Changes Summary

Summarizes changes between current

and new Oracle Application releases.

Business Requirements
Mapping Form

Documents the gaps between current

business requirements and standard
application functionality in the new
release.

Trained Project Team

Project personnel trained to perform

assigned project tasks.

Table 3-3

Oracle Method

Migration Assessment Phase Key Deliverables

Migration Assessment 3 - 5

Approach
This section describes the approach for the Migration Assessment phase.

Tasks and Deliverables

ID

Core

Task

Business Requirements Review

RR.020
N
Review Current Business Processes
RR.030
N
Develop Future Process Model
RR.060
N
Gather Business Volumes
RR.070
Y
Review Business Requirements
Scenarios
Requirements Mapping Update
MU.005
Y
Identify New Release Changes
MU.011
Y
Upgrade Project Environments
MU.020
Y
Remap Business Requirements
MU.030
Y
Remap Business Data
MU.040
N
Review Integration Fit Analysis
MU.070
Y
Review Reporting Fit Analysis
MU.090
Y
Confirm Integrated Business Solutions
Migrate Application and Technical Architecture
MA.020
N
Prepare Architecture Impact Analysis
MA.110
N
Define Technical Prototype
Subprojects
Migrate Custom Extensions
ME.010
N
Perform Customization Impact
Analysis
ME.020
N
Estimate Custom Extension Migration
Data Migration
DM.020
N
Perform Data Impact Analysis
Training
TR.010
Y
Prepare Training Strategy
TR.050
Y
Prepare Project Team Training
TR.060
Y
Train Project Team

3 - 6 Migration Assessment

Deliverable

Current Business Baseline

Future Process Model
Business Volume Requirements
Business Requirements Scenarios

Release Changes Summary

Configured Project Environments
Business Requirements Mapping Form
Business Data Mapping
Integration Fit Analysis
Master Report Tracking List
Acceptance Certificate
Architecture Impact Analysis
Technical Prototype Subprojects SOA

Customization Impact Analysis

Solution Document
Data Impact Analysis
Education and Training Plan
Training Preparation Checklist
Trained Project Team

EMM Method Handbook

ID

Core

Task

Deliverable

Production Migration
PM.010
Y
Prepare Transition Strategy
Table 3-4

Oracle Method

Transition Strategy

Migration Assessment Phase Tasks and Deliverables

Migration Assessment 3 - 7

Core Task Dependencies

This diagram shows the dependencies between core tasks in the Migration
Assessment phase.
Migration
Assessment

BUSINESS
REQUIREMENTS
REVIEW
RR.070
Review Business
Requirements
Scenarios

REQUIREMENTS
M APPINGUPDATE

MU.005

MU.011

MU.020

Identify New
Release Changes

Upgrade Project
Environments

Remap Business
Requirements

1 Line
( 6 5/16 tall X 6 1/4 wide)

TR.010

TR.050

TR.060

TRAINING
Prepare Training
Strategy

Prepare Project
Team Training

Train Project Team

P RODUCTION
M IGRATION

Figure 3-2

3 - 8 Migration Assessment

Migration Assessment Phase Core Task Dependencies

EMM Method Handbook

Migration
Assessment

BUSINESS
REQUIREMENTS
REVIEW

MU.030

MU.070

Remap Business
Data

Review Reporting
Fit Analysis

REQUIREMENTS
M APPING UPDATE

1 Line
MU.090

( 6 5/16 tall X 6 1/4 wide)

Confirm
Integrated
Business Solutions

TRAINING

PM.010
Prepare Transition
Strategy

Figure 3-2

Oracle Method

PRODUCTION
M IGRATION

Migration Assessment Phase Core Task Dependencies (cont.)

Migration Assessment 3 - 9

Core and Optional Task Dependencies

This diagram shows the dependencies between all tasks in the Migration
Assessment phase.
Migration
Assessment
RR.020

RR.030

Review Current
Business Processes

BUSINESS
REQUIREMENTS
REVIEW

RR.060

Develop Future
Process Model

Gather Business
Volumes

RR.070
Review Business
Requirements
Scenarios

MU.005

MU.011

MU.020

Identify New
Release Changes

Upgrade Project
Environments

Remap Business
Requirements

REQUIREMENTS
M APPINGUPDATE

MU.040
Review Integration
Fit Analysis

M IGRATE
APPLICATIONAND
T ECHNICAL
ARCHITECTURE

MA.020

MA.110

Perform
Architecture
Impact Analysis

Define Technical
Prototype
Subprojects

ME.010

M IGRATE CUSTOM
E XTENSIONS

DATA M IGRATION

Perform
Customization
Impact Analysis

DM.020
Perform Data
Impact Analysis

Figure 3-3

3 - 10 Migration Assessment

Migration Assessment Phase Task Dependencies

EMM Method Handbook

Migration
Assessment

BUSINESS
REQUIREMENTS
REVIEW

MU.030

MU.070

Remap Business
Data

Review Reporting
Fit Analysis

REQUIREMENTS
M APPING UPDATE

MU.090
Confirm
Integrated
Business Solutions

1 Line
( 6 5/16 tall X 6 1/4 wide)

M IGRATE
APPLICATIONAND
T ECHNICAL
ARCHITECTURE

ME.020

M IGRATE CUSTOM
E XTENSIONS

Estimate Custom
Extension
Migration

DATA M IGRATION

Figure 3-3

Oracle Method

Migration Assessment Phase Task Dependencies (cont.)

Migration Assessment 3 - 11

Migration
Assessment

TR.010

TRAINING

TR.050

Prepare Training
Strategy

TR.060

Prepare Project
Team Training

Train Project Team

P RODUCTION
M IGRATION

Figure 3-3

3 - 12 Migration Assessment

Migration Assessment Phase Task Dependencies (cont.)

EMM Method Handbook

Migration
Assessment

TRAINING

PM.010
Prepare Transition
Strategy

PRODUCTION
M IGRATION

1 Line
( 6 5/16 tall X 6 1/4 wide)

Figure 3-3

Oracle Method

Migration Assessment Phase Task Dependencies (cont.)

Migration Assessment 3 - 13

Staffing
This diagram illustrates a typical project organization for the Migration
Assessment phase.

Migration Assessment Phase Organization

Project Manager

System
Administrator
(Technical
Services)

Business Analyst

Trainer
(Project Team)

System Architect

Developer
(Custom
Development)

Applications
Specialist

Technical Analyst
(Upgrade/Data
Migration Lead)

Database
Administrator

Technical Services Team

Legend

Business
Analyst 1

Management

Business
Analyst 2

Required

Optional
Technical
Analyst

Functional/Technical Application Analyst Team

Figure 3-4

3 - 14 Migration Assessment

Migration Assessment Phase Staffing

EMM Method Handbook

Staffing Suggestions
This section provides advice and comments on project organization for the
Migration Assessment phase.
Project Management
Organize the project so that single point accountability exists for certain
subsets of EMM processes. This will leverage synergy among project
activities and minimize risk by providing visibility of key inter-process
relationships to key team members.
Business Requirements Review
The majority of Business Requirements Review work occurs during this
phase.
Staffing for this process may range from zero to a sizable sub-team
depending on the extent that new release changes impact current business
processes. Only business requirements affected by the migration project
should be reviewed.
New release enhancements may alter functionality that is integrated with
manual procedures. These procedures may need to be enhanced if the
new functionality is used without customization. In this case, the
migration team must have a complete understanding of related business
requirements to design and implement procedural changes.
The staffing for this process is driven in part by the condition of existing
business requirements documentation. Accurate and complete
documentation can significantly reduce staffing requirements.
Requirements Mapping Update
The majority of work for this process occurs during this phase. Staffing
requirements for this process are driven by the changes between the
current and new applications release that impact the organization.
Specific expertise concerning the new release changes impacting the
organization is needed. Although it may appear that staff with a broad
knowledge of the new applications release are not required, be aware that
what may initially appear to be a single, isolated change may have
broader implications.

Oracle Method

Migration Assessment 3 - 15

Migrate Application and Technical Architecture

The technical architecture impact assessment and identification of
prototype sub-projects are performed during this phase.
Migrate Custom Extensions
An analysis of the impact of the new release on customizations is
performed during this phase and estimates are developed for migrating
and developing customizations. Usually only the custom development
lead is needed during this phase since actual development work starts in
Update and Test.
Data Migration
The data impact analysis is performed during this phase and detailed
plans are finalized for both automated and manual data migration steps.
The upgrade/data migration lead is responsible for conducting the data
impact analysis, making use of the functional/technical application
analyst team as needed.
This process addresses migrating data stored in custom tables and
production data errors that may require correction before the migration.
Staff with SQL skills and a detailed knowledge of Oracle application
tables may be required. Be sure you have the right blend of functional and
technical skills on the team.
Training
Project team training is planned and conducted during this phase. The
primary need is to learn about the new release changes that impact the
organization rather than learning the entire new application release.
There may not be an Oracle class focusing on the release changes
impacting your project offered when you need it. Using consultants with
these specific skills is another option; choose someone on the team who
has knowledge of all the changes to lead this activity.
Production Migration
The Transition Strategy (PM.010) is developed during this phase. Assign
Production Migration responsibility to the systems administrator who
leads the technical services team. The upgrade/data migration lead is on
this team and the functional/technical application analyst team reports to

3 - 16 Migration Assessment

EMM Method Handbook

this individual. Additionally, the lead for this process needs a broad,
system-wide focus usually associated with a systems administrator role.

Oracle Method

Migration Assessment 3 - 17

CHAPTER

Update and Test

T

his chapter describes the Update and Test phase of EMM. The goal of
the Update and Test phase is to update all components of the system
and thoroughly test the migrated business solution. The Update and Test
phase results in the confirmation of the proposed system design and
application setups.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 4-1

Oracle Method

Context of EMM Update and Test Phase

Update and Test 4 - 1

4 - 2 Update and Test

EMM Method Handbook

Overview
This section provides an overview of the Update and Test phase.

Objectives
The objectives of the Update and Test phase follow:
Update application and technical architecture design.
Update design documents and code for customizations and
interfaces.
Thoroughly test the updated application system.
Update all user and system documentation.
Develop user training materials.

Critical Success Factors

The critical success factors of the Update and Test phase follow:
effective participation by business management
sufficient technical and application architecture expertise
successful completion of system and user acceptance testing

Prerequisites
Prerequisites for the Update and Test phase follow.

Oracle Method

Prerequisite

Source

Acceptance Certificate

Requirements Mapping
Update

Application Setup Document

Prior implementation

Update and Test 4 - 3

Prerequisite

Source

Business Data Mapping

Requirements Mapping
Update

Business Requirements Mapping Form

Requirements Mapping
Update

Business Requirements Scenarios

Business Requirements
Review

Configured Project Environments

Requirements Mapping
Update

Education and Training Plan

Training

Master Report Tracking List

Requirements Mapping
Update

Process Narratives

Prior Implementation

Release Changes Summary

Requirements Mapping
Update

Security Profiles

Prior Implementation

System Test Scripts

Prior Implementation

Training Preparation Checklist

Training

Transition Strategy

Production Migration

User Guide

Prior Implementation

Table 4-1

4 - 4 Update and Test

Update and Test Phase Prerequisites

EMM Method Handbook

Processes
The processes used in the phase follow:

Oracle Method

Process

Description

Requirements Mapping Update

Update process narratives and

revise application setups and
security profiles.

Migrate Application and

Technical Architecture

Update application and

technical architecture
documentation. Identify new
performance risks and update
system procedures.

Migrate Custom Extensions

Identify custom database and

module design changes.
Implement database changes
and update custom modules.
Create custom migration
routines.

Data Migration

Design manual migration

strategy. Create and test data
migration programs.

Documentation

Update user, technical, and

system manuals.

Business System Testing

Update test scripts. Test

customizations. Test software
upgrade steps. Perform business
process-oriented system and
user acceptance testing.

Training

Develop user training materials

emphasizing new application
functionality.

Update and Test 4 - 5

Process

Description

Production Migration

Develop a detailed transition

and contingency plan.

Table 4-2

Update and Test Phase Processes

Key Deliverables
The key deliverables of this phase follow:

4 - 6 Update and Test

Deliverable

Description

Process Narratives

Updated job-level descriptions

reflecting business process changes
associated with the upgrade project.

Application Setup Document

Updated or new documentation

describing changes to existing
application setup data.

Application Architecture
Documents

Various documents describing

different aspects of the application
architecture of the existing business
information systems from the original
application implementation project.
The project team updates these
documents to reflect the target
application architecture of the
business after migrating to the new
application release.

EMM Method Handbook

Oracle Method

Deliverable

Description

Technical Architecture
Documents

Various documents describing

different aspects of the technical
architecture of the existing business
information systems from the original
applications implementation project.
The project team updates these
documents to reflect the target
technical architecture of the business
after migrating to the new application
release.

Performance Risk Assessment

Describes the performance risks

inherent in the business information
systems. The project team updates this
document to include the new
performance risks in the IS architecture
resulting from the migration to the new
application release.

Custom Database Objects

Updates to the Oracle Application

database with changes to support
existing and new customizations.

Module Source Code

Updates to the existing custom

modules prior to migration and
development of new custom modules.

Custom Migration Routines

Checklist of suggested steps to support

migration of customizations.

Manual Migration Strategy

The strategy for manual migration of

data to the new release.

Migration Test Procedures

A document containing the data

migration test procedures.

Validation Tested Migration

Programs

Documents the data migration

validation test steps, results, and
exceptions follow-up.

Update and Test 4 - 7

Deliverable

Description

User Guide

An updated User Guide that reflects

the new application functionality and
business processes.

System Management Guide

An updated System Management

Guide that reflects the upgraded
application.

User Acceptance Test Scripts

Documents the user acceptance test

procedures.

Post-Upgrade Checklist

Documents standard Oracle upgrade

steps and any custom upgrade steps
for the migration of custom extensions
and data.

User Acceptance Test Report

Documents the approach and results

of user acceptance testing in the test
environment.

User Training Manuals

Training materials for user training

that focus on new release changes.

Detailed Transition and

Contingency Plan

Documents the sequence of events that

must occur during transition to
production and provides a plan in the
event that the transition is
unsuccessful.

Table 4-3

4 - 8 Update and Test

Update and Test Phase Key Deliverables

EMM Method Handbook

Approach
This section describes the approach for the Update and Test phase.

Tasks and Deliverables

ID

Core

Task

Requirements Mapping Update

MU.100
Y
Update Process Narratives
MU.110
Y
Revise Application Setups
MU.120
Y
Revise Security Profiles
Migrate Application and Technical Architecture
MA.140
N
Update Application Architecture
MA.160
N
Update Technical Architecture
MA.180
N
Identify New Performance Risks
MA.190
N
Update System Management
Procedures
Migrate Custom Extensions
ME.030
N
Update Design and Build Standards
ME.050
N
Identify Custom Database Changes
ME.060
N
Identify Module Design Changes
ME.100
N
Implement Database Changes
ME.110
N
Update Custom Modules
ME.120
N
Create Migration Routines
Data Migration
DM.050
N
Perform Migration Data Mapping
DM.060
N
Design Manual Migration Strategy
DM.070
N
Design Migration Programs
DM.080
N
Prepare Data Migration Test Plans
DM.090
N
Develop Data Migration Programs
DM.100
N
Perform Data Migration Unit Test
DM.110
N
Perform Migration Business Object
Test
DM.120
N
Perform Data Migration Validation
Test

Oracle Method

Deliverable

Process Narratives
Application Setup Document
Security Profiles
Application Architecture Documents
Technical Architecture Documents
Performance Risk Assessment
System Management Procedures

Design Standards
Database Extension Design
Module Design
Custom Database Objects
Module Source Code
Custom Migration Routines
Migration Data Mapping
Manual Migration Strategy
Migration Program Design
Migration Test Procedures
Migration Programs
Unit Tested Migration Programs
Business Object Tested Migration
Programs
Validation Tested Migration Programs

Update and Test 4 - 9

ID

Core

Task

Deliverable

Documentation
DO.100
N
Update User Reference Manual
DO.110
Y
Update User Guide
DO.120
N
Update Technical Reference Manual
DO.130
N
Update System Management Guide
DO.140
N
Update Online Help Text
Business System Testing
TE.010
Y
Develop Test Strategy
TE.020
N
Update Unit Test Scripts
TE.030
N
Update Link Test Scripts
TE.040
Y
Update System Test Scripts
TE.050
N
Update System Integration Test Scripts
TE.055
Y
Update User Acceptance Test Scripts
TE.070
N
Perform Unit Testing
TE.080
N
Perform Link Testing
TE.085
Y
Test Pre-Upgrade Steps
TE.091
Y
Test Software Upgrade
TE.092
Y
Test Post-Upgrade Steps
TE.093
Y
Perform Post-Upgrade Reconciliation
Testing
TE.096
Y
Review Upgrade Test Results
TE.100
Y
Prepare Key Users for Testing
TE.110
Y
Perform System Testing
TE.130
N
Perform Systems Integration Testing
TE.135
Y
Perform User Acceptance Testing, Test
System
Training
TR.070
Y
Develop User Training Materials
Production Migration
PM.030
Y
Develop Detailed Transition and
Contingency Plan
Table 4-4

4 - 10 Update and Test

User Reference Manual

User Guide
Technical Reference Manual
System Management Guide
Online Help Text
Testing Strategy
Unit Test Scripts
Link Test Scripts
System Test Scripts
System Integration Test Scripts
User Acceptance Test Scripts
Unit Tested Modules
Link Tested Modules
Pre-Upgrade Checklist
Upgraded Applications
Post-Upgrade Checklist
Reconciliation Test Report
Upgrade Test Analysis
Prepared Users
System Tested Applications
Integration Tested Systems
User Acceptance Test Report

User Training Materials

Detailed Transition and Contingency
Plan

Update and Test Phase Tasks and Deliverables

EMM Method Handbook

Core Task Dependencies

This diagram shows the dependencies between core tasks in the Update
and Test phase.
Update
and Test

BUSINESS

MU.100

MU.120

Update Process
Narratives

Revise Security
Profiles
MU.110

REQUIREMENTS
REVIEW

Revise Application
Setups

DO.110

DOCUMENTATION

Update User
Guide

TE.010

TE.100

Develop Test
Strategy

Prepare Key Users

for Testing

BUSINESSS YSTEM
T ESTING

TE.040
Update System
Test Scripts

TE.055
Update User
Acceptance Test
Scripts

TR.070

TRAINING
Develop User
Training Materials

P RODUCTION
M IGRATION

Figure 4-2

Oracle Method

Update and Test Phase Core Task Dependencies

Update and Test 4 - 11

Update
and Test

BUSINESS
REQUIREMENTS
REVIEW

DOCUMENTATION

TE.085
Test Pre-Upgrade
Steps

TE.091
Test Software
Upgrade

TE.092
Post-Upgrade
Checklist

TE.093
Perform PostUpgrade
Reconciliation
Testing

TE.096
Review Upgrade
Test Results

TE.110

BUSINESSS YSTEM
TESTING

Perform System
Testing

TE.135
Perform User
Acceptance
Testing, Test
System

TRAINING

PM.030
Develop Detailed
Transition and
Contingency Plan

Figure 4-2

4 - 12 Update and Test

PRODUCTION
M IGRATION

Update and Test Phase Core Task Dependencies (cont.)

EMM Method Handbook

Core and Optional Task Dependencies

This diagram shows the dependencies between all tasks in the Update
and Test phase.
Update
and Test

MU.120
Revise Security
Profiles
MU.100

REQUIREMENTS
M APPINGUPDATE

MU.110

Update Process
Narratives

Revise Application
Setups

MA.160
Update Technical
Architecture

M IGRATE
APPLICATIONAND
T ECHNICAL
ARCHITECTURE

MA.180

MA.140
Update
Application
Architecture

Identify New
Performance Risks

ME.030
Update Design
and Build
Standards

M IGRATE CUSTOM
E XTENSIONS

ME.050

ME.100

Identify Custom
Database Changes

Implement
Database Changes

DM.050

DM.060

Perform Migration
Data Mapping

Design Manual
Migration Strategy

DM.070

DM.090

ME.110
Update Custom
Modules

ME.060
Identify Module
Design Changes

DM.080
Prepare Data
Migration Test
Plans

DATA M IGRATION

Design Migration
Programs

DM.100
Perform Data
Migration Unit
Test

Figure 4-3

Oracle Method

Develop Data
Migration
Programs

Update and Test Phase Task Dependencies

Update and Test 4 - 13

Update
and Test

REQUIREMENTS
M APPINGU PDATE

M IGRATE
APPLICATIONAND
TECHNICAL
ARCHITECTURE

MA.190
Update System
Management
Procedures

ME.120
Create Migration
Routines

M IGRATE CUSTOM
EXTENSIONS

DM.120
Perform Data
Migration
Validation Test

DATA M IGRATION
DM.110
Perform Migration
Business Object
Test

Figure 4-3

4 - 14 Update and Test

Update and Test Phase Task Dependencies (cont.)

EMM Method Handbook

Update
and Test

C
DO.100

DO.140

Update User
Reference Manual

Update Online
Help Text

DOCUMENTATION
DO.110
Update User
Guide

TE.020
Update Unit Test
Scripts

BUSINESSS YSTEM
TESTING

TE.010
Develop Test
Strategy

TE.070
Perform Unit
Testing

TE.030
Update Link Test
Scripts

TE.040
Update System
Test Scripts

TE.050
Update Systems
Integration Test
Scripts

TR.070
Develop User
Training Materials

TRAINING

P RODUCTION
M IGRATION

Figure 4-3

Oracle Method

Update and Test Phase Task Dependencies (cont.)

Update and Test 4 - 15

DO.120

Update
and Test

DO.130

DOCUMENTATION

Update System
Management
Guide

Update Technical
Reference Manual

TE.080

TE.085

Perform Link
Testing

Test Pre-Upgrade
Steps

TE.110
Perform System
Testing

TE.100
Prepare Key Users
for Testing

TE.091
Test Software
Upgrade

TE.130
Perform Systems
Integration Testing

TE.135
Perform User
Acceptance
Testing, Test
System

TE.092
Test Post-Upgrade
Steps

TE.093
Perform PostUpgrade
Reconciliation
Testing

BUSINESSS YSTEM
TESTING

TE.096
Review Upgrade
Test Results

TE.055
Update User
Acceptance Test
Scripts

TRAINING

PM.030

PRODUCTION
M IGRATION

Develop Detailed
Transition and
Contingency Plan

Figure 4-3

4 - 16 Update and Test

Update and Test Phase Task Dependencies (cont.)

EMM Method Handbook

Staffing
This diagram illustrates a typical project organization for the Update and
Test phase.

Update and Test Phase Organization

Project Manager

System Administrator
(Technical Services)

Business Analyst

System Architect

Developer
(Custom
Development)

Applications
Specialist

Technical Analyst
(Upgrade/Data
Migration Lead)
Architecture
Prototype
1 Team

Database
Administrator
Trainer
(Course
Development)
Technical Analyst
(Performance
Testing)
Technical Services Team

Architecture
Prototype
2 Team

Developer 1

Developer 2

Programming Team

Business
Analyst 1

Business
Analyst 2

Legend
Management

Required

Technical
Analyst

Optional

Functional/Technical Application Analyst Team

Figure 4-4

Oracle Method

Update and Test Phase Staffing

Update and Test 4 - 17

Staffing Suggestions
This section discusses project organization for the Migration Assessment
phase.
Project Management
Organizational changes between the Migration Assessment and Update
and Test include:
optionally adding a technical analyst specializing in performance
measurement
potentially including teams to develop architecture prototypes if
complex architecture impacts must be addressed
including an optional programming team for custom software
development
transition of the functional/technical application analyst team from
supporting business requirements review and early requirements
mapping activity to process work
elimination of the trainer position for project team training and
addition of a trainer to develop user training materials
It may be possible to use the same training resource during the Migration
Assessment to coordinate project team training and to continue
developing user training materials.
Continue to seek continuity and risk minimization by allowing key team
members to participate in multiple processes. This will maximize the
probability that integration issues will be identified.
Requirements Mapping Update
Requirements Mapping Update activity transitions from mapping related
activities to implementing changes in the Process Narratives (MU.100),
Application Setup Document (MU.110), and Security Profiles (MU.120).
Migrate Application and Technical Architecture
Architecture changes are implemented based on the architecture impact
analysis performed in the previous phase. The system architect during
this phase needs management skills to oversee implementation work.

4 - 18 Update and Test

EMM Method Handbook

Screen architect candidates for a combination of analytical and

managerial skills.
Migrate Custom Extensions
If updates to existing customizations or new customizations are required,
they are designed, developed, and tested during this phase.
Programmers, who participated in Migration Assessment, are added to the
team reporting to the custom development lead. It is a challenge to
accurately forecast required programming staff needs during systems and
acceptance testing. Do not underestimate the number of programmers
needed for program changes and regression testing.
Data Migration
Data mapping is performed and data migration custom software is
designed, developed, and tested. The programming team is used to
develop data migration and other programs. Manual data migration
procedures are designed and developed. Production database errors are
identified, analyzed, and corrected.
Depending on the current data quality, additional staff may be required to
correct production data errors.
Documentation
User and systems management documentation (as well as online help text)
is updated in this phase. Schedule a sufficient number of qualified writers
to complete this process. It is important to the ongoing success of the
project that documentation standards are maintained.
Business System Testing
Testing activity, with the exception of acceptance testing, is performed
during this phase.
The functional/technical application analyst team works closely with the
programming team. Business and technical analysts who initially
reviewed current business requirements and performed requirements
mapping tasks are now included in testing tasks.

Oracle Method

Update and Test 4 - 19

Unit and link testing should be lead by the development lead. Systems
testing should be lead by the business analyst lead since system testing
should be driven by business transactions.
Training
User training materials are developed during this phase.
If a significant amount of user documentation updating or development is
to be performed, consider using technical writers rather than functional or
technical analysts.
Production Migration
The Detailed Transition and Contingency Plan (PM.030) is developed
during this phase. Due to the critical nature of this plan, the project
manager should lead its development.

4 - 20 Update and Test

EMM Method Handbook

CHAPTER

Transition
T

his chapter describes the Transition phase of EMM. The goal of the
Transition phase is to create a fully configured and migrated
production environment. The Transition phase results in cutover to the
new production system.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 5-1

Oracle Method

Context of EMM Transition Phase

Transition 5 - 1

Overview
This section provides an overview of the Transition phase.

Objectives
The objectives of the Transition phase follow:
Upgrade the production environment.
Prepare personnel to support the new system.
Verify that the system meets all acceptance criteria.
Begin to use the migrated applications in the production
environment.

Critical Success Factors

The critical success factors of the Transition phase follow:
a clear understanding of the business objectives
effective participation by business management
sufficient technical and application architecture expertise
available and committed support staff
committed user involvement and ownership
effective training

Prerequisites
Prerequisites for the Transition phase follow:

5 - 2 Transition

Prerequisite

Source

Application Setup Document

Requirements Mapping
Update

EMM Method Handbook

Prerequisite

Source

Security Profiles

Requirements Mapping
Update

Validation Tested Data Migration

Programs

Data Migration

Education and Training Plan

Training

User Training Manual

Training

Pre-Upgrade Checklist

Business System Testing

Post-Upgrade Checklist

Business System Testing

Updated Technical Architecture

Documents

Migrate Application and

Technical Architecture

Detailed Transition and Contingency

Plan

Production Migration

User Guide

Documentation

Table 5-1

Transition Phase Prerequisites

Processes
The processes used in this phase follow:

Oracle Method

Process

Description

Data Migration

Install migration software.

Business System Testing

Perform user acceptance testing

of production system.

Training

Prepare user training

environment and train users.

Transition 5 - 3

Process

Description

Production Migration

Upgrade the production system

and cutover to production.

Table 5-2

Transition Phase Processes

Key Deliverables
The key deliverables of this phase follow:
Deliverable

Description

Installed Data Migration

Software

Installed data migration software.

Acceptance Results

Documents the approach and results

of user acceptance testing of the
production environment.

Trained Users

Users who are capable of using the

upgraded application to its fullest
capacity.

Post-Upgrade Checklist

Documents the work steps and the

information concerning exceptions
generated by the upgrade steps.

Production System

The upgraded production system

running live business transactions.

Table 5-3

5 - 4 Transition

Transition Phase Key Deliverables

EMM Method Handbook

Approach
This section describes the approach for the Transition phase.

Tasks and Deliverables

ID

Core

Task

Deliverable

Data Migration
DM.130
N
Install Data Migration Software
Business System Testing
TE.140
N
Perform User Acceptance Test,
Production System
Training
TR.080
Y
Prepare User Training Environment
TR.090
Y
Train Users
Production Migration
PM.035
Y
Perform Pre-Upgrade Steps
PM.040
Y
Upgrade Production Environment
PM.045
Y
Perform Post-Upgrade Steps
PM.050
Y
Revise Application Setups
PM.070
Y
Verify Production Readiness
PM.080
Y
Commence Production
Table 5-4

Oracle Method

Installed Data Migration Software

Acceptance Results

User Training Environment

Trained Users
Pre-Upgrade Checklist
Production Environment
Post-Upgrade Checklist
Configured Applications
Production-Ready System
Production System

Transition Phase Tasks and Deliverables

Transition 5 - 5

Core Task Dependencies

This diagram shows the dependencies between core tasks in the
Transition phase.

Transition

TR.080
Prepare User
Training
Environment

TRAINING

1 Line
( 6 5/16 tall X 6 1/4 wide)
PM.035

P RODUCTION
M IGRATION

PM.040

Preform PreUpgrade Steps

Figure 5-2

5 - 6 Transition

Upgrade
Production
Environment

PM.045
Perform PostUpgrade Steps

PM.050
Revise Application
Setups

Transition Phase Core Task Dependencies

EMM Method Handbook

Transition

TR.090

TRAINING

Train Users

1 Line
( 6 5/16 tall X 6 1/4 wide)
PM.070
Verify Production
Readiness

Figure 5-2

Oracle Method

PM.080
Commence
Production

PRODUCTION
M IGRATION

Transition Phase Core Task Dependencies (cont.)

Transition 5 - 7

Core and Optional Task Dependencies

This diagram shows the dependencies between all tasks in the Transition
phase.

Transition
DM.130

DATA M IGRATION

Install Data
Migration
Software

BUSINESSS YSTEM
TESTING

TR.080
Prepare User
Training
Environment

TRAINING

1 Line

( 6 5/16 tall X 6 1/4 wide)

PM.035

P RODUCTION
M IGRATION

PM.040

Preform PreUpgrade Steps

Figure 5-3

5 - 8 Transition

Upgrade
Production
Environment

PM.045
Perform PostUpgrade Steps

PM.050
Revise Application
Setups

Transition Phase Task Dependencies

EMM Method Handbook

Transition

DATA M IGRATION

TE.140

BUSINESSS YSTEM
TESTING

Perform User
Acceptance Test,
Production System

TR.090

TRAINING

Train Users

1 Line
( 6 5/16 tall X 6 1/4 wide)
PM.070

PM.080

Verify Production
Readiness

Figure 5-3

Oracle Method

Commence
Production

PRODUCTION
M IGRATION

Transition Phase Task Dependencies (cont.)

Transition 5 - 9

Staffing
This diagram illustrates a typical project organization for the Migration
Assessment phase.

Transition Phase Organization

Project Manager

System
Administrator
(Technical Services
Lead)

Business Analyst

Developer
(Custom
Development)

Application
Specialist

Technical Analyst
(Upgrade/Data
Migration Lead)

Database
Administrator

Trainer
(User Training)

Technical Services Team

Developer 1

Developer 2

Programming Team

Business
Analyst 1

Legend

Business
Analyst 2

Management

Required
Technical
Analyst

Optional

Functional/Technical Application Analyst Team

Figure 5-4

5 - 10 Transition

Transition Phase Staffing

EMM Method Handbook

Staffing Suggestions
This section provides advice and comments on project organization for
Transition.
Project Management
Organizational changes between the Update and Test and Transition
phases include:
The trainer role changes from developing user training materials to
conducting user training.
The database administrator joins the technical services team and
the performance measurement specialist is released since
architecture updates should have been completed in the previous
phase.
The number of programmers may be reduced if user acceptance
testing did not identify significant custom software errors or
problems in running data migration programs.
If application specialists are being used, their numbers could be
reduced or phased off entirely if sufficient knowledge has been
transferred to other team members.
System architects phase off the project since all architectural
updates should have been completed in the previous phase.
Continue to seek continuity and risk minimization by assigning key
team members to multiple processes. This maximizes the
probability that integration issues will be identified.
Data Migration
Data migration software (such as Oracles EDMS or Smart Corporations
SmartDBTM) is installed during this phase. Consider using vendor staff for
training and initial configuration.
Business System Testing
Obtaining user and management approval to cut over to the migrated
system is a key project milestone and quality control point. Verify that the
user acceptance test is led and staffed by users. The migration project team
performs a support role only in this critical test.

Oracle Method

Transition 5 - 11

Training
User training is conducted during this phase.
Production Migration
The actual production migration is performed during this phase.
A key staffing objective for migration projects is to make sure that the team
performing the production migration (consisting of the pre-upgrade steps,
running Oracles upgrade utility, and the post-upgrade steps) is equipped
to do so efficiently. Staffing assignments from the beginning of the project
should have been made to develop a highly qualified team.
Balance meeting budget objectives with maintaining sufficient staff to deal
with potential problems during and immediately after the production
migration.

5 - 12 Transition

EMM Method Handbook

CHAPTER

Production
T

his chapter describes the Production phase of EMM. The goal of the
Production phase is to monitor the production system and make sure
that the migrated application is performing adequately.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 6-1

Oracle Method

Context of EMM Production Phase

Production 6 - 1

Overview
This section provides an overview of the Production phase.

Objectives
The objectives of the Production phase follow:
Monitor application performance and make necessary corrections.
Provide agreed upon levels of user support.
Audit the production system.
Maintain the production system.

Critical Success Factors

The critical success factors of the Production phase follow:
effective change control tools and procedures
accurate compilation of volumes, transaction histories, and other
performance measures
adequate staff and expertise
effective technical and application architecture

6 - 2 Production

EMM Method Handbook

Prerequisites
Prerequisites for the Production phase follow:
Prerequisite

Source

Performance Risk Assessment

Migrate Application and

Technical Architecture

Production System

Production Migration

Table 6-1

Production Phase Prerequisites

Processes
The processes used in this phase follow:
Process

Description

Production Migration

Begin production system

execution. Perform audit and
measurement of migrated
production system. Measure
system performance and adjust
as appropriate.

Table 6-2

Oracle Method

Production Phase Processes

Production 6 - 3

Key Deliverables
The key deliverable for this phase follows:
Deliverable

Description

Refined Production
Environment

The upgraded and refined production

system running live business
transactions.

Table 6-3

6 - 4 Production

Production Phase Key Deliverables

EMM Method Handbook

Approach
This section describes the approach for the Production phase.

Tasks and Deliverables

ID

Core

Task

Deliverable

Production Migration
PM.090
N
Audit Production System
PM.100
PM.110
PM.120

Y
Y
Y

Measure System Performance

Maintain System
Refine Production System
Table 6-4

Oracle Method

Post-Implementation Production
System
System Performance Assessment
Maintained Production Environment
Refined Production Environment

Production Phase Tasks and Deliverables

Production 6 - 5

Core Task Dependencies

This diagram shows the dependencies between core tasks in the
Production phase.

Production

Production

PM.100
Measure System
Performance

1 Line

PM.120

P RODUCTION
M IGRATION

PRODUCTION
M IGRATION

Refine Production
System

( 6 5/16 tall X 6 1/4 wide)

PM.110
Maintain System

Figure 6-2

6 - 6 Production

Production Phase Core Task Dependencies

EMM Method Handbook

Core and Optional Task Dependencies

This diagram shows the dependencies between all tasks in the Production
phase.

Production

Production

PM.090
Audit Production
System

PM.100

P RODUCTION
M IGRATION

PM.120

Measure System
Performance

1 Line

Refine Production
System

( 6 5/16 tall X 6 1/4 wide)

PRODUCTION
M IGRATION

PM.110
Maintain System

Figure 6-3

Oracle Method

Production Phase Task Dependencies

Production 6 - 7

Staffing
This diagram illustrates a typical project organization for the Production
phase.

Production Phase Organization

Project Manager

Database
Administrator

Business Analyst

Technical Analyst
(Performance
Testing)

Legend
Management

Required

Optional

Figure 6-4

6 - 8 Production

Production Phase Staffing

EMM Method Handbook

Staffing Suggestions
This section provides advice and comments on project organization for
Production.
Project Management
Most of the project staff can be released before this phase except the project
manager, business analyst lead, and database administrator. Optionally,
a technical analyst may also remain to assist in tuning the migrated
system by performing performance testing.
Production Migration
Avoid releasing staff too early. You may need to address unexpected
problems after cutover. However, you may also be under budget pressure
to reduce staff as quickly as possible.

Oracle Method

Production 6 - 9

III
PART

EMM Processes

CHAPTER

Business
Requirements
Review (RR)
T

his chapter describes the Business Requirements Review process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 7-1
Oracle Method

Business Requirements Review Context

Business Requirements Review (RR) 7 - 1

Process Flow
Business Requirements Review (RR)

RR.020
Review Current
Business Processes
MU.005 - Release Changes Summary
Future
Process Model
RR.030
Develop Future
Process Model

RR.060
Gather Business
Volumes

Business Analyst
TR.060 - Trained Project Team
RR.070
Review Business
Requirements
Scenarios
Business
Requirements Scenarios

Figure 7-2

7 - 2 Business Requirements Review (RR)

Business Requirements Review Process Flow Diagram

EMM Method Handbook

Approach
The objective of the Business Requirements Review process is to
understand the basic business requirements that the installed applications
must satisfy and determine how those requirements are affected by
changes in the new Oracle Applications release. Some requirements
identified during the original implementation may not have been fully
satisfied by the current applications functionality. They may have
required manual workarounds, customizations, or even third-party
solutions. The new release may fully satisfy these requirements or allow
you to support them in a different way. Some of your business processes
may need to change to accommodate application changes. The Business
Requirements Review process addresses these issues as well.
Business Requirements Review encourages the use of existing
documentation from the original application implementation. For those
tasks requiring the creation or enhancement of documentation, Business
Requirements Review uses a combination of top-down and bottom-up
analytical techniques to obtain, understand, and document the objectives
and requirements and their changes for the new application system.
During Business Requirements Review planning, decide whether you
need to conduct an analysis of the current business and, if so, to what
depth. Management must make this decision by considering the business
scope and objectives of the migration project.
The business analyst starts the process by conducting a series of
interviews with the project sponsor and management representatives from
the affected business areas. The only Core task in this process, Review
Business Requirements Scenarios (RR.070), updates your detailed
business requirements documentation and identifies the requirements
impacted by new release changes. You will perform the detailed mapping
of the requirements to applications functionality during the Requirements
Mapping Update process.

Oracle Method

Business Requirements Review (RR) 7 - 3

Tasks and Deliverables

ID

Core

Task Name

Deliverable Name

RR.020
RR.030
RR.060
RR.070

N
N
N
Y

Review Current Business Processes

Develop Future Process Model
Gather Business Volumes
Review Business Requirements
Scenarios

Current Business Baseline

Future Process Model
Business Volume Requirements
Business Requirements Scenarios

Table 7-1

Business Requirements Review Tasks and Deliverables

Objectives
The objectives for the Business Requirements Review process are:
Understand the business requirements associated with business
processes impacted by the upgrade.
Define the future business processes (and specific functions
performed in those processes), for business areas that are affected by
the upgrade.
Quantify changes in transaction and data volumes for business
processes impacted by the upgrade.
Develop a complete set of Business Requirements Scenarios for
business processes affected by the upgrade, that can be used to map
business requirements to application functionality.

7 - 4 Business Requirements Review (RR)

EMM Method Handbook

Key Deliverables
The key deliverables of this process follow:
Deliverable

Description

Future Process Model

The future process model

consists of event catalogs,
process listing, process
descriptions, process flow
diagrams, and optional
process step catalogs for each
business process changed as a
result of the upgrade project.

Business Requirements Scenarios

Updated or newly prepared

formal statements of detailed
business requirements for a
business process and the
source of these requirements.

Table 7-2

Business Requirements Review Key Deliverables

Key Responsibilities
The following role is required to perform the tasks within this process:
Role

Responsibility

Business Analyst

Conduct interviews and

working sessions. Identify
business requirements
impacted by the upgrade and
create revised business models
where appropriate. Perform
analysis to resolve issues.

Table 7-3

Oracle Method

Business Requirements Review Key Responsibilities

Business Requirements Review (RR) 7 - 5

Critical Success Factors

The critical success factors of the Business Requirements Review process
follow:
effective project management
a clear understanding of the migration projects scope and
objectives by all project team members
comprehensive and common understanding of business processes
impacted by the upgrade by all members of the project team
adequate integration of processes across design teams
dedicated resources for conducting analysis
understanding of new release application functionality and
industry best practices by the project team
a committed project sponsor who provides a consistent, high level
of commitment across the team
active involvement and support of management
active involvement and support of knowledgeable business area
experts
full access to information about relevant business areas, their
processes, data generation, and use
effective management of issues, including their timely resolution
involvement of skilled analysts to work with management, project,
and area teams to obtain information required for requirements
definition; to model the business processes; and to organize and
present that information coherently and consistently
complete deliverables that meet quality standards

7 - 6 Business Requirements Review (RR)

EMM Method Handbook

RR.020

Review Current Business Processes (Optional)

Review current business processes to provide the project team with an
accurate understanding of the current business requirements. This is
necessary to map the current business requirements to the new release
functionality in Remap Business Requirements (MU.020) and Remap
Business Data (MU.030). Use Release Changes Summary (MU.005) to help
focus analysis on current processes that are likely to be impacted by new
release changes. In addition, use existing documentation and personnel
with knowledge of current business processes.
Suggestion: If Oracles Application Implementation Method
(AIM) was used in the initial implementation, use its Future
Process Model deliverable as your starting point (it represents
how you are currently running your business with the
applications).
Exercise care in establishing the scope of this optional task. In many
cases, little or no work will be needed due to minimal impact on current
processes, sufficient documentation, and team knowledge.

Deliverable
The Current Business Baseline depicts the business events and processes
that represent how the business currently operates. You should review
and update the business process documentation that you already have.
Use the Current Business Baseline worksheet in the EMM Master Tracking
Workbook to document key information about project impacts on current
business processes and status information concerning team activities.
This worksheet is intended to be the central reference for current process
impact information throughout the project.
The Current Business Baseline worksheet includes one row for each
process being evaluated. Use the New Release Change Identification code
from the Release Changes Summary (MU.005) for the same field in this
worksheet.

Oracle Method

Business Requirements Review (RR) 7 - 7

Deliverable Components
Update the Current Business Baseline documentation from the initial
implementation using the Current Business Baseline worksheet
information to assist you. If this documentation is not available or
inadequate, it must be created. For each business process, create one
Current Business Process Model, consisting of the following components:
Event Catalog List all of the events to which the business
responds. Each event has a name, brief description, frequency, and
the conditions under which it occurs. Receiving a customer order is
an example of an event that triggers a business process.
Process Listing and Process Descriptions Provide an
introductory, textual description of the processes that are executed
in response to current business events, together with an
identification of each processs main inputs and outputs.
Current Business Baseline Use a process flow to clearly show the
process steps for each process, as well as the agent who owns each
step. This may be supported by a process step catalog.
Use structured process questionnaires to provide content and
structure in the interviewing activity during process research.
Process Improvement and Redesign List Identify processes that
require significant improvement and redesign before they can be
used as the basis for future process modeling and requirements
mapping.

Responsible
Business Analyst

7 - 8 Business Requirements Review (RR)

EMM Method Handbook

RR.030

Develop Future Process Model (Optional)

For business processes that will change due to the migration, develop
future process models that describe how these processes will be performed
after the migration. Update existing process documentation.
After conducting current business baseline activities for business
processes impacted by the application migration, define a model of the
new business system.
Refer to the Current Business Baseline (RR.020) completed in conjunction
with current process documentation for detailed information
requirements. The Release Changes Summary (MU.005) describes the new
release changes impacting the organization.
It is essential to have a trained project team to perform this task. A
thorough knowledge of new release functionality is necessary to design
business process changes that will be supported by the migrated system.
Only processes impacted by the migration need to be modeled. Avoid
unnecessary modeling activity related to objectives beyond the scope of the
applications migration (such as business process reengineering).

Deliverable
The Future Process Model depicts business events and the response to the
events as a series of process steps. The Future Process Model should
effectively communicate the following:
To what events does the business respond?
What processes make up the response?
What process steps make up each process?
Who performs each process step (organization or role)?
How are business decisions supported by the new system?
What necessary control elements (approval steps) should be
established?

Oracle Method

Business Requirements Review (RR) 7 - 9

 What organizational changes are required to support the new

processes?
Use the Future Process Model worksheet in the EMM Master Tracking
Workbook to record key information about Future Process Models
developed for the migration project.
One row should be completed for each process you model. Use the New
Release Change Identification code from the Release Changes Summary
(MU.005) for the same field in this worksheet.

Deliverable Components
Update the Future Process Model documentation from the initial
implementation using the Future Process Model worksheet information to
assist you. If the initial documentation is not available or inadequate you
may create a Future Process Model for each process using the following
components:
Event Catalog This catalog lists all events to which the business
responds. Each event has a name, a brief description, frequency,
and conditions under which it occurs. You can bring many of these
forward from the Current Business Baseline models, but any
changes due to the upgrade must be applied.
Process Listings and Descriptions This component provides a
textual description of the process that is executed in response to
each event, along with an identification of the main inputs and
outputs of the process.
Process Step Catalogs This catalog lists the process steps that
make up the process. Each step should have a brief, descriptive
title. One objective of this task is that the analysis be sufficiently
detailed so that each step is at an elementary business function
level. It also records the agent responsible for the execution of each
step, and classifies each step by desired degree of automation:
manual, computer assisted, or fully automated.

7 - 10 Business Requirements Review (RR)

EMM Method Handbook

 Process Flow Diagrams These diagrams exist for any process

with conditional steps or more than two steps. A process model
reflects how an organization actually performs work. In process
modeling, organizations are regarded as adaptive and purposeful
systems that respond to changes in their environment by receiving
inputs from, and producing outputs for, that environment. These
organizational systems, in turn, consist of subsystems that also
accept inputs and produce outputs. Such subsystems are the
business processes of an organization.
Based on this conceptual framework, process modeling views
processes as systems that are triggered by events that receive inputs
and produce outputs. Process modeling shows the detailed steps
that occur within a process to transform the inputs into the process
outputs. Process models can also represent flows of information
and material between process steps. By showing which
departments or employee roles are responsible for the various steps,
process modeling places processes in their organizational context.
The process flow diagram presents this information visually. The
result is a visual map of the information needed during the
execution of the business process and the finished work. People
who understand how the work is actually performed can review
these visual models, identify inaccuracies, and make corrections.
They can also more easily identify problem areas and visualize
opportunities for process improvement and process redesign.
Process modeling of the future business processes results in a
common and comprehensive picture of the projects scope of
relevant processes and, if desired, expected metrics and costs.

Responsible
Business Analyst

Oracle Method

Business Requirements Review (RR) 7 - 11

RR.060

Gather Business Volumes (Optional)

During this task, analyze impacts of the new application release on
business volumes and estimate changes in operational processing
volumes, transaction patterns, and data storage volume requirements.
This information provides the basis for determining changes in the size
and performance of the upgraded production system.
Additional tables or columns in existing tables may be present in the new
release that could significantly increase the size of the database if they are
populated, which would in turn could affect system performance.
The amount of production data is a primary determinant of how long the
automated portion of the production migration will run. This can be a
crucial factor if volumes require more time than is available (such as
exceeding a weekend).
Identify potential changes in transactions volumes from interfaced
systems as well as native Oracle transaction volumes.
If available, the Future Process Models (RR.030) should be referenced.
Statistics for current production data should be available from the
information systems department.

Deliverable
Use the Business Volume Requirements worksheet in the EMM Master
Tracking Workbook to document key information about business volumes.
This worksheet is intended to be the central reference for business volume
information throughout the project.
Complete one row for each data object associated with volume
information. Use the New Release Change Identification code from the
Release Changes Summary (MU.005) for the same field in this worksheet.
Future Process Models (RR.030) may also be referenced.

7 - 12 Business Requirements Review (RR)

EMM Method Handbook

Deliverable Components
Complete the following columns in the Business Volume Requirements
worksheet for this deliverable:
Data Object
New Release Change Identification Code
Impact Description
Current Volume
Current Time Period
Estimated Future Volume
Future Time Period
Percent Change

Responsible
Business Analyst

Oracle Method

Business Requirements Review (RR) 7 - 13

RR.070

Review Business Requirements Scenarios (Core)

For business processes affecting the migration, review Business
Requirements Scenarios (BRS) developed during the initial
implementation project to make sure the project team has a complete
understanding of functionality requirements that must be met by the
upgraded system.
When a team creates a BRS, it is completing the design of the business
process that began with development of the Future Process Model
(RR.030). Since BRS development sessions are design sessions, you can
expect that additions and corrections will be made to process models and
function models during the course of design. Although it is possible to
create a BRS at the same time that its process model is being developed, it
is actually better to start with a graphical representation of the business
process before going into descriptive detail. Using visualization
techniques during the early stages of any design is crucial to
understanding and common agreement.
This is a core task. Even for simple migrations, some BRS review is
necessary to verify that no significant business requirement change will
occur due to the upgrade.
It is essential to have a trained project team when performing this task.
Thorough knowledge of new release changes is necessary to determine
impact.
Be aware that some migrations have no impact on business requirements.
Addressing objectives beyond the scope of the upgrade project such as
business process reengineering or implementation of new modules should
be postponed until after the upgrade project.
Use the Release Changes Summary (MU.005) and identify what processes
and requirements are affected by each change. Establish cross references
between the specific release change and the corresponding requirements.

7 - 14 Business Requirements Review (RR)

EMM Method Handbook

Deliverable
Business Requirement Scenarios are formal statements of the detailed
business requirements for a business process, the source of these
requirements, how these requirements will be satisfied (either by the
application, manual process steps, workarounds, or other application
solutions), and what prototyping steps must be taken to prove the designs.
Use the Business Requirements Scenario worksheet in the EMM Master
Tracking Workbook to document key information about the review of
Business Requirements Scenarios. This worksheet is intended to be the
central reference for BRS review information throughout the project.

Deliverable Components
Update the BRS from the initial implementation using the BRS worksheet
information to assist you. If the initial documentation is not available or
inadequate you may create a BRS using the following components:
Business Requirements Scenario One row should be completed
for each BRS reviewed, updated, or created. Columns provide
references to the related Future Process Model (RR.030) and to the
Release Changes Summary (MU.005). Other columns describe the
nature of BRS review activity, task status, and analysis results.
References to other documentation may be provided.
Business Process Identification Describe the business process
and its detailed process steps in a list format with references to
Events, Business Functions, and Agents (organizations and roles).
Requirements and Sources Traces the need for each process step
to its source.
Additional Components Three other components of the BRS will
be completed during the mapping process:
Process Analysis: facilitates quantitative analysis and
measurement of each process step
Solution: refers to how the requirement is satisfied by the
application or other solution workaround.
Mapping Scenario: supports solution prototyping

Oracle Method

Business Requirements Review (RR) 7 - 15

Responsible
Business Analyst

7 - 16 Business Requirements Review (RR)

EMM Method Handbook

CHAPTER

Requirements
Mapping
Update (MU)
T

his chapter describes the Requirements Mapping Update process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 8-1
Oracle Method

Requirements Mapping Update Context

Requirements Mapping Update (MU) 8 - 1

Process Flow
Requirements Mapping Update (MU)
MU.011
System Administrator

Upgrade Project
Environments

MA.140 - Application
Architecture Documents

Application
Setup Document

MU.110
Business Requirements
Mapping Form

Revise Application
Setups

PJM.CR.010 - Establish Scope,

Objectives and Approach
Process
Narratives

MU.020

Business Analyst

Remap Business
Requirements

MU.005

RR.070

MU.070

MU.090

Identify New
Release Changes

Review Business
Requirements
Scenarios

Review Reporting
Fit Analysis

Confirm
Integrated
Business Solutions

MU.100
Update Process
Narratives

MU.120

Release Changes
Summary

Revise Security
Profiles

MU.040
Review Integration
Fit Analysis

Technical Analyst
MU.030
Remap Business
Data

Figure 8-2

8 - 2 Requirements Mapping Update (MU)

Requirements Mapping Update Process Flow Diagram

EMM Method Handbook

Approach
This process assesses the changes between the current and new
application release. It maps the changes to the business requirements
updated in the Business Requirements Review (RR) process. For
application upgrades, the release changes drive the Requirements
Mapping Update process. This differs from application implementation
projects, which must map all application functionality and technical
features to business requirements. You will identify gaps between new
release features and business requirements and make recommendations
on how to deal with these gaps. During this process you can also assess
system-enabled business process improvement opportunities where new
release capabilities exist.
Requirements Mapping Update begins early in the life cycle of a migration
project. Reviewing the business requirements mapping documentation
prepared during the initial implementation may help you identify the gaps
that required customizations or changes in business processes.
Some examples of application release changes that can create gaps are:
new functionality and corresponding database changes can affect
customizations and application interfaces
new functionality that enables business process improvement
additional technological capabilities such as web-deployed user
interfaces
database enhancements such as advanced replication facilities and
new data warehouse capabilities
changes to Oracle Application Interfaces such as EDI support
custom tables used with the current releases that may change with
the new release
As business process designs progress during mapping, so do deliverables.
Mapping provides a basis for documenting changes in detailed business
requirements and proposed solutions.

Oracle Method

Requirements Mapping Update (MU) 8 - 3

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

MU.005
MU.011
MU.020
MU.030
MU.040
MU.070
MU.090
MU.100
MU.110
MU.120

Y
Y
Y
Y
N
Y
Y
Y
Y
Y

Identify New Release Changes

Upgrade Project Environments
Remap Business Requirements
Remap Business Data
Review Integration Fit Analysis
Review Reporting Fit Analysis
Confirm Integrated Business Solutions
Update Process Narratives
Revise Application Setups
Revise Security Profiles

Release Changes Summary

Configured Project Environments
Business Requirements Mapping Form
Business Data Mapping
Integration Fit Analysis
Master Report Tracking List
Acceptance Certificate
Process Narratives
Application Setup Document
Security Profiles

Table 8-1

Requirements Mapping Update Tasks and Deliverables

Objectives
The objectives of the Requirements Mapping Update process are:
Identify changes between the current and new application release
and establish new application release fit to business requirements.
Identify gaps between new release features and business
requirements.
Propose feasible bridges to gaps.
Prove designs through demonstration.
Create job-level descriptions of business process designs related to
processes impacted by the upgrade.
Define the application configuration you need to support the new
application release solution.

8 - 4 Requirements Mapping Update (MU)

EMM Method Handbook

Key Deliverables
The key deliverables of this process follow:
Deliverable

Description

Release Changes Summary

Worksheet in the Master EMM

Tracking Workbook providing
information about changes between
the current and new Oracle
application release.

Business Requirements
Mapping Form

Documents key business requirements

or gaps between business
requirements and standard
application functionality in the new
applications release.

Process Narratives

Updated process narratives reflecting

changed job-level descriptions due to
business process changes.

Application Setup Document

Updated or new documentation

describing changes to existing
application setup data.

Table 8-2

Requirements Mapping Update Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:
Role

Oracle Method

Responsibility

Requirements Mapping Update (MU) 8 - 5

Role

Responsibility

Business Analyst

Conduct interviews and working

sessions. Identify detailed business
requirements impacted by the upgrade
and create revised business
requirement scenarios as appropriate.

Technical Analyst

Propose solutions and technical

assumptions. Remap business data to
new release applications.

System Administrator

Upgrade application environment for

mapping activities.

Table 8-3

Requirements Mapping Update Key Responsibilities

Critical Success Factors

The critical success factors of the Requirements Mapping Update process
follow:
consistency of team composition across business process design,
mapping, narrative writing, and approval activities
consistency of team approach across business area or business
process groups
adequate integration of business processes across design and
mapping teams
project team understanding of new application release
functionality, including changes and new features
a committed project sponsor who encourages a high level of
commitment across the team
active involvement and support of management
full access to impacted business areas, their processes, and
information generation and use
effective management of issues, including their timely resolution
proper sign off throughout all stages

8 - 6 Requirements Mapping Update (MU)

EMM Method Handbook

Oracle Method

Requirements Mapping Update (MU) 8 - 7

MU.005

Identify New Release Changes (Core)

Identify the changes between the current and new Oracle application
release. The single most important factor in an upgrade project is the
accurate identification and understanding of these changes.
The primary sources for release change information are the Oracle release
manuals, training on the new release, and external personnel with new
release expertise.
Consider the various categories of new release changes since they relate to
different areas of technical, functional, and application architecture. The
organization may be migrating from character or GUI to web deployed
access. A database upgrade may be involved. The new release might
require more or less disk storage and network bandwidth. Application
functionality may have been enhanced resulting in new tables or new
columns in current tables. Current table columns may have been split into
multiple columns creating data migration challenges. Forms, reports, and
processing logic may have changed allowing elimination of current
customizations. New integration features may be available allowing
elimination or simplification of existing custom interfaces.
During this task, the project team assesses the changes between the current
and new release. It is essential that a thorough understanding of these
changes is achieved since this task drives the remainder of the upgrade
project.

Deliverable
Use the Release Changes Summary worksheet in the EMM Master
Tracking Workbook to document key information about changes between
the current and new Oracle Application release. This worksheet is
intended to be the central reference for Business Requirements Scenarios
(BRS) review information throughout the project.
Complete one row for each identified change. Assign a New Release
Change Identification code, which is used by other EMM deliverables to
refer back to a given row in this worksheet.

8 - 8 Requirements Mapping Update (MU)

EMM Method Handbook

Deliverable Components
Complete the following columns in the Release Changes Summary
worksheet:
New Release Change Identification Code
Short Description
Project Impact
Impact Description
Impact Person Days
Impact Dollars
Oracle Documentation Reference
Other Documentation Reference

Responsible
Business and Technical Analysts

Oracle Method

Requirements Mapping Update (MU) 8 - 9

MU.011

Upgrade Project Environments (Core)

During this task, update existing application environments for various
project activities such as mapping requirements to new release
functionality, developing custom software, testing, and conducting
training.
Project environments should include the new release software and
realistic data. They must be accessible to team members for mapping,
future process modeling, custom software development, and designing
and developing training materials. The easiest way to achieve this is to
run Oracles migration utility, which installs the software and migrates
production data stored in standard Oracle tables. However, the utility
will not smoothly migrate production data errors or custom tables. If there
are existing customizations that alter current release functionality, the new
release may not function as intended until the customizations are
migrated.
Pay attention to long lead time hardware, software, and network
enhancements. For example, if additional disk storage must be acquired
and installed and project activities are scheduled to begin in a few weeks,
the disk storage order may be too late to meet the project schedule.

Deliverable
The deliverable for this task is the Configured Project Environments.
Hardware, software, and network environments must be provided to
enable high productivity by the project team. Such environments consist
of hardware, systems software, networks, Oracle database instances, and
software tools for activities such as office automation, custom software
development, custom data migration, and testing.

Deliverable Components
None

8 - 10 Requirements Mapping Update (MU)

EMM Method Handbook

Responsible
System Administrator

Oracle Method

Requirements Mapping Update (MU) 8 - 11

MU.020

Remap Business Requirements (Core)

During this task, assess the fit of the new release to detailed business
requirements. You will use the Future Process Model (RR.030) and
Business Requirements Scenarios (RR.070) since they provide detailed
business requirements.
It is essential that the project team has a thorough knowledge of the new
applications release. Errors here can cause substantial unplanned time
and resource requirements later.
An effective mapping environment is essential for this task. Analysts must
be able to efficiently use a test database instance to exercise the new release
functionality by using test scenarios relevant to the organizations
business.
Avoid mapping activities not necessary for the applications upgrade.
Normally, business process reengineering and implementation of new
modules or major new functionality for applications currently in use
should be postponed until after the upgrade.
This task reassesses the fit of standard application and system features in
the new release to detailed business requirements. A focus is placed on
the changes documented in the Oracle Upgrade Preparation Manual.

Deliverable
Use Business Requirements Mapping Forms (BRM) to document
business requirements or gaps between detailed business requirements
and functionality in the new applications release. There is one BRM for
each requirement or gap. It includes a detailed description of the
requirement and a description of the proposed approach to resolving the
gap.
Always complete BRMs for gaps and for any requirements requiring
detailed documentation. BRMs refer to related Business Requirements
Scenarios (RR.070) and specific changes in the Release Changes Summary
(MU.005).

8 - 12 Requirements Mapping Update (MU)

EMM Method Handbook

During mapping, you should also complete the mapping sections of the
Business Requirements Scenarios (RR.070) and annotate your Future
Process Model (RR.030) with mapping information.

Deliverable Components
Select the Business Requirements Mapping template to create the
deliverable for this task. Use the following components:
Introduction
BRM Source Contains a Requirement Essay section that describes
business requirements in business language and in terms of
business objectives, not application features. It also contains a
Current versus Proposed section that facilitates the analysis and
comparison of the current solution to a business requirement for a
proposed solution.
Solution This component details the type and nature of the
solution in a descriptive format.

Responsible
Business Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 13

MU.030

Remap Business Data (Core)

During this task, you remap data elements from the current Oracle
production application, including custom tables, flexfield data, and
interfaced systems to the business objects and attributes in the new release.
The primary objective is to determine if the new release supports data
elements currently stored in custom tables or flexfields. You must also
determine if any current business objects or attributes are no longer
supported in the new release.
Refer to the Business Requirements Scenarios (RR.070) during this task for
detailed information requirements.
Oracles migration utility automatically migrates production data stored
in standard Oracle tables. It does not migrate data stored in custom tables,
although it should leave them intact.
Examples of new release changes requiring remapping follow:
Enhanced features or table changes in the new application release
may require remapping. Table changes may include new tables,
additional or changed columns in tables, or deleted tables.
New features that require additional application setup data values
may require remapping.
The new release may support data that you currently store in
custom tables or flexfields.
Oracle standard open interfaces may change, which affects custom
interfaces.
If changes in the data distribution across sites are being addressed
by the upgrade project, a review of what, where, and how data will
be stored is important due to impacts of the new release.

Deliverable
The Business Data Mapping deliverable documents the mapping between
data stored in custom tables and flexfields to tables and columns in the
new applications release.

8 - 14 Requirements Mapping Update (MU)

EMM Method Handbook

Complete one table row for each business object being mapped.

Deliverable Components
Select the Business Data Mapping template to create the deliverable for
this task. Use the following components:
Introduction
Business Data Mapping

Reference Number

New Oracle Application Attribute

New Oracle Application Table Column

New Datatype

Not Null?

Current Application Table Type

Current Attribute

Current Table Column

Current Datatype

Validation

Rule Number

Responsible
Technical Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 15

MU.040

Review Integration Fit Analysis (Optional)

During this task, identify new and changed integration points based on
mapping the new applications release onto the existing applications
architecture. This mapping may also include distributed integration
points between standard applications and other applications. Changes to
Oracle application programming interfaces (APIs), or to tables used by
custom interfaces, must also be analyzed.
Once the business solution for each integration point gap is identified, a
complete listing of all new or changed integration points can be
developed. At this stage in the upgrade project no detailed interface
specifications are completed.
Business Data Mapping (MU.030) is used as input for this task.

Deliverable
Use the Integration Fit Analysis worksheet in the EMM Master Tracking
Workbook to document key information about new release changes
affecting the integration of Oracle Applications with other systems. This
worksheet is intended to be the central reference for integration fit
information throughout the project.
Complete one row for each integration point impacted by the application
release migration. Use the New Release Change Identification code from
the Release Changes Summary (MU.005), for the same field in this
worksheet.

Deliverable Components
Complete the following columns in the Integration Fit worksheet for this
deliverable:
Integration Point
New Release Change Identification Code
Impact Degree

8 - 16 Requirements Mapping Update (MU)

EMM Method Handbook

 External System
Oracle Module
Impact Description
Analyst
Percent Complete
Estimated/Actual Completion Date

Responsible
Technical Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 17

MU.070

Review Reporting Fit Analysis (Core)

During this task, use documentation from the initial implementation that
mapped reporting requirements to the current release functionality.
Update this documentation to reflect the new application release and
reporting requirements. The new release may include new, changed, or
deleted reports. Enhanced query capability may reduce or eliminate the
need for some reports.
Determine the final disposition of every report requirement and seek to
minimize custom reports for the new release.

Deliverable
The deliverable for this task is the Master Report Tracking List. Use the
Master Report Tracking worksheet in the EMM Master Tracking Workbook
to document key information about the fit between reporting requirements
and the new release. This worksheet is intended to be the central reference
for reporting fit information throughout the project.
Complete one row for each current report. This spreadsheet should be
used to track standard reports to determine if they have changed in the
new release or are new to the application. Impact of the new release on
existing custom reports should also be recorded here.

Deliverable Components
Update the Master Report Tracking List from the initial implementation
using the Master Report Tracking worksheet information to assist you. If
the original documentation is not available or inadequate you may create
it using the following components:
Elements - General Tracking
Tracking Number - unique identifier assigned to each report
requirement

8 - 18 Requirements Mapping Update (MU)

EMM Method Handbook

 Analysis Activity
Report Filename/System Filename
Report Name/Report Title
Business Purpose
User Priority
User Run Frequency
User Name
User Phone Extension
User Email
User Position
User Division
Mapping
Assessment/Mapping Resolution
None
Build
Combine
Duplicate
Match
Modify
Not Needed
Assessment Comments
Combined into Tracking Number
Future Process Number
Function

Responsible
Business Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 19

MU.090

Confirm Integrated Business Solutions (Core)

During this task, confirm integrated business solutions by seeking
appropriate reviews and approvals. Use the standard acceptance form for
each proposed solution. Present the Business Requirements Scenarios
(RR.070), Business Requirements Mapping Forms (MU.020), and other
requirements mapping update deliverables to management for approval.
You can request approval for each business process area as it is mapped,
or you can get approval for an entire functional area (for example,
manufacturing, finance, distribution, and so on). Typically, individual
BRSs must be approved before larger groups of integrated processes are
approved. Approval as a group is required for each business area in large
projects composed of multiple business areas.
Internal customers must accept the assumptions surrounding the tests
and the test outputs. Try to limit the number of cross-process group
interdependencies as a way of simplifying internal communications and
reducing the number and complexity of support systems and the processes
required for their maintenance. If solutions are not accepted, the reasons
for non-acceptance should drive the revisions to the affected BRS and BRM
deliverables. Another cycle of process modeling, requirements definition,
and mapping will be necessary.

Deliverable
Use the Project Management Method (PJM) Acceptance Certificate to
document the approvals. Attach appropriate supporting documentation.

Deliverable Components
None

Responsible
Business Analyst

8 - 20 Requirements Mapping Update (MU)

EMM Method Handbook

MU.100

Update Process Narratives (Core)

During this task update existing process narratives from the initial
implementation. Process narratives are job-level descriptions of business
processes depicted in the Future Process Model (RR.030).
Suggestion: If process narratives are not available and AIM was
used during the initial implementation, you may want to reference
AIM for process narrative guidelines and templates.

Deliverable
Process Narratives define how the process is completed. A Process
Narrative
confirms business process design and how systems, files, tools, and
forms are to be used within each process step
creates prerequisite material for the User Guide, role-based user
training, and user certification or other types of readiness testing
Write one Process Narrative for each business process. In general, there
should be a one-to-one correspondence between BRSs (RR.070) and
Process Narratives.
A Process Narrative describes a business solution by explaining how the
new process supports the business requirement. Users, managers, and
developers use these essays to establish the framework for designing new
procedures, make organizational changes, and develop custom modules.
Attention: When writing these documents, make sure you are
clear about your principle audience. Write for a general
business audience. Refrain from making it a technical
document.

From BRS to Process Narrative

A Process Narrative represents a decomposition of a Business
Requirements Scenario (RR.070). Each business process step on a BRS can
be related to a series of procedures, application screens, reports, and

Oracle Method

Requirements Mapping Update (MU) 8 - 21

inquiries. The lowest level of detail for a BRS is the process step, which is
at an Elementary Business Function (EBF) level. Each process step
represents a work activity. Each activity is a set of procedural steps that
describes how to accomplish that step. Each activity is:
usually a set of operations (often including a system transaction)
logically grouped together
composed of manual, clerical, or online (system-assisted) types of
work
executed to achieve file/records update, notification, decisionsupport, and so on
performed by a person or piece of equipment (or combination)
Two examples of an activity are:
A receiving clerk inspects goods, updates a manual receiving log,
and enters a receiving transaction into the system.
A QC Inspector moves discrepant material to a holding area, hangs
a tag on the material, and records a transfer transaction into the
system.
An important quality objective is to verify process designs at the operator
job level. The Process Narrative deliverable is a step in that direction. All
Process Narrative development work is reusable downstream during
creation of training materials and user guides.
Use the Process Narrative worksheet in the EMM Master Tracking
Workbook to document key information about Process Narratives being
updated or developed. This worksheet is intended to be the central
reference for customization impact information throughout the project.
Complete one row for each Process Narrative.

Deliverable Components
Update the Process Narratives from the initial implementation using the
Process Narrative worksheet information to assist you. If the original
documentation is not available or inadequate you may create it using the
following components:
IdentificationDescribes the business process being documented

8 - 22 Requirements Mapping Update (MU)

EMM Method Handbook

 Inputs Inputs to the procedures, such as signals triggering the

procedure, and inputs acted on by the procedure
Controls Rules, policies, constraints, or references required by the
procedure
Mechanisms Identifies support tools required during execution
of the business process
Procedure Describes the detailed procedural steps for each
process step or task

Responsible
Business Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 23

MU.110

Revise Application Setups (Core)

Revise current application setup documentation during this task. The
new release may include new or changed functionality requiring
additional or modified setup data. As you map business requirements to
application features, you also begin to define the configuration you need to
support the solution. Your solution may include a number of user-defined
codes, system- and application-level parameters, and enabled features.
During this task, you revise setup decisions made during the initial
application implementation.
Oracle Applications include Oracle Application Implementation Manuals
that describe the set up steps in the appropriate sequence.
Attention: Pay close attention to the sequence of these setup
steps. In particular, the setup steps shown may assume that the
applications are set up in isolation, and thus do not account for
integrated or redundant setup steps for related or integrating
applications.

Critical Setup Parameters

Application parameters do not all carry the same importance to the
organization. Some are more critical in determining how the system will
operate. For instance, within the standard applications the following
parameters control significant processing features and functions:
Set of Booksan accounting ledger with a particular chart of
accounts, functional currency, and accounting calendar
Balancing Entitya division or other business unit for which you
prepare a balance sheet
Inventory Organizationa plant, warehouse, or other type of
business unit designed to provide control and transaction
functionality within one or more applications modules

Multi-Phase, Multi-Site Implementation

If the original implementation was multi-phase and multi-site, the
Application Setup Document is particularly susceptible to the risk of
change from one site to another. For those setups that are critical to

8 - 24 Requirements Mapping Update (MU)

EMM Method Handbook

process execution (and not just defaults), it is imperative that they be

managed closely to assure as much consistency as possible across sites
and phases. Given the number of setups and the importance of integrated
sequencing, close coordination and management is essential.

Deliverable
The deliverable for this task is the Application Setup Document. Use the
Application Setup Data worksheet in the EMM Master Tracking Workbook
to document key information about changes to the current application
setup data caused by migration to the new release. Update existing
documentation with changed setup data.
Setup documentation typically includes:
Application Configuration Tables
Create tables or spreadsheets that include major setup parameters and
codes. Create one table for each screen or zone. Let key users review this
document before preparing other environments. This method is
independent of how the mapping system is currently configured. It allows
you to make the change directly in the tables without altering the current
configuration and potentially causing integrity problems.
Low-Volume Conversion Activities
You can use the application setup tables or spreadsheets as source
documents for manual conversion activities. These spreadsheets help you
record the entries needed for production. Weigh the resource time needed
to enter this data against the total development time for automating the
conversion.
Standard Reports
Some standard applications provide setup reports that capture the input
data automatically. Simply run these reports and use them as source
documents for later setup activities.

Oracle Method

Requirements Mapping Update (MU) 8 - 25

Screen Shots
Take online screen shots of the standard applications displaying the
system and parameter selections. Be careful to capture the complete setup.
Many definition screens are made up of multiple screen pages (zones).

Deliverable Components
Update the Application Setups from the initial implementation using the
Application Setup Data worksheet information to assist you. Application
Setups contain master tables to control ownership, QA responsibility, due
dates, and approval sign off for each component setup. In addition, they
contain the detail table specific to each component. The deliverable
consists of the following components:
Common Setups The common setups contain tables to control for
the following setups:
Define Set Of Books
Define Period Types
Define Calendar
Define Currency
Define Daily Conversion Rate Types
Define Daily Rates
Open and Close Periods
Update System Profile Options
Application Setup Tables The Application setup tables contain a
master table with all of the setup steps for each of the Applications
selected, as well as a table for each setup step to use in capturing the
required information.
Key Flexfield The Key flexfield setup tables contain the following
worksheets:
Overall Key Flexfield
Key Flexfield Structure

8 - 26 Requirements Mapping Update (MU)

EMM Method Handbook

Responsible
Business Analyst

Oracle Method

Requirements Mapping Update (MU) 8 - 27

MU.120

Revise Security Profiles (Core)

Current security profiles are revised during this task. The new release may
include new or changed functionality requiring such changes.
The primary objective of this task is to verify that a security structure is
developed that naturally supports business processes. The primary
technique is to map business process steps and their agents (owners) with
the application-provided user responsibilities and make adjustments to
the responsibilities as required.
It is important to achieve a good menu structure so that application access
naturally supports the flow of information in the workplace. This will
also make learning the application easier.

Deliverable
The deliverable for this task is the Security Profiles. Identify roles (agents
from the Business Requirements Scenarios, RR.070) grouped together by
responsibility so that typical business functions, inquiries, and reports are
accessible.

Deliverable Components
Create a document containing each system user whose profile will change.
Record their name, role/title, department, and system user group
assignment.

Responsible
Business Analyst

8 - 28 Requirements Mapping Update (MU)

EMM Method Handbook

CHAPTER

Migrate Application
and Technical
Architecture (MA)
T

his chapter describes the Migrate Application and Technical

Architecture process.
Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 9-1
Oracle Method

Migrate Application and Technical Architecture Context

Migrate Application and Technical Architecture (MA) 9 - 1

Process Flow
Migrate Application and Technical Architecture (MA)
MA.020

MA.110

Perform
Architecture
Impact Analysis

Define Technical
Prototype
Subprojects

MU.005 - Release
Changes
Summary

Technical Prototype
Subprojects

MU.020 - Business Requirements

Mapping Forms

Application Architecture
Documents

MA.140
PJM.CR.010 - Establish Scope,
Objectives and Approach

Update
Application
Architecture

System Architect

Technical Architecture
Documents
ME.010 Customization
Impact Analysis

MA.160
Update Technical
Architecture

MA.180
RR.060 Business
Volume Requirements

Identify New
Performance Risks

MA.190
Performance Risk
Assessment

System Administrator

Figure 9-2

Update System
Management
Procedures

Migrate Application and Technical Architecture Process Flow

Diagram

9 - 2 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Approach
There are many business drivers for migrating from an existing production
environment to a new release of an Oracle Application. One is the
possibility of deploying information systems on the latest technology. The
new technology may include changes to application architecture,
technical architecture, or both.
The Migrate Application and Technical Architecture process identifies the
changes to the existing information systems architecture as a result of the
migration to a new application release. It also redesigns the overall
information systems architecture to reflect the new underlying package
application architecture. The original application implementation project
should have created an integrated architecture for the Oracle
Applications-based systems. Use the original implementation deliverables
and identify the fundamental drivers for the migration project along with
the new release technical changes. The system architects can then
determine the impact of the proposed release migration and establish any
major technical prototyping needed to verify or support the architecture
design changes.
All tasks in this process are optional. In the case of a migration between
two maintenance releases of Oracle Applications where there is little or no
change in features or technology, there may not be a need for any
architecture migration work. This process may then disappear from the
scope of the project. At the other extreme, the migration may be between
two major releases of Oracle Applications. Profound changes may have
occurred in the enabling technology of the applications, their database
architecture, and functionality. In this case, all of the tasks in this process
become mandatory, and a significant amount of work is necessary to
prepare the information systems architecture for operation under the new
release.

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 3

Architecture Drivers for Migrations

Changes in the underlying information systems architecture of Oracle
Applications in new releases can be a powerful reason to encourage a
business to undertake a migration project. The following list contains
examples of important Oracle architecture changes that can act as drivers
for a migration; however, this list is not exhaustive:
Implement a later release of Oracle Applications with supported Year
2000 compliance.
Implement Oracle Applications Multi-Organization capability to
support decentralized business processing.
Implement major globalization functionality and multi-lingual
capability.
Migrate to a new distributed processing model and/or align with
Oracles internet computing model.
Implement a later release of Oracle Applications that has enhanced
distributed application integration capabilities, for example more
and improved application programming interfaces (APIs) or
distributed processing infrastructure.
Migrate to a release of Oracle Applications that is certified to interoperate with the latest version of the Oracle Server and Oracle tools.
Each of these major changes may have implications for both the
application and technical architecture of the business information
systems.
Century Date Compliance
In the past, two-character date coding was an acceptable convention due
to perceived costs associated with the additional disk and memory storage
requirements of full four-character date encoding. As the year 2000
approached, it became evident that a full four-character coding scheme
was more appropriate.
In the context of the EasiPath Migration Method (EMM), the convention
Century Date of C/Date support rather than Year 2000 or Y2K support is
used. Coding for any future Century Date is now considered the modern
business and technical convention.

9 - 4 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Every applications migration team needs to consider the impact of the

century date on their migration project. As part of the migration effort, all
applications, processes, functions, customizations, data migration and
custom interfaces need to be reviewed for Century Date compliance.
Multi-Organization Architecture
The Oracle Applications Multi-Organization architecture is designed to
provide decentralized business operations within a single installation of
Oracle Applications with a single Oracle database instance. Prior to the
availability of Oracle Application releases supporting this type of
functional architecture across all financial, manufacturing, and
distribution applications, it was necessary to create custom application
architectures. These were based on multiple installs of financial subledger
applications to support the decentralized business model. Now that the
Multi-Organization architecture is available for all applications, there is a
clear driving force for companies to migrate to a supported application
functional architecture. The Multi-Organization architecture profoundly
affects the critical setup of the applications, and logical segregation of
business data and processing.
Globalizations and Multi-Lingual Capability
As Oracle Applications have expanded in functionality from one release to
the next, they have begun to support globalizations and multi-lingual
capability release features that are important for larger corporations that
operate in multiple countries. In older releases, country- or legislationspecific functionality might have required custom extensions. As this
functionality is increasingly supported in the standard applications, it can
be a powerful driver for companies. It motivates replacing significant
custom extensions or subsystems with base supported functionality, or
replacing manual processes.
A special example of this category is the need to support European
Monetary Union and the single European currency (known colloquially as
The Euro), in a transitional period with existing local currencies.
Distributed Processing and the Internet Computing Model
The earliest architecture for Oracle Applications was a simple character
mode, single host type with little distribution of intensive processing from
the server. That was superseded by a graphical 2-tier client-server
(SmartClient) architecture, and now a web-deployed, 3-tier architecture is

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 5

the new standard. The web deployed architecture promises easier and
significantly less costly system maintenance for client machines. The
potential savings in the total cost of ownership in a large corporation can
be significant enough to be a powerful driver in favor of a migration. In
addition, the web-deployed architecture is directly compatible with
Oracles internet computing model. This will enable a business to align
with Oracles strategic internet computing platform and take advantage of
other Oracle and third-party products that plug into the internet
infrastructure.
Distributed Application Integration
The larger implementations of Oracle Applications are usually integrated
with a set of legacy and third-party heterogeneous applications, and may
be implemented in an Oracle distributed database architecture as well.
Ease of application integration is a key concern for these businesses. Any
new application features, such as application programming interfaces
(APIs) or EDI-enabled transactions, that help alleviate the role of the IS
organization as system integrators, are of major importance. The cost of
migrating to the new release can be justified in terms of the reduction in
expense and risk of supporting custom developed interfaces between
applications.
Oracle Server and Tools
As newer releases of Oracle Applications become available they can
provide a business with an applications infrastructure based on the latest
versions of the Oracle tools and server. Newer versions of Oracle tools can
provide the IS organization with an improved development environment
for building custom applications and subsystems. Newer versions of the
Oracle Server can provide benefits for Oracle Applications; for example,
better scalability and database processing, as well as improved
management tools and technical infrastructure.

Application Architecture Changes

To assess whether or not a migration to a new release of Oracle
Applications will affect the information systems application architecture,
the project team will need to review the current application architecture
design as documented during the initial application implementation.
These would include:
conceptual architecture

9 - 6 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

 future application deployment

application functional architecture
application security architecture
logical application and database architecture
reporting strategy

Technical Architecture Changes

To assess whether or not a migration to a new release of Oracle
Applications will affect the information systems technical architecture, the
project team will need to review the current technical architecture design
as documented in the initial application implementation. These would
include:
conceptual architecture
system availability strategy
physical database architecture
hardware and network architecture
system capacity plan
system management procedures
Attention: The deliverables listed above are from the Application
and Technical Architecture process of AIM. If you did not use
AIM for your initial implementation, you must determine which
current documentation contains the equivalent information.

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

MA.020
MA.110

N
N

MA.140

Perform Architecture Impact Analysis

Define Technical Prototype
Subprojects
Update Application Architecture

Architecture Impact Analysis

Technical Prototype Subprojects Scope,
Objectives, and Approach
Application Architecture Documents

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 7

MA.160
MA.180
MA.190

N
N
N

Update Technical Architecture

Identify New Performance Risks
Update System Management
Procedures
Table 9-1

Technical Architecture Documents

Performance Risk Assessment
System Management Procedures

Migrate Application and Technical Architecture Tasks and

Deliverables

Objectives
The objectives of the Migrate Application and Technical Architecture
process are:
Identify the impact of the migration project on the existing
information systems architecture.
Identify any changes in the architecture of the new application
release that are profound, complex, or unfamiliar, and therefore
merit a separate prototyping study to enable the business to assess
the impact in more detail.
Verify that the architecture for the migrated systems is compatible
with the existing information systems framework and vision. If
necessary, modify the vision to reflect the altered state of the
architecture.
Redesign the business information systems architecture to
incorporate the changes in the new application release.
Verify that the information systems architecture constructed around
the new application release continues to be compatible with the
detailed business requirements.

Key Deliverables
The key deliverables for this process follow:

9 - 8 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Deliverable

Description

Application Architecture Documents

Documents describing
different aspects of the
application architecture of the
existing business information
systems from the original
application implementation
project. Update these
documents to reflect the target
application architecture of the
business after migrating to the
new application release.

Technical Architecture Documents

Documents describing
different aspects of the
technical architecture of the
existing business information
systems from the original
applications implementation
project. Update these
documents to reflect the target
technical architecture of the
business after migrating to the
new application release.

Performance Risk Assessment

Describes the performance

risks inherent in the business
information systems. The
project team updates this
deliverable to include the new
performance risks in the IS
architecture resulting from the
migration to the new
application release.

Table 9-2

Oracle Method

Migrate Application and Technical Architecture Key

Deliverables

Migrate Application and Technical Architecture (MA) 9 - 9

Key Responsibilities
The following roles are required to perform the tasks within this process:
Role

Responsibility

System Architect

Establish the future application

architecture of the new system after
migration. Meet with business
analysts to identify the impact of
business process changes on the
architecture. Translate the changes
into a revised application and data
architecture. Coordinate and lead the
development of an integrated
application and technical conceptual
architecture for the newly migrated
systems. The project team updates
these detailed technical design efforts
(for example, interfaces and custom
components), to provide compatibility
with the overall future application
architecture.

Business Analyst

Provide input about the key processes,

mapping decisions, and functionality
that will be used in the new release,
gather and communicate current and
future business volumes, and review
changes in the architecture.

Developer

Revise the logical application database

architecture including custom
extensions based on the logical
database architecture of the new
release.

9 - 10 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Oracle Method

Role

Responsibility

IS Manager

Provide input to the architecture

migration process regarding
technology changes that the business
wants to implement. Review changes
in key architecture deliverables.

Project Staff Member (IS)

Provide documents and information

about the operations procedures and
policies for existing Oracle
Applications and other systems. This
information covers applications,
databases, interfaces, hardware and
networks, system availability metrics,
and performance.

Network Administrator

Provide input into technical

architecture planning and design.
Review the network architecture and
network management and
maintenance procedures as
appropriate for the scope of the
migration changes.

Database Administrator

Provide input into logical database

design and technical architecture.
Review the database management and
maintenance procedures, database
disk capacity requirements, and
database level performance risks as
appropriate for the scope of the
migration changes.

Project Manager

Conduct detailed process planning

and assign tasks, establish roles, brief
client and staff, manage team, manage
changes, manage issues, and maintain
quality.

Migrate Application and Technical Architecture (MA) 9 - 11

Role

Responsibility

System Administrator

Provide input into technical

architecture planning and design.
Review the design of the overall
systems management and
maintenance procedures, hardware
capacity requirements, and system
performance risks as appropriate for
the scope of the migration changes.

System Architect

Identify scope and strategy for the

architecture migration process, meet
with project and business managers,
provide guidance during architecture
redesign, manage dependencies to
other processes, and secure acceptance
for architecture redesign work.

Technical Analyst

Provide input to the architecture

process about technical designs for
custom modules and functionality.

System Architect

Establish the future technical

architecture of the new system after
migration. Review the existing
technical environment, and identify
changes based on the technology and
capabilities of the new release. Review
system capacity plan, gather input,
and advise about performance risks.
Work with the application architect to
confirm that the technical architecture
supports the revised application and
data architecture.

User

Participate in interviews and provide

input about the requirements for
system performance and availability.

Table 9-3

Migrate Application and Technical Architecture Key

Responsibilities

9 - 12 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Critical Success Factors

The critical success factors of the Migrate Application and Technical
Architecture process follow:
proper consideration of architecture as a key determinant in the
success of the migration project
early identification of the scope of the architecture process within
the migration project as a whole
use of technical prototyping where the migration to the new release
will profoundly change the technical infrastructure
consideration of the changes in both business and technology as
factors affecting the migration of architecture
realistic consideration of the capabilities and the limitations of the
technology to be used
experienced application and technical architecture practitioners

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 13

MA.020

Perform Architecture Impact Analysis (Optional)

This task analyzes the architectural changes between the release of the
current production environment and the target migration release. It
develops the approaches and strategies for incorporating these technical
changes into the existing overall architecture design.
The scope of the technical and architectural changes depends on the
precise existing and target versions of the applications. As a general
principle, the wider the disparity between application release numbers,
the greater the technical changes involved. It is also more likely that the
existing information systems architecture will need significant rework.
For some types of migrations, the complete technology stack of the
applications can change. Examples of this type of migration would
include migration from a character mode host-based architecture or a
graphical, distributed, client-server architecture (Oracle SmartClient) to an
intranet, web-deployed architecture.
This task is optional. The initial migration scoping subproject will create a
first version of the project's Project Management Plan (PJM.CR.010), and
during this exercise the requirements and scope of the Migrate Application
and Technical Architecture process are assessed. If the exercise
determines that the overall information systems migration is very limited
in scale and impact, a formal process for migrating the architecture may
not be needed.

9 - 14 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Deliverable
The deliverable for this task is the Architecture Impact Analysis. It
identifies all of the new release changes that affect application and
technical architecture and assesses the impact of each change. Any
particular change between the application releases may result in one or
more architecture impacts, and each impacted area will be classified. For
example, a change in the distributed processing architecture of Oracle
Applications from graphical client-server to web-deployed could lead to
impacts in hardware architecture, system capacity planning, systems
management, IS training, and so on.
In addition to indicating the direct impact of the changes in the new
Oracle Applications release, this deliverable should document indirect
impacts on the existing information systems architecture. An upgrade in
Oracle Applications may trigger changes in other areas of the information
systems architecture, especially if Oracle Applications are integrated with
a number of other applications and systems.
Use the Architectural Impact Analysis worksheet in the EMM Master
Tracking Workbook to document changes to the current architecture due to
the application release migration.

Deliverable Components
Complete the following columns in the Architecture Impact Analysis
worksheet for this deliverable:
New Release Change Identification
New Release Change Description
Prototype
Impact Category
Impact Description
In Prototype Scope
Impact Degree
Other Documentation Reference

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 15

Responsible
System Architect

9 - 16 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

MA.110

Define Technical Prototype Subprojects (Optional)

This task identifies any areas of the target application release architecture
that are considered sufficiently new, complex, or risk-prone to require
separate investigation by prototyping. By separating this from the
technical upgrade testing, the architecture team can focus on the target
architecture alone rather than having to consider the additional
complication of the technical mechanism for the upgrade.
Prototyping work is not required for all migration projects. For example, a
simple upgrade to a new application maintenance release or an upgrade
without significant change in the information systems architecture would
not necessitate prototyping. Conversely, where there is significant change
in the architecture, the IS organization and migration project team may
wish to test the characteristics of the future technical environment before
beginning the migration. An example of this situation would be the
migration from a character mode application to a web deployed
application, or migration through one or more major application releases
with changes in database architecture and application data partitioning.

Deliverable
The deliverable for this task is the Technical Prototype Subproject Scope,
Objectives, and Approach. It is a document for the application or
technical architecture area that requires prototyping prior to full
implementation within the overall migration project.
The Technical Prototype Subproject Scope, Objectives, and Approach
deliverable is the means by which a technical subproject is described and
communicated to the migration project manager and IS organization. The
deliverable is not intended to be as detailed or comprehensive as the
Project Management Plan document for the parent migration project itself.
It should justify the creation of a separate subproject to prototype a
particular aspect of the future technical environment, and give a brief
description of the work needed to assess the unknown area.
If the architecture team has identified multiple areas that require
prototyping in subprojects, a single physical version of this deliverable
can describe all prototyping subprojects in an integrated fashion.

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 17

Deliverable Components
Select the Technical Prototype Subproject Scope, Objectives, and Approach
template to create the deliverable for this task. Use the following
components:
Introduction This should introduce the architecture subproject
and should identify the circumstances in the architecture project
that led to the identification of the need for an architecture
subproject. It should describe the sources that contributed to the
definition of the prototype subproject.
Scope This should describe the scope of the architecture
subproject in as much detail as possible. It should include a
description of the key milestones and the assumptions underlying
the subproject.
Objectives This should describe what the subproject is
attempting to achieve and how it will address the problem
statement. It should also identify the critical success factors for the
architecture subproject.
Approach This should describe the method to be used for the
prototyping of the subsystem or architectural component, the project
deliverables, subproject application and technical environment, and
the organization of the subproject.

Responsible
System Architect

9 - 18 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

MA.140

Update Application Architecture (Optional)

This task uses the Architecture Impact Analysis (MA.020) to update
existing application architecture requirements, analysis, and design
documents. For simple upgrades between maintenance releases of an
Oracle Application, no update of the fundamental architecture may be
needed. In other cases, the system architect will need to change the logical
information systems architecture based on the new product features of the
target release the business will implement.
This task is optional. As with the other tasks in this process, the scope
and extent of the application architecture changes depends on the precise
existing and target versions of the applications and the magnitude of
change in the architecture. For situations like a migration from a custom
application functional architecture with multiple application installations
to a decentralized multi-organization enabled architecture, the existing
systems will require major changes, and it is expected that a substantial
amount of application architecture redesign will be necessary.

Deliverable
The deliverable for this task is the Application Architecture Documents.
It is a single logical deliverable made up of revised versions of all of the
separate application architecture design documents impacted by the
migration project. The project team revises these to reflect the change in
the architecture as a result of the migration to the new Oracle release.

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 19

Deliverable Components
Update the application architecture documents from the initial
implementation. If the original documentation is not available or
inadequate you may create it by using the following components:
Conceptual Architecture This deliverable component is a
document that describes the conceptual architecture design for the
new system. It should describe and integrate the applications,
databases, hardware, and networks in the future system and show
the relationship between the layers and components of the new
architecture. This is a high-level view of the new total information
systems architecture.
Reporting Strategy This deliverable component is a document
that describes the reporting requirements for the information
systems and specifies the technical components of the architecture
needed to satisfy them.
Future Application Deployment This deliverable component is a
document that is a map for the future deployment of the
applications. It describes the physical deployment of applications
and databases across sites, data centers, and platforms to support
the architecture requirements and conceptual architecture.
Application Security Architecture This deliverable component is
a document that describes the key application and database
security architecture, incorporating the requirements generated by
the business mapping.
Application Functional Architecture This deliverable component
is a document that describes the key functional architecture of the
installed applications. It should specify the values and
relationships between the key application setup parameters and the
business functions.
Logical Application and Database Architecture This deliverable
component is a document that gives a blueprint for the logical
application installation and database architecture. It specifies all
installations of applications and databases incorporating the
analysis and design from functional mapping, custom application
and database extensions, security, and reporting systems. It does
not include the detailed physical layout of databases nor the
hardware and networks that are addressed in other specific tasks.

9 - 20 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

Responsible
System Architect

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 21

MA.160

Update Technical Architecture (Optional)

This task uses the Architecture Impact Analysis (MA.020) to update
existing technical architecture requirements, analysis, and design
documents. For simple upgrades between maintenance releases of Oracle
Applications no update of the fundamental architecture may be needed.
In other cases the system architect will need to change the physical
information systems architecture based on the new product features of the
target release which the IS organization will implement.
This task is optional. As with the other tasks in this process, the scope
and extent of the technical architecture changes depends on the precise
existing and target versions of the applications and the magnitude of
change in the architecture. For situations like a migration from a character
mode central host or SmartClient architecture to a web-deployed
architecture, the existing systems will require major changes. It is expected
that a substantial amount of technical architecture redesign will be
necessary.

Deliverable
The deliverable for this task is the Technical Architecture Documents. It
is a single logical deliverable made up of revised versions of all the
technical architecture design documents impacted by the migration
project. The project team revises these to reflect the change in the
architecture as a result of the migration to the new Oracle release.

Deliverable Components
Update the technical architecture documents from the initial
implementation. If the original documentation is not available or
inadequate you may create it by using the following components:

9 - 22 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

 Conceptual Architecture This deliverable component is a

document that describes the conceptual architecture design for the
new system. It should describe and integrate the applications,
databases, hardware, and networks in the future system and show
the relationship between the layers and components of the new
architecture. This is a high-level view of the new total information
systems architecture.
System Availability Strategy This deliverable component is a
document that describes the strategies and approaches
incorporated into the technical architecture to provide the level of
system availability that the business requires. It describes the
possible types of system failure and suggests a solution that
provides the desired level of protection against each failure.
Physical Database Architecture This deliverable component is a
document that describes the device- and operating system-level
architecture of the databases supporting the applications in the
architecture. It specifies storage structures and parameters
necessary for physical partitioning and management of all
identified database objects.
System Capacity Plan This deliverable component is a document
that describes the system capacity requirements for all key
hardware and network infrastructure components including
database servers, application servers, networks, client desktop
machines, and file servers.
Hardware and Network Architecture This deliverable
component is a document that describes the hardware and network
architecture of the information systems including deployment of the
key hardware and network components of the new system and their
relationship to the application and database architecture.

Responsible
System Architect

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 23

MA.180

Identify New Performance Risks (Optional)

This task identifies any new risks to the performance of the information
systems as a result of the migration to a new application or technical
architecture, and suggests appropriate risk mitigation strategies.
This task is optional. As with the other tasks in this process, the scope
and extent of the new performance risks depends on the precise existing
and target versions of the applications and the magnitude of change in the
architecture. For situations like a migration from a character mode central
host or SmartClient architecture to a web-deployed architecture, the
existing systems will require major changes, and it is expected that major
new performance risks could result, and should be managed according to
the project risk escalation procedures.

Deliverable
The deliverable for this task is the Performance Risk Assessment
Document. It is a revised version of the existing Performance Risk
Assessment document, which the system architect updates to reflect any
new system performance risks as a result of the migration to the new
Oracle release.
Use the New Performance Risk worksheet in the EMM Master Tracking
Workbook to document key information about the new performance risks
associated with the migrated system.

Deliverable Components
Update the Performance Risks document from the initial implementation
using the New Performance Risks worksheet to assist you. If the original
documentation is not available or inadequate you may create it using the
following components:
Executive Summary This component summarizes the analysis of
performance risk areas in the architecture, the results of the
analysis, and the recommended risk mitigation approaches for the
benefit of executive management or project sponsors.

9 - 24 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

 Overview
Risk Areas This component describes the performance risk areas
associated with the architecture design. It identifies the risk areas
and the reasons why there are concerns.
Risk Mitigation This component discusses the risk mitigation
approaches possible for the performance risk areas and indicates
which approach is preferred.

Responsible
System Architect

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 25

MA.190

Update System Management Procedures (Optional)

This task identifies any changes resulting from the migration that may
need to be included in the existing procedures and tools used by the IS
operations staff to manage the information systems. After you design the
procedures in this task, you need to test and refine them later in the project.
This must be completed before incorporating them into the system
management guide and training the system support staff.
This task is optional. As with the other tasks in this process, the scope
and extent of the changes depends on the precise existing and target
versions of the applications and the magnitude of change in the
architecture. If there is a robust systems management infrastructure in
place for the existing information systems, much of this will remain
unchanged for the new release. For example, database resource
management will probably be largely unaffected. However for situations
like a migration from a character mode central host or SmartClient
architecture to a web deployed architecture, new procedures for managing
the different tiers of hardware and software will be necessary.

Deliverable
The deliverable for this task is the System Management Procedures. It is
a revised version of the existing System Management Procedures
document, which the information systems administrators update to reflect
the change in the system management infrastructure as a result of the
migration to the new Oracle release.

Deliverable Components
Update the System Management Procedures from the initial
implementation. If the original documentation is not available or
inadequate you may create it using the following components:
Introduction This component introduces the deliverable and
describes the sources used in its compilation.

9 - 26 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

 System Management Standards and Policies This component

describes the standards and policies that apply to the system
management aspects of the architecture.
Planned Maintenance Schedule This component lists all planned
maintenance activities that will affect the system across system
management areas.
System Management Tools Summary This component
summarizes the tools that will be used for managing the production
systems across all system management areas.
Database Management This component discusses the procedures
and tools needed for managing data and databases in the new
system. It covers both normal maintenance of the databases, as well
as all possible failure scenarios. It also describes the tools that will
be needed, those developed in-house and those that are purchased.
Security and Accounts Management This component discusses
the procedures and tools needed for managing access to systems
and accounts, and for preventing and responding to security
breaches.
Scheduling Management This component discusses the
procedures and tools needed for management of the job scheduling
functions in the new systems, including interfaces and batch
scheduling. It considers both normal maintenance operations and
abnormal failure scenarios.
Hardware and Networks Management This component should
discuss the procedures and tools needed for management of the
hardware and network configuration of the new system. It includes
discussion of procedures for the change management and testing of
technical configurations.
Software Management This component discusses the procedures
and tools needed for management of all the software components of
the new system. It includes configuration management of clients
and servers, source control, and patch and upgrade procedures.
Capacity Planning and Performance Management This
component discusses the procedures and tools needed for
management of the performance of the new systems and the
proactive future planning of system capacity.

Oracle Method

Migrate Application and Technical Architecture (MA) 9 - 27

Responsible
System Administrator

9 - 28 Migrate Application and Technical Architecture (MA)

EMM Method Handbook

10
CHAPTER

Migrate Custom
Extensions (ME)
T

his chapter describes the Migrate Custom Extensions process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 10-1 Migrate Custom Extensions Context

Oracle Method

Migrate Custom Extensions (ME) 10 - 1

Process Flow
Migrate Custom Extensions (ME)
PJM.CR.010 - Establish
Scope, Objectives and Approach
Technical Analyst
ME.010
Perform
Customization
Impact Analysis

MU.005 - Release Changes

Summary

ME.020
Estimate Custom
Extension
Migration

ME.030
Module Designer
MU.030 - Business
Requirements
Mapping Forms

Database Designer

ME.060

Update Design
and Build
Standards

Identify Module
Design Changes

ME.050

ME.100

Identify Custom
Database Changes

Implement
Database Changes

Module
Source Code

ME.110
Custom Database Objects
Programmer

Update Custom
Modules

ME.120
Create Migration
Routines

Custom Migration Routines

Figure 10-2 Migrate Custom Extensions Process Flow Diagram

10 - 2 Migrate Custom Extensions (ME)

EMM Method Handbook

Approach
Migrate Custom Extensions focuses on updating current customizations
so that they work properly with the new application release. One of your
goals in this process should be to eliminate customizations and replace
them with standard functionality.
Custom software solutions include program modules that are designed,
built, and tested to enable new business functionality. Migrate Custom
Extensions addresses the updating of the custom design documents and
program modules. The Business System Testing process supports testing
of custom modules.
Working together, technical analysts and business analysts define the
specific changes required for custom extensions to bring them forward to
the new release. They also estimate the work effort required to implement
the changes. Module designers update the detailed design for each
module that will be changed. Programmers update the code based on the
detailed design documents.
Suggestion: The Migrate Custom Extensions process supports
updating existing customizations. It is not designed to support
the development of new customizations. If you need to do this
during the migration project and you used AIM for the initial
implementation, you can incorporate tasks from AIMs Module
Design and Build process into your project plan. The
techniques used to develop new customizations are different
from the updating process. Developing customizations
generally takes more time.

Oracle Method

Migrate Custom Extensions (ME) 10 - 3

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

ME.010

Customization Impact Analysis

ME.020
ME.030
ME.050
ME.060
ME.100
ME.110
ME.120

N
N
N
N
N
N
N

Perform Customization Impact

Analysis
Estimate Custom Extension Migration
Update Design and Build Standards
Identify Custom Database Changes
Identify Module Design Changes
Implement Database Changes
Update Custom Modules
Create Migration Routines
Table 10-1

Solution Document
Design Standards
Database Extension Design
Module Design
Custom Database Objects
Module Source Code
Custom Migration Routines

Migrate Custom Extensions Tasks and Deliverables

Objectives
The objectives of the Migrate Custom Extensions process are:
Update design documents for existing custom extensions impacted
by the new release of the applications.
Replace existing custom extensions with new application release
functionality, where applicable.
Preserve/create design solutions that can be easily maintained and
upgraded to future application releases.
Update/build custom extensions according to the design
specifications.

10 - 4 Migrate Custom Extensions (ME)

EMM Method Handbook

Key Deliverables
The key deliverables for this process follow:
Deliverable

Description

Custom Database Objects

Updates to the Oracle

application database with
changes to support existing
and new customizations.

Module Source Code

Updates to the existing custom

modules prior to migration
and development of new
custom modules.

Custom Migration Routines

Checklist of suggested steps to

support migration of
customizations.

Table 10-2

Migrate Custom Extensions Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:
Role

Responsibility

Developer

Design the database schema to

support custom extensions. Define,
estimate, and design custom
extensions. Build/update the custom
modules and perform initial unit tests.

Technical Analyst

Propose solutions and confirm

technical assumptions.

Table 10-3

Oracle Method

Migrate Custom Extensions Key Responsibilities

Migrate Custom Extensions (ME) 10 - 5

Critical Success Factors

The critical success factors of the Migrate Custom Extensions process
follow:
understand the functional requirements
propose appropriate changes based on new application release
product and technology expertise
possess expertise in the selected development tools
know the capabilities and limitations of the available technology
estimate and plan accurately
restrict and control changes
properly configure the development environment

10 - 6 Migrate Custom Extensions (ME)

EMM Method Handbook

ME.010

Perform Customization Impact Analysis (Optional)

This task identifies the impact of the upgrade on existing customizations.
During the initial application implementation and system maintenance,
customizations may have been developed for the current Oracle
Applications. Custom database tables, triggers, and stored procedures, as
well as customizations to forms and reports, may exist.
Determine the disposition for each existing customization. Some may
need to be migrated unchanged because new release changes do not
provide the needed functionality. It may be possible to eliminate others.
Some may require changes before migration.
Do not underestimate the time and resources needed for this task. A
thorough knowledge of new release functionality is necessary as well as a
complete understanding of the nature of existing customizations. There
may be little or no documentation for these customizations and few, if any,
people with this knowledge available to the project team.
Be cautious about custom functionality developed by user organizations
without the knowledge of the corporate information systems department.
End user use of report writing and query tools based on extracts from
Oracle tables is common. The Oracle tables, which are the source for such
extracts, may have changed in the new release. The extract process may
need to be treated as a customization whose disposition must be
determined.
Release Changes Summary (MU.005) is a key input to this task.

Deliverable
Use the Customization Impact Analysis worksheet in the EMM Master
Tracking Workbook to document key information about the impact of the
migration project on existing customizations. This worksheet is intended
to be the central reference for customization impact information
throughout the project.
Complete one row for each existing and new customization. Columns
provide a description of the customization, a reference to the Release

Oracle Method

Migrate Custom Extensions (ME) 10 - 7

Changes Summary (MU.005), impact status, monitoring of project activity

regarding this task, and references to other required documentation.

Deliverable Components
Complete the following columns in the Customization Impact Analysis
worksheet for this deliverable:
Customization Identification
Short Name
Current or New
Impact Degree
New Release Change Identification
Impact Description
Disposition
Reference to Other Documentation

Responsible
Technical Analyst

10 - 8 Migrate Custom Extensions (ME)

EMM Method Handbook

ME.020

Estimate Custom Extension Migration (Optional)

During this task, briefly describe the changes required to each
customization, including the disposition of individual modules, and
estimate the time required to implement the changes. Based on this
information, management must decide whether the benefits of the
customizations are worth the time and expense to update and maintain
them.
Summary level resource estimates for each customization are maintained
in the Customization Impact Analysis worksheet in the EMM Master
Tracking Workbook. The Customization Impact Analysis (ME.010) is the
source for summary customization information.
Normally there should be few, if any, new customizations with EMM.
Implementation of new applications or major new functionality within
applications currently in use is beyond the scope of EMM. In most cases,
to minimize risk, new implementations should be postponed until after the
upgrade. The only scenario requiring new customizations for an upgrade
project is when features have been changed or dropped and new modules
must be built to retain the current functionality.
Information provided during this task includes a summary of the business
requirement, description of the functionality gap or change, assumptions,
the recommended approach, and estimates of the effort required.
References to the Release Changes Summary (MU.005) and to other
documentation may be provided.
Warning: The estimating metrics contained in the template for
this deliverable are designed for new customizations. They may
not produce accurate results for updates to existing
customizations. Due to the wide range of possible types of
updates it is impractical to provide a single set of metrics. To
estimate updates, use judgment and tailor your estimates to suit
each specific case.
This task describes, at a high level, how each custom extension must
change and produces a Solution Document with associated resource and
time estimates.

Oracle Method

Migrate Custom Extensions (ME) 10 - 9

Suggestion: If the design information for your customization is

stored in Oracle Designer and you know what tables have
changed in the new release, you can run reports from the
Designer repository to determine what modules are affected.

Deliverable
The Solution Document records key information concerning the proposed
disposition of current customizations. For each customization, the
document provides a summary of the business requirement, description of
the functionality gap or release change, assumptions, recommended
approach, and resource estimates.
Prepare separate Solution Documents for complex customizations.
Consider tailoring this deliverable to address multiple straightforward
customizations in one document.
Solution Documents refer to the Customization Impact Analysis (ME.010),
which provides summary information about each customization. They
also refer to the Release Changes Summary (MU.005).

10 - 10 Migrate Custom Extensions (ME)

EMM Method Handbook

Deliverable Components
Select the Solution Document template to create the deliverable for this
task. Use the following component:
Introduction
Estimating Methodology
Business Issue Name
Requirements
Assumptions
Proposed Solution
Estimates
Recommended Staffing
EMM Master Tracking Workbook

Responsible
Technical Analyst

Oracle Method

Migrate Custom Extensions (ME) 10 - 11

ME.030

Update Design and Build Standards (Optional)

During this task, update existing standards that designers and developers
follow when updating existing customizations or developing new ones.
Clear and detailed standards promote consistency in designs and source
code.
Remember that one of your implementation objectives is to provide a
business solution that is easy to understand and use. The designer of a
program update may not be the developer and therefore it is important to
clearly communicate design specifications. Standards help communicate
these ideas effectively by establishing a common format that is complete
and easy to understand.
Do not duplicate what Oracle has already defined in standard
documentation. The Application Object Library Reference Manual includes a
chapter entitled Product Customization Standards which provides
basic standards and guidelines for customizing Oracle Applications.
Oracle Applications User Interface Standards includes detailed standards for
using Oracle Forms to design data entry and inquiry screens.
Each standard you define should provide a specific design, development,
documentation, or training benefit. Good standards help you do the
following:
Explain functionality to current and potential users.
Train users.
Support users when they have questions or problems.
Manage the development of customizations.
Produce high-quality program modules.
Work efficiently and cost-effectively.
Port application modules to different hardware and software
platforms.
Upgrade customizations to new releases of the Applications.

10 - 12 Migrate Custom Extensions (ME)

EMM Method Handbook

What Makes a Good Standard?

A good standard has the following qualities:
unambiguous clearly communicates the standard and is easy to
read and understand
consistent is consistent with existing standards and your
development philosophy
easy to use increases productivity; it is not awkward or
impractical

Deliverable
The Design Standards document is an updated collection of standards
established for custom development during the initial implementation.
This usually consists of distinct Design Standards and Build Standards
documents; however, during a migration project you should update them
together since many of the standards are interrelated.
Use the Design and Build Standards worksheet in the EMM Master
Tracking Workbook to document the key information about enhancements
to be made to existing Design and Build Standards.

Deliverable Components
Update the Design Standards from the initial implementation using the
Design and Build Standards worksheet to assist you. If the initial
documentation is not available or inadequate you may create it using the
following components:
Design standards, including:
topical essay standards
cosmetic standards
report standards
database change
naming

Oracle Method

Migrate Custom Extensions (ME) 10 - 13

 interface
Build standards, including:
development environment standards
forms coding
reports coding
SQL
PL/SQL
database trigger
migration routines
source code control

Responsible
Developer

10 - 14 Migrate Custom Extensions (ME)

EMM Method Handbook

ME.050

Identify Custom Database Changes (Optional)

During this task identify database changes to be implemented for the new
release. Generally, changes will be limited to custom database objects that
are used by custom modules. You may be able to migrate some existing
custom database objects to the new release unchanged. Others may need
updates or may be eliminated due to changes in the new release.

Deliverable
The Database Extension Design describes new tables, indexes, views,
synonyms, and other custom database objects to support customizations.
This deliverable integrates all the custom database objects into a single
document that supports all custom designs. You may choose to store the
entire database design in Oracle Designer or another CASE tool.

Deliverable Components
Update the Database Extension Design document from the initial
implementation. If the original documentation in not available or
inadequate you may create it using the components listed below. For each
custom database provide some or all of the following:
logical database design
index design
physical database design
flexfield design

Responsible
Developer

Oracle Method

Migrate Custom Extensions (ME) 10 - 15

ME.060

Identify Module Design Changes (Optional)

During this task update existing design documents to reflect the required
changes to custom modules.

Deliverable
The deliverable for this task is the Module Design. Design documents
from the initial implementation are updated to reflect required changes.
Each custom design document from the original implementation consists
of a Module Functional Design and a Module Technical Design. The
functional design describes the customization in user's terms while the
technical design provides the details that a programmer needs to code the
modules. Although they are written, reviewed, and approved individually
during the development of new customizations, you should update both
together when identifying changes for a migration project.
Suggestion: If existing design documentation is inadequate or
non-existent, but the code is otherwise well-documented, you
can use bottom-up analysis techniques to identify the required
coding changes and maintain a detailed log of update
instructions. Use this information to construct a functional
summary of the design implications for functional reviewers.
The Module Design includes components from both the functional and
technical design documents. You should also include a summary of
changes to help reviewers quickly understand how the updated design is
different.

Deliverable Components
Update the Module Design from the initial implementation. If the original
documentation is not available or inadequate you may create it using the
following components:
Functional Design includes:
summary of changes

10 - 16 Migrate Custom Extensions (ME)

EMM Method Handbook

 topical essay
form descriptions
report descriptions
Technical Design includes:
technical overview
form logic
report/program logic
database design
integration issues
installation requirements
implementation notes

Responsible
Developer

Oracle Method

Migrate Custom Extensions (ME) 10 - 17

ME.100

Implement Database Changes (Optional)

During this task, develop scripts to modify or create tables, indexes, views,
grants, and synonyms, to support changes in existing customizations to be
migrated to the new release. Run them in the development environment to
support updates to custom modules. You will also use these scripts
during Test Pre-Upgrade Steps (TE.085), Test Post-Upgrade Steps (TE.092),
Perform Pre-Upgrade Steps (PM.035), and Perform Post-Upgrade Steps
(PM.045).

Deliverable
The deliverable for this task is the Custom Database Objects. Update
custom database objects in the development environment and the
supporting scripts to apply the updates in the test and production
environments.

Deliverable Components
None

Responsible
Developer

10 - 18 Migrate Custom Extensions (ME)

EMM Method Handbook

ME.110

Update Custom Modules (Optional)

During this task, modify existing custom modules associated with the
current release that will be migrated to the new release.

Deliverable
The deliverable for this task is the Module Source Code. Existing custom
modules are updated to reflect new release changes prior to the migration
to the new release.

Deliverable Components
None

Responsible
Developer

Oracle Method

Migrate Custom Extensions (ME) 10 - 19

ME.120

Create Migration Routines (Optional)

During this task, develop automated functions and detailed instructions to
install customizations being migrated from the current release.
These routines need to be incorporated in Test Pre-Upgrade Steps (TE.085),
Test Post-Upgrade Steps (TE.092), Perform Pre-Upgrade Steps (PM.035),
and Perform Post-Upgrade Steps (PM.045).

Deliverable
The deliverable for this task is the Custom Migration Routines. These are
detailed instructions and automated functions that will migrate
customizations to the new release during an upgrade.

Deliverable Components
Select the Custom Migration Routines template to create the deliverable for
this task. Use the following components:
Migration Instructions
Pre-Migration Steps for Custom Objects pre-migration steps to be
performed before the customization migration is performed
Migration Steps steps to migrate the customization
Verification Checklist checklist to verify customization was
migrated correctly

Responsible
Developer

10 - 20 Migrate Custom Extensions (ME)

EMM Method Handbook

11
CHAPTER

Data Migration (DM)

T

his chapter describes the Data Migration process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 11-1 Data Migration Context

Oracle Method

Data Migration (DM) 11 - 1

Process Flow
Data Migration (DM)
DM.020
Technical Analyst

Manual Migration Strategy

Perform Data
Impact Analysis
PJM.CR.010 - Scope, Objectives,
and Approach
DM.050

DM.060

Perform Migration
Data Mapping

Design Manual
Migration Strategy

DM.080
Prepare Data
Migration Test
Plans

ME.050 - Database Extension

Design

Migration Test Procedures

DM.070
Module Designer

Design Migration
Programs
ME.030 - Design Standards

Validation Tested
Migration Programs
Programmer

DM.090
Develop Data
Migration
Programs

Tester

DM.100
Perform Data
Migration Unit
Test

DM.110
Perform Migration
Business Object
Test

DM.120
Perform Data
Migration
Validation Test

DM.130

System Administrator
Installed Data Migration Software

Install Data
Migration
Software

Figure 11-2 Data Migration Process Flow Diagram

11 - 2 Data Migration (DM)

EMM Method Handbook

Approach
The goal of the Data Migration process is to move and test all required
data from the current application instance for operation of the new system.
The essence of an Oracle Application migration is using the standard
Oracle data migration utilities. These tools automatically migrate
application data to the new release environment. There are certain cases
where additional tasks must be performed such as:
populating new tables or new columns with data to support new or
changed application features
providing new values for setup data
migrating data in custom tables to new tables in the standard
applications
migrating data in descriptive flexfields to new columns in the
standard applications
correcting errors in current production data before the new
production database is upgraded
The project team determines an overall strategy to meet the data migration
requirements, defining both automated and manual methods. The process
includes the evaluation of existing data; designing, coding and testing any
modules that are necessary; as well as the migration itself.

Oracle Method

Data Migration (DM) 11 - 3

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

DM.020
DM.050
DM.060
DM.070
DM.080
DM.090
DM.100
DM.110

N
N
N
N
N
N
N
N

DM.120

Data Impact Analysis

Migration Data Mapping
Manual Migration Strategy
Migration Program Design
Migration Test Procedures
Migration Programs
Unit Tested Migration Programs
Business Object Tested Migration
Programs
Validation Tested Migration Programs

DM.130

Perform Data Impact Analysis

Perform Migration Data Mapping
Design Manual Migration Strategy
Design Migration Programs
Prepare Data Migration Test Plans
Develop Data Migration Programs
Perform Data Migration Unit Test
Perform Migration Business Object
Test
Perform Data Migration Validation
Test
Install Data Migration Software
Table 11-1

Installed Data Migration Software

Data Migration Tasks and Deliverables

Objectives
The objectives of the Data Migration process are:
Determine data migration requirements not addressed by the
standard data migration tool.
Define a data migration strategy.
Design and build required data migration programs.
Verify that data migration programs result in valid data that
supports the needs of the business.

11 - 4 Data Migration (DM)

EMM Method Handbook

Key Deliverables
The key deliverable of this process follows:
Deliverable

Description

Manual Migration Strategy

The strategy for manual

migration of data to the new
release.

Migration Test Procedures

A document describing the

data migration test
procedures.

Validation Tested Migration Programs

Migration programs that have

passed validation testing.

Installed Data Migration Software

Data migration software

installed in the production
environment.

Table 11-2

Data Migration Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:

Oracle Method

Role

Responsibility

Technical Analyst

Perform data migration mapping and

assist in design of data migration
modules.

Developer

Define, estimate, and design data

migration modules. Code data
migration modules. Develop data
migration unit test specifications and
perform the test. Perform the data
migration, if required.

Data Migration (DM) 11 - 5

Role

Responsibility

Tester

Help with data migration business

object and validation testing to verify
data correctness.

Table 11-3

Data Migration Key Responsibilities

Critical Success Factors

The critical success factors of the Data Migration process follow:
clear understanding of the current system data, including
customization and interface requirements
adequate quality of current system data
clear understanding of the standard Oracle migration utilities
adequate business expertise to assure resulting data quality
clear business understanding of historical versus new application
release business needs
complete and documented new application release configuration
and design
well-defined data exception handling procedures
well-defined data validation and error handling procedures

11 - 6 Data Migration (DM)

EMM Method Handbook

DM.020

Perform Data Impact Analysis (Optional)

Assess the impact of the new release on data that will not be migrated by
Oracles standard data migration tools. The standard migration utility
provided with the application release automatically migrates data stored
in existing standard Oracle application tables. It will not migrate data
stored in custom tables or data in standard tables requiring clean-up.
New tables and new columns added to current tables may exist in the new
release to support enhanced functionality. Current table columns may
have been split into multiple columns to provide more detail or flexibility.
In these cases additional work will be required to populate these tables if
related new functionality is to be used.
EMM addresses application migrations. It does not address initial
application implementations or major new functionality within current
production applications.

Deliverable
Use the Data Impact Analysis worksheet in the EMM Master Tracking
Workbook to record key information about the impact of the migration
project on current production data and to track related project activities.
Complete one row for each data object that must be migrated to the new
release and is not automatically migrated by Oracles standard migration
utility.

Deliverable Components
Complete the following columns in the Data Impact Analysis workbook
for this deliverable:
Data Object
Description
Source Type

Oracle Method

Data Migration (DM) 11 - 7

 Source Name
Target Table
Target Column
Impact Degree
Reference to Other Documentation

Responsible
Technical Analyst

11 - 8 Data Migration (DM)

EMM Method Handbook

DM.050

Perform Migration Data Mapping (Optional)

Map current production data elements to the new release data structures.
Data to be mapped may be stored in standard Oracle tables or custom
tables. Only map standard table data elements if it has been determined
they are impacted by the migration. Use the Data Impact Analysis
(DM.020) to determine which standard table data elements are impacted.

Deliverable
Use the Migration Data Mapping document to record information about
the mapping of current production data elements to new release data
structures. Use one line for each data element to be mapped. Record the
data element name, target application table, target column, data type,
source table name, source column, default value, and validation rules. For
current release data elements split into multiple elements in the new
release, show all of the new elements on multiple lines with the same
source table column name.

Deliverable Components
Select the Migration Data Mapping template to create the deliverable for
this task. Use the following components:
Migration Mapping
Extract File Layout

Responsible
Technical Analyst

Oracle Method

Data Migration (DM) 11 - 9

DM.060

Design Manual Migration Strategy (Optional)

Develop a strategy for manually migrating production data to the new
release. In most cases Oracles standard migration utility will
automatically migrate data to the new release. In some cases the migration
utility is not appropriate. For example a single column in a current release
table may be split into multiple columns in the new application
functionality. If data for the new columns is not in electronic form and
cannot be derived, it may have to be manually entered into the upgraded
application as a post-upgrade step.
Use the Data Impact Analysis (DM.020) and Migration Data Mapping
(DM.050) to perform this task.

Deliverable
Use the Manual Migration Strategy to document the manual data
migration strategy for appropriate business objects.

Deliverable Components
Select the Manual Migration Strategy to create the deliverable for this task.
Use the following components:
Introduction
Business Object Description
Data Elements to be Migrated
Date Elements Not to be Migrated
Data Clean-up
Data Normalization
Data Defaults
Migration Responsibility
Migration Dates

11 - 10 Data Migration (DM)

EMM Method Handbook

 Migration Navigation

Responsible
Technical Analyst

Oracle Method

Data Migration (DM) 11 - 11

DM.070

Design Migration Programs (Optional)

In many cases, AutoInstall, Oracles standard migration utility, will
address all data migration needs. It will not migrate data stored in custom
tables. Table columns in the current release may have been split into
multiple columns in the new release to provide more granularity and
support enhanced functionality. In these cases, use the Migration
Program Design to provide developers with necessary information for
writing accurate data migration programs.
The Data Impact Analysis (DM.020) and Migration Data Mapping
(DM.050) should be used as input to this task.

Deliverable
Use the Migration Program Design to communicate the information
required by developers to build accurate data migration programs.

Deliverable Components
Select the Migration Program Design template to create the deliverable for
this task. Use the following components:
Introduction
Migration Assumptions
Approach
Processing Rules
Translation Rules
Filter Rules
Foreign Key Rules
Derivation Rules
Default Values
Download Program Logic

11 - 12 Data Migration (DM)

EMM Method Handbook

 Interface Table Creation Program Logic

Upload Program Logic
Translation Program Logic
Interface/Validation Program Logic

Responsible
Developer

Oracle Method

Data Migration (DM) 11 - 13

DM.080

Prepare Data Migration Test Plans (Optional)

If custom data migration software is necessary to augment Oracles
standard migration utility, develop test plans during this task addressing
unit, business object, and validation testing objectives.
Unit tests confirm that each module successfully completes the task it is
designed to perform. For example, a unit test should verify that a program
has extracted the expected number of rows from an existing custom table.
The business object test verifies that the quality of the data migrated to the
Oracle system is accurate and functions properly in the individual Oracle
Application. Validation testing verifies the migrated data performs
accurately within the entire suite of Oracle Applications.
Migration Data Mapping (DM.050) and Manual Migration Strategy
(DM.060) are used during this task.

Deliverable
Use the Migration Test Procedures to document the approach, steps,
expected results, and actual results for the three categories of data
migration tests: unit, business object, and validation.

Deliverable Components
Select the Migration Test Procedures template to create the deliverable for
this task. Use the following components:
Migration Unit Test a table for recording unit test results
Migration Business Object Steps a table for recording the
migration test plan
Migration Validation Test the procedure to validate the migration

Responsible
Technical Analyst

11 - 14 Data Migration (DM)

EMM Method Handbook

DM.090

Develop Data Migration Programs (Optional)

Develop custom data migration programs if Oracles standard data
migration must be supplemented. This can be due to custom tables or
production data cleanup requirements. It can also occur if current data
needs to map to altered table structures in the new release. These
programs may perform the following functions:
Create interface tables that store data to be migrated before the data
is validated and inserted into the production tables of the new
release.
Transfer data from custom tables into interface tables.
Perform translation, transformation, or manipulation of data before
moving it to production tables.
Interface and validate, then insert or update data into the Oracle
production tables.
Upload data to custom tables which may be part of custom
extensions in the new applications release.
Correct errors in production data prior to migration.
Suggestion: When the source data is already in an Oracle table,
all of the above steps can be combined into a single program or
SQL script and may not require a separate interface table.

Deliverable
Migration Programs are the automated program modules that migrate the
data. They could also be rule sets in a data-driven migration utility such
as EDMS or Smart DB Workbench.
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of all data
migration programs. Record the program name, program
description/purpose, input file name, programmer, comment, target table,
and script name. If an automated data migration tool (such as Smart DB
Workbench) is used, other information such as template name and Smart

Oracle Method

Data Migration (DM) 11 - 15

DB map filename may be required. There should be one document for each
business object being migrated.
Distribute the Data Migration Programs document to the following:
programmers who are building the migration scripts to use as a
worksheet to document their work
approvers responsible for signing off on this deliverable
the project manager
team members who will run these migration programs during the
final production migration

Deliverable Components
Select the Migration Programs template to create the deliverable for this
task. Use the following components:
Introduction
Download Programs
Interface Table Creation Programs
Upload Programs
Translation Programs
Interface Programs

Responsible
Developer

11 - 16 Data Migration (DM)

EMM Method Handbook

DM.100

Perform Data Migration Unit Test (Optional)

The purpose of unit testing is to validate that individual data migration
programs perform according to their specifications.
Conduct unit tests for the custom data migration programs being
developed to verify they work according to the specifications in the
Migration Program Design (DM.070). Use the Migration Test Procedures
(DM.080) for the unit test plan. These custom programs migrate data
required by the new release that is not automatically migrated by Oracles
standard migration utility.

Deliverable
The Unit Test Migration Programs are data migration programs that have
passed unit testing.

Deliverable Components
None

Responsible
Developer

Oracle Method

Data Migration (DM) 11 - 17

DM.110

Perform Migration Business Object Test (Optional)

Business object testing verifies that the quality of the data migrated to the
new Oracle system is accurate and functions properly in the individual
Oracle Application to which it has been migrated.
Conduct business object tests for the custom data migration programs
being developed to verify they work according to the specifications in the
Migration Program Design (DM.070). Use the business object testing plan
from the Migration Test Procedures (DM.080). These custom programs
migrate data required by the new release that is not automatically
migrated by Oracles standard migration utility.

Deliverable
The Business Object Tested Migration Programs are migration programs
that have passed business object testing.

Deliverable Components
The deliverable for this task is a tool for tracking the progress of the
development effort. It can be used to document the status of all migration
programs being tested. Select the Migration Business Object Test template
to create the deliverable for this task. Use the following components:
Migration Business Objects Test Checklist
Problem Report Log

Responsible
Tester

11 - 18 Data Migration (DM)

EMM Method Handbook

DM.120

Perform Data Migration Validation Test (Optional)

Validation tests verify that the migrated data performs correctly for the
entire suite of Oracle applications. Conduct the tests using Migration Test
Procedures (DM.080).

Deliverable
The Validation Tested Migration Programs are migration programs that
have passed validation testing.

Deliverable Components
The deliverable for this task is a tool for tracking the progress of the
development effort. It can be used to document the status of all migration
programs being tested. Select the Data Migration Validation Test template
to create the deliverable for this task. Use the following components:
Migration Validation Test Checklist
Problem Report Log

Responsible
Tester

Oracle Method

Data Migration (DM) 11 - 19

DM.130

Install Data Migration Software (Optional)

Perform and document the installation of the data migration programs in
the production environment. This task presumes that the migration
programs have been successfully tested. If you are using an automated
migration tool, this task requires that you install the software, tested
migration templates, and required migration maps.

Deliverable
Installed Data Migration Software is data migration software installed in
the production environment.

Deliverable Components
None

Responsible
System Administrator

11 - 20 Data Migration (DM)

EMM Method Handbook

12
CHAPTER

Documentation (DO)
T

his chapter describes the Documentation process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 12-1 Documentation Context

Oracle Method

Documentation (DO) 12 - 1

Process Flow

Documentation (DO)
ME.060 - Module Design

DO.100
Update User
Reference manual

DO.140
Update Online
Help Text
MU.100 - Process Narratives
DO.110
User Guide

Update User
Guide

Technical
Writer
DO.120
Update Technical
Reference Manual

ME.110 - Module Source

Code

DO.130
Update System
Management
Guide
MA.160 - Technical Architecture Documents
MA.190 - System Management Procedures

System Management Guide

Figure 12-2 Documentation Process Flow Diagram

12 - 2 Documentation (DO)

EMM Method Handbook

Approach
The Documentation process begins with an early review of existing
materials. Using detailed documents from the project, the writing staff
updates or develops user and technical material that is tailored to the
upgrade project. A complete documentation set includes a System
Management Guide, User Guide, User Reference Manual, Technical
Reference Manual, and Online Help Text. If new documentation must be
developed, producing prototypes for each document encourages early
consensus on documentation design, format, and content.
Ideally, the documentation process will update existing documentation
created during the application implementation project and maintained
during production. If such documentation does not exist, this process
creates it.

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

DO.100
DO.110
DO.120
DO.130
DO.140

N
Y
N
N
N

Update User Reference Manual

Update User Guide
Update Technical Reference Manual
Update System Management Guide
Update Online Help Text

User Reference Manual

User Guide
Technical Reference Manual
System Management Guide
Online Help Text

Table 12-1

Oracle Method

Documentation Tasks and Deliverables

Documentation (DO) 12 - 3

Objectives
The objectives of the Documentation process are:
Update existing documentation affected by the upgrade or create
such documentation, if it does not exist. Only documentation
dealing with the changes between the current and new release
needs to be developed.
Update or produce a reference that shows the users how to use
custom extensions (User Reference Manual).
Update or produce a set of procedures for using the new application
release in response to day-to-day business events (User Guide).
Update or assemble the documents that describe the technical
details of custom extensions (Technical Reference Manual).
Update or produce a set of procedures for managing the new
application release system (System Management Guide).
Update or produce an online reference that explains the application
functionality and the procedures for using the application in
response to day-to-day business events (Online Help Text).

Key Deliverables
The key deliverable of this process follows:
Deliverable

Description

User Guide

Documents user procedures for the

upgraded application

System Management Guide

An updated System Management

Guide that reflects the upgraded
application.

Table 12-2

12 - 4 Documentation (DO)

Documentation Key Deliverables

EMM Method Handbook

Key Responsibilities
The following role is required to perform the tasks within this process:
Role

Responsibility

Technical Writer

Design, write, edit, and review

documentation deliverables.

Table 12-3

Documentation Key Responsibilities

Critical Success Factors

The critical success factors of the Documentation process follow:
availability of skilled technical writers
early involvement of technical writers
user input to the procedures
project team commitment to the time and resources required to
produce quality documentation
verification that the documentation accurately reflects the final
implementation of the new application release

Oracle Method

Documentation (DO) 12 - 5

DO.100

Update User Reference Manual (Optional)

In this task, update the current User Reference Manual to reflect changes to
custom extensions. It is a companion document to the standard Oracle
User Reference Manuals for Oracle Applications. A single User Reference
Manual can incorporate all custom modules.
Material to draft a User Reference Manual should be obtained from the
functional design components of the Module Design (ME.060). One
technique for assembling this document is to simply combine the relevant
portions of the module designs into a single volume.

Deliverable
The deliverable for this task is an updated User Reference Manual. It
contains the detailed descriptions of each custom extension function. The
User Reference Manual provides system information to the user
community and it should include all changes that were made for the
upgrade project.

Deliverable Components
Update the User Reference Manual from the initial implementation. If the
original documentation is not available or inadequate you can create it
using the components listed below. For each customization include:
Scope, Approach, and Method Document the scope of the
customization and how business needs were met.
Business Needs Describe the business needs that the
customization satisfies.
Major Features Describe the major features of the customization.
Definitions Define or update terms used in other deliverable
components.
User Procedures Document detailed procedures required to use
the customization.

12 - 6 Documentation (DO)

EMM Method Handbook

 Technical Overview Provide an overview of the technical

specifications of the customization.
Appendix Include screen shots, report samples, and other
materials to document the customization functionality.

Responsible
Technical Writer

Oracle Method

Documentation (DO) 12 - 7

DO.110

Update User Guide (Core)

In this task, update the User Guide, which documents the final set of
procedures for using the upgraded application. It is an instruction
manual for the business and is the basis for training new application
users. This task should be performed in parallel with the Business System
Testing tasks.

Deliverable
The User Guide is a comprehensive source for answering daily
procedural questions and for training new users.

Deliverable Components
Update the User Guide from the initial implementation. If the original
documentation is not available or inadequate you can create it using the
components below. For each business procedure provide:
Scope, Approach, and Method Document the scope of the
procedure and the general philosophy behind your business
approach.
Business Needs Describe the business needs that the procedure
addresses.
Major Features Describe the major features of the applications
that the procedure uses.
Definitions Define or update terms used in other deliverable
components.
User Procedures Document detailed procedure steps.
Technical Overview Provide an overview of the technical
specifications of the application features and customizations.
Appendix Include screen shots, report samples, and other
materials to document the new module or customization
functionality.

12 - 8 Documentation (DO)

EMM Method Handbook

Responsible
Technical Writer

Oracle Method

Documentation (DO) 12 - 9

DO.120

Update Technical Reference Manual (Optional)

Update the Technical Reference Manual which contains information
about customizations and extensions for the new release. This
information is intended to supplement the standard Oracle Technical
Reference Manuals and is consistent in format and content to Oracle
Documentation Standards. The Technical Reference Manual is a reference
document for application maintenance personnel.
The duration of this task depends on the extent of the technical changes
that were made during testing.

Deliverable
The Technical Reference Manual deliverable helps you provide
information regarding the custom modules and extensions. It does not
replace the standard Oracle Technical Reference Manual. Do not
duplicate information from the Oracle manual during your update.
Although this manual is directed at technicians, there may be a wide
range of knowledge and experience within the technical group. Be sure
your text has sufficient information to be a valuable guide to experienced
technicians, but can also be understood by less experienced staff as well.

Deliverable Components
Update the Technical Reference Manual from the initial implementation.
If the original documentation is not available or inadequate you can create
it. Develop a separate section for each customization and module.

Responsible
Technical Writer

12 - 10 Documentation (DO)

EMM Method Handbook

DO.130

Update System Management Guide (Optional)

Updating the System Management Guide helps support the ongoing
success of the application maintenance staff. They will depend on the
accuracy of the updated information presented in this document. This
task will require the active involvement of the IS support staff during this
stage.
The primary input to this task is System Management Procedures
(MA.190). In this task you are formally publishing the content in this
earlier deliverable and including any necessary refinements.
This task may be unnecessary for some upgrade projects if there are no
changes impacting this guide.

Deliverable
The deliverable for this task is an updated System Management Guide. It
contains the final set of procedures for operating the application system
and serves as a reference guide for system administrators and the internal
support staff.

Deliverable Components
Update the System Management Guide from the initial implementation. If
the original documentation is not available or inadequate you can create it
using the following components:
Introduction
System Management Standards and Policies
Planned Maintenance Schedule
System Management Tools Summary
Database Management
Security and Accounts Management
Scheduling Management

Oracle Method

Documentation (DO) 12 - 11

 Hardware and Networks Management

Software Management
Capacity Planning and Performance Management

Responsible
Technical Writer

12 - 12 Documentation (DO)

EMM Method Handbook

DO.140

Update Online Help Text (Optional)

In this optional task, you update the Online Help Text to reflect changes in
the upgraded system using:
standard Application Object Library forms to create Online Help
Text
updated User Reference Manual as input
updated User Guide as input
When implementing Online Help Text, you should consider the following:
process instructions versus definitions
technical instructions to be followed by users
navigation to alternative help
accurate references
time required to execute help text
validation of online help of forms or fields

Deliverable
The deliverable for this task is the Online Help Text. It helps you provide
online assistance to system users. Follow the standard procedures
recommended by Oracle Applications.

Deliverable Components
Update the Online Help Text from the initial implementation. If the
original documentation is not available or inadequate you may create it.
There are two types of Online Help Text:
form, zone, and field help for custom forms as outlined in the User
Reference Manual
process-oriented help specific to the business

Oracle Method

Documentation (DO) 12 - 13

Responsible
Technical Writer

12 - 14 Documentation (DO)

EMM Method Handbook

13
CHAPTER

Business System
Testing (TE)
T

his chapter describes the Business System Testing process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 13-1 Business System Testing Context

Oracle Method

Business System Testing (TE) 13 - 1

Process Flow
Business System Testing (TE)
TE.010
Develop Test
Strategy

Project Manager
PJM.CR.030 - Establish
Management Plans

Testing Strategy

Module Designer

TE.020

TE.030

Update Unit Test

Scripts

Update Link Test

Scripts
ME.060 - Module
Design

Business Analyst

Users

TE.070
Perform Unit
Testing

Programmer
ME.110 - Module
Source Code

TE.080
Tester

MU.110 - Application Setup Document

MU.120 - Security Profiles

Perform Link
Testing

TE.085
Technical Analyst

ME.120 - Custom Migration Routines

DM.120 - Validation Tested Migration Programs

TE.091

Test Pre-Upgrade
Steps

Test Software
Upgrade

Figure 13-2 Business System Testing Process Flow Diagram

13 - 2 Business System Testing (TE)

EMM Method Handbook

Business System Testing (TE)

Project Manager
PM.030 - Detailed Transaction
and Contingency Plan

Module Designer

MU.100 - Process
Narratives
TR.090 - Trained Users

TE.040
Business Analyst

Update System
Test Scripts

TE.050

TE.100

Update Systems
Integration Test
Scripts

Prepare Key Users

for Testing
PM.050 - Configured
Applications
TE.055

TE.135

Update User
Acceptance Test
Scripts

Users

Programmer

User Acceptance
Test Scripts

Perform User
Acceptance test,
Test System

TE.140
Perform User
Acceptance Test,
Production System

Post-Upgrade
Checklist
TE.140 - Acceptance Results

Tester

Technical Analyst

TE.110

TE.130

Perform System
Testing

Perform Systems
Integration Testing

TE.092
Test Post-Upgrde
Steps

TE.093
Perform PostUpgrade
Reconciliation
Testing

TE.096
Review Upgrade
Test Results

Figure 13-2 Business System Testing Process Flow Diagram (cont.)

Oracle Method

Business System Testing (TE) 13 - 3

Approach
The Business System Testing process is an integrated approach to testing
the quality of all elements of the application system in the pre- and postupgrade environment. It emphasizes a common planning approach for all
types of testing and advocates the re-use of deliverable components. It
focuses on preparing for all types of testing early in the upgrade process so
that you can link updated testing scenarios back to updated business
requirements. It supports utilizing common testing information including
updated data profiles. Finally, it promotes testing coordination and
minimizes duplication of test preparation and execution efforts.

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

TE.010

Develop Test Strategy

TE.020
TE.030
TE.040
TE.050

N
N
Y
N

TE.055
TE.070
TE.080
TE.085
TE.091
TE.092
TE.093

Y
N
N
Y
Y
Y
Y

TE.096
TE.100
TE.110

Y
Y
Y

Update Unit Test Scripts

Update Link Test Scripts
Update System Test Scripts
Update Systems Integration Test
Scripts
Update User Acceptance Test Scripts
Perform Unit Testing
Perform Link Testing
Test Pre-Upgrade Steps
Test Software Upgrade
Test Post-Upgrade Steps
Perform Post-Upgrade Reconciliation
Testing
Review Upgrade Test Results
Prepare Key Users for Testing
Perform System Testing

Testing Strategy section of CR.010

Scope, Objectives and Approach
Unit Test Scripts
Link Test Scripts
System Test Scripts
Systems Integration Test Scripts

13 - 4 Business System Testing (TE)

User Acceptance Test Scripts

Unit Tested Modules
Link Tested Modules
Pre-Upgrade Checklist
Upgraded Applications
Post-Upgrade Checklist
Reconciliation Test Report
Upgrade Test Analysis
Prepared Users
System Tested Applications

EMM Method Handbook

ID

Core

Task Name

Deliverable Name

TE.130
TE.135

N
Y

Integration Tested Systems

User Acceptance Test Report

TE.140

Perform Systems Integration Testing

Perform User Acceptance Testing, Test
System
Perform User Acceptance Testing,
Production System
Table 13-1

Acceptance Results

Business System Testing Tasks and Deliverables

Objectives
The objectives of the Business System Testing process are:
Establish an approach to testing that addresses all aspects of the
application release migration process including the software
upgrade itself and the pre-upgrade/post-upgrade steps.
Update scripts for all testing activities early in the custom extension
migration life-cycle.
Build on and reuse initial testing deliverables, including test scripts
and test data, in subsequent testing tasks.
Produce a thoroughly tested, high-quality new release application
system.

Key Deliverables
The key deliverables of this process follow:

Oracle Method

Deliverable

Description

User Acceptance Test Scripts

Documents the user acceptance test

procedures.

Post-Upgrade Checklist

Documents standard Oracle upgrade

steps and any custom upgrade steps
for the migration of custom extensions
and data.

Business System Testing (TE) 13 - 5

Deliverable

Description

User Acceptance Test Report

Documents the approach and result of

user acceptance testing in the test
environment.

Acceptance Results

Documents the approach and results

of user acceptance testing of the
production environment.

Table 13-2

Business System Testing Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:
Role

Responsibility

Project Manager

Provide high-level direction for testing

all components of the upgraded
applications.

Business Analyst

Support testing of the business

processes in the migrated applications
system.

System Architect

Support testing of the upgraded

applications systems integration with
other systems.

Developer

Update and execute unit and link test

scripts. Provide support during the
system test, the systems integration
test, and the user acceptance tests by
answering questions and helping
resolve potential issues.

13 - 6 Business System Testing (TE)

EMM Method Handbook

Role

Responsibility

Technical Analyst

Support testing of pre-upgrade,

software upgrade, and post-upgrade
migration steps. Assist in postupgrade validation testing and review.

Tester

Update and execute system test and

systems integration test scripts.

Table 13-3

Business System Testing Key Responsibilities

Critical Success Factors

The critical success factors of the Business System Testing process follow:
a project plan that endorses an integrated testing approach
adequate resources for test script updating and execution and
support of testing environments
adequate tools, including properly configured environments and
well-trained users, to support test script updating and execution
updated unit and link test scripts that are solid, integral
components of subsequent testing deliverables
updated test scripts that are based on business process
requirements
reliable, timely (migrated) test data for each testing environment
thorough execution of all business system and systems integration
tests
independent QA testing and quality sign-off on all testing activities

Oracle Method

Business System Testing (TE) 13 - 7

TE.010

Develop Test Strategy (Core)

Define the strategy and goals for testing. This includes the types of tests,
the number of iterations, the staffing assignments, and the expected
deliverables. For upgrades, the number of upgrade test iterations and the
differing prerequisites for each is important. For example, the first
upgrade test may be performed against a vanilla environment with no
customizations using the standard upgrade steps; therefore, updated
customizations and migration routines are not needed. The final upgrade
test is performed against a copy of the production instance with all
customizations and integrates all special upgrade steps for
customizations and data migration needs.

Deliverable
The Testing Strategy documents the strategy to be used for testing during
the upgrade project. Types of testing for upgrade projects include:
custom software testing addressing updated current
customizations, data migration programs, updated interface
programs, and production data clean-up programs
upgrade process testing comprised of pre-upgrade steps, running
Oracles migration utility, and post-upgrade steps
business process testing to validate that business requirements will
be met by the application system

Deliverable Components
Use the Testing Strategy section of the Project Management Plan
(PJM.CR.030) to document the strategy. Include the following:
strategy overview including relevant background, the testing
approach, critical success factors, and the risks associated with not
performing adequate testing
types and purpose of each testing task
deliverables for each testing task

13 - 8 Business System Testing (TE)

EMM Method Handbook

 testing tools overview

problem management overview
detailed acceptance criteria for testing

Responsible
Project Manager

Oracle Method

Business System Testing (TE) 13 - 9

TE.020

Update Unit Test Scripts (Optional)

Update unit test scripts for customizations and interfaces you are
migrating to the new release. A unit test confirms that a single module
(form, report, concurrent program, database trigger, and so on) functions
correctly by itself. These scripts should already exist from the initial
implementation, but you can create new scripts as needed. Use these
scripts during Perform Unit Testing (TE.070).

Deliverable
Create Unit Test Scripts in the form of standard checklists and step-bystep instructions to test specific functionality. Provide one Unit Test Script
for each custom module to be tested.

Deliverable Components
Select the Unit Test Scripts template to create the deliverable for this task.
Use the following components:
Overview
Form Identification
Functional Test The checklist defines categories of tests to
validate the features of the module (inserting a record, querying a
record using Query Mode). Design standards will determine many
of these and they will be common for all modules of the same type.
For example, you can use the same checklist to evaluate all forms for
adherence to cosmetic standards.
Cosmetic Standards Tests
Test Specification The Test Specification details the necessary
steps to test the unique logic of the custom module. Create as many
test specifications as you need to evaluate all of the logic
combinations. Since your goal is to exercise all logic, your tests
need not reflect real business situations. In fact your tests may be
very artificial, so that they test the maximum amount of
functionality in the fewest possible passes.

13 - 10 Business System Testing (TE)

EMM Method Handbook

 Data Profile The Data Profile specifies the test data required to
execute the unit test specification. Typically, you develop multiple
data profiles for execution with each test specification. By defining
a Unit Test Specification for each logic path and a Data Profile for
each data combination, you maximize the reusability of your tests
and the coverage they provide.
Defect Log The Defect Log facilitates the tracking of each defect
that the tester uncovers during unit testing. It also contains the
related correction recorded by the owning developer once they
correct the error.

Responsible
Developer

Oracle Method

Business System Testing (TE) 13 - 11

TE.030

Update Link Test Scripts (Optional)

Update current link test scripts for customizations and interfaces you are
migrating to the new release. A link test confirms that several modules
that make up a customization work together correctly and integrate
properly with other standard modules in a business flow. These scripts
should already exist from the initial implementation, however, you can
create new scripts as needed. Use these scripts during Perform Link
Testing (TE.080)

Deliverable
Create Link Test Scripts to communicate the procedures for conducting
link testing, the testing of connections, or links, between modules.

Deliverable Components
Select the Link Test Scripts template to create the deliverable for this task.
Use the following components:
Link Test Specifications The Link Test Specification defines test
script execution and involves the functional features of an
integrated set of modules. You may have more than one Link Test
Specification if you need to test more than one response path
through the process that the customization supports.
Data Profile The Data Profile describes the business conditions or
seeded data that you need to link test the customization. You may
have more than one Data Profile if the logic within the modules is
sensitive to data conditions. In particular, if one module calls
another, and the called module can only accept arguments within a
particular range of values, you should have data profiles that
include data both within and outside the range.
Defect Log A Defect Log facilitates tracking of each defect
uncovered during link testing. It also contains the related fix
documentation recorded by the owning developer once they have
corrected the error.

13 - 12 Business System Testing (TE)

EMM Method Handbook

Responsible
Developer

Oracle Method

Business System Testing (TE) 13 - 13

TE.040

Update System Test Scripts (Core)

Update system test scripts that were developed for the initial
implementation to reflect process changes, new functionality, and updated
customizations in the new release. Your focus should be on those aspects
that have changed and to make sure that all customizations work together
in an integrated environment. You also may want to review test scripts for
process areas that you expect to work in the same way as the prior release.
Use these scripts during Perform System Testing (TE.110) and Update User
Acceptance Test Scripts (TE.055).

Deliverable
Use System Test Scripts to record system test scripts that will guide
system testing.

Deliverable Components
Select the System Test Scripts template to create the deliverable for this
task. Use the following components:
Test Sequences The Test Sequences determine the order in which
to execute the System Test Specifications to simulate real life
business transaction processing.
Test Specification The Test Specification defines test script
execution and encompasses the functional features of an entire
business process. You may have more than one System Test
Specification if you need to test more than one response path
through the business scenario.
Data Profile The Data Profile describes the business conditions or
seeded data necessary in order to system test the business process.
You may have more than one Data Profile if you need to test more
than one response path through the business process.
Defect Log

13 - 14 Business System Testing (TE)

EMM Method Handbook

Responsible
Business Analyst

Oracle Method

Business System Testing (TE) 13 - 15

TE.050

Update Systems Integration Test Scripts (Optional)

Update systems integration test scripts for interfaces to legacy systems,
third-party applications, or nonstandard interfaces between multiple
installations of Oracle Applications. Use these scripts during Perform
Systems Integration Testing (TE.130) and Update User Acceptance Test
Scripts (TE.055).

Deliverable
Use the System Integration Test Scripts to record systems integration test
scripts. When developing Systems Integration Test Scripts, focus on the
following areas:
extending the system test scripts to include external systems data
and processing validation
testing the technical infrastructure using performance-related test
scripts that focus on integration points between the systems

Deliverable Components
Select the Systems Integration Test Scripts template to create this
deliverable. Use the following components:
Test Sequences The Test Sequences determine the order in which
to execute the Systems Integration Test Specifications to simulate
real life business transaction processing across and between system
boundaries.
Test Specification The Test Specification defines test script
execution and encompasses a business process that spans one or
more systems. You may have more than one System Integration Test
Specification for each script if you need to test more than one
response path through the business process.
Data Profile The Data Profile describes the business conditions or
seeded data necessary to test the integration points between
systems. You may have more than one Data Profile if you need to
test more than one response path through the business process.

13 - 16 Business System Testing (TE)

EMM Method Handbook

 Defect Log

Responsible
System Architect

Oracle Method

Business System Testing (TE) 13 - 17

TE.055

Update User Acceptance Test Scripts (Core)

Update User Acceptance Test Scripts confirm that the system meets user
requirements and is ready for production use. The development of User
Acceptance Test Scripts is the responsibility of the user community. The
formal project team can provide advice and guidance to the users on what
is required. Users may choose to adopt the system and systems integration
test scripts that the project team has developed, in addition to scripts that
test standard functionality.

Deliverable
Use the User Acceptance Test Scripts to document user acceptance test
scripts that will guide user acceptance testing. The contents of these
scripts is normally similar to test scripts produced during Update System
Test Scripts (TE.040) or Update Systems Integration Test Scripts (TE.050).

Deliverable Components
Select the User Acceptance Test Scripts template to create the deliverable
for this task. Use the following components:
Test Sequences The Test Sequences determine the order in which
to execute the Systems Integration Test Specifications to simulate
real life business transaction processing across and between system
boundaries.
Test Specification The Test Specification defines test script
execution and encompasses a business process that spans one or
more systems. You may have more than one System Integration Test
Specification for each script if you need to test more than one
response path through the business process.
Data Profile The Data Profile describes the business conditions or
seeded data necessary to test the integration points between
systems. You may have more than one Data Profile if you need to
test more than one response path through the business process.
Defect Log

13 - 18 Business System Testing (TE)

EMM Method Handbook

Responsible
Business Analyst

Oracle Method

Business System Testing (TE) 13 - 19

TE.070

Perform Unit Testing (Optional)

Test individual custom program modules using the test scripts you
developed from Update Unit Test Scripts (TE.020).

Deliverable
The Unit Tested Modules are custom program modules that have passed
unit test scripts without errors.
Use the defect log section in the Unit Test Scripts (TE.020) to record
information about detected errors and to track corrective action.

Deliverable Components
None

Responsible
Developer

13 - 20 Business System Testing (TE)

EMM Method Handbook

TE.080

Perform Link Testing (Optional)

Test groups of custom program modules to confirm that they work
correctly together and integrate properly with other standard modules in a
business flow. Use the test scripts previously updated in Update Link Test
Scripts (TE.030).

Deliverable
The Link Tested Modules are groups of custom program modules that
have passed link test scripts without errors.
Use the defect log section in the Link Test Scripts (TE.030) to record
information about detected errors and to track corrective action.

Deliverable Components
None

Responsible
Tester

Oracle Method

Business System Testing (TE) 13 - 21

TE.085

Test Pre-Upgrade Steps (Core)

Perform the pre-upgrade steps in your test environment. Follow the steps
documented by Oracle plus any custom upgrade steps you require for
migrating custom extensions and data. In your first iteration, you will
perform the standard steps and record them in your Upgrade Checklist
document. When you identify places where you need to perform special
steps for customizations, migrating custom data, or architecture changes,
add these steps to your checklist (even if you do not yet have all the custom
migration scripts you need). In subsequent iterations and the final
production upgrade, you will execute the pre-upgrade steps using the new
checklist that you have developed.

Deliverable
The Pre-Upgrade Checklist is a checklist for performing the pre-upgrade
steps. Continue to access and enhance this document during Test
Software Upgrade (TE.091) and Test Post-Upgrade Steps (TE.092). The
final checklist will contain all steps identified by these three tasks. During
Production Migration this checklist will document the test results of
Perform Pre-Upgrade Steps (PM.035), Upgrade Production Environment
(PM.040), and Perform Post-Upgrade Steps (PM.045).

Deliverable Components
Select the Pre-Upgrade Test template to create the deliverable for this task.
Use the following components:
Upgrade Test Steps Use this table to record information
regarding all pre-upgrade steps.
Issue Log Use this table to track issue resolution activities
associated with testing pre-upgrade steps.

Responsible
Technical Analyst

13 - 22 Business System Testing (TE)

EMM Method Handbook

TE.091

Test Software Upgrade (Core)

Run the standard software upgrade against your test environment as
documented by Oracle. This typically involves running the AutoInstall
utility. Your first iteration may be against a vanilla test environment, but
the final iteration should be against a copy of the production instance.

Deliverable
The Upgraded Applications is a checklist for performing the software
upgrade.

Deliverable Components
Add software upgrade steps to the checklist from Test Pre-Upgrade Steps
(TE.085). Use the deliverable components listed in that task.

Responsible
Technical Analyst

Oracle Method

Business System Testing (TE) 13 - 23

TE.092

Test Post-Upgrade Steps (Core)

Perform the post-upgrade steps in your test environment. Follow the steps
documented by Oracle plus any custom upgrade steps you require for
migrating custom extensions and data. In your first iteration, you will
perform the standard steps and record them in your Upgrade Checklist
document. When you identify places where you need to perform special
steps for customizations, migrating custom data, or architecture changes,
add these steps to your checklist (even if you do not yet have all the custom
migration scripts you need). In subsequent iterations and the final
production upgrade you will execute the post-upgrade steps using the
new checklist that you have developed.

Deliverable
The Post-Upgrade Checklist is a checklist for performing the post-upgrade
steps.

Deliverable Components
Add post-upgrade steps to the checklist from Test Pre-Upgrade Steps
(TE.085). Use the deliverable components listed in that task.

Responsible
Technical Analyst

13 - 24 Business System Testing (TE)

EMM Method Handbook

TE.093

Perform Post-Upgrade Reconciliation Testing (Core)

Run reconciliation reports to verify that the results between the upgraded
system and the original system match. This testing does not include full
testing of business processes, but may include spot testing of specific
functionality just to verify that the upgrade completed successfully.

Deliverable
The deliverable for this task is the Reconciliation Test Report. Use system
generated reports to reconcile the original and upgraded systems.

Deliverable Components
None

Responsible
Technical Analyst

Oracle Method

Business System Testing (TE) 13 - 25

TE.096

Review Upgrade Test Results (Core)

Review the results of the current iteration of your upgrade tests (Test PreUpgrade Steps (TE.085), Test Software Upgrade (TE.091), Test PostUpgrade Steps (TE.092), and Perform Post-Upgrade Reconciliation Testing
(TE.093)) to identify corrections and refinements and determine if
additional iterations are required.

Deliverable
Use the Upgrade Test Analysis to record key information regarding the
review of upgrade test results.

Deliverable Components
Select the Upgrade Test Analysis template to create the deliverable for this
task. Use the following components:
Executive Overview Document the upgrade test results by
reviewing purpose, approach, results, and recommended actions.
Issue Log Record information about each issue identified during
the test results review to facilitate follow-up activities.

Responsible
Technical Analyst

13 - 26 Business System Testing (TE)

EMM Method Handbook

TE.100

Prepare Key Users for Testing (Core)

The User Acceptance Test includes users who have not been involved in
unit, link, system, and systems integration testing. In this task, you will
train the users who will be involved in the User Acceptance Test. Since the
first User Acceptance Test occurs before formal user training, this task
must include some basic training on new features. You may wish to use
preliminary training material developed in Develop User Training
Materials (TR.070).

Deliverable
Prepared Users are key users who are trained on the migrated system and
are qualified to perform the User Acceptance Test.

Deliverable Components
None

Responsible
Tester

Oracle Method

Business System Testing (TE) 13 - 27

TE.110

Perform System Testing (Core)

Test the upgraded test system using the system test scripts you developed
in Update System Test Scripts (TE.040). The system test is performed by
the project team without user involvement. The primary goal is to confirm
that customizations are properly integrated in the new environment. It is
also an opportunity to confirm that new functionality works as expected
and that revised business processes are valid. The breadth of system
testing during an upgrade is not as great as for an implementation where
you must test all business processes.
In a simple upgrade without complex customizations, interfaces, or
process changes, you may be able to combine the system test, systems
integration test, and the user acceptance test into a single user acceptance
test.

Deliverable
The deliverable for this task is the System Tested Applications. Use the
Test Report for Systems Testing to summarize the systems test approach,
results, and action items.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of the system
testing. The components of this deliverable are:
Executive Overview Summarize systems test goals, approach,
results, and recommended actions.
Test Summary Document test goals, scope, requirements, and
constraints.
Test Method Document the detailed approach for conducting the
test including how different categories of test requirements will be
met, test scenarios, and test scripts.

13 - 28 Business System Testing (TE)

EMM Method Handbook

 Test Environment Describes the system configuration, server

architecture, application product setup parameters, and technical
considerations.
Test Results Provide the detailed test results. Use one section for
each business process including: failures, successes, timing,
conclusions, and potential areas for future investigation.
Test Action
Test Change Recommendations
Test Participants: Roles and Responsibilities
Confidentiality

Responsible
Tester

Oracle Method

Business System Testing (TE) 13 - 29

TE.130

Perform Systems Integration Testing (Optional)

Test all interfaces using the business process-oriented scripts you
developed during Update Systems Integration Test Scripts (TE.050).
This task is only required for installations that have significant interfaces
to third-party and legacy systems. For other installations use a
combination of Perform Link Testing (TE.080) and Perform User
Acceptance Testing, Test System (TE.135).

Deliverable
The deliverable for this task is the Integration Tested Systems. Use the
Integration Testing Report to summarize the systems test approach,
results, and action items.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of system
integration testing. The components for this deliverable include:
Executive Overview Summarize systems integration test goals,
approach, results, and recommended actions.
Test Summary Document test goals, scope, requirements, and
constraints.
Test Method Document the detailed approach for conducting the
test including test scenarios, test scripts, and how different
categories of test requirements will be met.
Test Environment Describe the system configuration, server
architecture, application product setup parameters, and technical
considerations.
Test Results Provide the detailed test results. Use one section for
each business process including: failures, successes, timing,
conclusions, and potential areas for future investigation.

13 - 30 Business System Testing (TE)

EMM Method Handbook

 Test Actions
Test Change Recommendations
Test Participants: Roles and Responsibilities
Confidentiality

Responsible
Tester

Oracle Method

Business System Testing (TE) 13 - 31

TE.135

Perform User Acceptance Testing, Test System (Core)

In this task, the project team and users conduct a thorough test of the
upgraded test system to confirm that it functions correctly and satisfies all
business requirements. In an upgrade without complex customizations
and interfaces, this task may also serve as the system test.
The user acceptance test generally exercises complete business processes,
which may span multiple systems. As a result, interfaces between Oracle
and third-party or legacy systems will also be tested.
Parts of the user acceptance test may be repeated after correcting errors
discovered during testing. You may need to repeat the cycle several times
before users accept the system, but the amount of testing in each iteration
should decrease.

Deliverable
The User Acceptance Test Report summarizes the user acceptance test
approach, results, and action items for the test system.

Deliverable Components
Select the User Acceptance Test Report template to create the deliverable
for this task. Use the following components:
Executive Overview Summarize systems test goals, approach,
results, and recommended actions.
Test Summary Document test goals, scope, requirements, and
constraints.
Test Method Document the detailed approach for conducting the
test including test scenarios, test scripts, and how different
categories of test requirements will be met.
Test Environment Describe the system configuration, server
architecture, application product setup parameters, and technical
considerations.

13 - 32 Business System Testing (TE)

EMM Method Handbook

 Test Results Provide the detailed test results. Use one section for
each business process including: failures, successes, timing,
conclusions, and potential areas for future investigation.
Test Actions
Test Change Recommendations
Test Participants: Roles and Responsibilities
Confidentiality

Responsible
Technical Analyst

Oracle Method

Business System Testing (TE) 13 - 33

TE.140
Perform User Acceptance Test, Production System
(Optional)
This task will involve some or all of the testing performed in Perform User
Acceptance, Test System (TE.135), except that the testing will either be
against a duplicate of the live production instance or on the actual
production instance after a full backup. The users may choose to only
perform a subset of the tests performed in Perform User Acceptance, Test
System (TE.135).

Deliverable
The Acceptance Results summarizes the user acceptance test approach,
results, and action items for the production system.

Deliverable Components
Select the Acceptance Results template to create the deliverable for this
task. Use the following components:
Executive Overview Summarize systems test goals, approach,
results, and recommended actions.
Test Summary Document test goals, scope, requirement, and
constraints.
Test Method Document the detailed approach for conducting the
test including test scenarios, test scripts, and how different
categories of test requirements will be met.
Test Environment Describe the system configuration, server
architecture, application product setup parameters, and technical
considerations.
Test Results Provide the detailed test results. Use one section for
each business process including: failures, successes, timing,
conclusions, and potential areas for future investigation.
Test Actions

13 - 34 Business System Testing (TE)

EMM Method Handbook

 Test Change Recommendations

Test Participants: Roles and Responsibilities
Confidentiality

Responsible
Technical Analyst

Oracle Method

Business System Testing (TE) 13 - 35

14
CHAPTER

Training (TR)
T

his chapter describes the Training process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration
Documentation

Business System Testing

Training

Production Migration

Figure 14-1 Training Context

Oracle Method

Training (TR) 14 - 1

Process Flow
Training (TR)
PJM.CR.010 - Establish
Scope, Objectives and Approach
Project Manager

TR.010
Prepare Training
Strategy

MU.005 - Release Changes Summary

TE.110 - System Tested Applications

TR.050

Business Analyst

Prepare Project
Team Training

TR.060
Trainer

Train Project Team

Trained Project Team

TR.080
Prepare User
Training
Environment

TR.090
Train Users

TR.070
Develop User
Training Materials

Technical Writer

Trained Users
User Training Materials

DO.100 - User Reference Manual

DO.110 - User Guide
DO.130 - System Management Guide

Figure 14-2 Training Process Flow Diagram

Approach
Training prepares both users and administrators to assume the tasks of
running the new application system. For upgrade projects, it usually

14 - 2 Training (TR)

EMM Method Handbook

includes training focused on changes in the use and administration of the

system due to differences between the current and new release.
EMM distinguishes between education and training. Education provides
an understanding of the fundamentals of how the business operates in a
specific type of environment. Training refers to the Oracle products and
skills courses. With an applications upgrade, both education and training
may be required to make the transition to the new application.

Tasks and Deliverables

The tasks and deliverables for this process follow:

ID

Core

Task Name

Deliverable Name

TR.010
TR.050
TR.060
TR.070
TR.080
TR.090

Y
Y
Y
Y
Y
Y

Prepare Training Strategy

Prepare Project Team Training
Train Project Team
Develop User Training Materials
Prepare User Training Environment
Train Users

Education and Training Plan

Training Preparation Checklist
Trained Project Team
User Training Materials
User Training Environment
Trained Users

Table 14-1

Training Tasks and Deliverables

Objectives
The objectives of the Training process are:
Provide users with the skills and knowledge to use the features and
functions of the new application release within their respective job
roles.
Achieve a smooth transition from the old application release to the
new application release.
Train applications maintenance staff.

Oracle Method

Training (TR) 14 - 3

Key Deliverables
The key deliverables of this process follow:
Deliverable

Description

Trained Project Team

Project personnel trained to perform

assigned project tasks.

User Training Manuals

Training materials for user training

that focus on new release changes.

Trained Users

Users who are capable of using the

upgraded application to its fullest
capacity.

Table 14-2

Training Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:

14 - 4 Training (TR)

Role

Responsibility

Project Manager

Determine the education and training

needs of the upgrade project team and
user community. Put plans in place to
achieve stated training objectives.

Business Analyst

Conduct interviews and prepare list of

proposed courses and the business
roles of the attendees.

EMM Method Handbook

Role

Responsibility

Trainer

Determine and prepare course

materials. Create demonstration and
lab data. Perform class dry-runs.
Verify that the new applications
release functions properly and report
bugs. Train the users, administrators,
and other trainers. Provide and
evaluate course evaluations.

Technical Writer

Develop and edit training materials.

Table 14-3

Training Key Responsibilities

Critical Success Factors

The critical success factors of the Training process follow:
clear and detailed definition of the training requirements
early trainer involvement in relevant design activities
a common understanding among project team members that
training is an integral part of the application upgrade
committed user involvement

Oracle Method

Training (TR) 14 - 5

TR.010

Prepare Training Strategy (Core)

Develop the training strategy for the upgrade project. The Release
Changes Summary (MU.005) identifies the new release changes impacting
the organization. Use this to focus training on high impact topics.
The strategy for preparing a training environment needs special attention.
It should include the new release, application, setup data, and table data
resulting in new release functionality.

Deliverable
The Education and Training Plan documents the training plan for the
migration project.

Deliverable Components
Use the Education and Training section of the Project Management Plan
(PJM.CR.030) to create the deliverable for this task. Include the following
components:
Project Team Training Document the training objectives and
strategy. Specify knowledge areas and the type of training (such as
custom or Oracle standard classes). Include funding and instructor
staffing approaches.
End-User Training Address the topics listed in the Training
Preparation Checklist (TR.050).
Systems Management/Administration Training Address the
topics listed in the Training Preparation Checklist (TR.050).

Responsible
Project Manager

14 - 6 Training (TR)

EMM Method Handbook

TR.050

Prepare Project Team Training (Core)

Use the Training Preparation Checklist to help conduct the detailed
preparation for delivery of required standard and custom classes to the
project team. These classes should fulfill the training requirements
identified in the Education and Training Plan (TR.010). This task includes
the following:
preparing the training aids
securing a training facility
confirming attendees
assembling reference and training notes
preparing training system for demonstrating exercises
preparing class evaluation forms
If you are planning custom training, you need standard applications
expertise. Consider the following elements when you prepare custom
training:
class handouts
lab exercises
self-help tools
partially implemented solutions (if applicable)
guidelines
workshops
company-specific data

Deliverable
The Training Preparation Checklist is used to plan and track the
preparation for project team training. You need the following information
to complete this deliverable:
list of training classes

Oracle Method

Training (TR) 14 - 7

 training agenda
list of resources providing training
class attendance list
demonstration data to use during training
class handouts
list of decisions made during classes
list of unresolved issues
class evaluation form

Deliverable Components
Select the Training Preparation template to create the deliverable for this
task. Use the following components:
Training Preparation Checklist

Technical Environment

Training Resources

Follow-up

Products Installed

Class Attendance List

List International Attendees

Responsible
Business Analyst

14 - 8 Training (TR)

EMM Method Handbook

TR.060

Train Project Team

This task provides technical and functional application training to the
immediate project team members. It includes specific training segments for
defining and using the new applications as well as maintaining the
system.

Deliverable
The deliverable for this task is a Trained Project Team.

Deliverable Components
None

Responsible
Trainer

Oracle Method

Training (TR) 14 - 9

TR.070

Develop User Training Materials (Core)

Develop or update existing training materials for user training.
Incorporate the changes related to the applications migration. Add the
functionality changes due to updated and new customizations.

Deliverable
User Training Materials should represent the highlights of forms, reports,
or programs. They educate the user in the process or use of a particular
form, report, or program.

Deliverable Components
Update the User Training Materials from the initial implementation. If the
original documentation is not available or inadequate you may create it.
Consider including the following in your training:
transaction level step-by-step procedures combined with feature
highlights of the system
labs and exercises that provide users with an opportunity to verify
their understanding of concepts or the use of a form or report
solutions to labs and exercises can be provided in case the student
needs prompting or is taking the course as a self-study
glossary or definition of terms that provide a cross-reference for
users as they become accustomed to new terminology
additional relevant documentation that augments the training
materials
reference the user or technical documentation to avoid duplicating
existing material
maximize reuse of previous project deliverables in the training
materials; for example, use the business process diagrams
representing the future business model as a visual representation of
the future system

14 - 10 Training (TR)

EMM Method Handbook

Responsible
Technical Writer

Oracle Method

Training (TR) 14 - 11

TR.080

Prepare User Training Environment (Core)

During this task, install a new application release or prepare an existing
application environment for end-user training. If a new application
release is installed, go through the appropriate pre- and post-installation
steps. If you are converting an existing environment for end-user training,
adjust the application setup and add training-specific data.

Deliverable
The User Training Environment is a configured user training
environment.

Deliverable Components
None

Responsible
Trainer

14 - 12 Training (TR)

EMM Method Handbook

TR.090

Train Users (Core)

During this task, the project team trains users on the migrated system.
Many users may only need training on aspects of the system that changed
due to the release migration.

Deliverable
The deliverable for this task is Trained Users.

Deliverable Components
None

Responsible
Trainer

Oracle Method

Training (TR) 14 - 13

15
CHAPTER

Production
Migration (PM)
T

his chapter describes the Production Migration process.

Migration
Assessment

Update and
Test

Transition

Production

Business Requirements Review

Requirements Mapping Update

Migrate Application and Technical Architecture

Migrate Custom Extensions

Data Migration

Documentation

Business System Testing

Training

Production Migration

Figure 15-1 Production Migration Context

Oracle Method

Production Migration (PM) 15 - 1

Process Flow

Production Migration (PM)

MU.090 - Acceptance
Certificate
PM.010

Project
Manager

Prepare Transition
Strategy

PM.030
Develop Detailed
Transition and
Contingency Plan

Detailed Transition and

Contingency Plan

MA.160 - Technical Architecture

Documents
PM.035

Technical
Analyst

Perform PreUpgrade Steps

PM.040
Upgrade
Production
Environment

PM.045
Perform PostUpgrade Steps

Post-Upgrade
Checklist

DM.130 - Installed Data

Migration Software
PM.050

Business
Analyst

Quality
Auditor

Revise Application
Setups

TR.090 - Trained Users

TE.140

PM.070

Perform User
Acceptance Test,
Production System

Verify Production
Readiness

System
Administrator

Database
Administrator

Figure 15-2 Production Migration Process Flow Diagram

15 - 2 Production Migration (PM)

EMM Method Handbook

Production Migration (PM)

PM.080

Project
Manager

PM.090

Commence
Production

Audit Production
System

Technical
Analyst
Production System

Business
Analyst

Quality
Auditor

System
Administrator

MA.180 - Performance
Risk Assessment

PM.100

PM.120

Measure System
Performance

Refine Production
System
Refined Production
Environment

Database
Administrator

PM.110
Maintain System

Figure 15-2 Production Migration Process Flow Diagram (cont.)

Oracle Method

Production Migration (PM) 15 - 3

Approach
Production Migration moves the company, system, and people to the new
application release. Following production cutover, it monitors and refines
the upgraded production system and plans for the future. The Production
Migration process encompasses transition to production readiness,
production cutover, and post-production support.
During Production Migration, the project team deploys the migrated
applications into the organization. This deployment requires fully tested
business solutions, migrated production data, updated custom extensions,
data migration programs, updated documentation, and training materials.
Transition is complete when users have started using the migrated system.
When the migrated system is stabilized, regular maintenance and system
refinement resumes. In addition, management begins preliminary
planning of the companys future business and technical direction as it
relates to the migrated systems.

Tasks and Deliverables

ID

Core

Task Name

Deliverable Name

PM.010
PM.030

Y
Y

PM.035
PM.040
PM.045
PM.050
PM.070
PM.080
PM.090

Y
Y
Y
Y
Y
Y
N

Prepare Transition Strategy

Develop Detailed Transition and
Contingency Plan
Perform Pre-Upgrade Steps
Upgrade Production Environment
Perform Post-Upgrade Steps
Revise Application Setups
Verify Production Readiness
Commence Production
Audit Production System

Transition Strategy
Detailed Transition and Contingency
Plan
Pre-Upgrade Checklist
Production Environment
Post-Upgrade Checklist
Configured Applications
Production-Ready System
Production System
Post-Implementation Production
System

15 - 4 Production Migration (PM)

EMM Method Handbook

ID

Core

Task Name

Deliverable Name

PM.100
PM.110
PM.120

Y
Y
Y

Measure System Performance

Maintain System
Refine Production System

System Performance Assessment

Maintained Production Environment
Refined Production Environment

Table 15-1

Production Migration Tasks and Deliverables

Objectives
The objectives of the Production Migration process are:
Gain company-wide acceptance of the new application release
system.
Prepare the production environment according to the detailed
transition and contingency plan.
Educate the company on new business operations.
Implement changes in processes and organizational structure.
Successfully migrate to the upgraded system.
Measure actual performance against expectations and plans.
Refine and tune the system to reflect business change.

Key Deliverables
The key deliverables of this process follow:

Oracle Method

Deliverable

Description

Detailed Transition and

Contingency Plan

Documents the sequence of events that

must occur during transition to
production and provides a plan in the
event that the transition is
unsuccessful.

Production Migration (PM) 15 - 5

Deliverable

Description

Post-Upgrade Checklist

Documents the work steps and the

information concerning exceptions
generated by the upgrade steps.

Production System

The upgraded production system

running live business transactions.

Refined Production
Environment

The production environment is refined

through tuning, application setup
changes, and other performance
adjustments.

Table 15-2

Production Migration Key Deliverables

Key Responsibilities
The following roles are required to perform the tasks within this process:

15 - 6 Production Migration (PM)

Roles

Responsibility

Project Manager

Plan and estimate resources required

to support the migration process.
Manage logistics and verify that
hardware and software are configured
properly. Coordinate transition
activities. Verify availability of
technical support, including system,
applications, and database
administrators.

Technical Analyst

Prepare for and perform the upgrade

process.

Business Analyst

Make the required application setup

changes for all applications.

EMM Method Handbook

Roles

Responsibility

Project Manager

Plan and estimate resources required

to support the migration process.
Manage logistics and verify that
hardware and software are configured
properly. Coordinate transition
activities. Verify availability of
technical support, including system,
applications, and database
administrators.

Technical Analyst

Prepare for and perform the upgrade

process.

Quality Auditor

Verify the companys preparedness for

production on the new release
application system.

System Administrator

Measure the performance of the

upgraded system in the production
environment. Refine the new
upgraded system as needed.

Database Administrator

Maintain upgraded system on an

ongoing basis.

Table 15-3

Oracle Method

Production Migration Key Responsibilities

Production Migration (PM) 15 - 7

Critical Success Factors

The critical success factors of the Production Migration process follow:
acceptance and support of organizational and process changes by
senior-level management
demonstration by end-users that they can perform their jobs using
the new release documentation, tools, and systems
successful migration of data by data migration programs within the
planned time frame
all application modules function as expected in support of the
business requirements
agreement by all involved parties on the transition schedule
measurable performance objectives for achieving high levels of
services
available technical experts to tune the production environment
exhibition of strong commitment by management, project team, and
user community to improve the system

15 - 8 Production Migration (PM)

EMM Method Handbook

PM.010

Prepare Transition Strategy (Core)

Develop the Transition Strategy for performing the migration of the current
application(s) to the new release and migrate the people and the company
to the upgraded system. Integrated business solutions are used to verify
that the strategy considers all technical, organizational, and business
process changes.
Pay attention to multiple site transition needs. If multiple data centers are
involved, careful synchronization of the upgrade processes may be
needed.

Deliverable
The Transition Strategy considers all aspects of the project and
organizations affected by transition to the new system. When developing
the Transition Strategy, consider the requirements of the following
categories: project team resources, human resources, end-user community,
internal support, external support, hardware preparation, network
preparation, software preparation, system management, training, business
management, logistics, administration, external customers, suppliers, and
partners. Include statements of transition priorities and determine
support types and levels required during the production cutover.

Deliverable Components
Use the Strategy component of the Project Management Plan (PJM.CR.030).

Responsible
Project Manager

Oracle Method

Production Migration (PM) 15 - 9

PM.030
(Core)

Develop Detailed Transition and Contingency Plan

Develop a detailed transition plan for migrating to the migrated
application based on the Transition Strategy (PM.010). Include detailed
tasks, checklists, end user training plans, the implementation contingency
plan, and a detailed schedule for the first week of production. Assign
team members to transition activities such as user acceptance testing, enduser training, the production application migration process, and
commencement of production for the migrated system based on this plan.

Deliverable
The Detailed Transition and Contingency Plan includes the preproduction steps, production schedule for the first week, support
infrastructure, approach for obtaining feedback on system performance
during the first week of production, the detailed transition plan, and an
end-user training plan. It also includes contingency steps in the event that
the migrated system becomes unavailable.

Deliverable Components
Select the Detailed Transition and Contingency Plan template to create the
deliverable for this task. Use the following components:
Detailed Transition Plan
End User Training Plan
Implementation Contingency Plan
Preparing for Production
Production Schedule - First Week

Responsible
Project Manager

15 - 10 Production Migration (PM)

EMM Method Handbook

PM.035

Perform Pre-Upgrade Steps (Core)

Perform the pre-upgrade steps for the production migration process using
the step specifications developed in Test Pre-Upgrade Steps (TE.085).
The standard Oracle migration process described in product migration
manuals specifies pre-upgrade steps for each application.
Even for simple migrations, the work steps, recording of results, and
follow-up actions are complex enough to justify detailed documentation
supported by the deliverable for this task. For some migration projects, it
may be necessary to add custom steps if the standard Oracle
documentation does not cover all required activities.
Oracles migration utility will not migrate certain types of invalid data and
will produce entries on an exception report. Production data cleanup
should have occurred earlier in the project to enable this task to complete
successfully.

Deliverable
Use the Pre-Upgrade Checklist to record the status of all pre-upgrade
steps as they are being performed for the production migration.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of all preupgrade steps. Use the checklist developed in Test Pre-Upgrade Steps
(TE.085). Delete the Business System Testing results and record the
Production Migration results in their place. Use the following
components:
Upgrade Test StepsUse this table to record information regarding
all pre-upgrade steps.
Issue LogUse this table to track issue resolution activities
associated with testing pre-upgrade steps.

Oracle Method

Production Migration (PM) 15 - 11

Responsible
Technical Analyst

15 - 12 Production Migration (PM)

EMM Method Handbook

PM.040

Upgrade Production Environment (Core)

Run Oracles upgrade utility to migrate production data stored in
standard Oracle tables to the new production environment. This utility
will not migrate data stored in custom tables, nor will it populate new
tables or new columns of existing tables. These have to be populated by
custom data migration routines.

Deliverable
The deliverable for this task is the Production Environment. Record the
status of software upgrade steps as they are being performed for the
production migration.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of all preupgrade steps. Use the checklist developed in Test Software Upgrade
(TE.091). Delete the Business System Testing results and record the
Production Migration results in their place. Use the following
components:

Software Upgrade StepsUse this table to record information

regarding all software upgrade steps.

Issue LogUse this table to track issue resolution activities associated

with testing software upgrade steps.

Responsible
Technical Analyst

Oracle Method

Production Migration (PM) 15 - 13

PM.045

Perform Post-Upgrade Steps (Core)

Perform the post-upgrade steps for the production upgrade process using
the step specifications developed in Test Post-Upgrade Steps (TE.091).

Deliverable
Use the Post-Upgrade Checklist to record the status of post-upgrade steps
as they are being performed for the production migration.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of all preupgrade steps. Use the checklist developed in Test Post Upgrade Steps
(TE.091). Delete the Business System Testing results and record the
Production Migration results in their place. Use the following
components:

Post-Upgrade StepsUse this table for recording information

regarding the post-upgrade steps.

Issue LogUse this table to track issue resolution activities associated

with testing post-upgrade steps.

Responsible
Technical Analyst

15 - 14 Production Migration (PM)

EMM Method Handbook

PM.050

Revise Application Setups (Core)

Make revisions to current application setup data in the production
environment before the cutover to the migrated system. The Application
Setup Document (MU.110) specifies the revisions.

Deliverable
Configured Applications are configured production applications.

Deliverable Components
None

Responsible
Business Analyst

Oracle Method

Production Migration (PM) 15 - 15

PM.070

Verify Production Readiness (Core)

Verify that the migrated application, people, and company are prepared
for production. Success with this task means that project leadership can
request approval for transition activities. This is the final approval step
before cutover to the migrated system.

Deliverable
The deliverable for this task is the Production-Ready System. Evaluate
production readiness with regard to key activities that must be complete
prior to cutover.

Deliverable Components
Create a checklist that addresses:
Business Processes
Updated system, reference, and manual procedures are
distributed to all users.
Updated system access, support infrastructure, and other
necessary connections are available.
Users are fully trained on changed functionality and updated
business processes.
Technical Considerations
database changes migrated
operating system
network
upgraded applications
revised setup data
migrated and new customizations
migrated custom data

15 - 16 Production Migration (PM)

EMM Method Handbook

 newly converted data

new tables or new columns in existing tables
new or replaced peripherals
support personnel changes
reference materials
updated contingency communication process

Responsible
Quality Auditor

Oracle Method

Production Migration (PM) 15 - 17

PM.080

Commence Production (Core)

Completing this task signifies company-wide use of all aspects of the
migrated production system. You must anticipate issues and quickly
remedy them. Priorities may shift during a production state and therefore
you must set expectations with users regarding the types of problems that
will be resolved first. While this task allows users to become familiar with
the new system, it also allows you to track and resolve problems as they
occur. Efficient issue tracking, resolution, and follow-up facilitates a
smooth initial cutover.

Deliverable
The deliverable for this task is the Production System. This deliverable is
an execution task. It certifies that all aspects of the system are operational.
Before declaring production status, you should consider the following:
All reports can be generated, printed, and viewed online.
All inquiries can be made from all established terminals.
Users have access to and have used all respective functions and
features of the business system.
All automated backup and recovery programs operate according to
schedule.
All background programs perform as designed.
No alternate support or business systems are required to run
portions of the system.

Deliverable Components
None

Responsible
Project Manager

15 - 18 Production Migration (PM)

EMM Method Handbook

PM.090

Audit Production System (Optional)

This task provides an assessment of how well the upgraded production
system meets the business objectives set at the beginning of the project.
You can measure system effectiveness using key performance indicators
agreed upon early in the project.
Reference the Project Management Plan (PJM.CR.030) for project goals,
objectives, and key performance indicators.

Deliverable
The deliverable for this task is the Post-Implementation Production
System. Record the results from an audit of the migrated production
system. Include performance measures, statement of project scope, audit
approach, performance measurement tools used, a summary of audit
results, a list of specific performance measures taken, conclusions and
recommendations.

Deliverable Components
The deliverable template for this task is a tool for tracking the progress of
the development effort. It can be used to document the status of the postimplementation production system. Select the Production System Audit
Report to create a deliverable for this task. Use the following components:
Executive Summary
Business Process Summary
Business System and Architecture
Project Metrics
Marketing

Responsible
Project Manager

Oracle Method

Production Migration (PM) 15 - 19

PM.100

Measure System Performance (Core)

This task measures the performance of the migrated system in the
production environment. This may include transaction processing
performance, system response time, and system usage. There may also be
continuing opportunities to refine and tune the performance of the system,
which can be identified by gathering system metrics.
Reference the Project Management Plan (PJM.CR.030) for system
performance related objectives and measures.

Deliverable
Use the System Performance Assessment to record the results of the
production system performance tests. Define and apply metrics to support
how well the system supports the technical needs of the business. The
report should cover:
objectives
strategy for performance measurement
participants required
conditions for test
findings
conclusions
gains accomplished
improvement recommendations

Deliverable Components
Select the System Performance Assessment template to create the
deliverable for this task. Use the following components:
Introduction
Scope

15 - 20 Production Migration (PM)

EMM Method Handbook

 Objectives
Approach
Results
Conclusions
Recommendations

Responsible
System Administrator

Oracle Method

Production Migration (PM) 15 - 21

PM.110

Maintain System (Core)

This task is an ongoing system maintenance or management task. The
system management procedures are put into practice and executed by the
IS Operations Staff.

Deliverable
The deliverable for this task is the Maintained Production Environment.
The purpose of this deliverable is to verify that all normal, ongoing
activities keep the system protected, purged, and operating as efficiently as
possible. This task starts the ongoing system maintenance procedures.
These types of procedures focus on necessary and preventative actions.
Some considerations are:
timing of maintenance procedures
reporting unusual occurrences
interpreting system indicators
logging completion of maintenance work
adjusting the software and hardware for anticipated business
changes
Make sure a Site Log and checklists for standing tasks are available for
recording change events.

Deliverable Components
None

Responsible
Database Administrator

15 - 22 Production Migration (PM)

EMM Method Handbook

PM.120

Refine Production System (Core)

This task solicits end-user feedback and acts on any requests relative to the
upgrade project, production system, or support.

Deliverable
The deliverable for this task is the Refined Production Environment.
Analyze recommendations for improvements and distinguish between
system errors and functionality or performance enhancements. Evaluate
the following:
type of feedback
urgency of request
impact on current business
recommendations to resolve the root problem
cost and benefit of implementing the recommendations
Always try to translate subjective comments into action-oriented
discussions that relate to business requirements. Remember that a number
of factors influence response to enhancement requests, including
management priority, budget, technology limitations, skill set levels, and
so on.

Deliverable Components
None

Responsible
System Administrator

Oracle Method

Production Migration (PM) 15 - 23

APPENDIX

EMM Work
Breakdown Structure
T

Oracle Method

his appendix provides a listing of the work breakdown structure

(WBS) for EMM.

EMM Work Breakdown Structure A - 1

How to Read the Work Breakdown Structure

Each WBS is composed of five elements: phases, activities, milestones,
tasks, and deliverables. Each element is indicated graphically, as shown
in the following legend:

Definition

Phase

B.RR.EXEC

Business Requirements Review

B.RR.020

Review Current Business Processes

Task

B.PL.END

End Phase Planning

Milestone

Activity/Process

Phases are indicated by large, bold type. Each phase has an ID, which is a
single letter indicating its sequence in the development approach.
Activities are indicated by medium-size bold type. Each activity has an ID
which indicates the types of tasks and milestones which it groups. The
last part of the activity ID indicates the category of tasks within the
activity:
PLAN

Planning tasks

EXEC

Execution tasks

CTRL

Control tasks

COMP

Completion tasks

Execution tasks are part of EMM; planning, control and completion tasks
are part of the Project Management Method (PJM). The middle part of the
activity ID indicates process, for execution tasks, or repeats the category,
for all other tasks.
Milestones are indicated by small type, and are preceded by a diamond.
Milestones indicate significant project events.

A - 2 EMM Work Breakdown Structure

EMM Method Handbook

Tasks are indicated by small type. Each task ID on the WBS contains the
following:
<phase ID>.<process ID>.<sequence number>
Each task belongs to a process. You can look up task guidelines by
process as follows:
Execution -- refer to the EMM Method Handbook
RR

Business Requirements Review

MU

Requirements Mapping Update

MA

Migrate Application and Technical

Architecture

ME

Migrate Custom Extensions

DM

Data Migration

DO

Documentation

TE

Business System Testing

TR

Training

PM

Production Migration

Project Management -- refer to PJM Process and Task

Reference

Oracle Method

CR

Control and Reporting

WM

Work Management

RM

Resource Management

QM

Quality Management

EMM Work Breakdown Structure A - 3

CM

Configuration Management

Deliverables are indicated with their corresponding tasks. You can find
guidelines on deliverable contents and format, by process, in either the
EMM Method Handbook or the PJM Deliverable Reference.
The following project management tasks are consolidated on the work
breakdown structure. For guidelines on these tasks, refer to the indicated
task IDs in the PJM Process and Task Reference.
PL.SUM: Review and Revise Project Plans consolidates the following
tasks:
CR.010: Revise Scope, Objectives and Approach
CR.020: Revise Control and Reporting Strategies, Standards
and Procedures
CR.030: Revise Management Plans
WM.010: Revise Work Management Strategies, Standards and
Procedures
WM.020: Revise Project Workplan
WM.030: Revise Finance Plan
RM.010: Revise Resource Management Strategies, Standards
and Procedures
RM.020: Revise Staffing and Organization Plan
RM.025: Revise Project Orientation Guide
RM.030: Revise Project Organization
RM.040: Revise Physical Resource Plan
RM.050: Revise Project Infrastructure
CM.010: Revise Configuration Management Strategies,

A - 4 EMM Work Breakdown Structure

EMM Method Handbook

Standards and Procedures

QM.010: Review Quality Management Strategies, Standards
and Procedures

Oracle Method

EMM Work Breakdown Structure A - 5

CT.SUM: Phase Control consolidates the following tasks:

CR.040: Issue/Risk Management
CR.050: Problem Management
CR.060: Change Control
CR.070: Status Monitoring and Reporting
WM.040: Workplan Control
WM.050: Financial Control
RM.060: Staff Control
RM.070: Physical Resource Control
QM.020: Quality Review
QM.030: Quality Audit
QM.040: Quality Measurement
QM.045: Support Healthcheck
CM.020: Document Control
CM.030: Configuration Control
CM.035: Knowledge Management
CM.040: Release Management
CM.050: Configuration Status Accounting

A - 6 EMM Work Breakdown Structure

EMM Method Handbook

EMM Work Breakdown Structure

The following is a listing of the EMM work breakdown structure.

ID

Task Name

Migration Assessment
A.PL.PLAN
A.PL.BEG
A.CR.010
A.CR.030

u Begin

Project Planning
Establish Scope, Objectives, and Approach

Scoping Project Management

Plan [CR.010, initial]
Project Management Plan
[CR.010, complete]
Workplan [initial]
Finance Plan [initial]
Staffing and Organization Plan
[initial]
Project Orientation Guide [initial]
Prepared Organization [initial]
Physical Resource Plan [initial]
Prepared Infrastructure [initial]

Establish Management Plans

Establish Project Workplan
Establish Finance Plan
Establish Staffing and Organization Plan

A.RM.025
A.RM.030
A.RM.040
A.RM.050
A.PL.END

Create Project Orientation Guide

Implement Organization
Establish Physical Resource Plan
Establish Infrastructure
u End Project Planning

A.RR.BEG
A.RR.020
A.RR.030
A.RR.060
A.RR.070

Business Requirements Review

Migration Assessment Execution
Review Current Business Processes
Develop Future Process Model
Gather Business Volumes
Review Business Requirements Scenarios

Core

A.MU.005
A.MU.011
A.MU.020

Identify New Release Changes

Upgrade Project Environments
Remap Business Requirements

Core
Core
Core

A.MU.030
A.MU.040
A.MU.070
A.MU.090

Remap Business Data

Review Integration Fit Analysis
Review Reporting Fit Analysis
Confirm Integrated Business Solutions

Core
Core
Core
Core

A.MU.EXEC

u Begin

Requirements Mapping Update

A.MA.EXEC

Migrate Application and Technical

Architecture

A.MA.020

Perform Architecture Impact Analysis

Oracle Method

Deliverable

Project Planning

A.WM.020
A.WM.030
A.RM.020

A.RR.EXEC

Core

Current Business Baseline

Future Process Model
Business Volume Requirements
Business Requirements Scenarios
Release Changes Summary
Configured Project Environments
Business Requirements Mapping
Form
Business Data Mapping
Integration Fit Analysis
Master Report Tracking List
Acceptance Certificate

Architecture Impact Analysis

EMM Work Breakdown Structure A - 7

ID

Task Name
A.MA.110

A.ME.EXEC
A.ME.010
A.ME.020

A.DM.EXEC
A.DM.020

A.TR.EXEC
A.TR.010
A.TR.050
A.TR.060

A.PM.EXEC
A.PM.010
A.TR.END

A.CT.CTRL
A.CT.BEG
A.CT.SUM
A.CT.RES
A.CT.END

A.CO.COMP

A.CO.BEG
A.CR.080
A.RM.080
A.RM.090
A.QM.050
A.CM.060
A.CO.END

Core

Define Technical Prototype Subprojects

Deliverable
Technical Prototypes Subprojects
SOA

Migrate Custom Extensions

Perform Customization Impact Analysis
Estimate Custom Extension Migration

Customization Impact Analysis

Solution Document

Perform Data Impact Analysis

Data Impact Analysis

Data Migration
Training

Prepare Training Strategy

Prepare Project Team Training
Train Project Team

Core
Core
Core

Education and Training Plan

Training Preparation Checklist
Trained Project Team

Prepare Transition Strategy

u End Migration Assessment Execution

Core

Transition Strategy

Production Migration
Phase Control
u Begin

Phase Control
Phase Control
Unallocated Reserve
u End Phase Control

Phase Completion
u Begin

Phase Completion
Secure Client Phase Acceptance
Release Staff
Release Physical Resources
Perform Quality Assessment
Audit Key Deliverables
u End Phase Completion

Client Phase Acceptance

Released Staff
Released Physical Resources
Quality Report
Audited Phase Baseline

Update and Test

B.PL.PLAN
B.PL.BEG
B.PL.SUM
B.PL.END

B.MU.EXEC

B.MU.BEG
B.MU.100
B.MU.110
B.MU.120

B.MA.EXEC

Phase Planning
u Begin

Phase Planning
Review and Revise Project Plans
u End Phase Planning

Requirements Mapping Update

u Begin

Update and Test Execution

Update Process Narratives
Revise Application Setups
Revise Security Profiles

Migrate Application and Technical

Architecture

A - 8 EMM Work Breakdown Structure

Core
Core
Core

Process Narratives
Application Setup Document
Security Profiles

EMM Method Handbook

ID

Task Name

Core

Deliverable

B.MA.140

Update Application Architecture

B.MA.160

Update Technical Architecture

B.MA.180
B.MA.190

Identify New Performance Risks

Update System Management Procedures

Application Architecture
Documents
Technical Architecture
Documents
Performance Risk Assessment
System Management Procedures

Update Design and Build Standards

Identify Custom Database Changes
Identify Module Design Changes
Implement Database Changes
Update Custom Modules
Create Migration Routines

Design Standards
Database Extension Design
Module Design
Custom Database Objects
Module Source Code
Custom Migration Routines

B.DM.050
B.DM.060
B.DM.070
B.DM.080
B.DM.090
B.DM.100
B.DM.110

Perform Migration Data Mapping

Design Manual Migration Strategy
Design Migration Programs
Prepare Data Migration Test Plans
Develop Data Migration Programs
Perform Data Migration Unit Test
Perform Migration Business Object Test

B.DM.120

Perform Data Migration Validation Test

Migration Data Mapping

Manual Migration Strategy
Migration Program Design
Migration Test Procedures
Migration Programs
Unit Tested Migration Programs
Business Object Tested Migration
Programs
Validation Tested Migration
Programs

B.ME.EXEC
B.ME.030
B.ME.050
B.ME.060
B.ME.100
B.ME.110
B.ME.120

B.DM.EXEC

B.DO.EXEC
B.DO.100
B.DO.110
B.DO.120
B.DO.130
B.DO.140

B.TE.EXEC
B.TE.010
B.TE.020
B.TE.030
B.TE.040
B.TE.050
B.TE.055
B.TE.070
B.TE.080
B.TE.085
B.TE.091
B.TE.092
B.TE.093

Oracle Method

Migrate Custom Extensions

Data Migration

Documentation
Update User Reference Manual
Update User Guide
Update Technical Reference Manual
Update System Management Guide
Update Online Help Text

Core

Business System Testing

Develop Test Strategy

Update Unit Test Scripts
Update Link Test Scripts
Update System Test Scripts
Update Systems Integration Test Scripts
Update User Acceptance Test Scripts
Perform Unit Testing
Perform Link Testing
Test Pre-Upgrade Steps
Test Software Upgrade
Test Post-Upgrade Steps
Perform Post-Upgrade Reconciliation
Testing

Core

Core
Core

Core
Core
Core
Core

User Reference Manual

User Guide
Technical Reference Manual
System Management Guide
Online Help Text
Testing Strategy
Unit Test Scripts
Link Test Scripts
System Test Scripts
Systems Integration Test Scripts
User Acceptance Test Scripts
Unit Tested Modules
Link Tested Modules
Pre-Upgrade Checklist
Upgraded Applications
Post-Upgrade Checklist
Reconciliation Test Report

EMM Work Breakdown Structure A - 9

ID

Task Name
B.TE.096
B.TE.100
B.TE.110
B.TE.130
B.TE.135

B.TR.EXEC
B.TR.070

B.PM.EXEC
B.PM.030
B.PM.END

B.CT.CTRL
B.CT.BEG
B.CT.SUM
B.CT.RES
B.CT.END

B.CO.COMP

B.CO.BEG
B.CR.080
B.RM.080
B.RM.090
B.QM.050
B.CM.060
B.CO.END

C.PL.PLAN
C.PL.BEG
C.PL.SUM
C.PL.END

C.DM.EXEC

C.DM.BEG
C.DM.130

C.TE.EXEC
C.TE.140

C.TR.EXEC
C.TR.080
C.TR.090

Core

Deliverable

Review Upgrade Test Results

Prepare Key Users for Testing
Perform System Testing
Perform Systems Integration Testing
Perform User Acceptance Testing, Test
System

Core
Core
Core
Core

Upgrade Test Analysis

Prepared Users
System Tested Applications
Integrated Tested Systems
User Acceptance Test Report

Develop User Training Materials

Core

User Training Manuals

Develop Detailed Transition and

Contingency Plan
u End Update and Test Execution

Core

Detailed Transition and

Contingency Plan

Training

Production Migration

Phase Control
u Begin

Phase Control
Phase Control
Unallocated Reserve
u End Phase Control

Phase Completion
u Begin

Phase Completion
Secure Client Phase Acceptance
Release Staff
Release Physical Resources
Perform Quality Assessment
Audit Key Deliverables
u End Phase Completion

Client Phase Acceptance

Released Staff
Released Physical Resources
Quality Report
Audited Phase Baseline

Transition

Phase Planning
u Begin

Phase Planning
Review and Revise Project Plans
u End Phase Planning

Data Migration
u Begin

Transition Execution
Install Data Migration Software

Installed Data Migration

Software

Business System Testing

Perform User Acceptance Test, Production
System

Acceptance Results

Training

Prepare User Training Environment

Train Users

A - 10 EMM Work Breakdown Structure

Core
Core

User Training Environment

Trained Users

EMM Method Handbook

ID

Task Name
C.PM.EXEC
C.PM.035
C.PM.040
C.PM.045
C.PM.050
C.PM.070
C.PM.080
C.PM.END

C.CT.CTRL
C.CT.BEG
C.CT.SUM
C.CT.RES
C.CT.END

C.CO.COMP

C.CO.BEG
C.CR.080
C.RM.080
C.RM.090
C.QM.050
C.CM.060
C.CO.END

D.PL.PLAN
D.PL.BEG
D.PL.SUM
D.PL.END

D.PM.EXEC

D.PM.BEG
D.PM.090
D.PM.100
D.PM.110
D.PM.120
D.PM.END

D.CT.CTRL
D.CT.BEG
D.CT.SUM
D.CT.RES
D.CT.END

D.CO.COMP

D.CO.BEG

Oracle Method

Core

Deliverable

Core
Core
Core
Core
Core
Core

Pre-Upgrade Checklist
Production Environment
Post-Upgrade Checklist
Configured Applications
Production-Ready System
Production System

Production Migration
Perform Pre-Upgrade Steps
Upgrade Production Environment
Perform Post-Upgrade Steps
Revise Application Setups
Verify Production Readiness
Commence Production
u
u End Transition Execution

Phase Control
u Begin

Phase Control
Phase Control
Unallocated Reserve
u End Phase Control

Phase Completion
u Begin

Phase Completion
Secure Client Phase Acceptance
Release Staff
Release Physical Resources
Perform Quality Assessment
Audit Key Deliverables
u End Phase Completion

Client Phase Acceptance

Released Staff
Released Physical Resources
Quality Report
Audited Phase Baseline

Production

Phase Planning
u Begin

Phase Planning
Review and Revise Project Plans
u End Phase Planning

Production Migration
u Begin

Production Execution
Audit Production System
Measure System Performance
Maintain System

Core
Core

Refine Production System

u End Production Execution

Core

Post-Implementation Production
System
System Performance Assessment
Maintained Production
Environment
Refined Production Environment

Phase Control
u Begin

Phase Control
Phase Control
Unallocated Reserve
u End Phase Control

Project Completion
u Begin

Project Completion

EMM Work Breakdown Structure A - 11

ID

Task Name
D.CR.080
D.RM.080
D.RM.090
D.QM.050
D.CM.060
D.CM.070
D.CO.END

Secure Client Phase Acceptance

Release Staff
Release Physical Resources
Perform Quality Assessment
Audit Key Deliverables
Conclude Configuration Management
u End Project Completion

A - 12 EMM Work Breakdown Structure

Core

Deliverable
Client Phase Acceptance
Released Staff
Released Physical Resources
Quality Report
Audited Phase Baseline
CM Production Readiness

EMM Method Handbook

APPENDIX

EMM Roles
T

Oracle Method

his appendix gives a brief description of each role, highlighting the main
responsibilities of the role.

Role Descriptions B - 1

Role Descriptions
Application Specialist
The application specialist provides knowledge and guidance regarding application
functionality. This person also supports and provides interpretation for tools, templates
and methods.

Business Analyst
The business analyst conducts interviews and working sessions. This person also
identifies detailed business requirements and creates business requirement scenarios.

Database Administrator
The database administrator installs and configures the production database and maintains
database access controls. This person provides consultation on performance, and is
responsible for monitoring growth and fragmentation of the production database, and
ensuring database backup and recovery.

Developer
The developer is responsible for production of application and module designs. The
developer also produces module and link test plans. During the various testing activities
and the production phase, this person diagnoses faults and determines corrections.
The developer must understand requirements from the business analysis and how to meet
these requirements using the technical and system architectures and System Data Model.
The developer produces working code that meets the module specifications. The
developer diagnoses and corrects faults found by tests. During production the developer
executes regression tests on the corrections.
The developer is also responsible for producing the Logical and Physical Database
Designs. This person reviews the module designs to ensure efficient access to the
database.
The developer must have a thorough understanding of the specifications for the modules
to produce code. This person should also understand how those modules fit in the
system architecture and business and technical requirements that they implement.

B - 2 Role Descriptions

EMM Method Handbook

The developer is responsible for production of working code that meets the conversion
module specifications. The developer diagnoses and corrects faults found by tests.
During production the developer executes regression tests on their corrections.
The developer must have a thorough understanding of the specifications for the
conversion modules for which he or she will produce code.

IS Manager
The IS manager directs the client information systems organization within a business.
The IS manager acts as a business line manager for the staff in the IS organization. This
person is responsible for the technical infrastructure of a business including decisions
about purchases, in-house development, and operational maintenance and support. The
following information systems staff report directly or indirectly to the IS manager:
application and technical architect
technical analyst
designer
technical (database, network, system) administrator
operations staff
support staff
The IS manager defines the information systems strategy for a corporation and puts the
strategy into practice through standards, policies, practices, and information systems
selection processes.

Network Administrator
The network administrator is responsible for administering the network. This includes
making sure that the network is correctly configured; configuring and maintaining the
network environment; and performance monitoring the network.

Project Manager
The project manager is ultimately held responsible for the success or failure of the
project. This person must understand the project business objectives of both the client
and consulting, and have a clear vision of how to achieve those objectives. The project
manager agrees on the scope of the project with the client and resolves any conflicts
among the various objectives of its stakeholders.
The project manager is responsible for the project planning, resourcing, monitoring, and
reporting the progress against the plan. This person obtains any physical resources

Oracle Method

Role Descriptions B - 3

required for the project, recruits staff, and, if necessary, dismisses staff. The project
manager is responsible for ensuring that activities are performed in accordance with the
Quality Plan.
Internal responsibilities of the project manager role should be delegated to subordinate
team leaders, as documented in the project organization plan.
The role of implementation project manager is used to distinguish between the two types
of projects on a program: focus area or program office and implementation. The
responsibilities of the implementation manager are the same as any project manager;
however, the implementation project manager is also responsible for roll out of the
baseline solution to the various implementation sites.
In contrast, the program office project manager manages projects tasked with creating a
common baseline solution for the implementation project to roll out. Again, the
responsibilities of this role are the same as any project manager.
The project manager is responsible for planning the project, resourcing that plan, and
monitoring and reporting the projects progress against the plan. This person obtains any
physical resources required for the project, recruits staff and, if necessary, dismisses
them. The project manager is responsible for ensuring quality control and quality
assurance are performed in accordance with the Quality Plan, and that configuration
management is performed in accordance with the configuration management procedures.
The project manager represents the project to both the business and IS management. This
person is ultimately held responsible for the success or failure of the project. They must
understand the project business objectives and have a clear vision of how to achieve those
objectives. The project manager must resolve the conflict among the differing objectives of
the various parties to the project.
The project manager primarily faces outwards from the project and handles political
conflicts and issues and makes sure they do not impede the project.
The project manager agrees to the scope of the project with the client. He or she must
ensure the implementation remains within the agreed scope and must guard against scope
creep. The Project Manager should review major deliverables particularly those from
the earlier phases of the project.
When using CDM/FT, the project manager must be thoroughly familiar with the
FastTrack approach. This role must have direct access to the project sponsor at all times.

B - 4 Role Descriptions

EMM Method Handbook

Project Staff Member

The project staff member reports directly to either the project manager or client project
manager.
This project role may be responsible for technical support of the clients systems. The
project staff member may provide information about existing systems with which the
new system is to interface with or replace. This project role provides information about
any IS standards with which the project must comply, supports the business software
systems, and takes over support of the system during production. Finally, the project
staff members may participate in training programs for the system initially as consumers
and later, possibly as providers.

Quality Auditor
The quality auditor conducts quality audits of the project. This position should be filled
by a person independent of the project staff in the consulting organization. The quality
auditor needs training in the audit process. The quality auditor prepares for, conducts,
reports on, and follows up on any actions raised by the quality audit(s).

System Administrator
The system administrator is responsible for administering the development system. This
persons responsibilities include ensuring hardware is correctly configured; installing,
configuring, and maintaining operating and development software; and ensuring daily
backups of the system are performed. The system administrator also designs and
maintains the systems security.
The system administrator provides first-line support for problems with the development
system and ensures faults are quickly rectified. This person may perform the set-up and
initial maintenance of the production system or advise the clients operational staff on
these tasks. The system administrator works with the project team to optimize system
performance.
The system administrator installs packaged applications environments and converts data.

System Architect
The system architect defines the system and technical architectures including the major
software components of the system, interfaces, and hardware configuration and software
foundation.
The system architect is generally the senior or lead technical designer on the project. This
person must understand the business and technical requirements for the system.

Oracle Method

Role Descriptions B - 5

Technical Analyst
The technical analyst poses solutions and technical assumptions and develops data
profiles in support of testing.

Technical Writer
The technical writer becomes familiar with the business and technical requirements of the
system and how the architecture, design, and modules achieve those objectives. The
technical writer specifies and produces the user, technical, and operational documentation.
The technical writer is responsible for specifying and editing the user, technical, and
operational documentation. This role provides skills in language and presentation.

Tester
The testers develop and execute test script. Testers ensure test scripts are reviewed by
the appropriate business analysts prior to test execution. This person records test results
during testing activities and documents test faults in the problem log. Testers update test
scripts due to approved change requests or software faults that were not anticipated in
the original development. When problems are resolved after re-testing, testers update the
problem log.

Trainer
The trainer is responsible for defining the training requirements, preparing a training plan,
producing training material, and delivering courses.
An external trainer may be needed to assist the key users in training end-users.

User
The user is a member of the clients staff who actually uses the production system. Their
responsibility is to be a consumer of the training program and report problems with the
production system. The users are involved in testing in the later stages of development
and assist the key users in performing the pre-production validation.

B - 6 Role Descriptions

EMM Method Handbook

Glossary
TERM
24x7 A period or window of service
availability that covers 24 hours day, seven
days a week.
3GL see THIRD -GENERATION PROGRAMMING
LANGUAGE .
4GL see FOURTH-GENERATION PROGRAMMING
LANGUAGE

A
ABT see APPLIED BUSINESS TECHNOLOGY.
Acceptance The approval, typically by a client
or user, of a project deliverable.
Access Control The ability to manage which
users or groups of users may have the privilege
to retrieve, create, update, or delete data held in
a repository, such as a relational database.

Oracle Method

ACE see APPLICATION CONFIGURATION AND

EXTENSIONS.
Activation A logical event corresponding to the
enabling of one high level business function at
one site for one business unit. Each activation
represents a discrete unit of work that we can
predict and measure.
Advocate An individual who supports the
project within the client environment, without
being involved in the projects implementation.
An advocate may be a formal or informal leader
within the organization.
AIM see APPLICATION IMPLEMENTATION
METHOD.
ANSI American National Standards Institute.
Application A collection of program modules
that work together to support a set of related
business functions; see also MODULE.

Glossary G - 1

Application and Technology Architecture

(ATA) A program management focus area
project that defines and establishes a common
enterprise-wide technical architecture.
Activities included are: hardware specification,
capacity planning, connectivity, and stress
testing strategies.
Application Environment (Oracle) A complete
application installation along with other
utilities used for business mapping, design,
build, testing, or training. Usually, an
application environment includes setups and
test data to support business modeling, and
procedures exist to recover to controlled
starting points after sessions are complete.
Application Fit A recorded match between
some aspect of a business requirement and the
capability or features of the application system
that satisfies the requirement.
Application Functional Configuration (Oracle)
The definition of key architectural setup
parameters in an application instance or
product group to reflect the financial and
operating environment of the business
organizations that transact within that
application instance or product group.
Application Gap A recorded variance between
some aspect of a business requirement and the
capability or features of the application system
that are necessary to satisfy the requirement.
Application Implementation Method (AIM) A
method that comprises a flexible approach for
implementing Oracle Applications.

G - 2 Glossary

Application Interface A mechanism used to

transfer data between applications. A data
flow between applications is always
implemented as a set of one or more application
interfaces; see also NEAR REAL-TIME
INTERFACE and REAL-TIME INTERFACE.
Application Process An indication of the
sequential execution of a series of system
functions, possibly including manual functions
as well; see also MANUAL FUNCTION, SYSTEM
FUNCTION, and SYSTEM PROCESS.
Application System An automated collection
of business functions, entities, modules,
technology platforms, and documentation that
performs a specified set of business functions;
see also BUSINESS SYSTEM, MODULE, PLANNED
RESPONSE SYSTEM, and SYSTEM FUNCTION.
Application Weight The assigned relative
weight (relative complexity) for each
application product being migrated.
Applications Interface (Oracle) An interface
between similar or dissimilar Oracle
Application products that have data stored in
the same database. The interface may or may
not be supported within the standard package
products.
Applied Business Technology (ABT) A
company that manufactures tools to profile,
estimate, and plan projects. Oracle Services has
a global licensing agreement with ABT. Oracle
Method makes use of Project Workbench,
Methods Architect, and Project Bridge Modeler
as its worldwide methods and project
management software standard; see also
PROJECT BRIDGE MODELER and PROJECT
WORKBENCH.

EMM Method Handbook

Approach A variation or subset of a method,

packaged in order to efficiently support the
delivery of a service; see also TECHNIQUE.
Attribute Any detail that serves to qualify,
identify, classify, quantify, or express the state
of an entity; any description of a thing of
significance.

B
Backup and Recovery Strategy A storage and
recovery strategy that protects against business
information loss resulting from hardware,
software, or network faults.
Baseline 1. A starting point or condition
against which future changes are measured. 2.
A named set of object versions which fixes a
configuration at a particular point in time. A
baseline normally represents a milestone or key
deliverable of a project; see also CURRENT
BUSINESS BASELINE.
Bottom-up Estimate A task-level estimate
derived by calculating the estimating factors
critical to completion of each task; see also
ESTIMATING FACTOR.
BPR see BUSINESS PROCESS REENGINEERING.
Business An enterprise, commercial entity, or
firm in either the private or public sector,
concerned with providing products or services
to satisfy customer requirements.

Business Function Something an enterprise

does, or needs to do, in order to achieve its
objectives; see also APPLICATION SYSTEM,
BUSINESS PROCESS, MANUAL FUNCTION, and
SYSTEM FUNCTION.
Business Function Model A representation of
all the business functions within a defined
scope. A wide range of techniques is available
for modeling business functions; see also
FUNCTION DECOMPOSITION and FUNCTION
HIERARCHY.
Business Location A uniquely identifiable
geographic location, site, or place from which
one or more business units may wholly or
partly operate.
Business Model A model or collection of
models representing the definition of key
components of a business. Components may
include models of processes, objectives,
functions, and information; see also BUSINESS
PROCESS MODEL, ENTITY RELATIONSHIP
DIAGRAM, and FUNCTION HIERARCHY.
Business Organization Any part of a business
treated for any purpose as a separate unit
within the parent business organization; for
example, a department, division, or subsidiary;
see also BUSINESS UNIT.
Business Priority A statement of the level or
urgency of important business needs.

Business Data Mapping Verification that the

underlying table structures and attributes will
support business processes.

Oracle Method

Glossary G - 3

Business Process The complete response that a

business makes to an event. A business
process entails the execution of a sequence of
one or more process steps. It has a clearly
defined deliverable or outcome. A Business
Process is defined by the business event that
triggers the process, the inputs and outputs, all
the operational steps required to produce the
output, the sequential relationship between the
process steps, the business decisions that are
part of the event response, and the flow of
material and/or information between process
steps; see also BUSINESS FUNCTION, BUSINESS
PROCESS MODEL, and EVENT RESPONSE.
Business Process Model The collection of
process flow diagrams that comprise the
complete set of business processes within the
application scope; see also PROCESS FLOW
DIAGRAM.
Business Process Reengineering (BPR) The
activity by which an enterprise reexamines its
goals and how it achieves them, followed by a
disciplined approach of business process
redesign. A method that supports this activity.
Business Requirement A formal statement that
describes application features necessary to
support a business process step.
Business Requirements Mapping An activity
that describes the business requirements for a
business process in business language,
optionally compares the current solution for a
business requirement to a proposed solution
and specifies details for the type and nature of
the solution in a descriptive format. The
deliverable can also be used as a record of key
decisions, or as a placeholder in anticipation of
additional detailed design documentation.

G - 4 Glossary

Business Requirements Scenario (BRS) A

formal statement of the detailed business
requirements for a business process, the source
of these requirements, how these requirements
will be satisfied (either by the application,
manual process steps, workarounds or other
application solutions), and what prototyping
steps must be taken to prove the designs.
Business Rule A rule under which an
organization operates. A policy or decision that
influences the process step.
Business System A combination of people and
automated applications organized to meet a
particular set of business objectives; see also
APPLICATION SYSTEM and PLANNED
RESPONSE SYSTEM.

C
CDM Advantage A packaged method based
on Oracle Consulting Services internal Custom
Development Method (CDM). It includes
ready-made standards, guidelines, workplans,
templates and development approaches for
executing custom development projects.
Change A deviation from a currently
established baseline.
Change Effort Any activity consciously
undertaken by an enterprise, business unit, or
individual, that will result in critical change in
one or more areas of the organization, e.g. new
technology implementation; see also
ORGANIZATIONAL EFFORT .

EMM Method Handbook

Change Readiness A measure of an

organizations state of readiness to realize
change successfully; involves a consideration
of an organizations high-impact leverage
points for change, as well as any change
impediments.
Client/Server A type of technical architecture
that links many personal computers or
workstations (clients) to one or more large
processors (servers). Clients generally manage
the user interface, possibly with some local
data. Servers usually manage multiple-access
databases, including ensuring data integrity
and other invariants; see also INVARIANT.
Column A means of implementing an item of
data within a table. It can be in character, date,
or number format, and be optional or
mandatory.
Company A commercial business; see also
BUSINESS.
Company Baseline The Company Baseline is
the supported configuration of hardware,
software, bug patches, modifications, operating
systems, etc. that is part of a common set of
business systems for the entire enterprise.
There may be lower level of Company Baselines
such as a Latin America Baseline that is a
subset of the Company Baseline.

Conceptual Architecture A high level model of

an enterprises business application that
identifies the organizational and geographical
deployment of the most critical application
systems and the technology components
required to support them.. This model provides
the direction for the detailed enterprise
technical architecture analysis. It should reflect
the vision of the client senior executive
management for the future direction of the
information systems in the enterprise.
Conference Room Pilot A system test in an
environment set up to simulate the future
production environment.
Configuration A named set of configuration
items. Configurations are used to
hierarchically organize configuration items in
order to facilitate their management; see also
CONFIGURATION ITEM.
Configuration Change The implementation of
one or more change requests which leaves the
configuration in an internally consistent state;
see also IMPACT ANALYSIS.
Configuration Management The process of
managing hardware, software, data, and any
other documentation needed during the
development, testing, and implementation of
information systems.

Completion Criteria Standards or rules which

determine completion of a task to an acceptable
level of quality.

Contingency Work effort allotted in a

workplan for all unforeseen but possible
occurrences of additional work.

Computer Network An interconnected group

of computers.

Controlled Document A document which

constitutes or represents a project deliverable
for approval internally or by the client, and is
subject to change control.

Oracle Method

Glossary G - 5

Controls Environmental information that

affects what is possible; constraints or limits.
Core Tasks The minimum set of tasks
necessary to migrate a clients Oracle
Applications system from one release to
another.
Corporation A group of businesses acting as
part of a single legal entity.
Critical Path A specific set of dependent tasks
in a project plan that will increase the overall
project duration, if any of the individual tasks
durations increase.
Critical Success Factor (CSF) A business event,
dependency, product, or other factor that, if not
attained, would seriously impair the likelihood
of achieving a business objective.
CSF see CRITICAL SUCCESS FACTOR.
Current Business Baseline The set of business
process and function models representing the
current application system that supports the
business area; see also BUSINESS AREA,
BUSINESS PROCESS MODEL, and BUSINESS
FUNCTION MODEL.
Custom Code Coding added to a packaged
application or module generated by a CASE
tool to implement functionality that the
application or generator has not provided; see
also CUSTOM EXTENSIONS.
Custom Development Method (CDM) A
structured method for full life-cycle custom
development projects; see also LINE OF
BUSINESS.

G - 6 Glossary

Custom Extensions Custom modules that

extend the functionality of packaged
applications without modifying the base
functionality; see also CUSTOM CODE.
Custom Training (CT) An organizational
change management area providing
organizations with training programs designed
to meet specific training needs identified
through a preliminary training needs
assessment. Custom training seeks to re-skill a
work force to optimize performance with new
technology.
Customization A change made to the standard
Oracle software which implements a solution
to a gap.
Cut-over Transition to a new application
system in a live, production mode of operation.

D
Data Cleansing The transformation of data in
its current state to a pre-defined, standardized
format using packaged software or program
modules.
Data Conversion The movement of data from a
legacy system or application to a replacement
application or subsystem.
Data Definition The specification of a data
element to be maintained. The specification
includes datatype, size, and rules about
processing: for example, derivation, and
validation; see also BUSINESS RULE and
INVARIANT.
Data Dictionary A part of a database that
holds definitions of data elements, such as
tables, columns, and views.

EMM Method Handbook

Data Integration The movement of data

between two co-existing systems. The
interfacing of this data may occur once every
hour, once a day, etc.

Data Transformation The process of

redefining data based on some predefined
rules. The values are redefined based on a
specific formula or technique.

Data Migration The movement of data from one

database to another database -- but not
necessarily to a working application or
subsystem tables.

Database A collection of data, usually in the

form of tables or files, under the control of a
database management system.

Data Profile A description of the business

conditions that are needed to test the
application system.
Data Registry The master copy of the data
associated with a business object. Several
databases may share access to a common data
registry to ensure consistency and eliminate
redundant entries across multiple applications
and databases. An example of a data registry
would be a shared customer master. All
updates and changes would be made to the
customer master data registry and are then
propagated to subscribing sites. All systems
requiring customer information would interface
with the customer data registry.
Data Scrubbing The process of manipulating
or cleaning data into a standard format. This
process may be done in conjunction with other
data acquisition tasks.
Data Source An operational system, thirdparty organization, or external system that
provides the data to support the information
requirements of the client. The data source is
accessed during the data acquisition process.
Data Transfer The physical movement of data
between applications, perhaps across sites.

Oracle Method

Database Architecture The collective

application and database instances that
comprise the complete system.
Database Function A callable routine executed
within a database server environment.
Database Index A mechanism to locate and
access data within a database. An index may
quote one or more columns and be a means of
enforcing uniqueness on their values.
Database Instance One set of database
management processes and an allocated area
in memory for managing those processes.
Typically, a database instance is associated
with one database. Note that a database
instance may process data for one or more
applications.
Database Management System (DBMS) A
software environment that structures and
manipulates data, and ensures data security,
recovery, and integrity.
Database Package An Oracle database object
comprised of PL/SQL code allowing execution
of code at the server based on specific events or
triggers.
Database Schema see ORACLE ID.

Glossary G - 7

Dataflow A named flow of information

between business functions, datastores, and
external entities represented as an arrow on a
dataflow diagram; see also BUSINESS
FUNCTION, DATASTORE , and EXTERNAL
ENTITY.
Deliverable Something a project must produce
in order to meet its objectives. A deliverable
must be tangible and measurable.
Deliverable Component A part or section of a
deliverable. A deliverable component may be
the output of a task step.
Deliverable Guideline A detailed description
of a deliverable that includes: detailed
description, usage, audience, and distribution,
format guidelines, control, template, and
samples; see also DELIVERABLE.
Deliverable Management The process of
managing the creation, review, modification,
and distribution of deliverables provided to a
client. Software may be included as one of the
managed deliverables.
Deliverable Template A tool designed to aid
in production of a deliverable; a template that
gives the format and structure of a deliverable;
see also DELIVERABLE.
Dependency 1. An indication that one task
cannot begin until another task has ended, or
progressed to a certain specified level of
completion; see also PREDECESSOR and
SUCCESSOR. 2. A relationship between two
modeling elements, in which a change to one
modeling element (the independent element)
will affect the other modeling element. (UML
1.1 Semantics)

G - 8 Glossary

Deployment The total set of activities

associated with the production implementation
of a set of applications in specific location(s) at
a particular point in time.
Distributed Database A database that is
physically located on more than one computer
processor. It is connected via some form of
communications network. An essential feature
of a true distributed database is that users or
programs work as if they had access to the
whole database locally.

E
End User see USER.
Enterprise Technical Architecture (ETA) A
series of rules, guidelines, and principles used
by an organization to direct the process of
acquiring, building, modifying, delivering, and
integrating Information Technology resources
throughout the enterprise. These resources can
include equipment, software, business
processors, protocols, standards,
methodologies, IT organizational structures
and more.
Entity A thing of significance, whether real or
imagined, about which information needs to be
known or held. It is implemented in a database
as one or more tables.
Estimate A preliminary calculation of the time
and cost of work to be undertaken. The
construct option calculates estimates using
bottom-up, percent adjustment, or top-down
techniques in Project Bridge Modeler; see also
BOTTOM-UP ESTIMATE, PERCENT ADJUSTMENT
ESTIMATE, WORK ESTIMATE, and TOP-DOWN
ESTIMATE.

EMM Method Handbook

Estimating Factor (EF) A metric that describes

an important project characteristic, used to
estimate either the amount of effort that project
tasks will take, or project risk or complexity.
The best EFs are those that represent counts
(number of users, objects); see also BOTTOM-UP
ESTIMATE.
ETA see ENTERPRISE TECHNICAL
ARCHITECTURE .

F
Feedback Response, including corrections,
additions, and approval, elicited from users,
stakeholders, sponsors, and others, to any
deliverable or deliverable component.
Financial Organization A business
organization that performs one or more
financial business functions. The data is
segregated for organizational management or
security. When mapped onto Oracle
Applications, a financial organization is
required to have a defined set of books. This
concept is more general than the set of books. It
is replacing the set of books as the key financial
application functional configuration parameter
in releases of Oracle Applications starting with
10.6.
Flexfield A user-definable field in an Oracle
Application that is made up of segments. Each
segment has a name you assign and a set of
valid values.

G
Gap A gap is a relationship between a
requirement and an application function where
the standard application function will not meet
the requirement.

Oracle Method

Gap Analysis 1. The process of determining,

documenting, and approving the variance
between business requirements and system
capabilities in terms of packaged application
features and technical architecture. 2. The
process of determining and evaluating the
variance or distance between two items
properties being compared. 3. The process of
determining and documenting the variance
between a business vision and the existing
processes and organization.

H
Helptext see METHOD HELPTEXT .

I
Impact Analysis The process of understanding
the complete effect of a particular change; see
also CHANGE REQUEST.
Implementation 1. The installation of an
increment of the data warehouse solution that
is complete, tested, operational, and ready. An
implementation includes all necessary
software, hardware, documentation, and all
required data. 2. A definition of how
something is constructed or computed. For
example, a class is an implementation of a type,
a method is an implementation of an operation.
(UML 1.1 Semantics)
Information Systems (IS) A system for
managing and processing information, usually
computer-based. Also, a functional group
within a business that manages the
development and operations of the business
information systems.

Glossary G - 9

Installation The loading of an instance of an

application system that is complete, tested,
operational, and ready. An installation
includes all necessary software, hardware
(including terminals, networks, etc.) and
documentation, and includes all required data;
see also APPLICATION SYSTEM.
Instance 1. An entity to which a set of
operations can be applied and which has a
state that stores the effects of the operations.
(UML 1.1 Semantics). 2. See DATABASE
INSTANCE.
Integration Test A sequence of steps or set of
procedures to verify the inter-operability of
various system components; see also SYSTEMS
INTEGRATION TEST.
Interface 1. A linkage between systems which
can be either automated (via software
programs) or procedural (manual). 2. A
declaration of a collection of operations that
may be used for defining a service offered by an
instance. (UML 1.1 Semantics).
IS see INFORMATION SYSTEMS .
IS Organization The organizational unit
responsible for planning, developing and
maintaining automated systems in an
organization.
IS Strategy A long term plan that focuses on
business processes, organization, and
technology. It identifies where to apply
information systems within the business and
how to set the objectives for each of those
systems.

G - 10 Glossary

Iterated Task A task that is repeated in order

to increase the quality of the deliverable to a
desired level or to add more detail to the
deliverable.

J
K
Key Deliverable A major deliverable that is
usually reviewed with the client, signed off,
and placed under change control; see also
DELIVERABLE.

L
M
Management The process of planning,
controlling, and completing the execution of an
undertaking.
Manual Function A business function that is
not system-assisted; see also BUSINESS
FUNCTION and SYSTEM-ASSISTED.
Mapping A technique for establishing
application fit to business requirements,
identifying gaps and proposing initial
solutions. Also a technique to define the
relationship between objects; see also
APPLICATION FIT and MATRIX DIAGRAM.
Mapping Scenario A plan for and record of
business solution testing including: business
processes involved in the test, the business
conditions that are needed to test the
application system, definition of test script
execution, support tools required during
execution of the test, and a record of test
actions; see also BUSINESS SOLUTION TESTING.

EMM Method Handbook

Method 1. A system of doing things and

handling ideas. A method establishes a
network of common tasks, a vocabulary, a set of
common processes, estimates, and guidelines
for delivering services. 2. The implementation
of an operation. It specifies the algorithm or
procedure that effects the results of an
operation (UML 1.1 Semantics).
Method HelpText The automated form of
Oracle Methods handbooks included with
every route. This may be accessed directly from
the Windows desktop or from within Project
Bridge Modeler or Project Workbench; also
called online help.
Module A logical program unit. Examples
include: forms, reports, user exits, C programs,
PL/SQL procedures, and database triggers; see
also PRIMARY MODULE and SUPPORTING
MODULE.
Multiply Instantiated Task A task that may be
performed at various times during a project,
such as status reports or healthchecks, or a task
that is partitioned on a project plan, for
example, by multiple teams or functional areas.
Multiply Occurring Task A task that is
repeated at specific, known times during a
project. A multiplying occurring task is similar
to a multiply instantiated task, except the
specific occurrences of the task can be planned
at the method level. Each occurrence has
specific task dependencies which determine
when it occurs.

N
Normalization A technique to eliminate data
redundancy.

Oracle Method

O
Objective A statement of business intent that
may be measured quantifiably.
OM see ORACLE METHOD.
Ongoing Task A task that occurs continuously
throughout a project, rather than at a specific
known time.
Operational System A system which supports
the operations of the clients business. These
systems may be missions critical systems or
support systems.
Optional Tasks Additional tasks that may
need to be completed during migration due to
specific client circumstances.
Oracle Method (OM) Oracle Services'
integrated service methodology which consists
of workplans, handbooks, and templates used
to provide enterprise business system
solutions.
Organization see BUSINESS ORGANIZATION.

P
PBM see PROJECT BRIDGE MODELER.
Phase A chronological grouping of tasks in an
approach. Services are delivered by phase in
order to reduce project risk. Each phase allows
a checkpoint against project goals, and
measurement against quality criteria to be
made.
PJM see PROJECT MANAGEMENT METHOD.

Glossary G - 11

Plan A scheme, method or design for the

attainment of some objective or to achieve
something.
Planning (M&D) A high-level business
function responsible for manufacturing and
distribution planning for one or more
manufacturing and distribution business units;
often synonymous with a business
organization; see also BUSINESS
ORGANIZATION TYPE.
Policy A guiding principle, typically
established by senior management, which is
adopted by an organization or project to
influence and determine decisions.
Prerequisite Something needed by a task,
which is produced by a previous task or an
external source; see also DELIVERABLE.
Problem A perceived variance between the
expected and observed ability of an item to
fulfill its defined purpose.
Process 1. The sequential execution of
functions triggered by one or more events. 2. A
discipline or sub-project that defines a set of
tasks related by subject matter, required skills
and common dependencies. A process usually
spans several phases in an approach.
Examples are: Data Conversion, Testing,
Documentation; see also BUSINESS PROCESS
and SYSTEM PROCESS.
Process Analysis A component of a business
requirements scenario that facilitates
quantitative analysis and measurement of each
process step and compares the current to the
proposed process in order to sell change to
management and to key business people and
systems users.

G - 12 Glossary

Program 1. A set of coded instructions that a

computer executes or interprets to perform an
automated task. 2. A interrelated group of
projects that are either being run concurrently
or sequentially and that share a system goal.
Individual projects may have different goals,
however the combined set of projects will have
a program goal.
Program Library The physical location,
typically a networked server, used as a shared
repository for all program information
produced during the life of a program.
Contents include issue logs, meeting minutes,
status reports, deliverable documents, working
papers, project plans, standards, tools, and
configured software deliverables. The library is
designed to facilitate access to all archived
program and project deliverables by all
members of a program.
Project A set of work processes, tasks with
associated deliverables and resources executed
over a specific period of time with
predetermined budget and business objectives.
Project Bridge Modeler (PBM) Applied
Business Technology tool used to build the
project planning and estimating system. PBM
allows project managers to select, edit, combine,
and create project workplans or routes, that
best fit the needs of the client.
Project Management Method (PJM) A method
which defines how a project is managed when
executed according to the requirements of
Oracle Method.
Project Milestone A significant project event.
Project Objectives The set of criteria for
measuring a projects success.

EMM Method Handbook

Project Workbench (PW) Applied Business

Technology tool used to schedule, track, and
analyze your project. PW provides work
breakdown structures based on the routes
selected in Project Bridge Modeler and provides
the capability to manage these plans.
Project Workplan A specification of the work
to be performed for a project, expressed as a set
of interdependent tasks with project resources
allocated over time.
Prototype A facsimile of an end product used
to demonstrate a concept rapidly, check
feasibility, or gain acceptance.
Prototyping The construction of a partial
system to demonstrate some aspect or aspects
of the intended system behavior in order to gain
user acceptance or to establish technical
feasibility.
PW see PROJECT WORKBENCH.

Q
Quality Audit An audit used to assess the
adherence of the project team to plans,
procedures, and standards.

R
RDBMS see RELATIONAL DATABASE
MANAGEMENT SYSTEM.

Oracle Method

Reference Materials Documents that describe

key aspects or samples for the current business.
These are normally compiled before the project
starts and may have been used during the presales cycle.
Relational Database Management System
(RDBMS) A database management system in
which data can be viewed and manipulated in
tabular form. Data can be sorted in any order
and tables of information are easily related or
joined to each other.
Role A classification of staff member used on a
project. Examples are: analyst, application
developer, system architect; see also RESOURCE.

S
Scenario A discrete instance of a system
process; see also MAPPING SCENARIO.
Scope The boundaries of a project expressed in
some combination of geography, organization,
applications or business functions.
Scope Creep The common phenomenon where
additional requirements are added after a
project has started without reconsidering the
resourcing or timescale of the project. Scope
creep arises from the misapprehension that
such small additions will not affect the project
schedule.
Script 1. A sequence of coded instructions
executed or interpreted by computer programs.
2. A prescribed set of steps to follow when
testing.
Security Profile A list of role-based security
specifications.

Glossary G - 13

Sign-off Agreement with a client of the

successful completion of a project, project
phase, or deliverable.
Singly Instantiated Task A task which occurs
once, at a specific time, during a project.
SQL see STRUCTURED QUERY LANGUAGE .
Standard A set of rules for measuring quality.
Usually, standards are defined for products
deliverables or deliverable components and
processes.
Structured Query Language (SQL) The ANSI
internationally accepted standard for relational
database systems, covering not only query but
also data definition, manipulation, security,
and some aspects of referential and entity
integrity; see also ANSI.
Swim Lane see AGENT CHANNEL.
System A named, defined, and interacting
collection of procedures and processes, along
with the organized deployment of people,
machines, various mechanisms, and other
resources that carry out those procedures and
processes; see also APPLICATION SYSTEM.
System Architecture A representation of the
structure of an application system usually
confined to essentials.
System Facility A part of an information
system that supports an identifiable set of
business functions. A facility may be a single
module or it may be a whole sub-system.
System Interface The mechanism used to
create connectivity between two systems.

G - 14 Glossary

System Test A project activity that tests an

application system over its complete life-cycle,
using scripts and associating scenario test
specifications into chronological sequences.

T
Task A unit of work that done in delivering a
service. A task is the smallest trackable item on
a project plan, and forms the basis for a work
breakdown structure. The minimum elapsed
time for a task iteration or instantiation should
be one day. The maximum should be two
weeks; see also WORK BREAKDOWN
STRUCTURE .
Task Dependency The relationship between
two tasks where the start or end date of the
successor task is constrained by the start or end
date of the predecessor task.
Task Dependency Network A network of
tasks and task dependencies where each node
is a task and each link is a task dependency;
see also CRITICAL PATH METHOD (CPM)
NETWORK.
Task Group A set of tasks that should be
treated similarly. For example, they should be
performed at the same time, should be iterated
as a group, should be multiply instantiated as a
group. A task group is represented on a
process flow diagram by enclosing the tasks in
a rectangle.
Task Step A discreet step to be done in
executing a task.
Technical Architecture The physical
hardware, network configuration, and software
tools that support the system architecture.

EMM Method Handbook

Template A predefined set of models that may

be used to jump start or expedite analysis
activities. The template may represent a
functional area, industry, or enterprise. It may
be for validating information; data acquisition;
metadata; and data access requirements.

Template Workplan A model workplan for a

method approach used as the starting point for
developing a project workplan. A template
workplan becomes a project workplan when
scheduling is applied.

Test Environment A combination of software

and possibly hardware that provides a stable
environment in which to test newly developed
software without elaborate preparation. A test
environment might provide test data; data
structures; test scripts; automatic test execution;
test results recording; and test results analysis.
Test Script A document consisting of a test
specification, a test data profile and
instructions for performing a test.
Third-generation Programming Language
(3GL) A programming language that uses
procedural definitions to carry out tasks, and
typically uses record-by-record processing of
data. Procedural 3GL language structures
include if....then....else, do....while statements and
others.

Unit Test see MODULE TEST.

User A person who uses a system to perform a
business function.

Version The rendering of a configuration item

which incorporates all of its revisions starting
from a given point.

W
WBS see WORK BREAKDOWN STRUCTURE .
Work Breakdown Structure (WBS) An
organization of project tasks into a hierarchy
for scheduling and reporting progress.

X
Y
Z

Tool Software applications, deliverable

templates, or any other utility suggested to
facilitate the completion of a particular task.
Top-down Estimate A high-level work effort
estimate. This type of estimate is derived by
taking a total project estimate and dividing it
among the projects phases, activities, and
tasks.

Oracle Method

Glossary G - 15

Abbreviations
ACCEPT
ALT
ANAL
APP
ARCH
ASSUMP
BKP
BLD
BUS
CERT
COND
CONFIG
CONSID
CORR
CTRL
CURR
DB
DEFN
DELIV
DESC
DESN
DESRD
DET
DEV
DFD
DIAG
DM
DOCN
DW
ENTY
ENV
ERR
ETT

EXCEP
EXG
EXT
FEAT

G - 16 Glossary

acceptance
alternative
analysis
application
architecture
assumption
backup
build
business
certificate
condition
configuration
consideration
corrective
control
current
database
definition
delivery
description
design
desired
detailed
development
dataflow diagram
diagram
data model
documentation
data warehouse
entity
environment
error
extraction,
transformation and
transportation
exception
existing
external
feature

FH

function hierarchy

FM
FOUNDN
FUNCN
FUNCNL
FUNCNY
HL
HW
INFO
INIT
INT
INTERF
INTGN
LEVL
LOC
MATX
MDU
MECH
MGMT
OPERL
PERF
PM
PRELIM
PROC
PRODN
PROJ
PRTZD
QLTY
RECOV
REQ
RESPDNG
REVD
SPEC
ST
STD
STRTGY
STRUCT
SW

function model
foundation
function
functional
functionality
high-level
hardware
information
initial
internal
interface
integration
level
location
matrix
module data usage
mechanism
management
operational
performance
process model
preliminary
procedure
production
project
prioritized
quality
recovery
requirement
responding
revised
specification
state
standard
strategy
structure
software

EMM Method Handbook

SYS
TECHL
TRANS

Oracle Method

system
technical
transition

Glossary G - 17