Beruflich Dokumente
Kultur Dokumente
APPLICATION IMPLEMENTATION
PROCESS AND TASK REFERENCE
Volume 1 Controlled Production Release 2.0.0
November, 1996
Application Implementation Method (AIM) Process and Task Reference, Volume 1, Controlled Production Release 2.0.0 Part No. C11179-1 Copyright 1996, Oracle Corporation All rights reserved. Printed in the U.S.A. Authors: Contributors: Jennifer Bennett, Anne Blaylock, Jim Lange, Craig Martell, Joseph Mychaleckyj, Janet Price, Bob Reary Loretta Anderson, Tom Coen, Mike Conners, Cedric Dettmar, Bill Dunkley, David Hardy, Karim Hatoum, Tom Heimburger, Venkatesh Kumar, Nicki Matushak, Cary Millsap, Jim Szafranski, John Webb, Walt Zerkow Linda Cherney, Tom Kauth, Odile Sullivan-Tarazi
Editors:
The programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be licensees responsibility to take all appropriate fail-safe, back up, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and Oracle disclaims liability for any damages caused by such use of the Programs. This software/documentation contains proprietary information of Oracle Corporation; it is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this software/documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable: Restricted Rights Legend Programs delivered subject to the DOD FAR Supplement are commercial computer software and use, duplication and disclosure of the Programs shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are restricted computer software and use, duplication and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data -General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. 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. Oracle Corporation does not warrant that this document is error free. ORACLE, Designer/2000, Developer/2000, SQL*Plus, SQL*Loader, SQL*Net, CASE*Method, ORACLE Parallel Server, PL/SQL, Pro*C, SQL*Module are registered trademarks of Oracle Corporation, Redwood City, California. Oracle Cooperative Applications, Oracle Financials, Oracle Alert, Oracle Manufacturing, Oracle Inventory, Oracle Bills of Material, Oracle Engineering, Oracle Capacity, Oracle Commissions, Oracle Master Scheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, Oracle Assets, Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables, Oracle Personnel, Oracle Payroll, Oracle Purchasing, Oracle Quality, Oracle Sales and Marketing, Oracle Service, and Application Object Library are trademarks of Oracle Corporation, Redwood City, California. Microsoft and MS-DOS are registered trademarks and Windows, Word for Windows, Powerpoint, Excel, and Microsoft Project are trademarks of Microsoft Corporation. Visio is a trademark of Shapeware Corporation. Project Workbench and Project Bridge Modeler are registered trademarks of Applied Business Technology. All other company or product names mentioned are used for identification purposes only and may be trademarks of their respective owners.
Preface
he Application Implementation Method (AIM) defines a set of organized and flexible process steps which guide project teams through an implementation of Oracle Applications. The Application Implementation Process and Task Reference provides detailed descriptions of these process steps, or tasks. This reference, and the Application Implementation Method itself, are part of Oracle Method Oracles integrated approach to solution delivery.
Oracle Method
Preface i
Audience
The Application Implementation Process and Task Reference is written for project managers, application implementors, and technical staff. Application implementors and technical staff use this reference in detail to execute tasks in AIM. Project managers use this reference as a task overview that will facilitate their ability to manage task execution.
ii Preface
Task Steps Approach and Techniques Role Contribution Deliverable Guidelines Tools Appendix A: This appendix is a cross-reference of task IDs between version 1.1 and version 2.0 of AIM. Appendix B: This appendix provides a brief description of each AIM role, highlighting the main role responsibilities. Glossary: The Glossary contains definitions of terms, abbreviations, and acronyms that are used in AIM.
Oracle Method
Preface iii
iv Preface
Reference: Hickman, Linda, and Longman, Cliff. Case*Method Business Interviewing. Addison-Wesley, 1994. ISBN 0-2-1-59372-6, Oracle Part Number A23446. Web Site Information available on the World Wide Web will be indicated by a Web symbol and an appropriate Web address. Here is an example: Web Site: Pure Atria Corporations Home Page on the World Wide Web is http://www.pure.com/
Related Publications
The AIM suite consists of the following: AIM Method Handbook AIM Process and Task Reference - volume 1 (this book) AIM Process and Task Reference - volume 2 You may also refer to the following Project Management suite of reference books: PJM Method Handbook PJM Process and Task Reference PJM Deliverable Reference
Oracle Method
Preface v
vi Preface
CONTENTS
VOLUME
INTRODUCTION
CHAPTER
Business Requirements Definition (RD) ...............................................1-1 RD.010 - Identify Financial and Operating Structure............................1-11 RD.020 - Conduct Current Business Baseline ........................................1-18 RD.030 - Develop Future Process Model ...............................................1-35 RD.040 - Develop Future Business Function Model..............................1-63 RD.050 - Establish Process and Mapping Summary .............................1-73 RD.060 - Gather Business Volumes ........................................................1-80 RD.070 - Create Business Requirements Scenarios ...............................1-86 RD.080 - Determine Audit and Control Requirements....................... 1-101 RD.090 - Identify Business Availability Requirements .......................1-111 RD.100 - Develop Reporting Requirements .........................................1-118
Oracle Method
Contents vii
CHAPTER 2
Business Requirements Mapping (BR)..................................................2-1 BR.010 - Prepare Mapping Environment ...............................................2-13 BR.020 - Map Business Requirements ....................................................2-19 BR.030 - Map Business Data....................................................................2-41 BR.040 - Conduct Integration Fit Analysis.............................................2-46 BR.050 - Develop Information Flow Model ...........................................2-52 BR.060 - Develop Information Access Model ........................................2-61 BR.070 - Conduct Reporting Fit Analysis ..............................................2-68 BR.080 - Test Business Solutions.............................................................2-77 BR.090 - Confirm Integrated Business Solutions ...................................2-93 BR.100 - Create Process Narratives ........................................................ 2-98 BR.110 - Define Application Setups...................................................... 2-110 BR.120 - Design Security Profiles.......................................................... 2-119
CHAPTER
Application and Technical Architecture (TA).......................................3-1 TA.010 - Define Architecture Scope, Objectives, and Approach .........3-23 TA.020 - Prepare Architecture Strategy ................................................. 3-32 TA.030 - Establish Architecture Requirements......................................3-42 TA.040 - Develop Conceptual Architecture...........................................3-51 TA.050 - Conduct Technical Architecture Baseline...............................3-67 TA.060 - Develop System Availability Strategy ....................................3-78 TA.070 - Define Future Application Deployment .................................3-91 TA.080 - Develop Reporting Strategy ....................................................3-99
viii Contents
TA.090 - Revise Conceptual Architecture ............................................3-115 TA.100 - Define Architecture Subsystems............................................3-121 TA.110 - Propose Architecture Subprojects .........................................3-131 TA.120 - Design Application Security Architecture............................3-137 TA.130 - Design Application Functional Architecture........................3-147 TA.140 - Design Logical Application and Database Architecture .....3-164 TA.150 - Design Physical Database Architecture ................................3-175 TA.160 - Design Hardware and Network Architecture......................3-188 TA.170 - Develop System Capacity Plan..............................................3-196 TA.180 - Assess Performance Risks......................................................3-223 TA.190 - Design System Management Procedures..............................3-230 CHAPTER 4 Module Design and Build (MD).............................................................4-1 MD.010 - Prepare Customization Strategy ............................................4-17 MD.020 - Define and Estimate Custom Extensions...............................4-24 MD.030 - Define Design Standards ........................................................4-40 MD.040 - Define Build Standards ...........................................................4-47 MD.050 - Design Database Extensions...................................................4-53 MD.060 - Produce Module Functional Design ......................................4-59 MD.070 - Produce Module Technical Design ........................................4-67 MD.080 - Review Detailed Designs ........................................................ 4-74 MD.090 - Prepare Development Environment ......................................4-79 MD.100 - Implement Database Extensions ............................................4-85
Oracle Method
Contents ix
MD.110 - Create Custom Modules ......................................................... 4-88 MD.120 - Create Installation Routines ...................................................4-95 VOLUME CHAPTER 2 5 Data Conversion (CV)..................................................................................5-1 CV.010 - Define Conversion Scope, Objectives, and Approach ...........5-12 CV.020 - Prepare Conversion Strategy...................................................5-21 CV.030 - Prepare Conversion Standards................................................5-29 CV.040 - Prepare Conversion Environment...........................................5-33 CV.050 - Perform Conversion Data Mapping........................................5-38 CV.060 - Design Manual Conversion Strategy ......................................5-45 CV.070 - Design Conversion Programs..................................................5-51 CV.080 - Prepare Conversion Test Plans................................................5-62 CV.090 - Develop Conversion Programs ...............................................5-69 CV.100 - Perform Conversion Unit Test ................................................ 5-78 CV.110 - Perform Conversion Business Object Tests............................5-82 CV.120 - Perform Conversion Validation Test ......................................5-86 CV.130 - Install Conversion Software ....................................................5-90 CV.140 - Convert and Verify Data..........................................................5-94 CHAPTER 6 Documentation (DO) ................................................................................6-1 DO.010 - Prepare Glossary......................................................................6-10 DO.020 - Specify Documentation Requirements ...................................6-14 DO.030 - Determine Documentation Standards and Procedures ........6-20
x Contents
DO.040 - Prepare Documentation Environment ...................................6-26 DO.050 - Produce Documentation Prototypes and Templates ............6-30 DO.060 - Produce Initial User Reference Manual..................................6-36 DO.070 - Produce Initial User Guide......................................................6-40 DO.080 - Produce Initial Technical Reference Manual..........................6-46 DO.090 - Produce Initial System Management Guide ..........................6-52 DO.100 - Complete User Reference Manual ..........................................6-57 DO.110 - Complete User Guide ..............................................................6-60 DO.120 - Complete Technical Reference Manual ..................................6-63 DO.130 - Complete System Management Guide...................................6-67 DO.140 - Provide Online Help Text........................................................6-71 CHAPTER 7 Business System Testing (TE) .................................................................7-1 TE.010 - Develop Testing Strategy.......................................................... 7-12 TE.020 - Develop Unit Test Scripts .........................................................7-21 TE.030 - Develop Link Test Scripts.........................................................7-28 TE.040 - Develop System Test Scripts ....................................................7-35 TE.050 - Develop Systems Integration Test Scripts ...............................7-42 TE.060 - Prepare Testing Environments.................................................7-46 TE.070 - Perform Unit Test......................................................................7-54 TE.080 - Perform Link Tests ....................................................................7-60 TE.090 - Perform Installation Test .......................................................... 7-65 TE.100 - Prepare Key Users for Testing..................................................7-68
Oracle Method
Contents xi
TE.110 - Perform System Testing............................................................7-73 TE.120 - Perform Regression Testing .....................................................7-82 TE.130 - Perform Systems Integration Testing ......................................7-87 TE.140 - Support Acceptance Test .......................................................... 7-93 CHAPTER 8 Performance Testing (PT) ........................................................................8-1 PT.010 - Define Performance Testing Scope, Objectives, and Approach............................................................................8-25 PT.020 - Prepare Performance Testing Strategy ....................................8-33 PT.030 - Identify Performance Test Scenarios .......................................8-42 PT.040 - Identify Performance Test Transaction Models......................8-54 PT.050 - Create Performance Test Scripts .............................................. 8-64 PT.060 - Design Performance Test Transaction Programs....................8-71 PT.070 - Develop Performance Test Transaction Programs .................8-77 PT.080 - Design Performance Test Data................................................. 8-81 PT.090 - Design Test Database Load Programs.....................................8-92 PT.100 - Develop Test Database Load Programs ..................................8-97 PT.110 - Construct Performance Test Database .................................. 8-102 PT.120 - Prepare Performance Test Environment ............................... 8-107 PT.130 - Execute Performance Test ......................................................8-118 PT.140 - Create Performance Test Report ............................................ 8-124 CHAPTER 9 Training (TR).............................................................................................9-1 TR.010 - Prepare Training Strategy ........................................................9-11 TR.020 - Prepare Project Team Training Environment .........................9-18
xii Contents
TR.030 - Conduct General Education Classes........................................9-23 TR.040 - Conduct High-Level Overview of Application Features.......9-27 TR.050 - Prepare Project Team Training.................................................9-31 TR.060 - Train Project Team ....................................................................9-37 TR.070 - Develop User Training Materials.............................................9-42 TR.080 - Prepare User Training Environment .......................................9-47 TR.090 - Train Users.................................................................................9-52 CHAPTER 10 Production Migration (PM) .....................................................................10-1 PM.010 - Prepare Transition Strategy...................................................10-14 PM.020 - Design Production Support Infrastructure ..........................10-19 PM.030 - Develop Detailed Transition and Contingency Plan...........10-25 PM.040 - Prepare Production Environment .........................................10-34 PM.050 - Set Up Applications ...............................................................10-40 PM.060 - Implement Support Infrastructure........................................10-47 PM.070 - Verify Production Readiness.................................................10-52 PM.080 - Commence Production ..........................................................10-60 PM.090 - Audit Production System ...................................................... 10-64 PM.100 - Measure System Performance...............................................10-69 PM.110 - Maintain System.....................................................................10-75 PM.120 - Refine Production System .....................................................10-81 PM.130 - Decommission Former System..............................................10-86 PM.140 - Propose Future Business Direction.......................................10-91
Oracle Method
Contents xiii
PM.150 - Propose Future Technical Direction .....................................10-95 APPENDIX A Task Cross-Reference ..............................................................................A-1 Cross-Reference Version 1.1 ID to Version 2.0 ID..................................A-2 Cross-Reference Version 2.0 ID to Version 1.1 ID................................A-11 APPENDIX B AIM Roles ................................................................................................. B-1 Role Descriptions ...................................................................................... B-2 GLOSSARY
xiv Contents
Introduction
P
rocesses and tasks are the building blocks from which project managers construct Application Implementation (AIM) projects. The AIM Process and Task Reference provides the details for every Application Implementation process and for every task within a process. This introduction defines the concepts of process and task, and provides additional information for each.
Oracle Method
Introduction xv
What Is a Task?
A task is a unit of work that results in the output of a single, measurable deliverable. Tasks are the most elementary unit of work in a project plan and provide the basis of the work breakdown structure. Project progress is most often measured by the successful completion of tasks. Usually one team member has overall responsibility for the deliverable, although many others may contribute, review, and approve its contents.
xvi Introduction
Deliverables
AIM is a deliverable-based method. This means that each task produces a single deliverable, or output, whose quality you can measure. Deliverables can have many formats, such as documents, schedules, program code, or test results. Each deliverable has the same ID as its corresponding task. Each deliverable also has a unique name, which the text always refers to using title capital letters. An example is the Initial System Management Guide. If you know the name of a deliverable, you can find its ID, and the name of its corresponding task, by using Appendix A.
Prerequisites
Each task assumes that certain things (such as information, programs, hardware platforms, and so on) have been previously produced or compiled and are available for use. In most cases, these prerequisites of the task are specific deliverables of previous tasks. In some cases, they are expected from the user organization. Each detailed task guideline lists that tasks prerequisites. Under each prerequisite is an indication of which components or specific information within the prerequisite is used in the task.
Task Steps
Tasks are broken down into smaller units of work called task steps. The person responsible for the task (the task owner) may want to change those steps to make them appropriate to the implementation approach, the tools, and resources that are available. Task steps frequently produce deliverable components that may be diagrams, worksheets, or text. Collectively these components become the task deliverable. Any set of task steps that produces the deliverable is acceptable as long as it includes adequate quality assurance steps. Gathering relevant material, reviewing documents, or discussing project topics may also be listed as task steps. Completing these activities may
Oracle Method
Introduction xvii
not produce a deliverable component, but the task step is essential in the overall creation of the deliverable. A task step may also produce an outcome that is listed as a deliverable component but actually stands alone. For example, a task step named unit test programs is considered complete when the appropriate source code is tested. The deliverable component, tested source code, is not integrated into a task deliverable. Another example is the task step, set up applications. Its deliverable component, setup data, is not incorporated into a task deliverable.
Role Contribution
In addition to the task owner, many other project team members may spend time on a task. Each of these team members will be fulfilling a particular role. Their responsibilities may be to contribute, analyze, document, set up, review, administer, or control information. The effort they spend on the task may be significant or nominal. Each detailed task guideline provides a list of roles that may play a part in completing the task, along with a percentage of the total task time that each role may contribute. These are suggestions that can be used in planning. Actual role contributions will depend on the assignment of task steps by the task owner.
xviii Introduction
What Is a Process?
Major project objectives are achieved by processes. A process is a series of tasks that results in one or more critical project deliverables. The tasks in a process are usually highly dependent upon one another, and often span much of the project. For example, the Data Conversion process begins early in the implementation life cycle by defining the scope and strategy of the conversion project. This is followed by designing and building the programs and tools for conversion. After testing, the data is converted and available for production. Figure I-1 shows the processes that are a part of AIM and their relative duration.
Business Requirements Definition Business Requirements Mapping Application and Technical Architecture Module Design and Build Data Conversion Documentation Business System Testing Performance Testing Training Production Migration
Figure I-1
Process Guidelines
Each chapter of the AIM Process and Task Reference is devoted to a single process. The first part of each chapter gives guidelines on the process as a whole. It shows the relationships of tasks within the process and lists the process tasks and deliverables. It also includes the key role responsibilities and the critical success factors.
Oracle Method
Introduction xix
Task: This symbol shows a task that is part of AIM. The text gives the AIM ID and the task name.
External Task: This symbol depicts a task that should be performed, but is not part of the process in which it appears. It may belong to another AIM process or be external to AIM. External tasks do not have a task ID. Multiples of a Task Deliverable: This task is performed by individuals or teams, each using different subject matter to produce the same deliverable. For example, during the Business Requirements Definition, you may have teams that focus on manufacturing, distribution, and financials independently, and each team would then produce a Current Business Baseline for their process area. Iterative Arrow: An iterative arrow indicates that a task activity will normally be repeated multiple times until the task deliverable is successfully achieved. Decision: A decision indicates two or more possible branches to the process flow, depending upon the outcome of the stated question. A decision symbol does not indicate another task all work that is done in order to indicate a particular outcome is included in previous tasks.
Test Successful?
xx Introduction
Process Flow: An arrow between two tasks indicates that the task at the end of the arrow cannot start until the previous task has been completed. Example: you cannot start the task Train Project Team until you have completely finished the task Prepare Project Team Training. Key Document Deliverable: This icon represents an important textual output of the process. It includes the name of the deliverable.
BR.100 Process Narratives
Key Software Deliverable: This icon represents an important software product of the process.
Conversion Modules
Major Prerequisite: A key input deliverable for a task. The name of the deliverable and the ID of the task that produces the deliverable are given. Different symbols may be used to represent the medium of the deliverable. Role: Each diagram is divided horizontally into sections or agent channels. Each agent channel is labeled with a role. All tasks within that section are the responsibility of that project role.
Technical Writer
Attention: Because of limited space in the diagrams, Major Prerequisites and Key Deliverables may sometimes appear in the agent channel above or below where they belong. To determine the correct agent channel, examine the lines connecting the Major Prerequisites and Key Deliverables to tasks.
Oracle Method
Introduction xxi
CHAPTER
Business Requirements Definition Business Requirements Mapping Application and Technical Architecture Module Design and Build Data Conversion Documentation Business System Testing Performance Testing Training Production Migration
Figure 1-1
Oracle Method
Process Flow
Existing Reference Material RD.020 Business Analyst RD.020: Conduct Current Business Baseline
RD.020: Current Business Baseline RD.030 RD.030: Develop Future Process Model
TR.030 and TR.040 : Trained Project Team RD.040 RD.040: Develop Future Business Function Model
RD.060: Business Volume Requirements RD.050 RD.050: Establish Process and Mapping Summary RD.040: Future Business Function Model
Figure 1-2
Approach
The objective of the Business Requirements Definition process is to define the business requirements of the new applications system. These requirements are defined in terms of the business process models and the business requirements scenarios that will be driven by the future business model. To ensure that business needs are met, you will later map these requirements against application functions and features in Business Requirements Mapping. Business Requirements Definition uses a combination of top-down and bottom-up analytical techniques to obtain, understand, and document the objectives and requirements for the new application system. The key technique you use to drive the analysis is business process modeling, which builds process flow diagrams for each of the business processes. You use this technique in both the analysis of current business processes and the creation of future business processes. Business function modeling proceeds jointly and sometimes simultaneously with future process modeling. This technique organizes both system and manual (e.g., nonsystem) process steps by business function to create hierarchical models that represent how the business will run from a functional viewpoint. Decide early during implementation planning 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 for the project. If the management decides to conduct a current business baseline, then business analysts will conduct a series of interviews and process modeling sessions with the project sponsor, the functional managers, and the line employees. The purpose of the current business baseline is to understand and document how the current business system responds to business events. The tools used to gather the relevant information are application questionnaires, current business process models, and a current business function model. If you decide to accelerate the implementation and define future business processes supported directly by the Oracle Applications, the process of requirements definition will start with a process model heavily focused toward application functionality. This process model will then expand to include the manual process steps required to support system processes. The main tools you will use in this case will be the future process models and business requirements scenarios.
Oracle Method
The business analyst starts the process by conducting a workshop or series of interviews with the project sponsor and management representatives from the affected business area, thus identifying first the high-level processes that depict the current business circumstances. Business staff and users work in focus groups to identify all the business events to which they must respond in the course of their work. The business analyst prepares summary descriptions of the processes that are performed in response to those events. Working directly with the users responsible for executing those business processes, the business analyst constructs a detailed model for each process. The users identify and describe each step within the process, including the flow of work between the steps. Attention: Be careful not to confuse the concept of business process (e.g., entering an order, taking inventory) with the process of Business Requirements Definition. The Business Requirements Scenarios (RD.070) list the necessary steps for executing a business function within a business process; some of the steps may be application-specific, some may be manual. Once you develop the business requirements, you will later map them to applications. During Business Requirements Definition, you also: Gather business transaction and data volumes from the future business model to help assess the systems ability to support current and future business volume. Carefully document audit and control requirements to satisfy financial and quality policies. Identify the business operating requirements that the technical architecture will need to support. Analyze and consolidate reporting requirements for the business.
Deliverable Name Financial and Operating Structure Current Business Baseline Future Process Model Future Business Function Model Process and Mapping Summary Business Volume Requirements Business Requirements Scenarios Audit and Control Requirements Business Availability Requirements Master Report Tracking List
Objectives
The objectives of the Business Requirements Definition process are as follows: Understand the business and business area requirements for the Applications Implementation project. Understand and document the organizational and financial structure of the business. Obtain a detailed understanding of the future business processes that the new applications are intended to support, as well as the specific functions performed in those processes. Quantify the transaction and data volumes required by those processes. Develop a complete set of business requirement scenarios that can be used to map business requirements to application functionality.
Oracle Method
Define the audit and control requirements for the business information generated. Document the reporting requirements of the business entity.
Key Deliverables
The key deliverables of this process follow: Deliverable Financial and Operating Structure Description A depiction of the financial structure and the operating organizations of the company. An analysis of the current business processes and functions. Process Flow Diagrams of the events and business processes that the applications and functions of the business area will support. A catalog of elementary functions to be supported within future business processes. A summary of the key processes, business requirements, and mapping decisions. An inventory of key transaction and data volumes by business functional area.
Description A set of formal statements of the detailed business requirements for each 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. A statement of security, monitoring, and review of requirements for business transactions. A statement of what the business needs are in terms of operating hours, system uptime, and response and turnaround time. A consolidated master list of reporting requirements.
Reporting Requirements
Table 1-2
Key Responsibilities
The following roles are required to perform the tasks within this process: Role Application Expert Responsibility Provide answers to functionality questions. Support and provide interpretation for tools, templates, and methods.
Oracle Method
Responsibility Conduct interviews and working sessions. Identify business requirements and create business models. Perform analysis to resolve issues. Participate in interviews and working sessions, review and approve contents of models, and provide access to existing systems. Manage deliverables, assist in process integration, update deliverable status, and manage project data and documentation. Run the modeling sessions and keep momentum going. Conduct project planning and assign tasks, establish roles, brief project staff, manage team, manage changes, manage resolution of issues, maintain quality, and obtain approval. Ensure availability of users, review contents of models, ensure user commitment, facilitate resolution of major issues, review and approve deliverables. Approve deliverables. Review backup and recovery needs for new applications and technical architecture.
Configuration Manager
Facilitator
Project Manager
Project Sponsor
Role Users
Responsibility Participate in interviews and working sessions, review content of models, and communicate current business requirements and processes.
Business Requirements Definition Key Responsibilities
Table 1-3
Oracle Method
Deliverable
The deliverable for this task is the Financial and Operating Structure. This document portrays the legal entity structure, business organizations, financial operating environment, revenue (and/or cost) centers, and consolidation path. It may also catalog other business entities.
.
Prerequisites
Optional
You may need the following input for this task:
G
Information developed during the sales cycle may address the current financial and operating structure of the business.
Task Steps
The steps of this task follow: No. 1. 2. Task Step Review sales cycle material. Interview company management to obtain clear understanding of current and proposed company structure. Deliverable Component
Oracle Method
No. 3.
Task Step Develop chart showing current company structure. Develop business organization overview and listing. Define and chart the financial operating environment. Define the Financial and Management Reporting Environment. Review the Financial and Operating Structure with project management and secure approval. Review the Financial and Operating Structure with appropriate company management and secure approval.
4.
Business Organization Listing Financial Operating Environment Financial and Management Reporting Environment
5.
6.
7.
8.
Table 1-4
A companys operating structure drives the business and has a strong influence on the setup and use of the applications; however, the financial statements will reflect the operating structure to allow profitability, balance sheet and cash flow reporting and analysis against that structure. Reporting and analysis begin by capturing and valuing operational transactions that occur at the specific event level. These events occur at a specific site that must be properly defined and ultimately set up at the correct organizational level and with the appropriate organizational attributes.
Oracle Method
Consolidation Entities these may be of two varieties: a single set of books with a division segment in the General Ledger for the consolidation, or two (or more) sets of books consolidated into one parent set of books Set of Books a financial operating environment combining a particular chart of accounts, fiscal calendar, and functional currency Operating Units an operational business unit that uses a common order entry, receivables, payables, or purchasing function Reporting Entities entities that may have different management reporting requirements, depending on classification as revenue, cost, profit, or investment center Organizations a physical or logical site used in manufacturing or distribution which holds inventory or other assets
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Business Line Manager
Table 1-5 Role Contribution for Identify Financial and Operating Structure
% 100 *
Deliverable Guidelines
The Financial and Operating Structure deliverable allows you to capture all organizational structure information in one place. It provides a place for compiling all the relevant attributes of the organization to be addressed in setting up and running the applications.
Deliverable Components
The following components comprise the Financial and Operating Structure: Introduction Briefly introduce the business, state its business purposes and the way in which the present organization supports the business purpose.
Oracle Method
Legal Entity Structure Display the structure of the company in chart format, showing the highest level of consolidation at the top. Reflect the operating or geographical entities rolled up into the consolidated level. Attention: The example provided in the template actually shows two types of consolidations done with one organization structure: (1) the consolidation of three sets of books into a parent consolidated set of books, and (2) the division rollup of many locations into each of the three individual sets of books. Show the specific business units at which the operating events or business transactions occur beneath the operating or geographical entities. The specific business units represent those locations where manufacturing, inventory, order entry, purchasing, and other similar business processes and functions are executed. Business Organization Listing Write an overview for each of the business units, explaining the nature of the facilities, the events and processes engaged in, the type of products handled, and a preliminary statement of business volumes and staffing levels. For each organization, show an abbreviation code for the organization; the city, state, and country of each physical location; the type of organization; its primary functions; and a description and/or comments (examples of organization types are Finance, Manufacturing, Logistics, Sales, and so on). Financial Operating Environment Develop the financial structure in more detail, according to these elements: Chart of Accounts Functional Currency Accounting Calendar Legal Entity
All of the elements above are relevant for the General Ledger entries for the organization when it is performing a particular function on its own behalf or on behalf of another organization. Financial and Management Reporting Environment Categorize the enterprises locations by type of financial and management reporting requirements. Categorize each location based on its type of reporting structure.
Tools
Deliverable Template
Use the Financial and Operating Structure template to help you construct your deliverable. Select from the following components: Introduction Legal Entity Structure Business Organization Listing Financial Operating Environment Financial and Management Reporting Environment
Oracle Method
Deliverable
The deliverable for this task is the Current Business Baseline. It consists of the Current Business Process model, Process Questionnaires, and the Process Improvement and Redesign List. You may need to include other business process documentation as well.
Prerequisites
You need the following input for this task:
G
The team uses existing reference material to gain an understanding of the existing practices, processes, and systems that support the business objectives.
.
Task Steps
The steps of this task follow: No. 1. Task Step Define scope of current business analysis. Develop, schedule, and confirm process definition sessions by business areas. Deliverable Component
2.
No. 3.
Task Step Identify and describe the events to which the business processes respond. Identify the core business processes; write a summary description of each process; and identify the main inputs and outputs for each process. Conduct business process analysis meetings to further define each process. Conduct interviews and other process analysis and research as required. Construct process flow diagrams for those processes. Identify those processes that are candidates for redesign and process improvement. Gather any other current business materials that may enhance team understanding of current business processes. Identify any issues from current business analysis. Review the Current Business Baseline deliverable with users and management. Secure acceptance of deliverable.
4.
5.
6.
Process Questionnaires
7.
8.
9.
10.
11.
12.
Table 1-6
Oracle Method
Warning: The minimum requirement is to understand the integrated nature of current business processes and the business information needs of each process within and across high-level business functions, as well as across organizations.
Oracle Method
required inputs (for example, prerequisite deliverables) and assignments for obtaining them expected outputs and the criteria for successful closure of the session
Objectives
The objective of this task is to understand and document the main processes that drive the requirements for keeping the business running today. Side benefits include the opportunity to recognize potential process improvements to capitalize on the new application functionality and the ability to establish a current business benchmark against which to gauge the ultimate success of the new business model.
The primary technique for obtaining and validating the information in the model is through these interview, working, feedback, and review sessions. Hold a presentation session for each process as the final review and signoff session.
Oracle Method
Use local business terminology to facilitate development of content and to avoid becoming bogged down with misunderstood words, phrases, and concepts during the interview. Before using a questionnaire, think about how to organize the information (into families and categories) and reuse the questions to cover representative products and processes for each group. For instance, the process baseline for finished goods shipments may be completely different from that of the shipment of spare component parts. In this case, if you ask questions about only one class of material, you may miss critical information about how the business works. Although baseline information concerns the current business system, you can usually reuse much of the information during future business process modeling. For instance, current business process interview sessions should uncover a list of current events that drive business processes. The events identified should be very close to the future events.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Facilitator Business Line Manager Project Sponsor User
Table 1-7 Role Contribution for Conduct Current Business Baseline
% 90 10 * * *
Deliverable Guidelines
The Current Business Baseline document reflects a common understanding of your existing business processes. The objective is to gain an understanding of the integrated current business requirements. Process flow diagrams and reports from interviews with key members of the staff are the recommended components of this deliverable. This deliverable is an important input for developing the future business
process models, which in turn become the basis for mapping process scenarios to applications.
Deliverable Components
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. The 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.
Acceptance Criteria
The Current Business Baseline should document clearly those requirements of the current business that the future business process and information model absolutely must cover. Each process should appear in a process flow; each flow should cover the essential steps to complete the process; and processes should reflect a definite triggering event and concluding event. The total number of steps on a process flow should be between 10 and 20 to be considered concise (crisp and
Oracle Method
easy to follow), accurate (thorough and usable as a complete test flow), and unified (covers one basic process and is not cluttered). Augment each process with the appropriate process information, dictated by the scope and objectives for the project.
Tools
Deliverable Template
Use the Current Business Baseline template to help you construct the deliverable for this task. Choose from the following components: Event Catalog Process Listing and Process Description Current Process Baseline (which includes Process Flow Diagrams and Process Questionnaires) Process Improvement and Redesign List Event Catalog List the events to which the processes above respond. Process Listing and Process Description List the processes to be covered by the Current Business Baseline and provide a brief description of each process. Current Business Baseline When you select Current Business Baseline from the template menu, the template displays the dialog shown in Figure 1-3:
Figure 1-3
Select the desired Functional Area by clicking on the corresponding button in the top section. Select Process Flow and/or Questionnaire from Document Sections to Insert. Then select the specific process from the Business Process list and choose the [Include>>] button to add it to the right hand window. You can include as many business processes as you wish, even from different functional areas. The Process Flow and/or Questionnaire will be inserted automatically. Menu choices correspond to processes. Table 1-8 shows the menu options to choose from when conducting and documenting the current process baseline, and the areas covered in that process.
Process/Menu Option
Event
Output/Result
NA Material Receipt
Oracle Method
Business Area
Process/Menu Option Invoice and Disbursement Fixed Asset Accounting Employee Expenses Invoice Generation Customer Payment Budgeting Financial Accounting and Reporting
Event Invoice Receipt Asset Addition Employee Expense Request Sales Order Customer Invoice Budget Financial Information Receipt Sub-Ledger Reporting Market Demand and Assumptions Order Placement Shipping Confirmation Return Request Distribution Planning New Product Introduction Target Audience Sales Order Market Demand Planning Purchase Request Work Orders Receipt Quality Event
Output/Result Invoice Paid Asset Retirement Employee Expense Disbursement Customer Invoice Payment Reconciliation Forecast Financial Statements
Supply Chain Management Demand Analysis Order Placement Order Fulfillment Customer Returns Distribution Planning Pricing Sales and Marketing Sales Compensation Manufacturing Forecasting Master Scheduling Procurement Work in Process Material Handling Quality Management Sales Forecast Master Scheduling Material Receipt Finished Goods Miscellaneous Issue Disposition or Corrective Action Sales Forecast Customer Receipt Customer Invoice Receipt Customer Receipt Delivery Pricing and Positioning Placed Order Paid Compensation
Business Area
Process/Menu Option Engineering Changes Inventory Accuracy Costing New Product Introduction
Event Engineering Change Requests Inventory Count Product Costing New Product Introduction Employee Set Up Time Submittal Request for Proposal (RFP) Project Cost Collection
Output/Result Implementation Adjustments Period Close and Analysis Pricing and Positioning Employee Tracking and Reporting Payment Cost Accumulation Project Billing
Human Resources Human Resources Payroll Project Accounting Project Set Up Project Billing
Table 1-8
Process Flow Diagrams The business process flow diagrams provide a starting point for charting processes and systems. The AIM template includes predefined generic business process flows for common business processes. These flows portray both material and information flows by process across logical, but generic, business functions. The table above includes a list of beginning and ending events for each generic process. By thinking of the triggering and the concluding event of the process, you will be able to frame each of the processes. Attention: Baselining flows are generic and not application specific because each companys current business process flows are typically unique. Figure 1-4 illustrates a sample business process flow:
Oracle Method
Planning
Release Shop Orders Check Capacity Capacity or Shortage Constraint Develop Material Plan
Quality Assurance
Reject
Sample Quality
Manufacturing
Manufacture
Inventory Management
Stage/Kit Material
Issue Material
Replenish Kanbans
Inventory Transactions
Inventory Transactions
Suppliers
Receiving Transactions
Replenish Kanbans
Figure 1-4
To edit the diagram that the AIM template inserts into your document, simply double-click the picture. You can also open the process flow diagrams directly from Visio. The diagrams are stored in the AIM20\DIAGRAMS directory. For each functional area, there is one file, with different diagrams on each page. The file names are: flow_fin.vsd, flow_dst.vsd, flow_mfg.vsd, and flow_hr.vsd. You can add pages with your own diagrams and link them to your Word documents, or create new files using the Oracle Process Modeling Visio template. To insert a new diagram directly into a Word document, click on the Visio icon in the Word command bar. Reference: Oracle Method Deliverable Template User Guide.
Process Questionnaires The process questionnaires help you create a set of interview questions to address the interests and concerns of your audience. Written from a business process perspective, these questions avoid references to specific Applications features. Each question provides information on one of the following: how a process operates what procedures and metrics are in place to measure process performance what transaction volume the current system supports how the current system is configured what the specific business rules are It is important to incorporate company-specific terminology into the template. Because the templates are used in analyzing legacy systems, the number of business processes will vary from project to project. For this reason, the questionnaires are organized along functional lines the top of the functional hierarchy. Questions are grouped into the following categories: financials, supply chain management, manufacturing, human resources, and project accounting. General questions apply to all processes in all functional areas. Each questionnaire also includes some general questions that are consistent across functional areas. Attention: For most options there is a one-to-one relationship between questionnaires and process flows; however, some areas have additional process flow diagrams to help you more effectively communicate the process. Questions are further classified into type as follows: Setup pertaining to system configurations that affect business operations Metric a particular quantifiable measurement Process operations steps and flow Performance volume, throughput, and so on
Oracle Method
When you complete the questionnaires, you can re-sort the questions by type for ease of analysis and use. Select Sort from the Word Table menu to sort the questions based on any combination of columns. Process Improvement and Redesign List Identify those processes and process steps which provide an opportunity for improvement and redesign.
Deliverable
The deliverable for this task is the Future Process Model. It consists of the Event Catalog, Process Listing and Descriptions, and Process Flow Diagrams. Optionally, it may include Process Step Catalogs.
Prerequisites
Required
You need the following input for this task:
G
The team can use the Current Business Baseline material to gain an understanding of the processes and systems that support the current business. It may identify processes that offer opportunities for process improvement in cycle time, cost, and quality. It may also show major processes that are candidates for process redesign.
G
The project team members must understand application concepts and capabilities in order to develop process models based on best practices. This prerequisite will help them understand what process steps are supplied by application-specific functions.
Oracle Method
Optional
You may need the following input for this task:
G
Future Business Strategy includes other internal business documents that describe the future business processes. For example, the original Request For Quote and management business strategy documents on manufacturing, distribution, financial, and administrative processes could be useful during this task.
G
Process reengineering studies may recommend the complete overhaul of current processes to be supported by the new applications. The output of a BPR study may, in fact, provide most of the content of the Future Process Model.
Task Steps
The steps of this task follow: No. 1. Task Step Review any documented future business requirements. Identify, at a high level, the business processes for each business area. Identify and describe the events to which the business responds. List each process and write a summary description of each, identifying the event it responds to and its main inputs and outputs. Event Catalogs Deliverable Component
2.
3.
4.
No. 5.
Task Step Identify the steps that make up each process, their sequence, any conditions that determine alternative execution paths, and the agent responsible for each step; validate that each step maps to an elementary business function. Construct Process Flow Diagrams for those processes with more than two steps or with conditional steps. Review the Future Process Model with users and management. Secure approval of project and business line management.
6.
7.
8.
Table 1-9
Oracle Method
between process steps. By showing which departments or employee roles are responsible for the various steps within each process, process modeling places processes in their organizational context. The process flow diagram presents this information visually. The result is a visual map of the finished work and the information that is needed during the execution of the business process. 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.
Business Processes
A business process, in general, is a combination of operational steps and management controls that, taken together, produce a product and/or deliver a service. Central to this definition is the fact that a business process produces an output of some kind. The product or service may be something received by an external customer, such as filling a customer order. Other business processes produce outputs that are not visible to the external customer, but are essential to the effectiveness of the organization (for example, hiring an employee). Business processes occur as pre-planned responses to business events. An event is an occurrence inside or outside of the business environment that causes an event response to execute (events are discussed in the Events section later in this chapter). Event responses follow an established, repeatable set of steps that make up the complete response to the business event. The combination of an event and its event responses form a process. The entire set of business processes in a highlevel business function area make up a planned response system. Process modeling focuses on planned response systems. The combination of process steps that will be executed on the future application system and the manual steps that support them represent the planned response system which the future business system will support. From the perspective of process modeling, a process is defined by the following information: 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 the flow of information and/or material between process steps
Process Types
From the reference point of the Business Function Model, a few processes may reside wholly within a functional area. An example of this might be the process of recording a change in a customers address. Most processes, however, are cross-functional, meaning that they include process steps from more than one functional area. An example
Oracle Method
of this would be the process of manufacturing an airplane according to customer specifications. In this example, the placement of an order with Sales would trigger the process, which would include steps in the Design, Manufacturing, and Distribution business functions. All processes, whether they cross functional boundaries or not, produce something essential that contributes to achieving organizational goals. Process modeling can take place at different levels, depending on the breadth of the defined process steps. A high-level process is one whose steps are further decomposed into more detailed steps. Highlevel processes often begin and end with a customer. For example, you might have a high level process called Order Management that begins with a customer order and ends with the receipt of products by the customer. The agent channels on high-level process flows often correspond to entire departments or divisions, while lower-level processes have agent channels corresponding to job roles. A lowerlevel process whose process steps all correspond to elementary business functions is called an elementary process. Business modeling can take place at any of these levels; however, the eventual application implementation must ultimately work with business processes at the elementary level to ensure that all process steps can be executed. You can also sort processes into types, depending on their complexity. Processes that contain many steps are called multi-step processes. Most processes are both multi-step and cross-functional. The planned response to an event may possibly be a process that can be executed in a single process step. Many of these processes are referred to in system analysis as update or reporting processes. They involve recording a change of some factual information in the stored memory of the organization or providing a report of stored information.
In this step you identify the core processes at a high level, through interviews or workshop sessions with the project sponsor and senior management. During these interviews you should also identify the parts of the organization and the managers responsible for those processes. The core processes then become the focus of the main process analysis effort. Because they provide the greatest information about the business, you should tackle them first. Repeat the task steps for this deliverable for each core process and then for noncore processes. Seek confirming feedback from the appropriate business area management at the end of each iteration.
Process Steps
Business processes consist of process steps. An important part of process modeling is taking a process and breaking it up into the steps required to execute the process from start to finish. For example, the process Fulfill Order might consist of the following steps: 1. 2. 3. 4. Document customer requirements. Design product. Build product. Deliver product to customer.
In this case, each process step appears to be a process in itself. It may be necessary to take each of these processes and drill down to the process steps to achieve a complete understanding. Alternatively, consider the process Hire Employee, consisting of the following process steps: 1. 2. 3. 4. 5. 6. 7. Define position requirements. Specify Advertising Requirements. Advertise position. Submit resume. Screen resumes. Send thank you letters (to rejected applicants). Schedule interviews with candidates.
Oracle Method
8. 9.
10. Send offer letter. 11. Accept offer. 12. Inform hiring manager. 13. Add new employee to payroll. The process step Send Offer Letter is at such a low level that it would be inappropriate to develop a process model for it. This process step corresponds to an elementary business function. A process step at this level is referred to as an elementary process step. Figure 1-5 illustrates an example process flow diagram from the process, Hire Employee:
E021
Conduct Interview
No
Yes Send Thank You Letter Schedule Interview All Applicants Interviewed?
No: 95%
Yes: 5% No
Resume OK?
Yes
Screen Resumes
Newspaper
Advertise Position
Applicant
Submit Resume
Payroll
Oracle Method
automated, either wholly or in part, are designated as system-assisted process steps. A further designation of process steps is whether they occur inside or outside the high-level business function. A process step performed within the business function is called an internal process step. If performed by an agent outside of the business area, it is an external process step.
Events
All business processes are planned responses to business events. An event is simply an occurrence that causes a response to execute. Some examples of events that trigger processes are shown in Table 1-10.
Event Customer Places Order. Position Opens. Request for Proposal Arrives. Fiscal Year Ends.
Table 1-10
Response Fulfill Customer Order. Hire Employee. Prepare Proposal. Prepare Tax Return.
Types of Events Events may be external to the organization (Customer Places Order), internal to the organization (Position Opens), or temporal (Year Ends). A temporal event is one which initiates at a predetermined point in time. Just as processes may be high- or low-level, events also may be high- or low-level, although in process modeling events are not formally decomposed. A high-level event is one that represents several similar events. Consider the example of the event Customer Requests Service, causing the process response Provide Customer Service. This event may actually represent several types of service request events. A manufacturing company, for example, may have many types of customer service events: The customer requests change of billing address. The customer orders inventory item. The customer orders warranty contracts. The customer requests credit approval. The event Customer Requests Service is really the most general case of these different types of events. An example of a low-level event is the arrival of a specific customer order. Event Mechanisms Event mechanisms identify the various ways in which an event is recognized. For example, a time sheet may arrive by electronic mail,
Oracle Method
surface mail, or fax. A customer may place an order by phone or through the mail. The ultimate deliverable the fulfilled order is the same, regardless of the mechanism used, but details of the process execution may be different. If the customer places an order by phone, a clerk may enter the order in the system while the caller is on the phone. When a customer sends an order by mail the process steps may be: 1. 2. 3. 4. Stamp the order with the date received. Check the order for errors. Enter the order into the system if there are no errors. Return the order to the customer with a request to fix the problem if there is an error.
Steps 1, 2, and 4 are not performed when the order is received by phone. If there is more than one mechanism by which an event can be recognized, and the event response is significantly different depending on the mechanism, you should model the differences. Consider each event-mechanism combination as different events and produce a process flow diagram for each. Using the above example, there are two different events: Customer Phones in Order. Customer Mails in Order. Develop a process flow diagram for each event. If the responses to an event recognized through more than one mechanism are similar, use one diagram, but show each mechanism as a separate event. If the variation in process steps is small, use decision diamonds and conditional branching to model the alternate responses.
internal event (initiated inside the business area) Ask questions regarding the fulfillment of customer (internal or external) requests to build a complete list of events. Capture high-level descriptive information about the event, such as its frequency and response requirements. Finally, work with the business staff to produce a summary description of the process that responds to the event and to identify its main inputs and outputs. The following examples of events from a customer information system for a manufacturing concern show the event identifier and event description: OE-10 Customer requests change of billing address OE-23 Customer orders inventory item OE-17 Customer orders warranty contracts OE-30 Customer requests credit approval Assign ownership of each event to a functional area. You can base ownership on who performs the majority of process steps in the process or on the functional area that initiates the business process responding to the event. Recognize that events create responses by processes which may be self-contained within one functional area or which may cross functional boundaries. It may be difficult to identify events or to distinguish an event from an event mechanism. For example, receiving internal information is not necessarily an event, but is simply the natural flow of information between process steps in a process. If you are not sure if something is an event, ask yourself if it would still be an event if the roles of sender and receiver were performed by the same person.
Agents
An agent is the party responsible for a process step. An agent may be an organizational unit, a functional unit, an employee role, or a party external to the organization such as a customer or supplier. As with processes and events, agents can represent any level in an organization, from a business unit down to a specific job description. Some examples of agents that might be involved in the process of making a sale are:
Oracle Method
Sales Account Executive Area Vice President Regional Sales Manager Administrative Assistant Sales Accounting These examples show the different levels at which agents can be identified. Sales is a business unit, and Account Executive is a job role. Area Vice President, Regional Manager, and Administrative Assistant identify specific roles. Sales Accounting represents a functional area. Assuming that Sales Accounting is a separate system, the last agent example could represent both a functional area and a business system; process flows to and from this agents process steps could represent system interfaces. The generic definition of agent as any responsible party gives the business analyst a high degree of modeling freedom. In some situations, the level of detail represented in the specification of an agent may be driven by the process for which the agent is responsible. For example, the manufacturing agent identifies the functional area responsible for building a product in an order fulfillment cycle. Viewing the process Build Product in more detail, you could differentiate Manufacturing into Shop Floor Manager, Assembler, Inspector, Packager, and so on. These examples illustrate the broad uses of the concept of agent. Its value is in representing who (in the generic sense) is performing the work of a process. From the perspective of application implementations, agents identify job functions that will be carried out on the applications. Suggestion: If you specify agents at the job role level, you can use them to develop custom responsibilities in Oracle Applications.
business functions into one or more hierarchical levels. Typically, the highest level corresponds to the company organization, the middle level corresponds to the a grouping of application functions, and the lowest level corresponds to elementary business functions. Functions near the top of the hierarchy are referred to as high-level functions while functions near the bottom are called low-level functions. Sometimes the term summary level is used synonymously with high-level. Because a functional hierarchy is a classification scheme, the concept of level carries the connotation of how broadly- or narrowly-defined a function is. Broadly-defined functions exist at the top of the hierarchy and include many different (although related) activities within them. Human Resources, for example, may include the functions Benefits, Compensation, Employee Relations, Hiring, and so on. High-level functions allow you to refer to an extensive group of related activities in a summary way, such as Human Resources. Thus, the concept of level also implies the amount of detail that is visible on the function hierarchy. The function Human Resources does not give you a direct view of all of the details involved in this function. To access this detail you must navigate down the functional hierarchy. The further down the hierarchy, the more narrowly the function is defined, and the more detail is included in the definition. Elementary business functions represent the most narrowly-defined functions in the functional hierarchy and include the most detail in their definition. The key concepts in process modeling business process, process step, event and agentall have a leveling dimension similar to functions in functional decomposition. A critical difference, however, is that in process modeling you are not attempting decomposition. In process modeling the analyst is free to choose the level at which each object (process, process step, event, and agent) is defined. This freedom extends to the use of objects at any level of detail in the same process flow diagram. These concepts are summarized in Figure 1-6.
Oracle Method
Function Model
High
Scope Increases, Detail is Sumarrized
Functional Area
Process Model
Business Process
Function
Level
Process Step
Low
Figure 1-6 Concept of Level in Process and Function Modeling
From the perspective of the applications, the functional model usually has only three conceptual levels: the first level, or top, is an organizational one; the second is an application-related function; the third is the elementary business function. Functions and Processes Functions are defined as something an enterprise must do to achieve its objectives. This definition does not carry with it the same constraints as the definition for process a planned response to a business event consisting of a sequence of operational steps that produces a product and/or delivers a service. Functions are identified and defined without the criteria that are inherent in the definition of processes. At the highest level in a functional decomposition, functions are groupings of related activities Sales, Marketing, Manufacturing, Distribution, and so on. High-level functions include processes, but from a modeling perspective, you should not attempt to achieve a oneto-one correspondence in a functional hierarchy between functions and processes at the top levels. In fact, a very important advantage that process modeling brings to the table is a cross-functional perspective. Process modeling allows you to understand business activity as it
crosses functional boundaries. It accomplishes this by highlighting interactions between process steps from different higher-level functions. When processes are fully specified, the process steps are defined at the elementary business function level. At this level there is necessarily a one-to-one correspondence between the elementary business functions in the function model and the elementary process steps in the process model. As a quality assurance step, you should make sure that each elementary process step equates to an elementary business function in the function model and that each elementary business function either appears in the process model or is a single-step process in itself. The relationship of elementary process steps to elementary business functions is shown in Figure 1-7.
Deliver Product To Customer Effectively
F1: Sales
F2: Operations
F3: Accounting
F11
F21
F31
F12
F22
F32
F13
F23
Figure 1-7 Relationship Between Elementary Business Functions and Elementary Process Steps
The process model designates the flow of all work through the business area. In order to do this, it should indicate all elementary process steps
Oracle Method
that form part of multi-step processes. The function hierarchy, on the other hand, should include those functions that are supported by the application system, manual steps, as well as single steps and maintenance steps. Table 1-11 designates types of elementary process steps and elementary business functions and the models in which they are included. EPS/EBF Type system-assisted manual single-step/standalone maintenance external
Table 1-11
The function performed by each step should be at the level of elementary business function and will match the elementary functions shown on your function hierarchy. For each step, get members of the business staff to specify who is responsible and to identify the inputs and outputs. Use these functions to provide input to the identification of entities and attributes. Also determine the degree of automation required for each step and specify whether it is to be performed manually, with computer assistance, or entirely automatically by the system.
Oracle Method
The most important point to recognize is that future processes must cover the minimum business requirements that current processes cover, to supply the information required to achieve the business objectives and, possibly, to yield business improvements in cost, time, and quality. You will construct future processes to respond to the events that become approved business drivers. They will consist of process steps which may be manual or automated. In the future process model evaluate each process step conducted by the current business system to confirm that it has been addressed either by a manual or an application step or that it is no longer required.
Oracle Method
Reengineered processes should be benchmarked against best-in-class processes, and should incorporate the best practices of world-class enterprises. Often new process definition and future process modeling activities trigger the recognition of significant process improvement and redesign opportunities, though on a smaller scale than Business Process Reengineering. In both business process re-engineering and process redesign, there may be an opportunity to take advantage of the best-in-class process designs available, sometimes referred to as dominant designs. Consider these dominant designs during Create Business Requirements Scenarios (RD.070) and Map Business Requirements (BR.020).
Staffing
Depending on the number and complexity of the business processes, you may need to divide the task workload among multiple teams. However, you should make every effort to minimize the number of teams and analysts involved in order to reduce communication overheads and improve efficiency. Ideally, these teams should have one or more analysts to work with the appropriate business representatives. Assign each team to a set of closely related processes, from which to develop a model. When deploying multiple teams, require that they coordinate their models. Under no circumstances should teams work in isolation, or they may produce inconsistent models, subsequently requiring considerable effort to integrate. When managing the construction of future business models, move as rapidly as possible through this task. Because there will be many resources engaged in this task, watch for and avoid the decision paralysis that can lead to scope and time creep. To meet the scheduled completion dates, the project manager and team members must see that decisions are made, issues resolved, and consistent progress achieved. Do not hesitate to elevate delays, increase the urgency, and demand date accountability from the process modeling teams.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Facilitator Business Line Manager % 90 10 *
Oracle Method
% * *
Deliverable Guidelines
After conducting current business baseline activities, define a model of the new business system. The future business processes should effectively communicate: what events the business currently responds to what processes make up the response what process steps make up each process how business decisions are supported by the new system how processes will be streamlined how desired process changes can be accommodated how resources will interact in the new system what necessary control elements (approval steps) should be established how process and performance will be fed back to management for improvement what organizational changes are required to support the new processes
Deliverable Components
Event 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 Process Model, but the new applications may also introduce new events.
Process Listing and Descriptions 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 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. Process Flow Diagrams exists for any process with conditional steps or more than two steps.
Tools
Deliverable Template
The deliverable template comprises the following components: Event Catalogs Process Listing and Descriptions
Oracle Method
Process Step Catalogs Process Flow Diagrams Event Catalogs List each event to which the business responds within the project scope. These may be external events (e.g., a customer order), internal events (e.g., the completion of production), or temporal events (e.g., end of the month). Process Listing and Descriptions List each business process and provide a brief description of each one. Process Step Catalogs Identify each step for each process. Process Flow Diagrams You can use the application-supported process flows provided in AIM as a starting point for creating the future process flow diagrams. These flows document processes directly supported by the Oracle Applications, but only show the process steps performed on the Applications. You can then augment these process steps by adding the process steps required by your company to support your unique processes. In many cases one application process flow will be the basis for several business process models. For example, when events and responses differ, a planning flow may need to vary by type of product family being planned. Figure 1-8 shows an example of an application-supported process flow:
Production Control
WIP 02
Check Capacity
WIP 03
Inventory Control
ID.060
ID.070
ID.080
Issue Material
\Nav WIP Transact Material
Pick Material
Deliver Material
ID.090
Production
Manufacture Product
ID.100
Supported Events: WIP 01: MRP/MPS Mfg.. Supply Required WIP 02: Manufactured Item Shortage WIP 03: WIP/Inventory Kanban
Oracle Manufacturing Process Team FOCUS Version No. 1 20 Jun, 1996 AIMPTR1.DOC Jim Lange - Oracle Corporation 1 of 3
Production Control
Close Order
\Nav WIP Discrete Close
Done
ID.130
Inventory Control
This is a process step triggering an event, which kicks off another process. Disposition Non-Conforming Material Yes
Production
ID.110
ID.120
Inspect Product
Defective?
No
Supported Events: WIP 01: MRP/MPS Mfg. Supply Required WIP 02: Manufactured Item Shortage WIP 03: WIP/Inventory Kanban
Oracle Manufacturing Process Team FOCUS Version No. 1 1 Nov, 1996 AIMPTR1.DOC Jim Lange - Oracle Corporation 24417 of 3
Figure 1-8
Oracle Method
The navigation paths shown here are not really necessary during the development of future process flow diagrams; however, if gathered, you can use them during later mapping activities. Note that this diagram shows steps performed within the Applications as well as steps performed manually.
Other Tools
Integration Testing Application Flows Integration Testing Application Flows were developed to construct testing plans and scripts that support the integration testing of processes that cross applications. They are included as a deliverable component option, as one of the application process flows. They can be selected under the following functional areas: Financials Supply Chain Management Manufacturing Human Resources Project Accounting Integration Testing Application flows consist of two levels. The first level shows process steps executed in different application channels; it may consist of several pages for a process. The second level shows details beneath each process step on the first level. Typically, this level is self-contained in one application and explains all the form and program logic executed within a high-level process step. Because this second level often covers concurrent programs and the updated tables, it may be more useful in the analysis and design of interfaces and conversions. Designer/2000 You can also use the Oracle Designer/2000 process modeler as a tool to construct process models. Reference: CDM Requirements Modeling Using Designer/2000, Vol. 1. Oracle Part Number C10928-1.
Deliverable
The deliverable for this task is the Future Business Function Model. The Future Business Function Model deliverable shows all the business functions arranged in a hierarchy diagram. It also specifies the data usage at each function.
Prerequisites
Required
You need the following input for this task:
G
You usually construct the Future Business Function Model in parallel with the Future Process Model. The Future Process Model describes the processes that the business is required to perform in response to the events that drive it; process steps from the process model will correspond to elementary business functions shown on the function hierarchy.
Optional
You may need the following input for this task:
G
This model provides an understanding of existing processes which the new system must support. The team can draw information from this
Oracle Method
model and should cross-check it against the function hierarchy to ensure that no currently required function is omitted.
G
This model (if available) specifies the data requirements of existing systems with which the new application system interfaces or which the new system replaces. The team can draw information from this model and should cross-check it against the function-data usage.
Task Steps
The steps of this task follow: No. 1. Task Step Construct the top level of the hierarchy from information provided by interviews with senior management and Current Business Baseline information. Construct the intermediate and lower levels from application reference material and other required business functions. Compare the Future Process Model to the Business Function Model. Check the function hierarchy for completeness. Deliverable Component Function Hierarchy
2.
Function Hierarchy
3.
4.
No. 5.
Task Step Review the Future Business Function Model with users and management. Secure acceptance of deliverable.
Deliverable Component
6.
Table 1-13
Scope
Do function modeling for all the processes using the Applications being implemented.
Function Hierarchy
Construct the function hierarchy by using a combination of top-down and bottom-up modeling. Construct the top levels with the information obtained during the interviews with the project sponsor and senior management mentioned in Conduct Current Business Baseline (RD.020) and Develop Future Process Model (RD.030). Use those interviews to obtain broad statements of the functions performed by the business and to identify the high-level functions of the hierarchy. Construct the bottom level from the elementary business functions identified by Develop Future Process Model (RD.030). This level corresponds to the process steps in the process model that are largely based on new application system functionality. Construct intermediate levels by classifying the bottom-level functions and tying them into the upper levels in such a way that, at each level, the functions belonging to
Oracle Method
a parent function are a complete statement of what the business must do to carry out the parent function. The result of such a decomposition might resemble the model shown in Figure 1-9:
Three Tier Function Model
Purchasing
Manufacturing
Finance
Sourcing
Receiving
Work In Process
MPS/MRP
General Ledger
Define Vendor
Receipt Material
Set Up Accounts
Inspect Material
Issue Material
Load Forecast
Load Budget
Record Labor
Generate MRP
Close Month
Figure 1-9
A good rule is: It is best to draw elementary business functions from the organization and structure of the application. The result will be a function hierarchy that is based on application functions, rather than on process steps that may diverge from the new applications.
Figure 1-10 visually represents the linkage between elementary process steps and elementary business functions.
Deliver Product To Customer Effectively
F1: Sales
F2: Operations
F3: Accounting
F11
F21
F31
F12
F22
F32
F13
F23
Figure 1-10 Relationship Between Elementary Business Functions and Elementary Process Steps
The process model designates the flow of all work through the business area. It should indicate all elementary process steps that are part of multi-step processes. Table 1-14 designates types of elementary process steps and elementary business functions, and the models in which they are included. EPS/EBF Type system-assisted manual Process Model include include Function Model include include
Oracle Method
The process model excludes those process steps that are standalone or maintenance; the function model excludes external steps.
Acceptance Criteria
The function model needs to reflect those functions that will be executed with new application functionality.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Project Sponsor % 100 *
Role User
Table 1-15
% *
Role Contribution for Develop Future Business Function Model
Deliverable Guidelines
The Future Business Function model shows a hierarchical diagram of the business functions incorporated in the process model. It also presents in table format the function data usages by business function.
Deliverable Components
The Future Business Function Model has the following two components: Function Hierarchy Diagram Function-Data Usage Function Hierarchy Diagram Present a hierarchical breakdown of functions in which successively lower levels of the hierarchy provide more detailed statements about what the business is required to do. All process steps within every Business Process Model are elementary functions and may be found in the hierarchy. The function hierarchy is a nested view of functions to be performed within a particular organizational unit (e.g., Materials Management, Accounting, Purchasing, and so on).
Tools
Deliverable Template
Use the Future Business Function Model template to help you construct your deliverable. Select from the following components: Function Hierarchy Function Model Diagram Prototype
Oracle Method
Function Hierarchy A template table is provided for constructing the function hierarchy. Complete the table by providing the following information: Function a brief description of the function, or its short name Function Owner the agent with overall responsibility for the function Date date form is being initiated Function Number the code that uniquely identifies each business function Function Description a more complete description of the function Function Model Diagram Prototypes You can access several representative samples of function models for the processes supported by the Oracle Applications in the Future Business Function Model template. Figure 1-11 shows the application-supported functions only:
IN 1.0 Create Organizations and Items IN 1.1 Create Organizations IN 1.2 Create Item Subinventory IN 1.3 Create Item Locator IN 1.4 Create Item Definition IN 1.5 Create Item Controls IN 1.6 Delete Item
IN 2.0 Replenish Inventory IN 2.1 Define Forecast and Planning Levels IN 2.2 Calculate Available to Promise IN 2.3 Process Items for Replenishment IN 2.4 Process WIP Replenishment IN 2.5 Process PO Replenishment
IN 3.0 Process Inventory Transactions IN 3.1 Process System Material Issues* IN 3.2 Process Manual Material Issues IN 3.3 Process System Receipts to Stock* IN 3.4 Process Manual Receipts to Stock IN 3.5 Process PO Receipts to Stock IN 3.6 Process Scrap Transactions IN 3.7 Transfer Inventory Between Subinventories IN 3.8 Transfer Inventory Between Organizations IN 3.9 Process Shipping Transactions* IN 3.10 Process RMA Transactions IN 3.11 Reserve Inventory
IN 4.0 Process Accuracy IN 4.1 Process ABC Inventory Analysis IN 4.2 Conduct Cycle Count IN 4.3 Conduct Physical Inventory
IN 5.0 Process Accounting Interfaces IN 5.1 Process Intercompany Invoicing* IN 5.2 Process Inventory Costs IN 5.3 Process Inventory Valuations IN 5.4 Maintain Average Costs IN 5.5 Maintain Standard Costs IN 5.6 Open Accounting Period IN 5.7 Prepare and Close Accounting Period IN 5.8 Transfer to G/L and Close Period
IN 6.0 Access Information IN 6.1 Process Information Inquiry IN 6.2 Process Information Reports
Legend:
AIM II AIM II PFD A 25 Jul, 1996 Drawing2 Jim Lange - Oracle Corporation 1 of 5
Figure 1-12 shows the integrated functions that correspond to the WIP Process Model for Discrete, Push Production (Figure 1-8) shown earlier.
Oracle Method
Manufacture Product
F1
F2
F3
Production Control
ID.010
Inventory Control
ID.060
Production
ID.090
Check Capacity
ID.020 ID.070
Issue Material
Manufacture Product
ID.100
Pick Material
ID.080
Inspect Product
ID.120
ID.150
Close Order
Deliverable
The deliverable for this task is the Process and Mapping Summary. It provides a single source of information on key implementation decisions for new project members and executive management. The Project Manager can also use it to maintain a status on the progress of deliverables in requirements definition through build and test.
Prerequisites
Required
You need the following input for this task:
G G
The Financial and Operating Structure portrays organization structure that may be important for application and technical architecture. Current Business Baseline (RD.020)
The Current Business Baseline lists events and processes that the new business system may continue to support. In addition, it may identify some processes as requiring redesign or reengineering.
G G
The Future Business Model has processes and embedded decisions that need to be captured and documented. Business Requirements Scenarios (RD.070)
During the requirements definition and mapping cycle, you identify and prototype scenarios and create a summary listing.
Oracle Method
G
Optional
During the requirements definition and mapping cycle, you will identify and prototype scenarios and create a summary listing.
G
This document explains the business objectives for investing in new applications and describes items, objects, processes, events, and financial payoffs. It may be important to include in the Process and Mapping Summary.
Task Steps
The steps of this task follow: No. 1. Task Step Review the original system justification. Review and capture high-level management policies that might affect application usage and architecture configuration. Capture key implementation decisions. Capture the key financial and operating structure components. Capture the current business events and processes from the Conduct Current Business baseline task. Key Business Requirements Deliverable Component
2.
3.
4.
5.
No. 6.
Task Step Capture the current business metrics. Capture the processes needing business process reengineering or redesign. Capture future metrics and update summary. Review with project leader and company management as part of regular reporting.
7.
8.
Metrics Summary
9.
Table 1-16
Oracle Method
Capture Current Process and Future Business Processes, Events, and Metrics
The original investment decision is justified on the basis of some or all of the following: process, quality and/or cost improvements additional sales revenue ability to develop new products and markets customer responsiveness and satisfaction state-of-the-art information management state-of-the-art technical architecture employee satisfaction initiatives There may also be key management directives mandated as strategic business initiatives that may have overarching impact on the application and technical architecture. Be sure to clearly document and adhere to these directives as the implementation unfolds. For example, the future business requirement to have global ATP or a chart of accounts that consolidate in a specific way, may have significant impact on technical considerations or user procedures for the applications use. As the implementation progresses, the analysis to support the implementation will formalize or generate significant information about supported events, processes, resources, costs, and other metrics; many of these can be captured en route, so that the pieces gradually come together to enable efficient audit to determine whether original business objectives were met.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Business Line Manager
Table 1-17
% 100 *
Deliverable Guidelines
The Process and Mapping Summary should provide several types of information: key business decisions, process definitions, and organizational structures that support the application implementation in achieving the original business justification the intended application setup and usage to support those business processes across organizations, which may impact the application and technical architecture status information for the project manager on the deliverables being produced during the following tasks: Conduct Current Business Baseline (RD.020)
Oracle Method
Develop Future Process Model (RD.030) Develop Future Business Function Model (RD.040) Create Business Requirements Scenarios (RD.070) Map Business Requirements (BR.020) Test Business Solutions (BR.080) Produce Module Functional Design (MD.060) Produce Module Technical Design (MD.070) Create Custom Modules (MD.110) Perform Unit Testing (TE.070) Perform Link Testing (TE.080) The Process and Mapping Summary may not be necessary on smaller implementation projects. On large projects it is essential to prevent duplication of effort and hidden or stolen face-to-face time for new team members to become familiar with project history.
Deliverable Components
The Process and Mapping Summary consists of the following components: Key Business Requirements Record any key business policies, strategies, or enterprise level requirements. Key Implementation Decisions Record any key decisions made during the implementation. Financial and Operating Structure Use the key components of the Financial and Operating Structure(RD.010) to show business organizations covered by the project.
Process and Mapping Tracking Summary Use this component to record completion percentage or status for the implementation progress on business processes by organization and by function. Metrics Summary Consolidate any metrics that were gathered during Conduct Current Business Baseline (RD.020) and Map Business Requirements (BR.020). After gaining sufficient experience with the new production system, update this summary with metrics captured from the execution of newly designed business processes. Process Improvement and Redesign List Use the Process Improvement and Redesign List component from Conduct Current Business Baseline (RD.020) and any processes from Create Business Requirements Scenarios (RD.070) that have been targeted for business process reengineering or redesign to update the Process and Mapping Summary
Tools
Deliverable Template
Use the Process and Mapping Summary deliverable template to construct the following components: Key Business Requirements Key Implementation Decisions Process and Mapping Tracking Summary Metrics Summary Process Improvement and Redesign List Other Deliverable Components Select the New Deliverable template and use the styles and formatting macros to create additional deliverable components for this task as appropriate for your implementation.
Oracle Method
Deliverable
The deliverable for this task is the Business Volume Requirements.
Prerequisites
Required
You need the following input for this task:
G
The Future Process Model provides the process context for the steps that drive the business volumes.
G
The Future Business Function Model documents all the elementary process steps that will have transaction, data, and storage volumes associated with them.
G
Business Requirements Scenarios have volumes quantified for process steps included in the scenarios.
Optional
You may need the following input for this task:
G
Use the Current Business Baseline as a high-level check for estimating future volume (if there is some confidence that current and future business process volumes will be similar).
Task Steps
The steps of this task follow: No. 1. Task Step Review existing documentation. Extract business volumes from current business baseline, the business function model and the business requirements scenarios. Summarize business transaction volume statistics by functional area. Gather total data volume requirements. Determine critical processing window. Gather user counts by functional area. Review volume requirements with area managers.
Task Steps for Gather Business Volumes
Deliverable Component
2.
3.
4.
5.
6.
7.
Table 1-18
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst User Business Line Manager
Table 1-19 Role Contribution for Gather Business Volumes
% 100 * *
Deliverable Guidelines
The Business Volumes Requirements document is an input to subsequent tasks that determine the sizing and performance needs of the production system. This document should address the following: critical volume and frequency processing requirements (such as completing overnight job stream by morning) online inquiries online transactions batch processing
Oracle Method
batch reporting average and peak volumes average number of users and peak period users transactions per day within a critical processing period (such as quarter close) total number of periods of data to be kept online percentage change due to growth total data volume requirements
Tools
Deliverable Template
Use the Business Volumes Requirements template to create the deliverable for this task. Choose from the following components to summarize current system transaction volume and reporting requirements: Business Transaction Volumes Total Data Volume Requirements Critical Processing Periods System User Counts Business Transaction Volume List the key transaction processes (online entry, batch creation, reports) of each business function; further subdivide the functions by business object. The other dimension of the worksheet matrix captures the current detailed transaction volumes by month and projects future volumes by using the additional columns. Total Data Volume Requirements Document the volume changes in the key business objects for each business function and the total number of periods of data likely to be present in the production system at maximum data population (just before the next archive or purge of the production data).
Critical Processing Periods Lists the key transaction volumes for the business function by precise day of the critical processing period, relative to the average days processing activity. In the case of financial-based periods, the critical processing window would often be around month or quarter end, with the main processing day (day 0) being the period end. Complete the matrix to view the trend in transaction volumes and users for all the key transactions of a business function. System User Counts Profile the number of users today by function or user group. Estimate the projected growth over future periods.
Oracle Method
Deliverable
The deliverable for this task is the Business Requirements Scenarios (BRS). At least one BRS is created for each business process, linking requirements to process steps.
Prerequisites
Required
You need the following input for this task:
G G G
Current baseline information for relevant processes is useful in determining minimum business requirements based on functionality that supports the business today. Of particular importance are identification of transactions, their volumes, costs, and metrics, because these are the bases against which future business processes are measured. Future Process Model (RD.030)
For each BRS you must begin with the Future Process Model associated with that business process. Future Business Function Model (RD.040)
Each process step in the Business Process Identification section of the BRS must refer to a valid function in the Future Business Function Model (RD.040). This model represents the future business functions after application implementation.
Optional
You may need the following input for this task:
G
For core processes, it is possible that preliminary BRSs were created during the sales cycle in response to the RFP (Request for Proposal). Use of such material strengthens the implementation by forming a solid link with the reasons for acquiring the application package. This can be a key facilitator of rapid implementation.
Task Steps
The steps of this task follow: No. 1. Task Step Train all assigned team members in use of the methods and tools for BRS development, and in the boundary and characteristics of the target business process. Check the prerequisite deliverables and get a control number assigned for the new BRS. Assign preliminary research topics to team members and ensure that they complete all research before the first design session begins. Revise Future Process Model and Business Function Model based on research findings. Future Process Model; Future Business Function Model Master BRS log Deliverable Component
2.
3.
4.
Oracle Method
No. 5.
Task Step Construct a process identification for the target future business process. Use the preliminary BRS collected during project initial planning if it exists. For each process step, indicate the source of the detailed business requirement. Assess initial fit of application functions to business requirements at the elementary business function level. Make references to application documentation and/or navigation and indicate where known gaps exist. Publish the BRS to reviewers, get feedback, and make adjustments. Secure acceptance of deliverable.
6.
7.
Solution
8.
9.
Table 1-20
A BRS is 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. When a team creates a BRS, it is completing the design of the business process that began with development of the Future Process Model. 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 because people tend to respond better to pictures than to words. Using visualization techniques during the early stages of any design is crucial to understanding and common agreement.
Oracle Method
configuration management (to ensure proper use of tools and cataloging of deliverables). In order to work effectively, all design sessions should be accompanied by a thorough agenda that includes: session location and duration role assignments the business process to be designed and its process boundary activities and sequence the inputs required (like prerequisite deliverables) and assignments for bringing them the expected outputs and criteria for successful closure of the design session
Determining Requirements
The objective of BRS development is to compile a comprehensive list of requirements against which to map Oracle Application features (Map Business Requirements [BR.020]). You can develop detailed business requirements and process flows concurrently, but the process flow diagrams created during process modeling provide the best input. As a starting point, use vendor evaluation lists or the request for proposal (RFP) to begin summarizing the future requirements for the new system. Review this list with the project team and ensure that there is a common understanding of the requirements between the team and Oracle Applications experts. Pay special attention to features which were rated unsatisfactory during the vendor evaluation process. Establish a strong linkage with the reasons for the selection of the new application system. In this way, you can more quickly gain acceptance of new approaches, because they are then seen as sanctioned by management and key representatives from the business who participated in selection. The idea is to focus on the new system and deemphasize the old system as much as possible. This is a key technique for rapid application implementation. If preliminary BRS material was not created during the pre-sales cycle, review the Original Justification for Business Systems Investment document referred to in Establish Process and Mapping Summary (RD.050) to understand the business objectives that supported the investment.
Documents may exist that describe key business requirements, architectural assumptions, or policy statements all of which could influence process design. These documents should be referenced in the BRS. It is especially important to transition properly from the RFP wish lists that are often created by functional organization, into processdriven, detailed business requirements. Pay particular attention to the role that the new technology will play in driving business requirements it can even cause revisions to project scope (Scope, Objective, and Approach document) if not understood early enough during the life of the project. Watch for requirements that do not match the business processes identified in the Conduct Current Business Baseline (RD.020) or Develop Future Process Model (RD.030) tasks. Team members may list as requirements features of their old system, even if they no longer need those features. New requirements are likely to emerge as the analysis progresses. Ensure that these new requirements fit within the scope of the project before adding them to the business requirements list. Set aside time to finalize these requirements. Attention: Avoid describing requirements based exclusively on legacy system functionality. Such requirements may reflect a current system constraint or workaround. In many cases these shortcomings will no longer apply.
Process Research
Assign team members preliminary process research just after the team kickoff and before intensive design sessions begin for each business process. The research goals are to test feasibility of the process models and gather facts in order to offset doubters and naysayers. Since BRS development sessions are process design sessions, there is much at stake. Final designs will dictate how the business operates. Therefore, team members must be informed about (1) process characteristics and idiosyncrasies, (2) transaction volumes, and (3) exception processing both real and perceived (e.g., legacy workarounds). Follow the Rule of 3-2-1. This means that roughly 3 hours of research are normally required for 2 hours of process design and 1 hour of formal entry (capturing the BRS using a template or other tool).
Oracle Method
Perform research at the job site (shop floor, user office, and so on). If this task is performed in an isolated environment like a conference room, the product will not be as complete or accurate. Process research also helps you to establish minimum business requirements that must be met to keep the business running. If Conduct Current Business Baseline (RD.020) was performed and the Future Business Process Model maps closely to this baseline, and if the same team is employed in both baselining and BRS development, process research may be a minimal activity.
Define each process step on a BRS at an elementary business function level. This provides a quality check against the functional hierarchy, and ensures that BRSs are developed at an appropriate and consistent level. If during the course of process design, questions arise regarding the boundaries for a particular process, suggest this approach to help with boundary identification: a process extends from the first activity by the group which receives the initial request (triggering event) to the final activity of the last group that fulfills the request and thus closes the loop with the requester. (Use this rule of thumb: How FAR should we go with this process? Fulfill A Request). Also note that business processes often end with the deliverable being completed at one step and placed in storage, followed by a delay before it is used or acted on by some new business process.
Inter-team Integration
Make sure that processes do not overlap and that process steps are not left hanging and unclaimed by any team. These mistakes occur when process models have not been quality assured for consistency and completeness, or when teams assume certain tasks are the responsibility of other teams. The best preventive approach is to have an integration team that monitors process designs when they are in-process and looks for interteam integration problems. A helpful technique is to cross-reference all events with process outputs. This is useful because most process outputs also serve as events that trigger other processes. In this way you can identify overlapping and missing processes or process steps early and avoid rework. Also note when an agent is an automated functional area outside the business area or outside the domain of a design team. This could indicate that there are system interfaces that must be considered when making assumptions about business requirements.
Oracle Method
Within the Business Requirements Mapping process, and particularly during Solution Design, you must refine BRSs through detail mapping. Mapping means: (1) proving application fit through demonstration, (2) identifying gaps, and (3) bridging the gaps.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Application Expert Configuration Manager Facilitator Team Leader - BRS User
Table 1-21
% 50 30 10 5 5 *
Role Contribution for Create Business Requirements Scenarios
Deliverable Guidelines
The Business Requirements Scenario deliverable helps you organize detailed business requirements by business process and process owner. The BRS provides a linkage that spans business requirement decisions made during the RFP activity of the pre-sales cycle, generation of detailed business requirements, and requirements mapping (during Solution Design).
Deliverable Components
The following deliverable components comprise the Business Requirements Scenario deliverable: Business Process Identification Describe the business process and its detailed process steps in a recipe format with references to Events, Business Functions, and Agents Requirements and Sources Traces the need for each process step to its source. Three other components of the Business Requirements Scenarios will be completed in the Requirements Mapping process, during the Map Business Requirements (BR.020) task. They follow: Process Analysis facilitates quantitative analysis and measurement of each process step Solution refers to how the requirement is satisfied by either the application or some other solution or workaround Mapping Scenario supports solution prototyping
Oracle Method
references to solutions: either application, manual or otherwise (generally this portion of the deliverable is completed during mapping within Solution Design) ability to support multiple prototyping mapping scenarios from each business process The BRS should contain heading information such as: process control number priority owner process or scenario description triggering event(s) Organize detailed information by process step. Each process step should be in a recipe format, with the requirement description written in the imperative (do this, move that, enter this, and so on). The BRS serves both as a test script and an operational procedure, so write it to that level of detail. Each BRS will generally be driven by one event, and will be in a one-to-one correspondence with a process model. Create a line on a BRS for each process step, and also create a line whenever one of these conditions occurs: A transaction is entered into the system. Ownership of a task is different from that of the prior task. A zone changes during transaction entry. Unique output is produced. Additional inputs are added or brought into the task. Attention: Define major exception flows in a separate BRS (such as when there are two long parallel lists of tasks on the same flow, especially resulting in separate deliverables or outputs).
Acceptance Criteria
In order to pass a Quality Review, a BRS needs to meet these criteria: The BRS must be developed using the approach discussed in this task. A qualified peer who signs off as the first reviewer must review the BRS. This signoff indicates that the BRS is accurate and consistent; for best results, the review should include both the process owner as well as the customer of the process (either the requester or the owner of the next process down the line within the business area). Major exceptions to a process must reference separate BRSs. The total number of tasks on a BRS should not exceed 20 in order to be considered concise (crisp and easy to follow), accurate (thorough and usable as a complete test flow), and consistent (covers one basic process and is not cluttered). At the process step level there should be a one-to-one correspondence with an elementary business function (EBF). The rule of thumb is that a sub-step within the EBF must be completed once started, or else rolled back, and never left in a partial state of completion. Otherwise record accuracy problems might result.
Tools
Deliverable Template
Use the Business Requirements Scenarios template to help you construct your deliverable. Select from the following components: Business Process Identification BRS Requirements and Sources Substitution Variables The following variables uniquely identify each BRS deliverable: Process Name Business Area Date
Oracle Method
Control Number Priority Process Owner Business Process Identification Supply the following BRS Header Information: Process a brief description of the process Business Area a code designating the mapping team responsible for this process Date date form is being initiated Control Number a unique identifier for each business process (e.g., a 6-character code in format AAA.999, where AAA represents the subprocess, and 999 is a unique 3-digit code assigned sequentially from a log maintained by each team) Mapping Team either the process modeling, design or mapping team responsible for this business process Process Owner the Agent with overall responsibility for the process; could be the Customer of the process, or the Supplier (one who fulfills the request) Librarian person charged with maintaining this BRS deliverable and interfacing with other teams in order to ensure control and proper alignment with integration goals Priority determined at each teams discretion; one option is to identify core processes here Core an identification of major driver processes that affect or influence business objectives Supply the following information for Header Two: Process Number the code that uniquely identifies each business process Process Description a more complete description of the process that includes the primary deliverable, output, or completion criteria, as well as key inputs
Assumptions a numbered list of major dependencies or requirements assumed to be available or in place by the proposed process; these may be out of the control of the process owner. Do not include open issues these belong in the Issues section. In particular, list systems or technologies required by the proposed process; list points that you believe management would want to know, or those that could affect their approval of the proposed process. Event Description brief description of the event Event Number unique code that designates the event Event Type External, Internal or Temporal Event Source Agent the agent that originates or initiates this event Event Mechanisms type of event forms or formats that are permissible Provide the following information for each BRS Task (line item): Process Step # a unique sequence number for each task. (Note: Assign these after mapping is complete. Also, try to avoid referencing task numbers by other task numbers. The need to create such references usually means you need to write a new, separate BRS). Step Description a brief description, beginning with an action verb, that captures the purpose and deliverable task. (Note: Each task should have one deliverable.) Type a combination of Manual or System-assisted, and Internal or External Elementary Business Function reference to a valid EBF number on the functional hierarchy Result the direct action to be taken as the result of a decision step (e.g., a branch to another step) Agent the step owner (charged with fulfillment) Status Active, Pending Active, Pending Obsolete, or Obsolete
Oracle Method
BRS Requirements and Sources Provide the following information to link the requirement back to a source: RFP Reference # a document number, page number, and line number for a requirement on the initial Request for Quote (used during system selection) Policy Reference # a document number, page number, and line number for a key requirement, driven by business policy Requirement Document Reference # reference to some other formal requirement description source document Frequency periodicity of the process step Volume example: 60/day in batches of 30; surge = 120; work time = 1 min/ea (Note: The volumes captured here are primarily for the purposes of prioritizing. They are different from the volumes identified for Business Volume Requirements [RD.060] and are not used to update that deliverable.) Extended Requirement Description additional requirements narrative for each requirement reference
Deliverable
The deliverable for this task is the Audit and Control Requirements.
Prerequisites
Required
You need the following input for this task:
G G G G
You must consider audit and control requirements for each organization. Future Process Model (RD.030)
For each future process and potentially each process step, it is important to understand the type of audit and control requirements needed. Future Business Function Model (RD.040)
Business policies provide a good source of audit and control requirements. Use of the Business Function model will point you toward relevant functions where policies may reside. Current Process Baseline (RD.020)
System security specifications and existing operations procedures for current processes may yield future audit and control requirements information.
Oracle Method
G
Optional
Policies and procedures may exist that contain audit and control requirements that will need to be perpetuated.
G G
Specific scenarios may have audit and control requirements. Business Requirements Mapping Form (BR.020)
When you map business requirements scenarios to applications, additional audit and control requirements may surface.
Task Steps
The steps of this task follow: No. 1. Task Step Review current security, manual operations procedures, and future business requirements scenarios. Evaluate audit specifications for division of responsibility in finance and operations. Create a list of security requirements for the company, operating system, application, and database to support future business processes. Create a list of user security requirements. Audit and Control Requirements Questionnaires Deliverable Component
2.
3.
4.
No. 5.
Task Step Review the audit and controls with business area management. Secure acceptance of the deliverable.
Deliverable Component
6.
Table 1-22
Oracle Method
From an auditing standpoint, these are the questions you are attempting to answer: What was changed? Who changed it? When did they change it? Why did they change it? Who logged in? Why did they log in? What kind of monitoring takes place of transaction processing? From the standpoint of financial controls, consider the following questions: What steps need to be taken to facilitate external auditors review of procedures and controls? What controls are in place to prevent insider trading, fraud, nonmalicious errors, and so on? What approval hierarchies need to be in place? What are the electronic commerce and Web-based systems security requirements? What business transactions are permissible in a Web-based system? What policies will prevent unauthorized intranet access? What kind of special security is required for financial and confidential information systems, such as General Ledger, Accounts Receivable, Human Resources, Electronic Funds Transfer, EDI, and Data Warehouse?
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Business Line Manager User
Table 1-24 Role Contribution for Determine Audit and Control Requirements
% 100 * *
Deliverable Guidelines
This deliverable helps you plan the future procedures for maintaining and controlling the new system. To capture audit and control requirements, define the types of fundamental audits and control you need to run your business. Remember to include functional and manual audits and controls, as well as automated background controls. By categorizing these types, you can further describe the distinct needs of each area. When summarizing your audit and control requirements, consider the following: Who or what is dictating such control? Why do certain data, functions, or other elements require control? Why do certain data, functions, or other elements require audit? Who or what will perform these audits or controls?
Is timing or sequencing critical to the requirement? What is the level and type of control (field, form, process, host, and so on)? What impact do audit and controls create for normal business operations?
Tools
Deliverable Template
Use the Audit and Control Requirements template to create the deliverable for this task. Choose from the following components: Audit and Control Requirements Questionnaire Use the provided set of self-assessment questions to: Facilitate compliance with generally accepted application audit and control objectives. Serve as a checklist of issues for consideration during application setup. Assist the functional leads/application owners in defining audit and control requirements. Tailor the seeded questions to your enterprise by adding additional ones or deleting those that do not apply. The specific questionnaire categories follow: Application Owner and User Security Requirements Separation of Duties Sensitive Programs Logical Access Controls Vital Records Change Control Transaction Origination Controls Communication Controls
Oracle Method
Processing Controls Output Controls Documentation Application Owner and User Security Requirements The application owner is generally responsible for accomplishing the following for each application: identifying sensitive programs and establishing controls classifying data ensuring controls are in force reviewing for maintaining compliance establishing adequacy of security testing Separation of Duties Review the duties of the programmers, computer operation, and user groups to ensure that problems do not exist with the separation of duties. In other words, no one individual should control activities within a process in a way that permits errors of omission, fraud, or theft to go undetected. Sensitive Programs Sensitive programs are application programs whose improper use could cause serious financial loss that normal application controls cannot prevent. In considering application security, examine the names of sensitive programs, identification and protection of application data files, and the arrangements for archiving and recovering vital records. The proper identification of sensitive programs is critical to an effective control procedure. The sensitive program control concept is valuable only when a relatively small number of programs are identified. Once identified, controls must be in place to prevent unauthorized modification and/or use.
Logical Access Controls While a site procedure generally controls sensitive programs, application data has a formal access control mechanism. Through this mechanism, the application owner can authorize and control who has access to data (by user ID) and how the data can be accessed (read, update, and alter). Vital Records Vital records are those which are essential to the continuing operation of the application system. You must identify and safeguard all such records. Change Control A change control system should be in place to evaluate, justify, and control changes to programs or procedures, including those for backlog management, library management, and system testing. Define a change control process for each of these. Transaction Origination Controls Ensure accuracy and completeness of information before it enters the application system. Owner and user responsibilities include activities up to the point of converting data to machine readable format. Communication Controls Ensure integrity of data as it passes through the communication lines from the input device to the reception devices. This covers hardware controls, message transmission, message accountability and reception controls. Processing Controls Apply controls for entry of data into the computer application system to ensure accuracy and completeness of data during processing. Output Controls Output controls ensure the integrity of the output data from conclusion of computer processing to delivery to the user.
Oracle Method
Documentation The quality and completeness of existing program documentation determines the degree to which programs could be efficiently reconstructed if they were destroyed.
Deliverable
The deliverable for this task is the Business Availability Requirements document.
Prerequisites
Required
You need the following input for this task:
G
The Future Process Model describes the processes that the business is required to perform in response to the events that drive it. This determines the requirements for business availability and implies systems availability to support those requirements. Business availability effectively overlays a level of timing requirements on the business process model.
Optional
You may need the following input for this task:
G
This deliverable provides an understanding of existing systems that the new system will replace. It may contain the current contingency procedures, and you can use it as a checkpoint to ensure that business availability requirements are not overlooked.
Oracle Method
G
There may be an existing contingency plan that defines how to respond to business interruptions. If so, it may serve as a guide to start the redefinition of contingency plans for the new software and technical architecture.
Task Steps
The steps of this task follow: No. 1. Task Step Identify the critical window of time in which interrupted business processes must be reestablished and normal operations must resume. Identify contingency situations and cause(s) of business interruptions. Describe the method for supporting contingency situations. Review requirements with business areas. Secure acceptance of deliverable.
Task Steps for Identify Business Availability Requirements
2.
3.
4.
5.
Table 1-25
that IS controls the business availability. This conventional reasoning does not give adequate representation to the business operations and user communities who may have a different view of what availability is necessary in order to perform critical business functions and provide customer satisfaction. This task is designed to facilitate a discussion between the operational and information systems parts of the business in order to arrive at a consensus on what is an acceptable percentage system uptime and the contingency measures to implement during a system outage. The technical architect, database administrator and system administrator should represent the IS organization. Key business analysts and lead users should represent the business operations and user communities in the discussion. This task should have the following results: a detailed description of the business availability requirements, taking into account any variations in criticality of different applications, application modules, organizations, and so on a binding Service Level Agreement that states what the minimum systems-level availability is that the IS organization will undertake to provide a discussion of the contingency tools and procedures (if any) that will be used to provide availability during periods of system outage For a technical view of a Service Level Agreement, see: Reference: Millsap, Cary V., Designing Your System to Meet Your Requirements, OAUG Conference Proceedings, Fall 95.
Acceptable Downtime
Find out what the maximum acceptable system downtime is for daily and weekly backup procedures and the maximum acceptable recovery time in the event of a disaster. These factors will affect both the backup and recovery procedures and the type of hardware and software required to support the requirements.
Oracle Method
Contingency requirements outline the specific situations that cause abnormal behavior or complete business process failure.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Technical Analyst % 95 5
% * *
Deliverable Guidelines
Business Availability Requirements
Use the Business Availability Requirements to provide the operating requirements that support the business transactions to the technical architecture process. It catalogs those transactions having the highest volume or significance in your business and identifies the maximum allowable window for the application system to be down. It will also help you to prepare for abnormal business and system conditions.
Oracle Method
the mechanisms, subsystems, and procedures each business function needs and calculate the time needed to sustain these temporary processes. Considerations for defining contingency requirements include the following: paper forms PC tools related files and programs alternate system components
Tools
Deliverable Template
The deliverable template consists of the following components: Business Availability Business Contingency Requirements Business Availability Requirements Use the series of questions to capture and formalize feedback: from business process owners to systems management from systems management to business process owners The questions address such issues as the operational schedule, operating window, volume and frequency of transactions, and backup schedules. This component formalizes the understanding of both groups of people in order to optimize the technical support of business activities. Business Contingency Requirements Use this template to formalize a contingency plan for each critical process in the business. Identify both internal and external transactions. List the paper forms that can be used as alternate source documents during the contingency period and identify other tools or systems that could be used. This enables you to understand which business processes have documented procedures in place to cover the contingency.
Describe contingency situations that need to be anticipated; prioritize them by severity. The nature of each contingency situation will help you determine the robustness of the contingency plan you require for each possible situation.
Oracle Method
Deliverable
The deliverable for this task is the Master Report Tracking List. It is the primary repository for all information collected about a report requirement. It should contain system and report name, business purpose, frequency, priority, user name and contact information.
Prerequisites
You need the following input for this task:
G
The collection of current system reports will be the starting point for the baseline of the present system reporting output.
G
Reporting requirements that are linked to future process steps may be identified in business requirements scenarios.
Task Steps
The steps of this task follow: No. 1. Task Step Determine an approach for collecting report requirements and implement. Deliverable Component
No. 2.
Task Step Design Master Report Tracking List. Update Master Report Tracking List from method selected in step 1. Update Master Report Tracking List from BRS documents. Identify critical reporting issues and document. Forward copy of Master Report Tracking List to enduser for approval.
3.
4.
5.
6.
Table 1-27
Oracle Method
End-User Survey
For large organizations where it may be difficult for the project team to determine all the critical report requirements, some form of user survey may be necessary. If the list produced after extracting requirements from the Business Requirements Scenarios (BRS) and researching system report files is not satisfactory, the team may need to survey the end-users. Attention: The goal of the survey is to collect business critical report requirements that may have been overlooked, not a list of every report that may have been run regardless of whether or not anyone used it. Stress to the users that only critical business requirements are important and that their manager must approve their list before mapping begins. Analyzing, mapping, and building reports is very expensive. When designing a survey approach, consider the following elements: Develop a Survey Rollout Plan Detail how you will distribute and collect the reporting requirements within the organization. If the organization is small, you can send a survey to each individual. However, as organizations increase in size it becomes more and more difficult to distribute, track, and summarize the survey information. In this case, the best approach is to appoint a representative user to be responsible for gathering all requirements and representing their department during analysis, construction, test, and delivery. This will reduce the number of individuals the reporting team must interact with. Make sure that the representative user understands the responsibility for their groups requirements. Also, when distributing the survey in a large organization, the best approach is to distribute it through the management chain. As managers pass the survey through their organizations, they can stress the importance of full participation.
Develop Survey Organization Chart This chart diagrams how the survey will be distributed throughout the organization. Start by separating the organization by its logical units. Identify the manager in charge of each unit and have him or her identify who should represent each organization. The manager may further divide his or her organization until finally reaching the user who represents a particular group of end-users. List the manager, the representative user, and the group they represent. Use this chart to verify that all organizational areas have been covered. Prepare the Survey Packet This packet should include a survey cover letter introducing and describing the survey process, survey instructions, and the survey itself. Examples of survey data are included in the guidelines section. Attention: It is extremely important that users specify a priority for each requirement. This priority helps determine which requirements are most important and therefore should be considered first. The priority can be a combination priority/ranking, such as A1, A2, where A reports are needed at go live, and A1 is the most important go live report. Once the survey packet has been prepared, distribute the packets through management. Make sure that you stress when the completed packet is due and that you track all returns.
Survey Elements
You should include the following elements on a survey: Report Filename/System Filename Report names may be similar and become interchangeable. The filename is a unique name representation. End-users may need help from their IS representative to determine filenames. Report Name/Report Title (optional) Business Purpose What business purpose does this report satisfy? Use this information to determine whether or not the report is needed in the future processes. User Priority How important is this report to the user? Build some logic into this field so it includes both priority and ranking, (e.g., A1, A2, A3, B1, B2, B3, C1, C2, C3). Suggested priorities are: A - highest priority, needed by go live date
Oracle Method
B - needed by first month-end C - needed by first quarter-end D - needed by year-end E - nice to have User Run Frequency (optional) How often is the report run? This is useful when setting up daily or night batch jobs. User Name Who owns this requirement? You may have several people requesting the same report. Track each request as a new unique request. This points out which reports are common across divisions, teams, departments, and so on. A report used by multiple divisions has a higher implied priority than a report used by one person. If the multi-divisional report is not replaced, it will have a greater negative impact. If the requirement originated in a BRS document, enter the BRS name. User Phone Extension (optional) User Email (optional) User Position This information is useful when determining the future reports associated to a position. User Division The division is useful in consolidating reports.
larger projects, a database tool is necessary. For very large projects, maintaining the Master Report Tracking List is a full-time position. To make tracking easier, you can divide the elements of this tracking document into the following files and link them together through the report tracking number: Business Requirements Scenarios (BRS) and Survey Master Requirement List Development End-User Delivery Information Keep the Master Report Tracking List in the same directory as other project tracking documents. Because the list may actually be composed of smaller files, a separate directory may be necessary. The following calculations show how to use the Master Tracking List for status reporting. If you are using a spreadsheet, this may require sorting the spreadsheet. Total Report Requirements = total number of entries on the tracking list Total Unique Requirements = (total number of entries on the tracking list) - duplicates [sort by assessment] Customization List = (total builds + total modifies) [sort by assessment] Total specs completed = sort by spec done = y Development backlog = sort by assessment and with a subsort by development = n Map old report to new report = sort spreadsheet by future report name All reports for a specific user = sort by user name
Update Master Report Tracking List from BRS Documents and Other Sources
Collect all BRS documents, surveys, interviews, and so on, that contain report requirement information and transfer them to the Master Report Tracking List. It is important to catalog requirements as quickly as possible so mapping can begin. If the requirement was gathered from a BRS, it is very important to include the future process flow number in
Oracle Method
the Master Report Tracking List. Any requirement categorized as a build cannot be built without a valid future process flow number. Also, insert the BRS name as the user name. This will make it easier to identify all requirements coming from a BRS.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Business Line Manager User
Table 1-28 Role Contribution for Develop Reporting Requirements
% 100 * *
Deliverable Guidelines
The deliverable for Develop Reporting Requirements consists of the Master Report Tracking List.
Oracle Method
User Run Frequency (optional) How often is the report run? This is useful when setting up daily or night batch jobs. User Name Who owns this requirement? You may have several people requesting the same report. Track each request as a new unique request. This points out which reports are common across divisions, teams, departments, and so on. A report used by multiple divisions has a higher implied priority than a report used by one person. If the multi-divisional report is not replaced, it will have a greater negative impact. If the requirement originated in a BRS document, enter the BRS name. User Phone Extension (optional) User Email (optional) User Position This information is useful when determining the future reports associated to a position. User Division The division is useful in consolidating reports. Mapping Assessment/Mapping Resolution This field tracks the report status and is the basis for compiling management reports. Suggested statuses are as follows: None The report has not been analyzed and its status is unknown. Build The report is required for future processes and must be built. Combine The report requirement can be satisfied by combining with similar requirements from another report. Always match a report classified as a combine to a report classified as a build or match. In other words, the requirement for reports ABC, DEF, 123 combine into report XYZ. XYZ is the new requirement which replaces ABC, DEF, 123. This is how to represent one new report replacing several old reports. Duplicate The requirement exactly matches another users requirement. In other words, there are five entries for the required filename costanalysis.rpt. Categorize one as Build, Combine, Match or Not Needed, and the other four as Duplicate.
Match The report requirement is being replaced by a standard Oracle report. The requirement directly maps to standard functionality. Record the name of the standard report in Future Report name. Modify The requirement maps to standard functionality, but the standard report needs modification. If the standard report needs significant modification, classify the requirement as a Build. Use Modify for those situations where minor changes are needed to standard functionality. Not Needed The requirement does not map to a future business process, or upon further analysis is categorized as no longer used. Assessment Comments Record additional comments about the assessment. Example: Requirement appears to match Cost Rollup standard report, but needs to be tested. Combined into Tracking Number Enter the tracking number for the report replacing this requirement. Future Process Number Enter the Business Requirements Scenario (BRS) this requirement maps into. A report must map to a BRS in order to be classified as a Build or Modify. If the report does not map to a BRS enter No Match in this field. All reports with No Match should not be developed because they are not part of the new business processes. Function Use functions to group reporting into logical business units such as shipping, accounts receivable, journal entry, scheduling, checks, backlog, bookings, billing, and so on. It can also help determine which reports can be combined together. (Example: There are 90 shipment reports listed on the Master Report Tracking list. After further analysis it is determined 60 reports contain the same data and can be reduced to five new report requirements.) You can also use functions to determine whether any reports are missing. If after assigning a function to all reports no cash receipt report has been identified, it may be that the BRS is inaccurate, or the survey may have missed a group of users, a report, or a business function.
Oracle Method
Tools
Deliverable Template
Use the Reporting Requirements deliverable template to generate the Master Report Tracking List. Record the appropriate reporting information.
CHAPTER
Figure 2-1
Oracle Method
Process Flow
Business Requirements Mapping (BR)
RM.01 0 BR.010: Prepare Mapping Environment PJM.RM.050: Prepared Infrastructure RD.020: Current Business Baseline RD.030: Future Process Model RD.070: Business Requirements Scenarios TA.040: Conceptual Architecture RM.03 0 BR.070: Conduct Reporting Fit Analysis TA.080: Reporting Strategy RM.02 0 BR.020: Map Business Requirements Analyst
System Administrator
PJM.CR.030: Quality Plan RD.030: Future Process Model RD.050: Process and Mapping Summary RD.070: Business Requirements Scenarios RD.080: Audit and Control Requirements TA.040: Conceptual Architecture MD.010: Customization Strategy TR.040: Trained Project Team
TA.040: Conceptual Architecture TA.050: Technical Architecture Baseline TA.070: Future Application Deployment
RD.010: Financial and Operating Structure RM.04 0 BR.030: Map Business Data RD.020: Current Business Baseline RM.05 0 BR.040: Conduct Integration Fit Analysis RM.11 0 BR.050: Develop Information Flow Model
Team Leader
Figure 2-2
TA.130: Application Functional Architecture RM.06 0 BR.080: Test Business Solutions Analyst RM.09 0 BR.110: Define Application Setups
RD.010: Financial and Operating Structure RD.040: Future Business Function Model RD.080: Audit and Control Requirements RD.100: Master Report Tracking List
Team Leader
Figure 2-2
Oracle Method
Approach
The objective of the Business Requirements Mapping process is to ensure that an acceptable and feasible solution emerges, is proven, and becomes well documented. The Business Requirements Mapping process is closely related to the Business Requirements Definition process. During the definition activities, the two typically share many resources and common deliverable components. The completion of these deliverable components takes place during mapping. The primary goal of both implementation processes is to create a set of business processes that represent how the business will operate after implementation. The design of new processes to meet business requirements occurs during definition activities. You ensure that the new application system supports these new processes by mapping. The Business Requirements Mapping process encompasses the following areas: mapping business solution testing process narratives application setups
Mapping
Mapping is an iterative approach with the following objectives: Prove business process designs through demonstration Identify gaps in the application Propose feasible bridges to gaps Mapping begins early in the life cycle of a project. During presales, application teams often express strong feelings about the level of fit of application features to business requirements or gaps between requirements and features. When the documentation of initial assessments takes place, it forms the initial basis for mapping. As process designs progress during mapping, so do deliverables. Mapping tasks span both the Business Requirements Definition and
Business Requirements Mapping processes. The creation of one Business Requirements Scenario document begins for each business process during Definition, and then completes during Mapping with solution information. Some tasks require these mapped BRSs, while others require only the initial BRS. If a task has a Business Requirements Mapping Form as a prerequisite, mapping occurred on those business processes being considered by that task. Mapping provides a basis for documenting detailed business requirements and proposed solutions. Generally, mapping teams are the same as process design teams (organized either by business area or some other process grouping that crosses organizational boundaries). Areas that are necessary to map include: business requirements attached to business process steps report requirements business data requirements
Process Narratives
Process narratives further define process designs to job-level designs, thereby determining how the work gets done and laying a foundation for the following: user guide user training (role-based)
Oracle Method
user certification or other types of readiness testing Write one process narrative for each business process.
Application Setups
Application setups include both static data, such as common codes and tables, and system configuration options. It is important to capture applications setups and security decisions in mapping. The approval of process designs will allow use of the resulting configuration in the training and production environments.
Deliverable Name Configured Mapping Environment Business Requirements Mapping Form Business Data Mapping Form Integration Fit Analysis Information Flow Model Information Access Model Master Report Tracking List Mapping Scenario Acceptance Certificate Process Narrative Application Setup Document Security Profiles
Objectives
The objectives of the Business Requirements Mapping process are as follows: Establish application fit to business requirements, identifying gaps and proposing initial solutions. Identify gaps in the application. Propose feasible bridges to gaps. Prove designs through demonstration. Trace business requirements to application solutions. Create a model that visually depicts information flows in the business in order to specify data use within and across your organization. Create job-level descriptions of business process designs. Define the application configuration you need to support the solution.
Key Deliverables
The key deliverables of this process follow: Deliverable Configured Mapping Environment Description New or existing application environment(s) prepared for exclusive use during mapping activities by mapping teams. Detailed business requirements written in business language and associated with business processes; analysis and comparison of the current solution for a business requirement to a proposed solution; details for the type and nature of the solution in a descriptive format.
Oracle Method
Description Revise BRSs while finalizing process designs. In addition, create or update some BRS components during mapping (like Process Analysis and Solution components). Update Process Models while finalizing process designs. Document workarounds or new designs when initial designs are not feasible. Verification that the underlying table structures and attributes will support business processes. Statement of fit and gaps for integration points between unique applications and installations of the same application. A model that visually depicts information flows in the business between business functions, business organizations, and applications. A model that depicts access to key process and organization information for reporting and/or security purposes. A working document that supports the analysis and mapping of report requirement to future business processes and standard application reports. It contains the final disposition of every report requirement.
Description A plan for and record of business solution testing, including: business processes involved in the test, the necessary business conditions to test the application system, definition of test script execution, support tools required during execution of the test, and a record of test actions. Agreement by Management that integrated business solutions cover business objectives and satisfy the project problem statement. This problem statement is a concise phrase, motto or goal-oriented explanation of the motivation behind buying a new application system. A Process Narrative is a job-level description of business process design used in defining how the work gets done, confirming process designs, and creating prerequisite foundational material for: (1) User Guide, (2) User Training (role-based), and (3) User Certification or other types of readiness testing. Definition of the configuration that has been proven to support the solution. List of role-based security specifications necessary to ensure good controls and transaction access.
Acceptance Certificate
Process Narrative
Security Profiles
Table 2-2
Oracle Method
Key Responsibilities
The following roles are required to perform the tasks within this process: Role Application Architect Responsibility Provide input and advice on the architectural consequences of particular gaps and solutions. Provide application functionality and guidance. Support and provide interpretation for tools, templates, and methods. Conduct interviews and working sessions. Identify detailed business requirements and create business requirement scenarios. Participate in interviews and working sessions, review and approve contents of models, and provide access to existing systems. Ensure availability and commitment of company personnel and availability of hardware, software, and facilities. Establish commitment to the project from the appropriate users. Ensure that they review and formally approve deliverables for which they will be responsible. Install and configure the mapping database. Make sure all users have access to the database. Run the design sessions and keep momentum going.
Application Expert
Business Analyst
Facilitator
Responsibility Perform deliverable and template version management. Gather and inspect deliverables. Assign document names and record new documents into the library. Provide some advice regarding process integration. Provide deliverable status. Install and configure hardware and operating system. Install and configure application code. Ensure that login IDs exist for the mapping team. Conduct project planning and assign tasks, establish roles, brief staff, manage team, manage changes, manage issues, maintain quality, and obtain acceptance. Propose solutions and technical assumptions. Develop data profiles. Provide writing standards, models, and guidelines. Write non-business content. Participate in interviews and working sessions, review content of business requirement scenarios, and help identify gaps and solutions.
Business Requirements Mapping Key Responsibilities
System Administrator
Technical Analyst
Technical Writer
Users
Table 2-3
Oracle Method
Deliverable
The deliverable for this task is a Configured Mapping Environment.
Prerequisites
You need the following input for this task:
G G G G
Early in the project, plan the approach to use and configuration of mapping environments. Follow this approach to maintain consistency with resource allocations and schedules. Current Business Baseline (RD.020)
An understanding of current operations is useful when setting up a mapping environment. Business Requirements Scenarios (RD.070)
Business Requirements Scenarios (BRS) help establish the scope of environment configuration and boundaries with environments used by other mapping teams. Future Process Model (RD.030)
Process Flow Diagrams provide a graphical view of the employment of transactions during mapping and, therefore, mapping environment requirements.
Oracle Method
G
Task Steps
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. Conceptual Architecture (TA.040)
Perform mapping in an environment that simulates, or at least assumes, the proper application and database structure for the business area.
The steps of this task follow: No. 1. Task Step Review Project Environment Strategy. Review the Conceptual Application and Database Architecture. Install mapping environment, if necessary. Set up applications. Review end-user procedures. Obtain actual baseline business scenarios, if necessary. Gather necessary sample data. Enter data for baseline mapping purposes. Sample Data Installed Applications Deliverable Component
2.
3.
4. 5. 6.
Setup Data
7. 8.
No. 9.
Deliverable Component
Table 2-4
Oracle Method
Suggestion: Assign a specific team member to record decisions made during class that affect setup.
Role Contribution
The percentage of total task time required for each role follows: Role System Administrator Project Database Administrator Applications Administrator Team Leader Client Project Manager
Table 2-5 Role Contribution for Prepare Mapping Environment
% 40 30 20 10 *
Deliverable Guidelines
After installing the mapping environment, follow these steps to make sure it contains the minimum configuration required to support downstream mapping tasks: Set up all application parameters to enable transactions. Enter enough business data to demonstrate application features effectively. Make sure you reflect early decisions from the presales discussions, analysis, and product training in the initial setup. Provide access to definition and setup screens to appropriate users. Enable any links to nonstandard application or custom systems (if applicable). Make reporting and data query tools available in the mapping environment to verify correct mapping.
Oracle Method
Tools
Deliverable Template
Use the Application Setup document template to document early setup decisions. Although this template is optional for this task, you can use it to get a good start in the mapping process. Attention: Any application setups captured at this point will probably require review after mapping activities are complete.
Deliverable
A Business Requirements Mapping Form (BRM) is the deliverable for this task. There is one BRM per key business requirement or gap. The BRM is an extension of the BRS, since it shows the result of the mapping activity.
Prerequisites
Required
You need the following input for this task:
G G G
The organization of mapping activities is by business process. You identify and define business processes by Business Requirement Scenarios (BRSs). Therefore, there will be one mapping task planned for each BRS. The intent is to ensure that the business process and its associated detailed requirements are feasible and supportable by the application and, if not, to define a feasible solution. Future Process Model (RD.030)
The picture of the business process will be very helpful to mapping teams in visualizing how the business will operate after implementation is complete. Trained Project Team (TR.040)
During the mapping procedure, some online prototyping will take place. To assure the feasibility of proposed solutions to business requirements, each mapping team must be knowledgeable in application concepts and features.
Oracle Method
G G G G
Each mapping team needs a modeling environment in which to create prototypes of initial solutions. Audit and Control Requirements (RD.080)
After establishing business requirements at the business process level, determine methods and procedures for controlling and auditing these processes. Map these requirements to the application system. Customization Strategy (MD.010)
Consider the stated project policy and approach that constrains the formulation of solutions that entail application customizations. Conceptual Architecture (TA.040)
Use this deliverable to help assess the feasibility of solutions with respect to architectural strategies, requirements, and decisions. The conceptual architecture is both an enabler and a constraint to process designs.
Optional
You may need the following input for this task:
G
Document standards and guidelines for organizing and running mapping teams before mapping begins. In this way, all teams will follow the same approach and deliverable creation, and review will be more consistent.
Task Steps
The steps of this task follow: No. 1. Task Step Train all assigned team members in the use of the methods and tools for mapping and BRM creation. Check out the prerequisite deliverables and get a block of control numbers assigned for expected new BRMs. Become familiar with business requirements scenarios for the target process in need of mapping. Conduct mapping session to assess detailed application fit and create or revise solutions to business requirements. Map future business requirements to application features, programs, reports, and other standard modules. Perform online prototyping and deliver a prototype demonstration. Document major requirements or fit issues into a Requirement Essay. Perform process research; look for and document solutions and supporting evidence. BRS Solution Deliverable Component
2.
3.
4.
5.
Prototype
6.
Mapping Source
7.
Oracle Method
No. 8.
Task Step Identify current versus proposed process steps and assess the feasibility of proposed solutions. Document solution components. Record possible alternative solutions for application gaps. Document major operating and policy decisions. Secure Acceptance of Deliverable.
9.
Mapping Solution
10.
11.
Table 2-6
The following list includes some broader connotations of the term mapping: the identification of detailed business requirements the formal linkage of Future Process Models to application features the basis for establishing application fit to business requirements, identifying gaps, and proposing initial solutions a set of tasks to trace business requirements to application solutions In this regard, mapping describes the evolution of process design for a business process. The BRS will continue to evolve and be supplemented and improved throughout all mapping tasks. The formal mapping task, however, is very specific in that it documents key business requirements and proposed solutions in much more detail than generally described in a BRS.
Oracle Method
configuration management (to ensure proper use of tools and cataloging of deliverables) tracking events and BRSs and BRMs in order to ensure integrity (no missing or overlapping processes or solutions) Attention: The skill set requirements for this library function exceed the typical training and experience for this role. Do not just assign this function to clerical staff based on their availability or similar experiences in the past. Always organize mapping sessions for efficiency by publishing a thorough agenda beforehand that includes: session location and duration role assignments the business process to be mapped activities and sequence the inputs required (like prerequisite deliverables) and assignments for bringing them the expected outputs and criteria for successful closure of the mapping session
Mapping Process
It may be hard to separate mapping activities from those of process design, especially in the following situations: The project is small or its target business area contains few business processes. The project team is pursuing rapid implementation and therefore wants to complete deliverables in parallel as much as possible. The process design team is intact through the mapping stage, and therefore process design and mapping form more of a continuum. The objective of mapping is to ascertain the fitness for use of application features in satisfying detailed business requirements expressed at a business process step level and then to make a formal disposition of any and all identified gaps. Each business process step relates to a series of procedures, application screens, reports and inquiries. As a starting point, use approved BRS documentation for a given business
process. Usually this means that the mapping team has a formal statement of requirements and their sources. Update the BRS as a record of your mapping progress. For instance, the fields in the BRS Solution deliverable component indicate whether there is a fit or a gap in functionality, and the BRS Business Process Identification component indicates the status of each process step. In addition to updating the BRS, create the Business Requirements Mapping (BRM) form as needed. This deliverable is a proposal for change to some process design detail (at the process step level) that needs approval or specification. It is a description of the proposal. If a BRS maps 100 percent to the application, it may not be necessary to create any BRMs for that business process. Attention: You must complete a BRM for all requirements or process steps coded as Custom (where there is a required customization to the standard application). It is also acceptable to use the BRM form to document the purpose and reason behind a particular design. Another way to accomplish this is to put a reference to a topical essay or other standard documentation reference in the BRS deliverable. When mapping, keep the following step-savers in mind: Address critical business processes identified by the company before seeking resolution to issues that crop up in minor business process designs and maps. Use standard system features, functions, and reports whenever possible. New business requirements could emerge during a mapping session. Ensure that these new requirements fit within the scope of the project before adding them to the business requirements list. Set aside time to finalize these requirements. Attention: When you discover new business requirements as a result of mapping activities, you should always revisit the Project Workplan to ensure that downstream estimates are still valid, and update the workplan if necessary.
Oracle Method
Prototyping
When using traditional mapping techniques, you discuss the requirements and alternatives drafted before any online configuration or development begins. A better approach is to use system functionality to help converge on needed features that support business operations. Using a prototype technique, draft an initial solution and prepare a model of the solution. Consultants help create the alternative solutions and set up the appropriate configuration in the mapping environment. Then the project team and key users review the solutions, using the prototype as a guide, and interactively refine the model. These sessions also include a high degree of testing. The emphasis is on proof
proving the model, concepts, and approaches that form the core of the recommended solutions. Repeat this process until you arrive at an acceptable solution. By preparing the process flow and system in advance, the project team concentrates on satisfying the business need and focuses on inputs and outputs from the process. This method reduces the tooling or setup time necessary for each requirement. Suggestion: Prototyping requires a thorough understanding of integrated applications. To use this technique effectively, schedule consultants or other application-knowledgeable people full time during mapping to deliver the preliminary solution. A prototype is primarily an online deliverable that is modifiable interactively by the project team. This technique enables the company to focus on the end result rather than the mechanics of setting up the applications. You combine knowledge of the business requirements, current operations, and applications experience to formulate a number of solutions for the project team to review. It is important to involve team leaders in the mapping development process. This provides an excellent opportunity for leaders to gain practical experience configuring and testing the applications. As soon as possible, encourage the team leaders to take responsibility for driving mapping sessions, thus allowing the application expert to facilitate and provide guidance. By presenting the solutions to the rest of the team and to end-users, team leaders convey support and generate confidence in the new system. Providing one solution may not be enough to satisfy the mapping team. Therefore, the prototyping process must be iterative regarding the design and test of proposed solutions. Repeat the process as needed until the team is comfortable with the business solution and are ready to sign off on acceptance certificates. Figure 2-3 depicts the creation of a visual process model, followed by a detailed business requirements scenario. Complete a BRM form for those task steps on a BRS with a gap (or whenever you need a detailed requirement essay). A BRM is like a placeholder and usually results in a Solution Document during the Solution Design phase. After process refinements and decisions are made, Solution Design activities can begin, resulting in process narratives and application setup documents.
Oracle Method
Analysis
Business Requirement Scenario Business
Process Model
Manual
ORACLE
Other Applications
SI S2 S3 S4 S5 S6
Requirement Mapping
Application Gap
Requirement BRM Current vs. Proposed
S1
Agent 1
S2
S3
S5
S6
Detailed Requirement
Solution
S4
Agent 2
Design
Revise
N O
OK?
YES
Solution Document
Essay Estimate
Process Narrative
Application Setups
Parameters
Profiles
Figure 2-3
Consider these prototyping tips: Quickly devise and show an essential solution (not necessarily complete the first time). Focus on core processes and characteristics that drive business objectives. Create just the major components of a working model. Do not worry about cosmetics.
process characteristics ways to reduce process exceptions ergonomics such as ease of error correction how to think ahead and consider linkage of final process designs and solutions with user procedures and training Just as in initial process design creation, inform team members of (1) process characteristics and idiosyncrasies, (2) transaction volumes, and (3) exception processing. The best way to approach this is through detailed interviews and observing how the business operates, in order to be in a better position to test design feasibility and offset concerns particularly from those who do not want the new system to succeed. Another approach to process research is to employ a combination of workshops and key process walkthrough tests (watching how the business works). This technique requires careful management and careful picking of workshop members, but can provide instant feedback and verification of the perceptions of different groups regarding cycles, processes and dependencies. Workshops often convey more information in a shorter time than a series of interviews, and could reduce time spent in verification and cross analyzing. Try to get informal agreement before the formal sign off. Just as in the creation of BRSs, follow the Rule of 3-2-1 and skew time spent toward talking with real users and reviewing real process outputs. Avoid mapping exclusively in a conference room.
Oracle Method
reporting systems critical enterprise interfaces It is best to avoid very detailed solution documentation in the BRM. There are other deliverables more suited for this purpose. Think of the BRM as a record of key decisions, or as a placeholder in anticipation of additional detailed design documentation. Adequately bridging gaps is the primary purpose of the BRM. Consider these tips when mapping and creating BRMs: Design solutions for the desired state of the business, rather than directly mapping to current needs. Always implement workarounds before designing and building a custom solution. When multiple solution options are available, choose the option that supports company goals or broad business areas, rather than satisfying the needs of a single department or user. Consider these rapid implementation mapping tips: Get quick closure on gaps. Push hard on perceived gaps up to 80 percent of the initial gaps identified may actually be found to be unnecessary. Ask the question: What does the application do? in order to keep the mapping session moving when it gets stuck. Pay special attention to prioritizing gaps in order to manage scope and budgeted resources properly.
use of repetitive manufacturing functionality for final assembly operations use of Lot Control for key components Another general rule for inclusion of a decision on the Process and Mapping Summary: look at the request-for-proposal document that drove the presales cycle (before selection of the application). This document usually contains primary requirements with its solutions classified as key decisions.
Process Analysis
Generally, you should quantify any solution that requires unexpected cost or resources. Comparison of cost/resource for current versus proposed processes is vital to selling change to management, key business people and systems users. It is particularly important to draw in sponsors for the change by getting them involved in the justification process itself. The following reasons justify change: saving time reducing resource/labor or improving utilization increasing efficiency (and ability of process agents to take on more work due to the proposed changes) Capture key process information for both current and proposed process steps.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Application Expert Technical Analyst Configuration Manager Facilitator Team Leader Application Architect Business Line Manager
Table 2-7 Role Contribution for Map Business Requirements
% 35 25 20 5 5 5 5 *
Deliverable Guidelines
The mapping process begins the design of business solutions. Refer to the Quality Plan for any mapping guidelines that should be used. You should attempt to map standard features of the applications to each defined business requirement.
Oracle Method
The deliverable for the Map Business Requirements task represents the best solution for satisfying the particular business need. Explore all possible workarounds before recommending custom extensions if previously noted gaps exist. Describe the requirements in terms of business objectives rather than application features. State any risks that might occur from an unmet requirement. This helps prioritize competing requirements. The following guidelines are useful when creating this deliverable: Maintain organization of mapping solutions. Focus on the elimination of non-value-added steps. Analyze the best method to implement solutions. Graphically illustrate new or changed processes. Identify the reporting and messaging needs of custom extensions. Define special or additional implementation steps. Respond to perceived shortfalls and required system enhancements. While it is ideal to use the standard application system, the reality is that each company has unique business needs that standard components cannot always fulfill. This task investigates possible solutions that use combinations of standard and custom components. Therefore, it is important to separate product fit, workarounds, and custom extensions. This distinction helps you plan the necessary custom extension design and development later. The Business Requirements Mapping form deliverable helps you specify the bridging of gaps. The BRM closes the loop on key design issues for which a solution must be found.
If there is an acceptable workaround, the BRS and process model should reflect it, and there is no need for a BRM; otherwise create a BRM. Use one BRM to support multiple gaps from a single BRS only if there will ultimately be a single Solution Document written in support of these gaps, and if there is a logical relationship. When listing requirements on a BRM, describe these requirements in terms of one or more business objectives and not application features; focus the BRM on Why to satisfy the requirement more so than How. You may optionally use a BRM as a placeholder when a mapping team wishes to preserve some record of detailed design that might be useful later during detailed solution documentation, even in those cases where no application gaps exist. When used for this purpose, clearly mark the BRM as a Design Note so it is not perceived as a gap. When using rapid implementation mapping techniques, it is customary to develop a BRS for the proposed process (using features from the new application package as the driver), and then have one BRM that reflects how the process is being improved along measurable lines. The BRM # can be listed in a zero step in the Solution component of the BRS. Attention: BRMs are more of a placeholder for identified gaps, not Solution Documents. A BRM serves as a bridge between a BRS and a Solution Document.
Deliverable Components
The Business Requirements Mapping form deliverable consists of the following: Mapping Source contains a Requirement Essay section that describes the business requirement in business language and in terms of business objectives, rather than application features It also contains a Current versus Proposed section that facilitates the analysis and comparison of the current solution to a business requirement to a proposed solution. Mapping Solution details the type and nature of the solution in a descriptive format.
Oracle Method
Acceptance Criteria
The BRM form should contain the following heading information: process control number priority owner process or scenario description source type (gap, design note, and so on) In order to pass a quality review: Develop the BRM using the approach listed in this task. The BRM must be reviewed by a qualified peer who signs off as the first reviewer. This sign off indicates that the BRM is accurate and consistent. For best results, the review should include both the process owner as well as the customer of the process (either the requester or the owner of the next process down the line within the business area).
Tools
Deliverable Template
Use the Business Requirements Mapping Form template to create the entire deliverable or specific deliverable components. The components for the deliverable follow: Mapping Source used to establish identification and source for a particular business requirement Mapping Solution used to document a proposed bridge to that gap
Mapping Source Complete the information in the header areas for identification purposes. Process a brief description of the process Business Area a code designating the mapping team responsible for this process Date date form is being initiated Control Number a unique identifier for each business process (e.g., 6-character code in format AAA.999, where AAA represents the subprocess, and 999 is a unique 3-digit code assigned sequentially from a log maintained by each team) Mapping Team either the process modeling, design, or mapping team responsible for this business process Process Owner the agent with overall responsibility for the process; could be the customer of the process, or the supplier (one who fulfills the request) Librarian the person charged with maintaining this BRS deliverable and interfacing with other teams in order to ensure control and proper alignment with integration goals Priority determined at each teams discretion; this is a good place to identify Core Processes Core an identification of major, driver processes that affect or influence business objectives Source Type indicate whether the BRM is to document a Gap, or is a Design Note Author originators name Ref Doc reference to some other formal requirement description source document (usually such a document already exists and the BRM initiator simply wishes to avoid rekeying its contents on the BRM) BRS Reference # Business Requirement Scenario document control number that is the parent of this BRM (also enter process step number)
Oracle Method
Complete a Requirement Essay. Answer these questions: What? Why? Who? Gap or Design Note (e.g., non-Gap). Clearly define the reason(s) for the requirement, along with references to any support information (e.g., policy or mission statements, etc.). Complete the Current Versus Proposed section to document current process steps planned for elimination or modification, including the expected effect on cycle time, cost and other resources. You might want to duplicate the section and show both current and proposed processes. Practices narrative description of customary or usual actions Policies principles, plans or courses of action, especially as dictated by Management Procedures narrative description of sequence of steps to be followed Seq process step number Ref/Description a brief description, beginning with an action verb, that captures the purpose and deliverable task; alternatively, could include a reference to another document (or just use the BRS step description) Activity optionally may be used for activity-based analysis purposes Action ADD/DEL/CHG status for the sequence number Cost/Time/Resource measurable resource usage by the sequence number Mapping Solution The Mapping Solution component is optional. Use it to describe process changes, organization changes, usage of other systems, or to describe other process enablers. Workaround description of the proposed method for getting around an Application-to-Requirement gap Application Enhancement description of the custom modification to the Application whose implementation will result in satisfaction of the business requirement
Reengineering Opportunity description of simplification, elimination or enhancement of the target process Solution/Design Document Reference if available, a document number for high-level or detailed design planned to satisfy the requirement Mechanism resources that influence the process; people, tools, or machines affected by the BRM proposal Interfaces description of system interface requirements necessary to satisfy the requirement Solution Technique description and type of Application feature that will satisfy the requirement (configuration, setup, flexfield, alert, zoom, report, form, etc.)
Oracle Method
Output Specification the source record for how to determine acceptable task output Cost the costed dollars added by this task Cycle time the elapsed time duration added by this task Other Resource the quantity of some additional key resource used by this task BRS Solution As required, update the BRS Solution deliverable component with this information: Process Step # a unique sequence number for each task System/Module a reference to the Application system module that satisfies this task requirement Application navigation path or transaction zone information describing entry form used for system-assisted tasks Ref Manual Page/Line a topical essay or other narrative in an Application User or Technical Reference manual Tools reports or other mechanisms used in completing the task successfully Solution Type used to designate Workaround/Custom; use W if there is a non-system workaround that is acceptable, although not necessarily optimal; use C if there is a need for customization (note: complete a BRM form for all tasks coded with C) BRM Ref # Business Requirement Mapping document control number; optional unless Solution Type is C
Deliverable
The deliverable for this task is the Business Data Mapping Form. The deliverable records the standard application module, business object, and attribute. Also record the legacy system file name and fields for each business object in the table provided in the deliverable template.
Prerequisites
Required
You need the following input for this task:
G
The product of Business Data Mapping activities should be in alignment with business processes. Identify and define Business processes, and while developing BRSs, analyze them for business data requirements. The intent is to ensure that the business process and its associated detailed requirements are supported by defined business objects whose sources are known. A business object is a logical business grouping of data within an application (see the next section for more information).
G
Use the Existing Reference Material to identify and gain an understanding of the existing source systems and data structures that require data conversion.
Oracle Method
G
Optional
An understanding of current operations is necessary for mapping the existing source system data structures to the new target data structures and identifying conversion requirements.
G
Use this preexisting data model to identify and gain an understanding of the existing source system data structures that require conversion.
Task Steps
The steps of this task follow: No. 1. Task Step Analyze Business Requirements Scenarios for business objects required. Identify the legacy source file and field/data elements that are being converted and record this information in the table provided in the Business Data Mapping deliverable template. Use the Existing Reference Material and Initial Business Data Model to perform this task step. Business Data Mapping Form Deliverable Component
2.
No. 3.
Task Step Identify the target application, business object name, and attributes that the legacy files and fields map to and record this information in the table provided in the deliverable template. Record the fields which the legacy system stores but the application does not, and record the attributes which the application stores but the legacy system does not. Secure Acceptance of Deliverable.
4.
5.
Table 2-8
Oracle Method
For each business object being converted, identify the application name, business object, and attributes. Define a business object in this context as a business grouping of data that may map to one or more forms or tables. Examples of business objects are customers, vendors, invoices, items, and so on. The attributes for a business object are the adjectives or descriptive pieces of information about a business object that are either stored in the underlying tables or appear in the application forms as fields. Determine the required application attributes for a given business object to support future business processes. Use the application reference manuals to determine whether there are required fields in the application forms for which the legacy system does not have a data element. In these cases, the users should define default values that make sense for the companys business. Make sure that you map the new form fields/attributes to the legacy data and that you map the legacy data elements to the Standard application form fields. One way to map the legacy data elements to the application attributes is to navigate to the appropriate form and try to find a field for each data element/field in the legacy file for a given business object. If you cannot find a place to store the legacy data element in the application forms, confirm with the users that this is a required data element in need of storage within the new application. If the users require this data element, review the possibility of storing this element in an application descriptive flexfield. If many related data elements do not map to fields in the forms, then a custom form and underlying table might be required. Determine the source of each business objects data elements. For example, for the business object called Inventory Items, there may be more than one source from the existing system item master. Ask for the legacy source system file layouts and discuss the use of each of these fields in the current system with someone who understands the legacy system.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Application Expert Technical Analyst Business Line Manager
Table 2-9 Role Contribution for Map Business Data
% 50 30 20 *
Deliverable Guidelines
The Perform Conversion Data Mapping task (CV.050) uses the deliverable template for this task. For this deliverable, only insert data into the columns indicated in the notes of the deliverable template. The table in the template will later be used and completed by the Conversion Team Technical Analyst responsible for the conversion of this given business object in task CV.050. Complete one template for each standard application business object being converted to.
Tools
Use the Business Data Mapping Form template to create the entire deliverable by choosing the following deliverable component: Business Data Mapping
Oracle Method
Deliverable
The deliverable for this task is the Integration Fit Analysis document.
Prerequisites
Required
You need the following input for this task:
G G G
Use this deliverable to identify key distributed data integration points between applications, systems, and external systems. Future Application Deployment (TA.070)
This deliverable details the future deployment of applications required to establish the high-level integration points. Technical Architecture Baseline (TA.050)
Use this document to acquire technical information about the existing legacy systems, and especially the applications. Use this information to help determine integration points.
G
Business Requirements Scenarios (BRS) represent all relevant business processes that are within the business area, including those that are supported by existing systems. Therefore, BRSs will be a key driver for required integration points. It is best to consider only BRSs already mapped to the application. Unmapped BRSs may not be complete enough to be useful. Concentrate primarily on using BRSs for core business processes.
Optional
You may need the following input for this task:
G
BRMs are detailed explanations of key requirements and/or their solutions particularly if application gaps exist for a business process. These documents may provide information regarding interfaces identified as solutions.
Task Steps
The steps of this task follow: No. 1. Task Step Review list of existing interfaces in the technical architecture baseline. Perform an approximate application replacement mapping. Replace legacy applications in the listing of existing interfaces with the desired applications from the replacement mapping. Application Replacement Mapping Deliverable Component
2.
3.
Oracle Method
No. 4.
Task Step Create a diagram of the future external integration points. Examine the Conceptual Architecture document to identify key distributed data integration points between applications, systems, and external systems. Create diagram of the new distributed data integration points. Secure Acceptance of Deliverable.
Deliverable Component External Integration Point Diagram Distributed Data Integration Points
5.
6.
7.
Table 2-10
should be handled in some way by the new system, either as a direct mapping or as a change in implementation or functionality. Many fast track implementations justifiably use this type of bottom-up analysis, but so do larger, more complex implementations. Although the approach helps scope and validate the completeness of the mapping work, it also carries significant risks. It requires significant attention to detail when you define the existing technical architecture, and it does not guarantee that new interface requirements will be noticed and documented. The technique carries the risk of reimplementing outmoded practices, rather than leveraging the capabilities of new applications, and may miss critical requirements that would only become apparent with an understanding of the role of the interface in one or more business requirements scenarios. By using a tangible mapping of old interfaces to new, you may find it easier to focus on specific implementation deliverables. In larger implementations, this integration fit analysis should supplement the overall interfaces development and the top-down process and information modeling from the formal mapping process.
Oracle Method
complete reference document for all integration points to the new applications.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Analyst Team Leader User
Table 2-11 Role Contribution for Conduct Integration Fit Analysis
% 95 5 *
Deliverable Guidelines
The Integration Fit Analysis document describes the interfaces needed to integrate existing applications with the applications you are implementing. This document is an input to the Confirm Integrated Business Solutions (BR.090) and Define and Estimate Custom Extensions tasks (MD.020).
Tools
Deliverable Template
Select the Integration Fit Analysis Template to complete the deliverable for this task. Select from the following components: Introduction Application Replacement Mapping External Integration Point Replacement Mapping External Integration Point Diagram Distributed Data Integration Points Distributed Data Integration Point Diagram
Oracle Method
Deliverable
The deliverable for this task is an Information Flow Model for the business.
Prerequisites
You need the following input for this task:
G G G
The Business Requirements Scenarios documents provide the process and scenario flows on which the information flow model is based. It will include mapping of the business processes to application and system processes and allow the identification of processes that cross organizations, applications or installations and require custom extensions. Financial and Operating Structure (RD.010)
The Financial and Operating Structure document provides information about the business organizations that execute the process flows and scenarios. Integration Fit Analysis (BR.040)
The Integration Fit Analysis document provides information about the integration points between different applications and application installations.
Task Steps
The steps of this task follow: No. 1. Task Step Determine the information modeling approach and strategy. Review Business Function Models and Operating Structures to determine major functions to include in scope. Review Business Requirements Scenarios and Mapping documents to determine which business processes cross major functional, organizational or applications boundaries. Create a table, sorted by BRS code or number, of business objects transferred across business functions. Create a diagram that depicts cross-business function information flow. Create a table, sorted by BRS code or number, of business objects transferred across business organizations. Create a diagram that depicts cross-business organization information flow. Information Flow Between Business Functions Deliverable Component
2.
3.
4.
5.
6.
7.
Oracle Method
No. 8.
Task Step Review Integration Fit Analysis and identify all integration points within the scope of the information flow model. Create a table, by BRS, of business objects transferred between applications. Create a table, by BRS, of business objects transferred across data centers. Review the information model with process and mapping teams. Secure Acceptance of Deliverable.
Deliverable Component
9.
10.
11.
12.
Table 2-12
but the process-focused approach tends to submerge the actions taken on the business information. This task, together with the information access task, extracts and highlights the information view of the business processing and helps to provide a more complete picture of the business operational model in the new system. The term information model is preferable over the more traditional data flow model since data tends to imply structured data, while information can encapsulate structured relational data as well as nontraditional information media such as electronic text and image documents, video and multimedia. In modern processing environments, these nontraditional media are increasingly important.
Oracle Method
mapping teams do not create a formal information model, the technical analysts and designers of these processes will be forced to gather the information model requirements in a piecemeal fashion. This is undesirable for three reasons: Technical individuals may try to understand and recreate the information flow requirements, often at some later time in the project. They are clearly not the best individuals to compile the information flow model. The information model requirements may be collected as individual requirements for custom extensions, thereby potentially duplicating efforts. A full information model, on the other hand, will place the information flows in the context of a full process scenario and will aid understanding of the way an architecture component or subsystem, or a custom interface, fits into the overall process.
Defining Scope
You will need to identify the areas of the business for which you will create an information model. A suggestion for the minimum information modeling effort is to model the information flows for process scenarios under the following circumstances: There are custom extensions in the process. The process requires agents to access or manipulate information in two or more different applications (an interface between heterogeneous applications). The process requires agents to access or manipulate information in two or more different application installations (an interface between separate homogeneous application installations). Avoid Inappropriate Depth or Breadth of Analysis The type of information flow model required for implementing a set of packaged applications is different from the comprehensive entity and attribute analysis that takes place in a typical custom development (CDM) project. You probably do not need to deal with all of the attributes of a business object until the detail design portions of the project, if your project even requires those tasks. Focus your analysis on key business requirements scenarios at the business object level or where interfaces may be an issue. Analyze how information flows between organizations, and which organizations can access which data.
Functional Implications
A new applications system provides a platform for simulating the physical domain that it represents in ways such as the following: Inventory records provide an efficient method for locating stock. Production process records provide in-depth source information for product costing and variances. Payables records provide for forecasting cash requirements. Think of the application as a model that helps business users evaluate the potential impact of operating decisions before they are made. The key to success with any such computer-based simulation is a high level of sustainable record accuracy. To achieve high record accuracy, carefully document and visually depict the specification and ownership of information at each point of transfer. Clearly define and ensure the transfer of information and passage of ownership across the following: business functions business organizations applications
Technical Implications
The precise content of the information model will vary depending on the level of detail required and the exact circumstances of the business. Typical components include the following: a description of data entities and key attributes required by each organization and site by business function reporting requirements and data flows between organizations data flows between applications timeliness requirements for shared data (this has implications for data synchronization if distributed replication is being considered) In subsequent tasks, this information will be used to identify the specific transaction, reporting, and distributed interfaces within the Application and Technical Architecture process or the Module Design and Build Process. The results of this task provide the input for application and database architecture design by documenting data sharing, data flow,
Oracle Method
and initial data interface requirements. The data flows identified in the information model provide a basis for identifying required interfaces when different organizations and applications are on either end of the data flow. An Information Model also provides the basis for identifying and designing shared registries of information that can eliminate redundant data capture and storage, thereby reducing data maintenance and improving data integrity across the enterprise. An example of a shared data registry would be a common customer master or common item master that is shared across organizations (and potentially across application or database instances).
Role Contribution
The percentage of total task time required for each role follows: Role Technical Analyst Team Leader User
Table 2-13 Role Contribution for Develop Information Flow Model
% 95 5 *
Deliverable Guidelines
This deliverable helps you define your future information flow model. The objective is to specify how information will flow across your business in response to business process scenarios.
Deliverable Components
The Information Flow Model deliverable should contain the following components: Introduction Purpose Scope Information Flow Between Business Functions Flow Details Flow Diagrams Information Flow Between Business Organizations Flow Details Flow Diagrams Information Flow Between Applications Cross-Application Flow Details Cross-Application Flow Diagrams Cross-Installation Flow Details Cross-Installation Flow Diagrams
Tools
Deliverable Template
Select the Information Flow Model to complete the deliverable for this task. Select from the following components:
Oracle Method
Introduction Information Flow between Business Functions Information Flow between Business Organizations Information Flow between Applications
Deliverable
The deliverable for this task is a model for the information access requirements of the business. It is described in an Information Access Model document and analyzes the business organization access and security requirements. It is a major source document for these requirements for any of the processes in the project.
Prerequisites
Required
You need the following input for this task:
G G
The basis for the information flow model stems from the process and scenario flows provided by the Business Requirements Scenarios documents. The intention is to provide general information about the future business model that you will need to understand before developing the model for access of information and data in the new system. Financial and Operating Structure (RD.010)
The financial and operating structure will provide information about the business organization structure.
Oracle Method
Optional
You may need the following input for this task:
G
The information flow model will describe the flow of information supporting the business processes and the required movement of information across organizations. If you have documented the information flow model prior to starting the current task, this information will provide additional support for constructing the model for accessing information and data. If you are working on this task in parallel with the Develop Information Flow Model task, you may not have the completed deliverable to work from.
G G
The future business function model may augment the process model in summarizing the business functions that each business organization performs. If a particular business function requires specific information access, you will be able to use this deliverable to identify the business organization that also requires the same access. Audit and Control Requirements (RD.080)
The Audit and Control Requirements document may provide additional information about the general security policies, requirements and constraints. The usefulness of this deliverable will depend on precisely captured information for the audit and control requirements of the business.
Task Steps
The steps of this task follow: No. 1. Task Step Review future business process and function models for secure business functions. Review Information Flow Model. Deliverable Component
2.
No. 3.
Task Step Review Financial and Operating structure. Summarize the relevant business organizations. Identify general security policies and requirements. Analyze the business organization CRUD requirements for each business object type. Analyze the inter-organization CRUD requirements for each business object type. Identify ownership and access across organizations for the business objects.
Deliverable Component
4.
Business Organizations
5.
6.
7.
Table 2-14
Oracle Method
Oracle Method
Org 1
Org 2
Consumer Org 3
Org 4
RUD
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Technical Analyst User Business Line Manager
Table 2-17 Role Contribution for Develop Information Access Model
% 75 25 * *
Deliverable Guidelines
This deliverable helps you define your future information access model. The objective is to specify how to use the information within and across your organizations and what the partitioning and security requirements are.
Deliverable Components
The Information Access Model deliverable should contain the following components: Introduction Purpose Scope Business Organizations List of relevant organizations Security Policies and Requirements Security Policies Security Requirements Organizational Information Access Analysis High-level organizational data requirements and their impact on organizations Inter-Organizational Information Access Analysis Statement of high-level access requirements across organizations
Tools
Deliverable Template
Select the Information Access Model template to complete the deliverable for this task. Select from the following components: Introduction Business Organizations Security Policies and Requirements Organizational Information Access Analysis Inter-Organizational Information Access Analysis
Oracle Method
Deliverable
The deliverable for this task is an updated Master Report Tracking List.
Prerequisites
Required
You need the following input for this task:
G G G
The Tracking List, begun during the Business Requirements Definition process, is updated to reflect the results of mapping activities. Business Requirements Scenarios (RD.070)
Whether provided by the standard application or custom-developed, reports must always be traceable to business processes and business requirements. Since reports are usually either outputs of business processes or tools used in support of process operations, Business Requirements Scenarios (BRSs) provide the source for most report requirements. Reporting Strategy (TA.080)
Planned architecture for reporting systems will influence the type of reports that will be feasible and the magnitude of the customization effort.
Optional
You may need the following input for this task:
G
BRMs specify solutions to business requirements. Frequently, the solution documented will be a report.
Task Steps
The steps of this task follow: No. 1. Task Step Map requirements to future business processes using Business Requirements Scenarios and Mapping forms, and update Master Report Tracking List. Review Reporting Strategy to understand the capabilities of placing reporting systems and constraints on designs. Decide approach for mapping report requirements and assign responsibilities. Map report requirements to Standard Application reports. Analyze reports for reduction. Prioritize custom reports. Secure Acceptance of Deliverable.
Task Steps for Conduct Reporting Fit Analysis
2.
3.
4.
5. 6. 7.
Table 2-18
Oracle Method
team. If there is not adequate help from the team, their mapping will be inaccurate and their reports could be useless. Suggestion: Set up an interview process where the end-user and the project team member (user liaison role) do the mapping together. The user liaison must invest enough time before mapping to become familiar with all standard application reports that impact the area in question. The user liaison (mapper) can show the end-user what is available and answer any questions about future processes. At the same time the end-user can discuss reporting needs. Organization of the company may be such that major divisions within the organization have similar subfunctions. Purchasing might be an example. Each division or group may have a purchasing function. If the organization of the project is by division or group, the purchasing role might have a possible duplication multiple times across the project. The mapping of all purchasing reports by one user liaison will save the time and energy of the rest of the team.
Oracle Method
Reduction Techniques Eliminate reports with duplicate file names. This is the easiest way to reduce requirements. If several people request the same report, or the same report is identified in more than one process, update the Master Report Tracking List for the first report to Build, Match (whatever is appropriate) and update the rest as Duplicate. Do not delete these requirements from the list because they represent a valid user requirement that is necessary when preparing status documents for the user, users department or management. Analyze based on function. Resort the Master Report Tracking List by function. If several reports relate to the same function, you may be able to combine the requirements from one report into another. This type of consolidation may dramatically reduce the number of requirements. If you combine five reports into one new report, mark one as a Build and the rest as Combined. Make sure you put the tracking number of the report marked as Build in the Combined Into Tracking Number field on the template form. The users and the team need to know which reports are being consolidated and the name of the new report. Warning: Track consolidations carefully, especially if they cross departmental boundaries. While initially all parties may agree the consolidation looks good, changes requested by one group may not be appropriate for others. When this happens, you may need to create another new report and track it separately.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Technical Analyst Application Expert Configuration Manager Facilitator Team Leader Application Architect User
Table 2-19 Role Contribution for Conduct Reporting Fit Analysis
% 35 20 20 10 5 5 5 *
Deliverable Guidelines
Master Report Tracking List
Tasks in several implementation processes use the Master Report Tracking List. Use the following information during mapping activities: Tracking Number Unique identifier assigned to each report requirement. Use this field as the key field when the Master Tracking List is stored in a database and divided into separate files. Suggestion: Build some logic into the tracking number. During the course of the project, many reports are commonly recognized by their tracking number and not their name (e.g., Finance_XXX, Tax_XXX, Division_XXX).
Assessment The assessment is the result of the Mapping resolution. This field tracks the report status and is the basis for compiling management reports. Suggested status categories are: None The report has not been analyzed and its status is unknown. Build The report is required for future processes and must be built. Combine The report requirement can be satisfied by combining it with similar requirements from another report. A report classified as a combine is always matched to a report classified as a build or match. In other words, the requirement for reports ABC, DEF, and 123 have been combined into report XYZ. XYZ is the new requirement that replaces ABC, DEF, and 123. This is representative of how one new report can replace several old reports. Duplicate The requirement exactly matches another users requirement. In other words, there are five entries for the requirement filename costanalysis.rpt. One is categorized as Build, Combine, Duplicate, Match or Not needed, the other four are categorized as DUPLICATE. Match The report requirement is being replaced by a standard application report. The requirement directly maps to standard functionality. Record the name of the standard report in Future Report name. Modify Requirement maps to standard functionality, but you will need to modify the standard report. If the standard report needs significant modification, classify the requirement as a Build. Use Modification for those situations where there is a need for minor changes to standard functionality. Not Needed The requirement does not map to a future business process or, upon further analysis, is categorized as no longer used. Assessment Comments Record additional comments about the assessment (e.g., Requirement appears to match Cost Rollup standard report, but needs to be tested). Combined into Tracking Number Enter the tracking number for the report replacing this requirement.
Oracle Method
Future Process Number the Business Requirements Scenario (BRS) into which this requirement maps. A report must map to a BRS in order to classify it as a Build or Modify. If the report does not map to a BRS, enter No Match in this field. Do not develop reports with No Match because they are not part of the new business processes. Function Group reporting into logical business units, such as shipping, accounts receivable, journal entry, scheduling, checks, backlog, bookings, billing, and so on. This will also help determine which reports can combine together. (Example: There are 90 shipment reports listed on the Master Report Tracking list. Further analysis determines that 60 reports contain the same data and can be reduced to five new report requirements.) Functional grouping can also help determine whether any reports are missing. If after assigning a function to all reports no cash receipt report has been identified, it may be that the BRS is inaccurate, or the survey may have missed a group of users, a report or a business function.
Tools
Deliverable Template
Use the Reporting Fit Analysis deliverable template to update the Mapping section of the Master Report Tracking List developed in Develop Reporting Requirements (RD.100). Record the appropriate mapping information based on the report mapping activities performed.
Deliverable
The deliverable for this task is the Mapping Scenario document.
Prerequisites
Required
You need the following input for this task:
G G
Each scenario is a unique response path through the process flow diagram for a business process. Listing all responses that are possible from within a process will produce an associated list of scenarios. Configured Mapping Environment (BR.010)
Each test team will need a modeling environment in which to test individual and integrated solutions.
Optional
You may need the following input for this task:
G
For scenarios with workarounds or proposed custom extensions, BRMs are necessary in order to properly specify the nature and characteristics of the business test.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Collect future process model, Business Requirements Scenarios, and mapping documents. Develop mapping scenarios based on updated process flows and designs. Identify inputs and outputs, data conditions, and business rules. Develop business solution testing specifications. Develop support requirements. Assign testing roles and responsibilities. Review responsibilities and events with project team. Execute tests. Summarize test results. Document required corrective actions. Update Business Requirements Scenario based on testing results. Tested Solutions Test Specification Test Actions Mapping Scenario Identification Deliverable Component
2.
3.
Data Profile
4.
Test Specification
5.
Support Profile
6.
7.
8. 9. 10.
11.
No. 12.
Task Step Update Business Requirements Mapping Forms based on Testing Results. Secure Acceptance of Deliverable.
13.
Table 2-20
Oracle Method
Attention: Business solution testing is not the same thing as module or system testing. Instead, you are verifying that a process design will satisfy business objectives using stated tools, resources, and application system components.
Scenario
Step 2
Role A
Step 1
Step 3
Step 9
Role B
Step 4
Step 8
Role C
Step 5
Step 6
Step 7
Figure 2-4
Mapping Scenario
Each scenario is a unique path plus a set of initial state conditions to be tested in order to assure satisfaction of business requirements. Inputs to a scenario include:
Data Profiles describe the initial business conditions necessary to test the application system. To design a process that will exhibit consistent results, properly anticipate controllable variables. Test Specifications define the test script execution for a scenario. Support Profiles identify the support tools required during execution of the test. Qualified Agent as the owners of process steps, they fulfill a role whose qualifications must be clearly stated before testing (and later process certification) begins.
Oracle Method
expected outputs and criteria for successful closure of the testing session
Test Specifications
A test specification is the component of a test script that defines test script execution. The basis is entirely on a specific system process and consists of scenario information, process information, and a series of test steps, the order having been determined from the process. A test specification communicates the following: test steps, corresponding to some, if not all, system process steps, detailing the business testing requirement of a scenario the sequential relationship between test steps the data profiles involved in each test step the actions performed in each test step the expected application system responses in each test step Figure 2-5 represents the relationship between a process, process steps, scenarios, and test steps.
Process
Figure 2-5
Attention: When varying initial conditions cause multiple outcomes, decide whether to remodel the process and possibly separate it into more than one process, or plan multiple scenarios from the same business process. It could be that a decision step was inadvertently omitted. It is also possible that different sets of unique initial conditions really correspond to multiple events or event mechanisms. Test Specifications also provide for recording the results of tests both qualitative (like description of outputs) and quantitative (like measured cycle time of the actual test).
Oracle Method
Process
Figure 2-6
Support Profiles
The consideration of expected environmental information (such as controls and constraints) and resource capabilities (known also as mechanisms) is required for any business process step, if adequately defining and testing for feasibility. Specifying these support requirements into a profile for each scenario accomplishes the same result as when listing assumptions in a business proposal paper. This technique alerts management regarding necessary prerequisites in order for the process step to perform satisfactorily. This is true even when a process step is system assisted, or when it is an automated step. If support profiles are planned properly, they will provide a linkage with downstream process narratives and user procedures. Good documentation during business solutions testing will save time later and will increase the quality of deliverables.
functionality gaps because it is likely that no final solution has been designed or built to bridge those gaps. A conference room pilot (CRP) is a technique for evaluating a proposed solution that simulates actual business processes in a controlled environment. It is often performed in an actual conference room so that all participants may be close together, and delays will be minimized. A CRP can reveal missed problems and issues of processes tested in isolation. A conference room pilot is usually run by business area or some other, wider grouping of business processes. This means that multiple mapping teams must be ready at the same time in order to begin. As with most testing strategies, a CRP consists of iterations, converging on a practical and feasible solution. Once all testing is complete and confirmed, you can document final setups and solutions.
Parallel Testing
A faster but riskier approach is to pursue a strategy of ongoing testing in parallel with other mapping activities. Essentially, project team members test whenever they are not participating in mapping activities. As each process area is mapped, those processes are added to an overall integrated test flow. The project team then repeats some or all of the tests to confirm that new processes integrate with the overall business flow. As testing proceeds, the team begins documenting setups and procedures (for later use in the Define Application Setups and Create Process Narratives tasks) and performs these in parallel with testing. After all processes are mapped, tested, and confirmed, documentation can be considered complete, and the design of custom extensions (if any) can be started.
Oracle Method
Requirements Mapping processes into a tight, holistic set of tasks that produce a final, feasible design for a business process.
Cross-Process Integration
Completion of solution testing faces two significant challenges: The tested BRS may not integrate properly with other BRSs. Custom solutions may not yet be available. There may be many interdependencies across BRSs. The key is to identify key internal customers who must help document and plan for testing these linkages. One way to do this is to try to match process outputs with the list of events. Outputs that have no match may mean that a process overlaps another process, or it could mean that some business process steps are not contained within any process. As far as possible, try to simulate the effect of tools that are not yet developed. List key assumptions like response time. These will be key inputs into later construction of Solution Document and Design Document deliverables. Remember, you are not testing programs in this task; instead, you are testing business solution ideas. It is permissible to establish tests with unique scenario numbers that actually link scenarios across two or more business processes. This is especially useful with multiple events that drive a process source from different business processes.
Additionally, during mapping not all teams are necessarily synchronized for integrated testing since some will progress ahead of others. So the BST integration testing is more thorough.
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Application Expert Technical Analyst Team Leader Business Line Manager
Table 2-21 Role Contribution for Test Business Solutions
% 60 30 5 5 *
Oracle Method
Deliverable Guidelines
Create the BRS mapping scenario deliverable components during this task. This is a logical extension of the work performed during process design and mapping. If there are multiple scenarios for a business process, each one will have a unique scenario number. Maintain all scenarios in the same BRS deliverable to present a comprehensive history. Or, you may want to have a unique BRS deliverable for each scenario.
Deliverable Components
Each Mapping scenario contains the following components: Scenarios Identification describes the business processes involved in the test Data Profile describes the business conditions that are needed to test the application system Test Specification defines test script execution Support Profile identifies support tools required during execution of the test In addition, test results and actions will be captured.
Acceptance Criteria
The BRS mapping scenario should contain heading information, such as: scenario number scenario description Organize detailed information by scenario step such that all mapping scenario deliverable components carry information supportive of their respective step. A scenario step will be in a one-to-one correspondence with a business process step. In order to pass a quality review: The mapping scenario must describe all tools and user actions necessary in order to perform the test.
Accomplish and close all documented test actions. Attention: As an alternative to using the detailed test actions form, you can simply document and track problems and their resolutions in an issues list.
Tools
Deliverable Template
Use the Mapping Scenario template and choose the MAP SCEN shortcut button to help you construct your deliverable. Select from the following components: BRS Deliverable Components A Mapping Scenario is a subset of a Business Requirements Scenario. Figure 2-7 below provides an example of the deliverable template component selection options.
Oracle Method
Figure 2-7
Use the Insert Boilerplate menu option while in the appropriate BRS document to create the necessary deliverable components. Select one or more of these components as required: Mapping Scenario Identification Data Profile Test Specification Support Profile Warning: When you use the boilerplate feature to insert a new mapping scenario for the BRS, make sure that the existing Scenario Numbers in the deliverable are no longer coded as substitution variables (highlighted variable style). Otherwise, these existing fields will be renamed to the new scenario number. Mapping Scenario Identification Supply the following information for each scenario: Scenario # unique control number for the scenario
Description brief descriptive narrative of the scenario; this is the name of the scenario and should imply the associated business conditions Business Area a code designating the design/mapping team responsible for the process being tested Initial Process the process in which the test begins Intermediate Processes a list of processes that are tested at the same time, or linked with the Initial Process Final Process the process that completes the test Test Number a control number that uniquely identifies each test to run Test Coordinator person responsible for running the test QA Owner person responsible for ensuring that the proper tools, environment and procedures are used QA Profile procedure for verifying quality Data Profile You can have several Data Profiles per process task. Scenario Step unique sequence number for each task as listed on the BRS for this scenario Business object the name of a particular data element that must be present (e.g., Customer or Master Demand Schedule) Data Condition actual values, reference to some other document containing values, or even a screen shot Business Rule the policy or decision drivers that influence the process step Type the entity type Status the entity state Test Specification You can have several Test Specification line items per process task. Scenario Step unique sequence number for each task as listed on the BRS for this scenario
Oracle Method
Test Step the series of procedural steps that must be taken for the scenario step in order to perform the test properly Role step/sequence owner Action or Path description of action to be taken by the primary resource or role during the test; either navigation, location or directive information Expected Results anticipated outcomes or outputs described in measurable terms Actual Results actual outcomes or outputs described in measurable terms Expected Cycle Time anticipated elapsed time for processing the step/sequence Actual Cycle Time actual elapsed time consumed during processing the step/sequence Status Active, Pending Active, Pending Obsolete, or Obsolete Support Profile You can have several Support Profile line items per process task. Scenario Step unique sequence number for each task as listed on the BRS for this scenario Test Step the series of procedural steps that must be taken for the scenario step in order to perform the test properly Controls environmental information that affects what is possible: constraints or limits Mechanisms resources that enable or facilitate the step/sequence Other Input other tools necessary for running this step/sequence of the test Status Active, Pending Active, Pending Obsolete, or Obsolete
Deliverable
The deliverable for this task is a signed Acceptance Certificate for each set of related Business Requirements Scenarios.
Prerequisites
Required
You need the following input for this task:
G G G G
It is helpful to show the process flow diagram for each future business process as it is being approved. Business Requirements Scenarios (RD.070)
Each BRS represents a feasible, tested solution to satisfying requirements for a business process. Mapping Scenario (BR.080)
The Solutions Testing Results contain test results and actions as part of the solution that must be considered when signing off on proposed process designs. Integration Fit Analysis (BR.040)
This deliverable lists all the integration points in the new system across applications and application installations, created from a bottom-up analysis. You should verify that these integration points are covered by business requirements scenarios.
Oracle Method
G G G G
Acceptable business solutions must be comprehensive in terms of stating fit and gaps for report requirements. Update the Master Report Tracking List to reflect report mapping decisions during reporting fit analysis activities. Information Flow Model (BR.050)
The specifications for the movement of information and data in the business across business functions, applications, organizations and data centers. Information Access Model (BR.060)
The specifications for the access of information and data in the business by business functions, organizations and other secure user groups. This is a high-level analysis of the security and reporting requirements in the future business model. Business Data Mapping Form (BR.030)
Show underlying table structures and attributes to adequately support business processes.
Optional
You may need the following input for this task:
G
Task Steps
The steps of this task follow: No. 1. Task Step Review prototype, test results, and mapping documents. Deliverable Component
No. 2.
Task Step Revise business solution for agreed upon changes. Prepare Acceptance Certificate for integrated solutions. Secure Acceptance of Deliverable.
Deliverable Component
3.
Acceptance Certificate
4.
Table 2-22
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Application Expert Business Analyst Team Leader Technical Analyst Business Line Manager Client Project Manager
Table 2-23
% 25 25 25 25 * *
Deliverable Guidelines
This deliverable represents an acknowledgment that all relevant parties have reviewed the materials produced and agree on the proposed business solutions. This approval task is especially important when new processes are being proposed. Dramatic changes to existing processes are likely to affect job definitions and sometimes organizational structure. The parties that approve the proposed business solutions should include: executive management financial management operating (functional) management human resources end-users (responsible for processes)
The parties usually note any desired changes and agree on a course of action to implement those changes. This deliverable authorizes the project to move forward to the next activity in the Solution Design phase. The deliverable serves as a formal record of the parties agreement. The deliverable should contain information such as: name of deliverable being confirmed type and status of deliverable objectives of deliverable agreements (expressed in terms of planned future actions or policy changes) key decisions key assumptions exceptions or references to components requiring changes controls: signatures of approvers and initiators, dates, revisions, and so on future direction This approval should reference the relevant list of BRS and BRM deliverables for the proposed business solutions being reviewed. You can use this document to clarify any issues encountered later. Confirmation is most effective when documented by a signed letter, memo, or certificate. As with all critical deliverables, verbal agreement is not as effective.
Tools
Deliverable Template
Use the Acceptance Certificate template to prepare the certificate.
Oracle Method
Deliverable
The deliverable for this task is a series of Process Narratives.
Prerequisites
Required
You need the following input for this task:
G G
Business processes are identified and defined by BRSs. Detailed joblevel descriptions of business process designs are a further refinement of the BRSs. The test environment and tools used also provide a direct input into narrative documentation. Acceptance Certificate (BR.090)
Obtain confirmation and approval of a business solution before writing detailed process narratives.
Optional
You may need the following input for this task:
G
For scenarios with workarounds or proposed custom extensions, BRMs are necessary to specify the job-level details for the business process.
Task Steps
The steps of this task follow: No. 1. Task Step Collect future process model, business requirements scenario, and mapping documents. Describe and identify the business process. List the required inputs into the process. List the controls, including rules, policies or other constraints, that limit or affect how the business process can or will function. List the mechanisms and support tools required by resources (people or equipment) during execution of the business process. Document the procedural steps for each process task/step. Repeat the task steps for each process narrative. Secure Acceptance of Deliverable.
Task Steps for Create Process Narratives
Deliverable Component
2.
Identification
3.
Inputs
4.
Controls
5.
Mechanisms
6.
Procedure
7.
8.
Table 2-24
Oracle Method
usually a set of procedural steps that describe how to accomplish that step. Each activity is: usually a set of tasks or 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.
Oracle Method
A Process Narrative reads like a set of directions for performing a job, and therefore begins to build understanding at the end-user level for confirming that the process design proposed is the correct and best one. A Process Narrative speaks to a user in work language and not in codes. How does the Process Narrative differ from a User Guide? A User Guide has field-level references (and refers to sample forms, reports, and so on). A Process Narrative has zone-level reference (like to Header/ Line-Item) and does not refer to field level. A User Guide generally includes a section on how to correct errors.
If you think about a business process as a production process, you realize the importance of being very detailed in developing specifications. A Process Narrative is such a specification. The IPO (Input-Process-Output) technique is a generic modeling tool that was designed for framing complete process specifications by identifying inputs, rules, process step descriptions, tools and outputs. To a large extent, the BRS provides much of the material necessary for employing such a technique in developing narratives: process step descriptions in the Identification, Requirements and Sources, and Solutions components process inputs in the Data Profile component rules in the Data Profile component tools in the Support Profile and Test Specification components process outputs in the Process Analysis component Many techniques can be used to develop sound Process Narratives. Possibly the most important technique is the use of a physical walkthrough to verify each narrative. This is not prototyping, where you are proving that a design satisfies business requirements, or solution testing, where you ensure that components will work together to create the output. Instead, this walkthrough technique focuses more on the ability of the resources involved to perform the work consistently and to have access to the appropriate tools/support systems (like reports, scanners, and so on) and knowledge of driving policies. A policy is defined as a principle, plan or course of action. Policies are the rules and shoulds that strengthen a business process and make it workable and acceptable. Warning: If a BRS must be revised as a result of creating a Process Narrative (for instance, a task turns out to be less feasible than planned), then that BRS must be tested again possibly resulting in project delay.
Oracle Method
Define the requirements for the system technical architecture. Define the requirements for the user interface. System Process Models enable users to visualize how the process will be executed with the new system. This goal can be accomplished in several ways and with varying levels of sophistication. Typically, System Process Models are process flow diagrams that are derived from the business process model and annotated with details about how the processes will be automated. Process steps are identified as manual or automated and as batch or online. The type of user interface, frequency of execution, sites where the process is executed, inputs, interfaces to other systems, and current systems support, if any, are also identified.
Although Business Solutions are generally approved before Process Narrative writing begins, solutions drive the narratives and the narratives may modify the way solutions are presented or described. Additionally, the Test Business Solutions task provides Data Profiles that describe business conditions required for the application system to function properly in support of the business. User certification and readiness testing will draw heavily from content found in Process Narratives. Such testing is important for quality. Each business process must meet the following performance criteria: perform consistently under the same trained resource, using the same tools and achieving the same measurable results produce consistent response in terms of acceptable process elapsed (or cycle) time meet cost target meet customer expectations (usually as required by the next process)
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Team Leader Business Line Manager
Table 2-25 Role Contribution for Create Process Narratives
% 95 5 *
Deliverable Guidelines
Create the deliverable components necessary for each Process Narrative during this task. This is a logical extension of the work that was performed during process design and mapping and solution testing.
Deliverable Components
Each Process Narrative consists of the following components: Identification describes the business process being documented Inputs lists primary inputs into the business process
Controls describes rules, policies, and other constraints Mechanisms identifies support tools required during execution of the business process Procedure describes the detailed procedural steps for each process step or task
Acceptance Criteria
The Process Narrative should contain heading information such as: process number process description In order to pass a quality review, the following conditions must be met: Each BRS must be covered by one Process Narrative, but one Process Narrative may cover multiple, related BRSs. When multiple BRSs are covered by one Process Narrative, they must have the same general flow with the same basic responsibilities and differ only in minor logic. A Process Narrative should mention how all Logs/Forms/Tools are to be used within each process step. A Process Narrative describes the sequence of job activities for a process from request/trigger to fulfillment/completion. Job activities will be defined to include all details pertinent to user training, except reference to individual fields on manual/ computerized forms. The Procedure section should read like an instruction or recipe, each sentence beginning with action verbs (use the imperative mood as you would in giving directions); conditional words like if, otherwise, etc.; and time-related words like after, when, before and so on. A user responsibility should appear first in each numbered paragraph of the Process Narrative (either in bold or with a trailing colon). Avoid acronyms in the Process Narrative; use simple, clear language.
Oracle Method
Tools
Deliverable Template
Use the Process Narrative template to create the entire deliverable for each required Process Narrative. Use the appropriate Process Narrative components from the following options: Identification Inputs Controls Mechanisms Procedure Identification Process a brief description of the process Business Area a code designating the mapping team responsible for this process Date date the form is being initiated Control Number a unique identifier for each business process (e.g., 6-character code in format AAA.999, where AAA represents the subprocess, and 999 is a unique 3-digit code assigned sequentially from a log maintained by each team) Design Team ongoing process design team responsible for this business process Process Owner the agent with overall responsibility for the process; could be the customer of the process, or the supplier (one who fulfills the request) Project Administrator person charged with maintaining this BRS deliverable and interfacing with other teams in order to ensure control and proper alignment with integration goals Priority determined at each teams discretion Core an identification of major, driver processes that affect or influence business objectives
Description brief descriptive narrative of the scenario; represents the name of the scenario and should imply the associated business conditions Scope including role/job responsible for initiation, closure and performance measurement Ref Doc reference to the associated BRS Frequency of execution periodicity for launching the process Inputs Description or specification reference, or how to recognize valid inputs that are either signals to begin a process step, used or acted upon during that step Controls Rules, controls, constraints, reference policies limit or control the process (Note: these may also be listed/referenced at the step level); typically beyond the control of the responsible agent to change or influence Mechanisms Skill Levels required to perform process steps (optionally may be referenced on another deliverable) Related Documents BRSs, BRMs, other Process Narratives, and so on Tools Required reports, logs, labels, and so on (not just system-assisted tools), and, optionally, versions for configuration management Procedure Narrative Section with process steps (1) how to measure completion of each step, (2) how to gather business metric data for each step, (3) interaction with systems components and other tools, and (4) text that reads like a recipe or a manufacturing routing
Other Tools
Also consider using one-step procedure development tools that permit the creation of process narratives and user procedures in one step early during process design. Some tools even permit automatic generation of process flow diagrams using text narrative as input.
Oracle Method
Deliverable
The deliverable for this task is an Application Setup Document.
Prerequisites
Required
You need the following input for this task:
G G
BRMs are detailed explanations of key requirements and/or their solutions. This deliverable contains intermediate decisions regarding application setups. Acceptance Certificate (BR.090)
Confirmation and approval of a business solution must be obtained before implementing application setups.
Optional
You may need the following input for this task:
G
If the application architect created a detailed map of the fundamental application setup parameters that affect application architecture, you
Task Steps
The steps of this task follow: No. 1. Task Step Review the application configuration in the mapping environment. Review business mapping decisions and documents. Define the application setups intended for production. Implement the application setups in the appropriate environments, if necessary. Review and confirm configuration and impact of changes. Secure Acceptance of Deliverable.
Task Steps for Define Application Setups
Deliverable Component
2.
3.
4.
5.
6.
Table 2-26
Oracle Method
number of separate application databases on the company systems, it becomes a challenge to ensure that the configurations represent the latest mapping decisions. Warning: Only key project team members, each with specific responsibilities, should initially define the system application setups. It is important to stabilize the environment and control the changes made during the mapping process so that any one team does not undo the settings made by another team. It is particularly challenging to maintain setups by application module when design, mapping, and testing activities have been organized by business process. If an integration team is responsible for cross-process integrity, let them assist with maintaining application setups as well.
Standard Reports
Some standard applications provide standard setup reports that capture the input data automatically. Simply run these reports and use these as source documents for later setup activities.
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.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst System Administrator Team Leader - Mapping
Table 2-27 Role Contribution for Define Application Setups
% 80 10 10
Deliverable Guidelines
The Application Setup deliverable is a composite of profile options, application options, key and descriptive flexfields, and user-defined codes. It consolidates the setup parameters and codes of all applications for centralized maintenance as decided during business mapping. This deliverable enables you to collect information about system parameters, user-defined codes, and application options. Use it to capture and communicate the final application setup decisions for implementation in the production environment. Typical information to capture in the Application Setup deliverable includes: screen name single- or multiple-entity relationships mandatory or optional setups duplicate setups across applications key flexfields descriptive flexfields navigation to the screen justification for selected options maintenance consolidation, if any date of last update
impact of any setup changes in the course of the implementation Because application setups will undergo many revisions during the Solution Design phase, ensure that procedures are in place to update and carefully control the setups. You may want to control application setups with a configuration management tool.
Deliverable Components
The Define Application Setups deliverable components each contain master tables to control ownership, QA responsibility, due dates, and approval sign off for each component setup, in addition to 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
Oracle Method
Value Set Worksheets for the following Validation Types: Independent Dependent None Table Special or Pair Use one set to manage the setup of each key flexfield. Descriptive Flexfield The Descriptive flexfield setup tables contain the following worksheets: Overall Descriptive Flexfield Key Flexfield Structure Value Set Worksheets for the following Validation Types: Independent Dependent None Table Special or Pair Use one set to manage the setup of each descriptive flexfield.
Tools
Deliverable Templates
Use the Application Setup template to capture the definitions and parameters for the production system. Choose from the following components to assemble your document: Common Setups Application Setup Tables Key Flexfield
Descriptive Flexfield Multiple Applications When you select the Application Setup Tables checkbox on the Application Setup template, the dialog box in Figure 2-8 is displayed:
Figure 2-8
Select any combination of applications you want to include in your document. The applications are grouped by Oracle Applications Product Family. Click on a product family button to select all the applications in that family. Click again to deselect options. Applications that do not have defined setup templates appear lighter and cannot be selected. The order of the setup screens within each application matches the order documented in the current Oracle Applications implementation manuals. The content is release specific and will be updated at the same time as Oracle products become available.
Oracle Method
Some of the setups are duplicated across products because Oracle Applications give you the flexibility to implement a single family of applications or all applications. For example, Define Employees is included in every application that requires employees to be defined. Therefore, when you select two applications, you get duplicate copies of the common setup. Manipulating and Extending Tables Add additional columns and rows as needed in all tables. Some tables appear in a horizontal format with the heading across the top (those with relatively few data elements) and others are presented vertically. For the vertical tables, you add additional columns for new records up to the page width limitations. If you need to add more columns, duplicate the entire table and label them 1 of 2, 2 of 2, and so on. Add additional headings for required descriptive flexfields in a zone and label them accordingly. Flexfields Select Key Flexfield or Descriptive Flexfield from the main dialog to insert flexfield setup forms wherever you need them.
Deliverable
The deliverable for this task is a Security Profiles document.
Prerequisites
Required
You need the following input for this task:
G G G
Business Requirements Scenarios (BRSs) help establish the range of responsibilities necessary to support secure usage of the application. Information Access Model (BR.060)
This provides the organizational view of the requirements for access of information and data in the business. The organizational view of information access is the sum total of all of the individual role-based access requirements within an organization and therefore is a foundation for the individual security profiles for the roles within the organization. Financial and Operating Structure (RD.010)
This provides a list of all of the organizations within the business. You will need to identify the roles of different users within the organizations and then map these to the security features within the applications.
Oracle Method
G G
There may be requirements based on audit and control analysis that will impact Security Profiles. Application Security Architecture (TA.120)
This provides information about the design and usage of the applications and databases to support the organization-based security requirements. The implementation of the application security architecture may impact the way that role-based security is implemented in the new system.
Optional
You may need the following input for this task:
G
BRMs are detailed explanations of key requirements and/or their solutions. This is the deliverable that contains intermediate decisions regarding application setups, including security and responsibility information. You may need to refer to this deliverable if the security requirements are sufficiently minor that they do not impact the major security architecture design performed in the Application and Technical Architecture process.
Task Steps
The steps of this task follow: No. 1. Task Step Identify user roles across all business functions and organizations. Identify security requirements for each user role. Map user roles onto application security structures. Deliverable Component User Roles
2.
User Roles
3.
No. 4.
Task Step Define application module access for each system user role. Secure Acceptance of Deliverable.
5.
Table 2-28
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst System Administrator % 80 10
Oracle Method
% 10
Deliverable Guidelines
Identify roles (agents from the BRS deliverable) grouped together by responsibility so that typical business functions, along with inquiries and reports, are accessible. Try to accomplish security objectives with the minimum number of profiles to make maintenance easier.
Tools
Deliverable Templates
Use the Security Profiles deliverable template to capture the Security Profile information.
CHAPTER
Figure 3-1
Oracle Method
Process Flow
Application and Technical Architecture (TA)
TA.010: Architecture Scope, Objectives, and Approach Team Leader Architecture TA.010: Define TA.010 Architecture Scope, Objectives, and Approach TA.020 TA.020: Prepare Architecture Strategy
RD.010: Financial and Operating Structure RD.060: Business Volume TA.030: Architecture Requirements
Application Architect
TA.090: Revise Conceptual Architecture TA.090: Conceptual Architecture TA.100: Define Architecture Subsystems TA.110: Propose Architecture Subprojects
Figure 3-2
TA.050: Conduct Technical Architecture Baseline RD.010: Financial and Operating Structure TA.070: Define Future Application Deployment TA.070: Future Application Deployment
Application Architect
TA.120: Design Application Security Architecture BR.060: Information Access Model TA.140: Design Logical Application and Database Architecture MD.030: Design Standards D TA.140: Logical Application and Database Architecture TA.120: Application Security Architecture
Figure 3-2
Oracle Method
TA.060: Develop System Availability Strategy Technical Architect RD.090: Business Availability Requirements TA.050: Conduct Technical Architecture Baseline TA.020: Architecture Strategy TA.050: Technical Architecture Baseline TA.060: System Availability Strategy
System Administrator
Figure 3-2
Technical Architect
TA.180: Assess Performance Risks TA.040: Develop Conceptual Architecture TA.160: Hardware and Network Architecture TA.180: Performance Risk Assessment
System Administrator
Figure 3-2
Oracle Method
Approach
The Application and Technical Architecture process is the means by which you design an information systems architecture to realize your business vision. The process takes the business and information systems requirements and develops out of these a blueprint for deploying and configuring: Oracle, third-party, and custom applications supporting application databases critical interfaces and data distribution mechanisms between applications, servers, and sites computing hardware, including servers and client desktop machines networks and communications infrastructure A coherent and well-designed information systems architecture is a critical success factor for any implementation project. To arrive at an architecture for your newly implemented systems, consider the following complex issues: the best deployment strategy for your applications across one or more data centers, business organizations, and business functions the high-level configuration of the applications to support your financial, administration, manufacturing, and distribution business units the interface points between the applications and/or remote sites, including specifications, data flows, and mechanisms the deployment and capacity planning of the hardware and network infrastructure that will support the applications processing the management tools and procedures that will enable the system to continue to operate as intended If your implementation project involves a complete replacement of legacy business systems, the architecture work needs to be comprehensive enough to define the framework for the information systems vision of the corporation, which will underpin the corporate
business vision. An example of this is where you are performing a complete replacement of your Enterprise Resource Planning (ERP) systems. Where the implementation is for a replacement of a portion of the business systems, the architecture of that replacement part of the system must be compatible with the overall system architecture. The Application and Technical Architecture process can be divided into two major areas: Application Architecture Addresses the deployment and configuration of applications across data centers, databases and machines. Addresses the configuration and capacity planning of the hardware and network infrastructure and system management issues.
Technical Architecture
Application Architecture
The Application Architecture portion of the process includes these key areas: Data Distribution Strategy (Centralized versus Distributed Data) Application Deployment Map and Integration Points Information Security Reporting Strategy Application Functional Architecture (Critical Application Setup) Data Distribution Strategy (Centralized versus Distributed Data) One of the key decisions in a new information systems architecture design is how to distribute your business data around the enterprise. Many different factors can affect this decision, and it can be a complex undertaking.
Oracle Method
Attention: Installation of Oracle Applications results in a single centralized database. A completely centralized Oracle Applications architecture is not always a good match for large distributed organizations with a decentralized corporate vision; therefore, some cases require a distributed architecture. Distributed processing and data may drastically increase the complexity of an implementation, and special care is needed to achieve success. Application Deployment Map and Integration Points This seemingly straightforward task is very important for piecing together the applications deployment across different data centers and servers, together with the supporting databases. The information flows between the deployed applications reveal the application integration points and interfaces that may be needed. Information Security Most information security issues are not critical to the success of an implementation, but some may be. The modification of tables to add new columns for the provision of custom, database-level security increases implementation complexity substantially. Reporting Strategy Reporting Strategy covers the different types of reporting in a business, such as operational reporting strategy (data collected or transacted over the last day, week or year), decision support strategy (usually covers data collected over a longer period of time), ad hoc reporting, and analytical reporting. The strategy needs to take into account physical data distribution in the business and the databases and applications within which the data are stored. Attention: Oracle Applications have robust operational, analytical, and decision support reporting capability, but, for example, this would not cover reporting across heterogeneous systems. You may need to define operational or decision support type data warehouses to provide consolidation or special reporting capability across different enterprise systems and applications.
Application Functional Architecture (Critical Application Setup) This area primarily covers the configuration of package applications (rather than in-house developed applications) where you have less control over the functional setup and must map your business to the fundamental features and functions built into the package. The choices you make about the critical application setup parameters can have a direct effect on your application and technical architecture, influencing the application deployment and data partitioning. Attention: In Oracle Applications you have choices for the number of sets of books, inventory organizations, and installations of each application. Multi-organization functionality, available starting Release 10.6 adds two further critical functional concepts: the legal entity and the operating unit. This area also covers issues in the use of key applications features that would affect application deployment. Examples of this are the need for Available To Promise (ATP) or Assemble To Order (ATO) in Oracle Distribution/Manufacturing. These decisions are very dependent on the specific features of the application release version.
Technical Architecture
The Technical Architecture portion of the process includes these key areas: Client-Server (Distribution of Processing number of physical tiers, N-tier configurations). Physical Database Design and Use of Database Features Hardware and Networks System Availability Strategy System Management Procedures Detailed Design of Distributed Data Interfaces
Oracle Method
Attention: The term distributed applications is sometimes applied to technical architectures that are client-server in nature. What is really meant is that the processing is distributed, but the data may not be. The reason for the confusion is that the second qualifier, processing or data, is often omitted in common parlance, and the ambiguity is compounded by the liberal use of such unqualified terms in industry literature as well. To avoid confusion in this document and the review questions, the term distributed is reserved for architectures that involve multiple separate databases containing data that need to interact in some way; the more pragmatic term client-server will be used to denote distributed processing (two or more physical tiers) without implying a distribution of data also. Client-Server (Distributed) Processing This area covers the various N-tier configurations for the separation of presentation, business logic, and data management processing within your applications. You will have direct control over this for in-house developed applications, but package applications can also require that you make choices for how you partition your processing. You can configure Oracle Applications to run with one, two, or three physical tiers of machines between the user and the application database. The more tiers you use, the more complex your implementation may become. The technical architecture you adopt is dependent on the technology that the applications release version uses. The architectural options across different Oracle Applications releases include: Central host (or one tier). The Oracle database and all applications processing reside on one machine. All users log into the same machine to access the applications. (The dumb terminal front end is not counted as a tier here).
Two tiers with application server machines. The database resides on a database server and the applications logic processing runs on one or more application server machines, the tiers being connected through SQL*Net. A dumb terminal front end is used again here. The applications concurrent manager optionally may also run on one of the applications server machines. This architecture requires a multi-processing application server platform, such as a Unix-based machine. This architecture was an option for pre-10SC character mode Oracle Applications, but its use may be more limited for 10SC, which has a PC platform for the client processing. Two tiers with Oracle Applications Display Manager (OADM, thin client-server). The database and all code reside on one machine except OADM, which runs on desktop PCs and acts as the presentation client. The OADM architecture is an older clientserver configuration that was designed to provide some GUI features to character mode Release 9 and 10 applications. It will be completely subsumed by 10SC. Three tiers with OADM (client-application server-database server). The database resides on a database server, the applications run on one or more application server machines, and OADM runs on desktop client PCs which act as the presentation client. Two tiers with 10SC clients. The database resides on a database server and 10SC clients (desktop PCs) connect to it using SQL*Net. Two tiers with Web Browser (thin client-server). The database and application business logic run on a single server machine and the Web browser runs on a desktop machine and acts as the presentation client (Web client). Physical Database Design and Use of Database Features This area includes the detailed layout of a database across file systems and disks and the use of the advanced database features such as MultiThreaded Server. Attention: Oracle Server has several advanced features you can use to run Oracle Applications, such as Multi-Threaded Server. Use of these features requires special knowledge of the Oracle database and appropriate tuning techniques for Oracle Applications.
Oracle Method
Hardware and Networks These constitute the technical infrastructure of the new system and must have the capacity to meet the transaction and user volumes anticipated at cutover and for some predetermined future period of time. System Availability Strategy This is the strategy you define for handling different kinds of planned or unplanned outages. There are many detailed techniques and tools for providing the system availability that a business needs and for guarding against loss of critical data, but there are tradeoffs to consider in selecting the mechanisms and systems to adopt. System Management Procedures These are the procedures and tools that you will use to keep the system functioning as it was designed to function, and in a modern, open systems environment there are many complex considerations in this area. Detailed Design of Distributed Data Interfaces These are the subsystems used to pass data between databases. They must ensure the integrity of data and guarantee delivery. Use of the Oracle server asynchronous remote procedure feature is one method for building these interfaces. The building of these special interfaces is often distinguished in a project from the design of interfaces to other third party applications, although conceptually the problem is the same in both cases. In fact, complex, tightly-integrated third party application interfaces are best treated as part of a distributed database architecture. This fact and the fact that distributed Oracle database interfaces usually affect multiple sites in an enterprise are the reasons for treating them as separate interface types.
ID TA.020 TA.030 TA.040 TA.050 TA.060 TA.070 TA.080 TA.090 TA.100 TA.110 TA.120 TA.130 TA.140 TA.150 TA.160 TA.170 TA.180 TA.190
Task Name Prepare Architecture Strategy Establish Architecture Requirements Develop Conceptual Architecture Conduct Technical Architecture Baseline Develop System Availability Strategy Define Future Application Deployment Develop Reporting Strategy Revise Conceptual Architecture Define Architecture Subsystems Propose Architecture Subprojects Design Application Security Architecture Design Application Functional Architecture Design Logical Application and Database Architecture Design Physical Database Architecture Design Hardware and Network Architecture Develop System Capacity Plan Assess Performance Risks Design System Management Procedures
Table 3-1
Deliverable Name Architecture Strategy Architecture Requirements Conceptual Architecture Technical Architecture Baseline System Availability Strategy Future Application Deployment Reporting Strategy Conceptual Architecture Architecture Subsystems Architecture Subproject Proposal Application Security Architecture Application Functional Architecture Logical Application and Database Architecture Physical Database Architecture Hardware and Network Architecture System Capacity Plan Performance Risk Assessment System Management Procedures
Objectives
The objectives of the Application and Technical Architecture process are as follows: Define a systems framework to realize the business and information systems vision of the corporation, where the circumstances and scale of the legacy systems replacement project warrant it. Ensure that the architecture for the replacement systems is compatible with the existing information systems framework and vision, where the scale of the replacement is more limited. Design an architecture for the replacement systems that is compatible with the detailed business requirements.
Oracle Method
Design a technical architecture to support the immediate processing capacity of the new system and for some specified period of future growth.
Key Deliverables
The key deliverables of this process follow: Deliverable Architecture Scope, Objectives, and Approach Description The scope of the architecture process, the objectives of the design and the approach that you will use. The strategy that you will use for the architecture process. It includes a discussion of the information systems standards, methods, tools and techniques required to perform the work outlined in the scope document. The high-level requirements for the architecture of the new systems. The requirements will include business operations, system and application preferences, IS operations, technical infrastructure and system management. The conceptual architecture design for the new systems. It is a high-level view of the new application and technical architecture and is intended as a working model for the architecture work and for the wider project team. It is also the primary vehicle for communication of the future information systems architecture to management.
Architecture Strategy
Architecture Requirements
Conceptual Architecture
Description Technical information about the existing legacy systems, including the applications, hardware, networks, and interfaces. The strategy for handling planned and unplanned outages. It is the system implementation of the more general business availability requirements defined elsewhere in the project. Details of the future deployment of applications needed to support the business and information systems requirements and the preferred conceptual architecture. Strategy study for the reporting systems needed to support the different reporting requirements of the business. Includes operational, ad hoc, decision support, and analytical reporting across applications, databases, and sites. Describes the subsystems needed to support the new architecture. The subsystems may need to be designed and built in-house, or may be purchased. Examples would include data warehouses, OLAP systems, enterprise data transport mechanisms, and so on. Proposals for architecture subprojects to handle the design and build of, or integration of, architecture subsystems.
Reporting Strategy
Architecture Subsystems
Oracle Method
Description The design of the security architecture to support the interorganization security requirements for business information. The design for the functional architecture of every separate installation site for the applications. This is created using business requirements mapping process input and defines the interrelationship between the critical setup parameters from an architecture and application configuration perspective. The design of the application and database architecture at the logical level. Includes the relationship between the functional architecture and the logical data partitioning. Includes database schemas and logical database objects. The detailed design for the physical layout of databases in the architecture. Includes the mapping of the logical database architecture onto the physical subsystems that support the database. The deployment and technical configuration of hardware and networks to support the applications deployment and database architecture.
Description The system capacity plan for the technical configuration. Includes the planning of client and server machines, and covers CPU, Memory, and disk capacity. The capacity plan covers initial system cutover into live production, and also some prescribed period of operations. Study of the performance risks inherent to the chosen architecture and the techniques and steps that can be taken to mitigate the risk. The detail design for the systems management procedures necessary to support the architecture.
Key Responsibilities
The following roles are required to perform the tasks within this process:
Oracle Method
Responsibility Establish the application architecture of the new system. Meet with business analysts to identify business vision and requirements important to architecture and then translate into an application and data deployment strategy. Coordinate and lead the development of an integrated application and technical conceptual architecture. Provide input to more detailed technical design efforts, such as interfaces and custom components, to ensure compatibility with the overall applications architecture. Provide input about the key processes, mapping decisions, and functionality that will be used in the new system; gather and communicate current and future business volumes; review proposed architecture. Design the logical application database architecture, including custom extensions. Provide input to architecture process about current and future systems and information systems strategy. Articulate the information systems policies and vision. Review key architecture deliverables. Provide documents and information about the existing operations procedures and policies covering applications, databases, interfaces, hardware and networks, system availability metrics, and performance.
Business Analyst
Database Designer
IS Manager
IS Operations Staff
Responsibility Provide input into technical architecture planning and design, design network management and maintenance procedures; recommend network management and monitoring tools and techniques; plan network capacity requirements; assess network performance risks. Provide input into logical database design and technical architecture; design database management and maintenance procedures; recommend database monitoring tools and techniques; plan database disk capacity requirements; assess database level performance risks. Conduct detailed process planning and assign tasks, establish roles, brief client and staff, manage team, manage changes, manage issues, maintain quality. Provide input into technical architecture planning and design; lead design of the overall systems management and maintenance procedures; recommend systems management and monitoring tools and techniques; plan hardware capacity requirements; assess system performance risks. Identify scope and strategy for the architecture process; meet with project and business managers; provide guidance during architecture design; manage dependencies to other processes; secure acceptance for architecture design work.
Project Manager
System Administrator
Oracle Method
Responsibility Provide input to the architecture process about technical designs for custom modules and functionality. Coordinate and lead the design of technical architecture, including gathering the baseline technical information, design of the hardware and network deployment and system capacity planning. Gather input and advice about performance risks. Meet with the application architect to ensure the technical architecture fully supports the business and information systems vision and the application and data deployment strategy. Participate in interviews and provide input about the requirements for system performance and availability.
Application and Technical Architecture Key Responsibilities
Technical Architect
User
Table 3-3
consideration of the interaction and dependencies between application architecture and technical architecture realistic consideration of the capabilities and the limitations of the technology to be used experienced application and technical architecture practitioners The fourth bulleted item is especially important. The architectural part of an implementation project is often considered to be purely technical in nature, with the risk that the business requirements are treated as subservient to the technology. A well-managed architecture project uses the business requirements and functional mapping as drivers for the optimal configuration of the applications being implemented; for the hardware and network infrastructure providing the applications processing; and for the tools and procedures needed to manage the complete system.
Oracle Method
Reference: Velpuri, Rama. Oracle Backup and Recovery Handbook. Oracle Press. Osborne McGraw-Hill, 1995. Web Site: Oracles home page on the World Wide Web http://www.oracle.com/. Web Site: The Transaction Processing Councils home page on the World Wide Web http://www.tpc.org/.
Deliverable
The deliverable for this task is the Architecture Scope, Objectives, and Approach document. It is a statement of the scope and the objectives of the application and technical architectural process, and the approach that the architectural team will take to perform the work.
Prerequisites
You need the following input for this task:
G
The project Scope, Objectives, and Approach document provides a highlevel discussion of the scope of the implementation project and how the project should be organized and run.
Task Steps
The steps of this task follow: No. 1. Task Step Discuss project structure with project manager and establish the need for a separate definition of Architecture Scope, Objectives, and Approach. Deliverable Component
Oracle Method
No. 2.
Task Step Review main project Scope, Objectives, and Approach. Verify the architecture description in the project-level scope objectives and approach, and move to the next task if a separate scope statement is unnecessary. Identify subproject scope, milestones, constraints, risks. Identify subproject objectives and critical success factors. Identify methods to be used for the architecture process or subproject. Identify subproject policies and procedures shared with the main implementation project, if applicable. Define policies and procedures unique to the subproject. Identify subproject dependencies to the main project and other subprojects. Establish technical background to the architecture subproject, including environment requirements. Review Architecture Scope, Objectives, and Approach with project management.
Deliverable Component
3.
4.
Scope
5.
Objectives
6.
Approach
7.
Approach
8.
Approach
9.
Approach
10.
Approach
11.
No. 12.
Task Step Secure acceptance for the Architecture Scope, Objectives and Approach deliverable.
Oracle Method
included. If necessary, you should define the level of completion for each key area of the architecture process in which you are engaged. Enterprise-Level Architecture Projects An enterprise-level architecture design will encompass all, or a major portion of, the important corporate information systems. This type of project may: help define strategic direction for information systems be subject to a program management approach to the implementation with a phased rollout strategy need to take into account multiple data centers, sites and/or countries need to be designed for a mix of new applications and older retained legacy applications be accompanied by an upgrade or strategic change of hardware and networks This type of architecture project covers the breadth of the enterprise and helps set strategic IS direction but may not get into the detailed design of every component of every new installation or system. Many design tasks that a site-level architecture would perform to completion are addressed only at a high level and may only set general enterprise-wide standards, policies, or procedures for the detailed design work at the site level. Site-Level (Localized) Architecture Projects A site-level architecture project is narrower in scope than the enterpriselevel architecture, but it goes into greater detail for the architecture components within the scope. It will only deal with single installation of key applications, or a very localized set of information systems. While there is still architecture work to be done, this will be organized to implement the architecture strategy and high-level architecture designs produced from the enterprise-level studies.
Role Contribution
The percentage of total task time required for each role follows: Role Team Leader - Architecture Project Manager Application Architect Technical Architect IS Manager
Table 3-5 Role Contribution for Define Architecture Scope, Objectives and Approach
% 50 30 10 10 *
Deliverable Guidelines
The Architecture Scope, Objectives, and Approach deliverable helps you collect and document the scope, objectives, and approach you will take for the architecture process in the implementation project. The Architecture Scope, Objectives and Approach document should expand the Scope, Objectives and Approach document created for the main implementation project in greater detail for the architecture process or subproject of the overall implementation project. It should make reference to the main project deliverable where appropriate and indicate those objectives and approaches that are inherited from the main project. It should not, however, be just a duplication of the main project Scope, Objectives, and Approach document.
Oracle Method
Project manager(s) of the main project that has spawned the architecture subproject IS manager Architecture team members Other process or subproject leaders who have dependent tasks with the architecture process/subproject
Deliverable Components
The Architecture Scope, Objectives, and Approach deliverable should contain the following components: Scope The scope component should describe the scope of the architecture process or subproject in as much detail as possible. Architecture scope statements can be made in terms of whether architecture components are in or out of scope for the project. Examples of such components that can define the scope include: Data Centers Business Processes, Sites or Functions Applications Interfaces Technical Infrastructure In addition to discussion of the scope, this component should also include a description of the key process milestones; the constraints to which this process will be subject and any assumptions made; the risks inherent in the application of the architecture process within the project; and the relationship of the architecture process to other systems projects and initiatives already underway. Objectives The objectives should list the high-level objectives that the business and project managers have communicated. Since this is a strategic document, the stated objectives should not be too detailed, but they should be specific and measurable. It should have a description of the critical success factors for the architecture process.
Approach The approach should describe the method, policies and procedures, project dependencies, and the technical background for the architecture process. The description of method should include a high-level discussion of the method selected for the architecture work, the tasks and deliverables, the reasons for selection of the method, and the benefits of the particular method adopted. The detailed architecture methodology does not need to be described in this document since it will be included in the subsequent Architecture Strategy deliverable (TA.020). The subproject policies and procedures should be related to the corresponding policies and procedures adopted for the main project. If the subproject is to use different polices, procedures or standards from the main project in any of the key control and reporting areas, the deliverable should document the differences in detail, explaining why they differ. The following are examples of areas where the subproject will typically inherit standards and procedures from the main project: Quality Plan Issue Management and Resolution Change Management Reporting Format Reporting Relationship to Main Project Acceptance Project Policies and Procedures Subproject Team Meetings Logistics and Administrative Support The dependencies part of the component should describe the dependencies between the architecture process and other processes or subprojects taking place within the overall implementation project. The technical background should describe the technical circumstances affecting the approach to the project. Examples of the points that might be included are: Implementation sites
Oracle Method
Technical architecture direction Computing platforms and technical infrastructure Major system or application requirements Innovative or unusual technical requirements In relation to the statements about the technical circumstances for the project, the deliverable should indicate the application and technical environments that will be necessary to support the subproject. In the absence of special technical requirements, much of the work in the architecture process can usually be performed using regular project documentation environments and the design or development environments used by other process teams. But for example, if there is significant prototyping to be performed as part of the architecture design process, there may be a need for particular architecture team environments. Suggestion: Use the main project Scope, Objectives, and Approach deliverable to assist in the creation of this processbased version of the same deliverable.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Are the project scope and objectives clearly identified? Are specific critical success factors and risks documented? Does this document take into account the impact of dependent tasks from other processes? Are the architecture requirements clearly defined?
Tools
Deliverable Template
Use the Architecture Scope, Objectives, and Approach template to create the entire deliverable or specific deliverable components. Choose from the following components and modify the standard text as needed to represent your project:
Oracle Method
Deliverable
The deliverable for this task is an Architecture Strategy document that describes the strategy to be used for the work performed in the application and technical architecture process.
Prerequisites
Required
You need the following input for this task:
G
The project Scope, Objectives and Approach document provides a highlevel discussion of the scope of the architecture work, the sites, applications and data centers of the existing information systems it should address, and how the project should be organized and run.
Optional
You may need the following input for this task:
G
If the architecture process is being managed as a subproject and the overall project manager has requested a separate, detailed Scope,
Objectives, and Approach document that focuses on architecture alone, this will be a required input to this task. Otherwise you will obtain the information from the Project Scope, Objectives, and Approach document.
G
If high-level systems strategy or policy documents exist, use them to provide information about current thinking on the architecture and systems strategy.
Task Steps
The steps of this task follow: No. 1. Task Step Document the context for the architecture process. Gather relevant materials from the project library. Establish the methodology to be used for the architecture design. Identify benefits of the methodology to be used for the architecture work. Establish the business vision, data distribution strategy, and IS policies. Identify IS standards for architecture and architecture components. Establish approach to technical baselining. Architecture Methodology Deliverable Component Introduction
2.
3.
4.
Architecture Methodology
5.
6.
7.
Architecture Methodology
Oracle Method
No. 8.
Task Step Establish approach to system capacity planning. Establish approach to system management. Identify risks in the architecture strategy. Document the technical infrastructure requirements. Document the staffing requirements for the tests. Identify resource requirements risks. Review the deliverable with the project and IS managers. Secure acceptance for the deliverable.
9.
10.
Risks
11.
Resource Requirements
12.
Resource Requirements
13.
Risks
14.
15.
Management Acceptance
Table 3-6
Business Vision
The vision for the new business systems is a key initial ingredient to the design of an architecture, especially where the architecture process is covering the strategic aspects of the new systems as well as the tactical design. The vision must be documented and understood early on in the process. Examples of business visions are listed below: Users must be able to perform a global check of inventory availability across the entire corporation, regardless of the manufacturing plant source of the inventory and the distribution center location. The corporation will standardize all financial operations on a new single chart-of-accounts structure. The business must achieve differentiating or transformational business processes (e.g., global available-to-promise, tight supply chain integration, or electronic receipt settlement). The business must streamline and reduce metrics for certain business processes(e.g., process payrolls) or close the financial books in a shorter specific cycle time.
Oracle Method
probably, for new technology as well. In projects where the implementation is more limited in scope, this may just be a matter of conforming to policies and principles that the IS department has already laid down for any new information systems. In situations where a formal Information Systems Strategy project has preceded the implementation architecture process, a set of principles, directives, and strategies may already be in place, which you can directly input as requirements to the implementation architecture here. The directives and policies are fundamental to the strategy for new information systems in the company and should underpin any architecture that is designed for the new systems. The selection of a particular suite of applications or technology may be partly in response to the demands of the particular information systems strategy. A common example of architecture standards is in the selection of hardware, where database servers in the new information systems will be purchased from hardware vendor ABC, with whom the business has forged a strategic relationship. Reference: For an example of one approach to information systems strategy development, see Oracles Information Systems Strategy Method, ISS Method Handbooks.
Architecture Methodology
The methodology that AIM employs for architecture is robust and proven in prior implementations. There are other techniques for arriving at the performance test transactions and database, but they are all very similar to the process presented here. The advantage of the AIM approach is that it is top-down in nature and strikes a balance between the business and technical requirements, with the demands of the business driving the technology rather than vice versa. Other bottom-up approaches to the architecture process can risk creating designs that lock the business into a technological solution incompatible with immediate or future business direction.
Data Distribution Strategy For larger implementations, requirements and strategies may exist for the deployment of data and databases in the enterprise systems. If these strategies and expectations are known early in the architecture process, you should document them here. The data distribution strategy may also include key interfacing and data transport strategies. Technical Baselining Technical baselining is important for the understanding of the existing systems, and the architecture process may share the need for this information with other processes in the project. A critical assessment of the need and ownership of the technical systems baselining is useful at this stage to prevent duplication of effort with other processes. For more information see Develop System Capacity Plan (TA.170). System Capacity Planning System capacity planning is an extremely important part of any technical architecture project and the strategy to be used for this should be considered as early as possible in a project. By agreeing on an approach early on, more effort can be devoted to the capacity analysis and steps put in place to mitigate any perceived risks. For more information see Develop System Capacity Plan (TA.170). System Management Creating a new system management infrastructure for replacement ERP applications can be a large undertaking. A well-designed system management infrastructure is a critical success factor for relatively trouble-free production operations in the new system, so an early strategy for this area is beneficial. For more information see Design System Management Procedures (TA.190).
Role Contribution
The percentage of total task time required for each role follows: Role Team Leader - Architecture % 50
Oracle Method
% 30 10 10 *
Deliverable Guidelines
The Architecture Strategy deliverable helps you collect and document the architecture strategy decisions for the project.
Deliverable Components
The Architecture Strategy deliverable should contain the following components: Information Systems Strategy The information systems strategy component should discuss the strategy that the company is following in selecting and implementing new information systems. The areas that should be detailed as part of this strategy are:
Statement of Problems in Existing Information Systems Business Vision Information Systems Vision Implementation (of the Information Systems Vision) Information Systems Policies Information Systems Standards The information systems standards component should discuss the standards that are in place for the selection, implementation, or development of new information systems in the company. The areas where standards may apply are: Hardware and Network Standards Business Applications and Enabling Technology Standards Office Automation and Desktop Standards Development Standards System Management Standards Architecture Project Methodology The architecture project methodology component should describe the methodology to be used for the architecture process in some detail. The description of the methodology should include a high-level discussion of the work breakdown structure, the tasks and deliverables, reasons for selection, and the benefits of the particular architecture methodology adopted. If specific terminology is associated with the methodology, include a glossary of architecture-related terms. Architecture Project Strategy The architecture project strategy component describes the strategy for addressing key areas in the architecture project. These areas may be highlighted and discussed because of their criticality in the architecture work, because of the inherent risk to the project, because of an innovative or unusual approach to be applied in the project, or for some other implementation-specific reason. Examples of areas that might be highlighted in this way include: Technical Architecture Baselining System Capacity Planning
Oracle Method
Systems Management Resource Requirements The resource requirements component should describe the specific resource needs for the architecture process in the following areas: Software Hardware and Networks Hardware and Software Delivery Schedule Staff Resources Risks The risk component should describe the risks in the strategy adopted for the architecture project. Examples of risk areas to mention here are: Approach to technical baselining Approach to system capacity planning Large scale implementation of distributed architecture systems Lack of clear architecture ownership and autonomy among divisions Lack of availability of suitably experienced resources
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Does the strategy discuss existing IS policies and strategies and indicate how they relate to this project? Is the strategy understood by those on the distribution list for this deliverable? Are all resource and tool requirements that could impact the architecture process stated and understood?
Tools
Deliverable Template
Use the Architecture Strategy template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your project circumstances: Introduction Information Systems Strategy Information Systems Standards Architecture Project Methodology Architecture Project Strategy Resource Requirements Risks Acceptance Certificate
Oracle Method
Deliverable
The deliverable for this task is an Architecture Requirements document. This contains a list of major requirements that the architecture design should meet.
Prerequisites
Required
You need the following input for this task:
G G
The project Scope, Objectives, and Approach document provides a highlevel discussion of the scope of the architecture work; the sites, applications, and data centers of the existing information systems it should address; and how the project should be organized and run. Architecture Strategy (TA.020)
The Architecture Strategy document describes the architecture strategy to be used in the process.
Optional
You may need the following input for this task:
G
If the architecture process is being managed as a subproject and the overall project manager has requested a separate, detailed Scope,
Objectives, and Approach document that focuses on architecture alone, this will be a required input to this task. Otherwise you will obtain the information from the project Scope, Objectives, and Approach.
Task Steps
The steps of this task follow: No. 1. Task Step Gather existing relevant materials from the project library. Identify reasons for choice of the new applications being implemented as a guide to key system requirements. Establish any general business requirements relevant to the architecture. Establish data sharing and data visibility requirements. Establish reporting needs and policies. Establish multilingual requirements. Establish system capacity requirements. Establish requirements for IS operations and organization. Establish application vendor software and version preferences. Detailed Requirements Deliverable Component
2.
3.
Detailed Requirements
4.
Detailed Requirements
5.
Detailed Requirements
6.
Detailed Requirements
7.
Detailed Requirements
8.
Detailed Requirements
9.
Detailed Requirements
Oracle Method
No. 10.
Task Step Establish security requirements. Establish user desktop and user interface preferences. Establish system availability requirements. Identify any other general system or business requirements affecting architecture. Summarize requirements, their stringency, and impact on architecture.
11.
Detailed Requirements
12.
Detailed Requirements
13.
Detailed Requirements
14.
Requirements Summary
Table 3-8
The dividing line between a requirement and a directive or policy is not hard and fast but the principle of immutability is probably the most reliable gauge. You should realize that policies for the overall application and technical architecture can derive not only from strategic technology decisions, but also from future business operations requirements and the business vision. Information Sources Much of the information needed for subsequent design activities may be strategic in nature, or at the very least, it may require decisions by senior management or project leaders. Often the strategic information will not be written down. This, combined with the fact that architecture is often a front-loaded project process, means that you may have to perform much of your information gathering in face-to-face meetings as you go along. The IS manager or director will be an important source of decisions and information for the high-level technical and IS requirements.
Oracle Method
ability to view corporate data regardless of its source location or database IS Operations Requirements in this area might include: IS restructuring in response to financial or operational changes centralization or decentralization of IS Operations as needed outsourcing some or all of IS functions performed in-house Specific Applications or Databases Requirements in this area might include: Oracle Applications as the central repository for all business data purchase and integration of specific third-party packages to assemble best-of-breed solutions retention of certain legacy systems that provide specific value (e.g., custom order scheduling systems or return material tracking systems) Security Requirements Requirements in this area might include: absolute need to secure all financial transaction data by site, legal entity or department absolute need to secure salary or other HR information, but employees still allowed to view and update their personal information corporate-wide requirement for manufacturing staff to be able to transact their own plant data but only view data from other plants. User Interfaces and Desktop Requirements in this area might include: standardization of all user desktop environments migration of legacy systems to achieve the same client-server look and feel as the Oracle systems to be implemented
implementation of web-based systems for casual (or supply chain) users that will not be given formal system training System Capacity Requirements in this area might include: system support of a specific number of concurrent or named users and volumes of transactions of critical business objects ability of the new system to continue functioning for a certain minimum time after cutover before the business will contemplate upgrades to the architecture ability of the system to support projected future business growth System Availability Requirements in this area might include: specifying a necessary minimum availability of systems for business processing specifying a maximum downtime the business can tolerate for recovery after any form of system failure necessity of having a disaster fail over site elsewhere, in case of disaster or catastrophic failure Reporting Systems Requirements in this area might include: a data warehouse or OLAP system to facilitate consolidated, summary, or analytical reporting operational reporting systems to span distributed data and heterogeneous applications ability of users to perform ad hoc queries easily, using a specified or unspecified set of tools report distribution and publishing via the company intranet Multilingual Requirements Requirements in this area might include: presentation of all forms and reports boilerplate text in the local language of the users
Oracle Method
ability to generate external reports for vendors, customers, and employees, with both text and data translated into the local language Suggestion: Get as much detail as you can, but remember that you are trying to cover all the major architecture requirements and are not doing the detailed analysis at this stage. Many of the specifics will be captured both in this process and in the Business Requirements Definition and Mapping processes.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Technical Architect Business Analyst IS Manager
Table 3-9 Role Contribution for Establish Architecture Requirements
% 45 45 10 *
Deliverable Guidelines
The Architecture Requirements deliverable helps you collect and document the architecture requirements for the project.
Deliverable Components
The Architecture Strategy deliverable should contain the following components: Requirements Summary The requirements summary component should summarize the detailed requirements gathered for the business and information systems and their likely impact on the architecture and systems. Detailed Requirements The detailed requirements component should detail the individual business and information systems requirements that will affect the architecture. Some of the requirements that may be included are: Key Reasons For Selecting New Application System The key reasons that led to the selection of the applications can be a useful indicator of the critical requirements that the systems must meet. Requirement Areas This is a list of individual requirements affecting architecture that may include some or all of the suggested areas discussed in the approaches to this task.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Is the deliverable thorough in capturing different types of business and information systems requirements that are directly relevant to architecture? Have the individual requirements been stated in terms that communicate their architectural significance?
Tools
Deliverable Template
Use the Architecture Requirements template to create the entire deliverable or specific deliverable components. Choose from the
Oracle Method
following sections and modify the standard text as needed to represent your project circumstances: Introduction Requirements Summary Detailed Requirements
Deliverable
The deliverable for this task is the Conceptual Architecture document. This describes the conceptual architecture design(s) for the new system. It may contain several designs, if there is more than one possible conceptual architecture, but will also indicate the conceptual architecture model that is preferred. If there is only one possible conceptual architecture model, it will only describe this one model.
Prerequisites
Required
You need the following deliverables for this task:
G G G
The project Scope, Objectives, and Approach document provides a highlevel discussion of the scope of the architecture work, the sites, applications and data centers of the existing information systems it should address, and how the project should be organized and run. Architecture Requirements (TA.030)
The Architecture Requirements document provides information about the high-level requirements for the architecture design, and covers various aspects of the application and technical architecture. Architecture Strategy (TA.020)
The Architecture Strategy document provides information about the information systems strategies currently in place for the business,
Oracle Method
including standards for the technical infrastructure, information systems policies, and enabling technologies that you should incorporate into the design. It also contains details about the methodologies and strategies for the architecture project.
G G G
The Financial and Operating Structure document provides information about the company financial hierarchy, the business organizations, and the functions the organizations perform. Process and Mapping Summary (RD.050)
If the project is using a Process and Mapping Summary document to record key process and mapping decisions, it will provide details of the future business model, including business processes and mapping decisions made to date. Business Volume Requirements (RD.060)
The Business Volume Requirements document provides the business volumes information which you need to perform preliminary capacity analysis of any candidate hardware architectures.
Optional
You may need the following input for this task:
G G
The designs and technical documents from the sales cycle may provide information about the original thinking for the architecture of the new systems. Architecture Scope, Objectives, and Approach (TA.010)
If the architecture process is being managed as a subproject and the overall project manager has requested a separate, detailed Scope, Objectives, and Approach document that focuses on architecture alone, this will be a required input to this task. Otherwise you will obtain the information from the Project Scope, Objectives and Approach.
G
Task Steps
The Physical Resource Plan document is needed if you plan to design the development environment architecture.
The steps of this task follow: No. 1. Task Step Gather and review any materials and documents from the requirements definition and mapping processes. Identify key business functions and organizations in the scope of the new architecture. Identify the data centers that manage the data and processing of the key business units. Identify major information and material flows for the business functions and organizations. Identify critical legacy applications replaced in the new architecture. Identify critical legacy applications retained in the new architecture. Business Operations Deliverable Component
2.
3.
4.
5.
Key Applications
6.
Key Applications
Oracle Method
No. 7.
Task Step Identify candidate application release versions within the project timescale and assess their base functionality and technology. Develop candidate application deployment strategies to support key business functions and organizations. Identify any specific reporting systems needed for each conceptual architecture. Identify possible hardware and networks that support each application deployment architecture. Map information flows onto each candidate application deployment. Identify key distributed data interfaces. Identify architecture subsystems needed to support each conceptual architecture. Perform approximate capacity analysis for each conceptual hardware and network architecture. Identify tradeoffs for each conceptual architecture.
8.
Conceptual Architecture
9.
Conceptual Architecture
10.
Conceptual Architecture
11.
Conceptual Architecture
12.
Conceptual Architecture
13.
Conceptual Architecture
14.
Conceptual Architecture
15.
Conceptual Architecture
No. 16.
Task Step Design architecture for the project development environment. Perform approximate capacity analysis for the project development environment architecture. Review competing architecture models with senior business and project management. Document preferred conceptual architecture and basis for preference. Document assumptions for selected architecture. Assess impact of selected architecture on enterprise. Review deliverable with senior business and project management. Secure acceptance for Conceptual Architecture deliverable.
17.
18.
19.
20.
21.
22.
23.
Management Acceptance
Table 3-10
Oracle Method
management, the application and technical architects update the Conceptual Architecture deliverable to reflect the choice and assess its impact on the business, the IS organization, and the implementation project. In some ways, this task is a high-level pass through the entire architecture methodology. You need to take into account enough detail to make intelligent and important decisions about what is and is not feasible from an architecture standpoint, but you are not fully designing the architecture. The conceptual architecture is a prototype model that enables early review by management and a definition of architecture direction or vision. The application architect needs to have a good highlevel grasp of the features and functions that the release of the applications being implemented support. He or she needs to apply this information as a constraint in deciding which conceptual architectures are feasible, either because of cost, complexity, or degree of custom development needed. Generally you will not have all the business and information systems requirements available to you when you start this task. The business requirements mapping may be in its early stages also, and the analysts may not have made all the key decisions at the time of starting this work. You will need to review any hard copy information available and selectively interview business analysts and IS operations staff as necessary. Attention: This task usually requires special expertise in both application and technical architecture. Ensure that the individuals fulfilling these roles have the knowledge and experience to perform the task.
Conceptual Architecture
The conceptual architecture is an initial, high-level attempt at designing the application and technical architecture for the new system. In projects of a larger scope, where you are implementing an entirely new financial, distribution, or manufacturing system, the conceptual architecture should not be geared toward one particular component or system layer, but should be a slice through the applications, databases, hardware, and networks in the future system. This enables the architecture to show the relationship between the layers or components of the new system architecture. At the other extreme, in more specific or smaller scale projects (e.g., where you are implementing a single business function or single Oracle Application module into an existing
Oracle Method
major custom architecture components or subsystems that you will have to design and build or purchase. Assess Risk and Scope You can use the conceptual architecture to assess risk in the new systems, thereby creating a checkpoint for architecture rescoping and replanning efforts.
Information Sources
Much of the information needed for designing the conceptual architecture may be strategic in nature, or at the very least, it may require decisions by senior management or project leaders. Often the
strategic information will not be written down. This, combined with the fact that architecture is often a front-loaded project process, means that you may have to perform much of your information gathering in faceto-face meetings as you go along. The IS manager or director will be an important source of decisions and information for the high-level technical and IS requirements. You may have to do the same for the business requirements and obtain high-level requirements and direction in face-to-face meetings with senior business analysts and operations managers.
Architecture Subsystems
When you define the possible conceptual architectures, identify any architecture subsystems that you need to build or purchase from another vendor. Examples of such systems are:
Oracle Method
Data registries Message transport systems for electronic commerce or for communication between distributed databases Data warehouses/OLAP systems Key enterprise-level interfaces to other applications or systems For more information refer to Define Architecture Subsystems (TA.100).
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Technical Architect Business Analyst IS Operations Staff IS Manager Project Sponsor
Table 3-11 Role Contribution for Develop Conceptual Architecture
% 40 40 20 * * *
Oracle Method
Deliverable Guidelines
The Conceptual Architecture deliverable helps you document the key components of possible candidate architectures and identify the preferred conceptual architecture after review has taken place.
Deliverable Components
The Conceptual Architecture deliverable should contain the following components: Business Operations The business operations component should provide a high-level description of the business operational model that the architecture must support. The component should describe the business that the company engages in, the structure of the business, and the critical aspects of the business processes that the architecture must take into account. Specific discussion areas in this component are: Key Business Organizations and Functions Financial Structure Major Business Processes Where possible, you should include diagrams of the geographical and organizational structure of the business.
Data Center Operations The data center operations component should describe the data centers within the scope of the architecture, the particular operations that the data centers perform, the systems or applications the data centers support, and the business functions and organizations for which they perform the operations. Business Information Model The business information model component should describe the information flows and information access within the corporation or company. The information flows should be associated with business processes or process steps. The component does not need to document all flows for all processes to the lowest elementary business function level of detail, but it should cover critical business processes and functions, processes that span multiple applications or application installations, and complex processes that may require detailed custom design. The information access model part of the deliverable component should describe the access to information that business units need in order to execute business process steps, but without compromising the integrity and security of the business information as a whole. Information access is concerned with: Information (data) partitioning to provide security and maintain integrity Information (data) aggregation, consolidation and summation to provide appropriate reporting views of the state of the business Suggestion: You should incorporate information from the BR.060 Information Access Model if it exists and has content at this point in the project. However, it may not exist at this time, and you should try to work with the business analysts to start defining the information access requirements. Key Applications The key applications component should describe the major or key applications that will be part of the future architecture. Specific discussion areas in this component are: Existing applications retained
Oracle Method
Replacement applications Conceptual Architecture The conceptual architecture component should describe the integrated conceptual application and technical architecture model for the business. This component may need to be repeated more than once, if there are multiple possible conceptual architecture models to document and consider. The component should illustrate the architecture models diagrammatically wherever possible and should consider these areas: Application architecture and deployment Functional architecture of the packaged applications Key application interfaces required for this model Technical architecture, hardware and networks Approximate capacity analysis Analysis of the architecture model, advantages and disadvantages Project Environment Architecture The project environment architecture component should describe the architecture of the application environments needed for the implementation project. This component is an optional inclusion. It will only be needed if the architecture scope includes architecting the implementation project infrastructure also. It should consider the impact of custom development on the standard package application environment. Preferred Architecture Model The preferred architecture model component should describe which of the multiple conceptual architecture models originally presented has been chosen as the preferred model for the future systems. The areas that the component should especially focus on are: Key Factors in Selection Impact of Selected Architecture
Quality Criteria
Use the following criteria to ensure the quality of this deliverable:
Are the high-level business operations and information model requirements clearly identified? Are there competing conceptual architectures included, or is there a clear reason why only one is considered? Are all components of each conceptual architecture covered (breadth of analysis, not depth, is emphasized at this stage)? Have diagrams been included to aid understanding and communication? Does the analysis of each architecture option include advantages, disadvantages, and risks? If a preferred architecture has been selected from multiple choices, is it clear why this choice was preferred?
Tools
Deliverable Template
Use the Conceptual Architecture template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your architecture design: Introduction Business Operations Data Center Operations Business Information Model Key Applications Conceptual Architecture Project Environment Architecture Preferred Architecture Model Acceptance Certificate
Oracle Method
Multiple Conceptual Architecture Models Use the Conceptual Architecture repeating component to document each individual candidate architecture that may fit the requirements and the business. The deliverable template prompts you for the name of the conceptual architecture option. You can easily add further candidate architectures by selecting the Insert Boilerplate menu option for as many architecture options as you need.
Deliverable
The deliverable for this task is the Technical Architecture Baseline document, an inventory of the systems, applications, hardware, and networks that constitute the existing technical infrastructure for the business.
Prerequisites
Required
You need the following input for this task:
G G
The project Scope, Objectives, and Approach document provides a highlevel discussion of the scope of the architecture work, the sites, applications, and data centers of the existing information systems it should address, and how the project should be organized and run. You use this to understand the scope of your technical baselining efforts. Architecture Strategy (TA.020)
The Architecture Strategy document provides information on the strategy for the architecture work and whether or not baselining is needed.
Oracle Method
Optional
You may need the following input for this task:
G G
If the architecture process is being managed as a subproject and the overall project manager has requested a separate, detailed Scope, Objectives, and Approach document that focuses on architecture alone, this will be a required input to this task. Otherwise you will obtain the information from the Project Scope, Objectives, and Approach. Existing System Architecture or Technical Configuration Documents
There should be at least some system architecture or technical configuration documents in existence. The technical configuration documents could include hardware deployment, network diagrams, system interfaces, and so on. Use them to provide information about the current systems and infrastructure, but make sure they are not out of date.
G
If documentation about current system management procedures exists, make sure the information is current.
Task Steps
The steps of this task follow: No. 1. Task Step Review overall project scope and decide the scope of the technical architecture baselining effort needed. Review and catalog existing architecture documentation and validate its relevance to the current systems. Deliverable Component
2.
No. 3.
Task Step Identify the gaps in the current systems documentation and establish information sources. Identify existing data centers, the functions they perform, and services they provide. Profile existing applications. Identify usage of applications by business units. Profile existing databases. Gather specifications of existing interfaces. Identify existing hardware, including desktop machines, servers, and so on. Gather information about existing networks, topology, and capacity. Gather information about peripheral devices such as printers, modems, and others that are relevant to the scope. Gather information about system management procedures. Gather metrics for current system availability. Identify known changes within implementation time frame.
Deliverable Component
4.
Data Centers
5. 6.
Applications Applications
7. 8.
9.
Hardware
10.
Network Architecture
11.
Peripheral Devices
12.
System Management
13.
System Management
14.
Oracle Method
No. 15.
Table 3-12
To Baseline or Not?
A baseline of the existing system architecture is often regarded as unnecessary, but consider what the task produces before dismissing its
value. Some projects may need minimal or zero baselining, but most projects will require at least some understanding of the existing systems. There are several good reasons for a technical baseline: Reuse of existing infrastructure, hardware and/or networks. To be able to redeploy or reuse the existing technical infrastructure for the new application and technical architecture, an understanding of what exists currently is needed. Replacement of existing systems. Business and technical analysts on the project need at least some elementary knowledge of the applications they are replacing, in order to be able to map business processes onto the new applications and design technical solutions. Integration with retained existing systems. Business and technical analysts on the project will need a knowledge of the applications and technology they are attempting to integrate. Integration cross-check. Cross-check that all existing interfaces have either been subsumed by the new applications or have been identified as being replaced wholly or partially by new interfaces. In a project where systems integration and/or infrastructure reuse is intended, it can be a mistake to ignore this task and believe that project time has been saved by not doing it. In reality, individuals designing technical architecture, performing capacity planning, designing new interface mechanisms, or designing technical mapping solutions will still need to have the information before they can undertake the work assigned to their project role. There is a danger of duplicate information gathering and wasted resource time, as compared to properly planned and scoped baseline effort. Use of Existing Documentation If a clear summary document already exists that discusses the current technical architecture baseline, this task can be marked as completed with little extra work other than validation that the documentation has all the details necessary. In general, however, documentation of existing systems easily falls into obsolescence over time, and some work is usually needed to restructure it and bring it up to date. Fast Track, Limited Scope Projects If you are working on a fast track project with complete replacement of existing systems and no integration requirements, it would probably be wasteful to undertake a formal baseline effort. Under these
Oracle Method
circumstances, you can drastically reduce the scope of the task, possibly to zero if you are upgrading much of your hardware and networks concurrently with the implementation.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Architect Business Analyst IS Manager % 80 20 *
% *
Deliverable Guidelines
The technical architecture baseline document should describe the existing technical architecture in detail. The document will be used for design and analysis work in the architecture process and possibly in other processes of the project. To complete this deliverable you must understand the technical direction, strategy, and technical resource plan of the business. Suggestion: When documenting information systems, use diagrams wherever possible to avoid (or enhance) text descriptions and to aid visualization of system integration points. For some aspects of the system, such as network topology, a diagram may be the only reasonable way to communicate the architecture.
Oracle Method
Architecture team members Team members for the processes listed above All members of the project team
Deliverable Components
The company may already have documentation on these key elements. In this case, simply assemble these materials and identify how each part of the existing system was implemented. Then add a section that identifies opportunities for improvement in the current system. The Technical Architecture Baseline deliverable should contain the following components: Data Centers The data centers component should describe the existing data centers within the scope of the architecture and the applications, systems and data centers they support. Applications The applications component should describe the current applications that handle the processing in the current architecture. Specific discussion areas in this component are: Summary of existing applications Application usage by business units Profile of existing applications Application Interfaces The application interfaces component should describe the existing application interfaces in the current architecture. Specific discussion areas in this component are: Summary of existing application interfaces Profile of existing application interfaces
Databases The databases component should describe the databases that currently store data with the current architecture. Information to record about each database is: Total volume of data in the database Business organizations that generate data in the database The database technology and vendor Hardware The hardware component should describe the computing hardware in the current architecture. Network Architecture The network architecture component should describe the high-level architecture and capacity of the networks in the current architecture that will be within the scope for the new architecture project. The information recorded in this component should include: Sites or machines linked by a network segment Network topology and protocol Network latency and bandwidth Service vendor You should include or reference a high-level network diagram. Peripheral Devices The peripheral devices component should describe any relevant peripheral devices or device standards in the current architecture. The peripheral devices might include printers, modems and so on. System Management The system management component should include the systems management metrics, tools and procedures that are used to manage the systems architecture. The component should record quantitative metrics about current system availability if possible.
Oracle Method
Expected Architecture Changes The expected architecture changes component should include a description of the expected changes to the baseline architecture during the timeframe of the implementation project. Areas for Improvement The areas for improvement component should highlight any specific opportunities for improvement in the systems based on the findings of the baseline analysis. Examples of these areas are: Hardware and software limitations System management tools and procedures Improvements in logistics, communications, or support
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Is the deliverable comprehensive in the systems it covers? Does the deliverable cover all applications and systems that are within the scope of this architecture project or that will impact the project? Does it have the information organized in a way easy for all project technical team members to find and understand?
Tools
Deliverable Template
Use the Baseline Technical Architecture template to describe the current technical architecture. Choose from the following sections to conduct your review: Introduction Data Centers Applications Application Interfaces
Databases Hardware Network Architecture Peripheral Devices System Management Expected Architecture Changes Areas for Improvement
Oracle Method
Deliverable
The deliverable for this task is the System Availability Strategy document, a study of the systems and approaches that will be incorporated into the technical architecture of the new system to provide the required level of system availability.
Prerequisites
You need the following input for this task:
G G
The Business Availability Requirements deliverable provides details of the agreed upon requirements for the availability of the business systems. It discusses the minimum level of service that the business expects from the information systems that support it, the downtime it will accept, and the contingency measures that will be adopted if unplanned outages of various types occur. Architecture Requirements (TA.030)
The Architecture Requirements deliverable provides information about the high-level requirements for system availability and fault tolerance characteristics.
Task Steps
The steps of this task follow: No. 1. Task Step Review task input deliverables and summarize systems availability requirements. Identify impact of database corruption scenarios and their handling. Identify software code corruption scenarios and their handling. Identify impact of disk failure scenarios and their handling. Identify impact of database server failure scenarios and their handling. Identify impact of application file server failure scenarios and their handling. Identify impact of network failure scenarios and their handling. Identify impact of client desktop failure scenarios and their handling. Identify impact of data center failure scenarios and their handling. Deliverable Component Critical Systems Availability
2.
3.
4.
5.
6.
7.
8.
9.
Oracle Method
No. 10.
Task Step Identify impact of code management and its handling. Identify impact of database maintenance and its handling. Summarize possible system failure scenarios that could affect systems availability. Summarize procedures or maintenance tasks that require planned downtime.
11.
Maintenance Outages
12.
13.
Table 3-14
Downtime for application of code patches or for code upgrade Unplanned outages generally occur because of an exception condition in the applications, or because a technical component fails. Unplanned system outages include: Disk or media failure that may affect database files Database failure caused by hardware or operating system crash or operator error Hardware or complete data center failure due to disasters such as fire and earthquakes Network failure that may affect critical interfaces between remote sites or online connections to a server
Oracle Method
The Cost of High Availability Management will often ask for 24x7x52 system uptime without a clear idea about what this really means. For an IS organization to guarantee the business 99.99 percent systems availability, they would usually have to make a prohibitively expensive investment in redundant hardware and communications links. Few businesses will end up with a fault tolerance strategy that enables this degree of availability once the costs are identified. The technical architect should ensure that expectations have been set properly, and that the management of the business has understood the realities of the situation and has not been misled into thinking that they have 24x7x52 operation simply because the database administration staff are performing regular database backups. The definition of the business availability requirements should be where these types of compromises have been discussed, and so at this stage you should have a set of realistically attainable system availability metrics.. For more information, see Identify Business Availability Requirements (RD.090).
components such as mirrored disks, it is important to document these within this task. For more information about backup and database copy procedures, consult the following: Reference: ORACLE7 Server Administrators Guide. Oracle Part Number 6694-70-1292. Reference: Velpuri, Rama. Oracle Backup and Recovery Handbook. Oracle Press. Osborne McGraw-Hill, 1995.
Oracle Method
Database administrators configure the production instance to run in archive log mode. The mirror instance has its database mounted but not open, equivalent to the startup mount command. When the production instance performs a log switch and the ARCH process creates an archive log, a batch process copies the archive log and the current control file to the standby server. The standby system is maintained in a continuous recovery mode, however, which means that it cannot be used for purposes other than standby. A cheaper and more cost-effective way to implement the standby server solution is to buy a minimum hardware configuration for the backup server. The technical architect can design the backup server to be a temporary fix until the production server is repaired. The minimum configuration will allow for smaller CPUs, or a reduced number of parallel CPUs, and a reduced amount of physical memory. The disk configuration can be quite different as well. The tradeoff is that the standby server may not be able to handle the regular processing load of all users and batch processing, and that some mechanism to limit system usage will be needed while the primary server is repaired and brought back online. It is not possible to estimate accurately the total recovery time for a database running with a standby server configuration. Accurate recovery time estimates are determined by thorough testing. Implementing the standby server allows for a much improved backup methodology. During off peak hours, administrators can perform a cold backup of the mirrored server using multiple backup devices. During this time, the administrator suspends the transfer of archive logs from the production instance to the mirrored instance. After the backup is complete, the transfer routine is re-enabled and the application of the archive logs continues. Remote Standby Server When the standby server is maintained in a remote location, such as a backup data center, it can act as a disaster recovery site to preserve system availability while the main data center is repaired and brought back online. Oracle server version 7.3 supports the standby database feature. For more information, see: Reference: Oracle7 Server Reference, Release 7.3. Oracle Part Number A32589.
Reference: Oracle7 Server Administrators Guide, Release 7.3. Oracle Part Number A32535.
Oracle Method
database mirror images is uncorrupted. In systems where the cost is not prohibitive, a triple mirror configuration can enable the database administrator to back up the database to tape without having to keep parts of the database in hot backup mode, while keeping the disk redundancy safety net. For an excellent discussion of RAID technology, see: Reference: Millsap, Cary V. Configuring Oracle Server for VLDB. OAUG Proceedings, Spring 1996. For a discussion of design for high availability, see: Reference: To, Lawrence. Design for Higher Availability and Faster Recovery. IOUW Proceedings, Fall 1995.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Architect System Administrator Production Database Administrator Network Administrator IS Operations Staff IS Manager
Table 3-15 Role Contribution for Develop System Availability Strategy
% 70 10 10 10 * *
Deliverable Guidelines
The System Availability Strategy deliverable helps you establish the strategy you will use to manage planned and unplanned system outages.
Oracle Method
Deliverable Components
The System Availability Strategy deliverable should contain the following components: Critical Systems Availability The critical systems availability component should describe the major and most critical system availability requirements. The discussion should include the availability needs at different times of the day and different points in the business cycles (month, quarter). Unplanned System Outages The unplanned system outages component should summarize the main unplanned system outages due to failures in different components of the system and the strategy that will be used to handle each. Each type of failure should be identified, its failure rate estimated, and the strategy for handling the failure identified so as to preserve the agreed upon level of system availability. Planned System Outages The planned system outages component should summarize the planned outages that are predicted to be needed for regular or routine system maintenance. Identify each type of planned outage and estimate the frequency and duration of downtime. Physical (Hardware or Network) Component Failure The physical component failure should focus on physical component failures, and the analysis should cover: Database Server Failure Application File Server Failure Network Failure Data Center Failure Client Desktop Failure Software Component Failure The software component failure should focus on software component failures, and should cover:
Database Software Application Software Software component failures should address these possible sources: User errors Operations (maintenance) staff errors Software bugs Lack of adequate database space management Maintenance Outages The maintenance outages component should describe the planned outage events that are required to perform some form of maintenance on the system. Examples of system maintenance events that this component should include are: Regular Database Maintenance Database Backups Database Tuning Database Space Management Software Maintenance Bug Patches Software Upgrade
Tools
Deliverable Template
Use the System Availability Strategy template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your system: Introduction Critical Systems Availability Unplanned System Outages
Oracle Method
Planned System Outages Physical (Hardware or Network) Component Failure Software Component Failure Maintenance Outages
Deliverable
The deliverable for this task is the Future Application Deployment document, which is a map for the future deployment of the applications.
Prerequisites
Required
You need the following input for this task:
G G G
The Architecture Strategy provides information about the strategies for the architecture work, including standards, business, and information system vision and rollout. Architecture Requirements (TA.030)
The Architecture Requirements document provides information about the high-level requirements for the architecture design, and covers various aspects of the application and technical architecture. Conceptual Architecture (TA.040)
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture and will indicate the approximate deployment of applications in this architecture model.
Oracle Method
G G
The Technical Architecture Baseline document provides information about the existing applications and any future changes to the information systems that may affect the architecture. Process and Mapping Summary (RD.050)
The Process and Mapping Summary provides information about the future business model, including business processes and mapping decisions made to date.
Task Steps
The steps of this task follow: No. 1. Task Step Review conceptual architecture. Review project rollout strategy. Create high-level application rollout map, if appropriate. Identify deployment of Oracle Applications needed to implement the final conceptual architecture across all data centers. Identify deployment of nonOracle applications needed to implement the final conceptual architecture across all data centers. Application Rollout Deliverable Component
2.
3.
4.
Application Deployment
5.
Application Deployment
No. 6.
Task Step Create application deployments for intermediate phases of a multi-phase rollout, if appropriate. Describe the assumptions made in creating the application deployment deliverable.
7.
Assumptions
Table 3-16
Oracle Method
to take into account rollout strategy across an enterprise, with intermediate stages where one or more data centers has converted to the new architecture, whereas others have not. This depends on the rollout and Program Management strategies adopted. Reference: Oracle Program Management Method. PGM Method Handbooks.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Business Analyst IS Manager
Table 3-17
% 85 15 *
Role Contribution for Define Future Application Deployment
Deliverable Guidelines
The Future Application Deployment deliverable helps you identify where in the business you will need to deploy your applications and supporting databases to support the architecture requirements and preferred conceptual architecture.
Oracle Method
Architecture team members will use the information to construct more detailed architecture designs for using the application deployment as a framework Business requirements mapping team members will use the information to help identify application integration points and custom interfaces Module design and build team may need the information to help specify and design customizations Production migration team will need to understand the application deployment when planning the migration process IS operations staff may use this as a reference to understand which applications will be installed where
Deliverable Components
The Future Application Deployment deliverable should contain the following components: Application Rollout The application rollout component should describe the high-level rollout of the applications. In the case of a simple, single phase project where all the applications will be deployed at the same time, this component of the deliverable will not contain much content and is optional. In a multi-phase project, this component should include the intermediate phases as milestones to the target end deployment. If possible, it should include a timeline of the rollout phases and a summary of the application deployment after each phase. Application Deployment The application deployment component should detail the future deployment of applications across the data centers within the scope of the architecture. It should include full and partial installs, as well as application versions where possible. For enterprise level projects that span multiple data centers, the component should include a detailed deployment map for each data center. If the project is multi-phase, each separate rollout phase should have a separate application deployment component.
Assumptions The assumptions component should detail any assumptions made in determining the application deployment. Examples of assumptions that may influence the deliverable include: Application releases or versions Impact/completion of ongoing IS projects Mapping work that is in process
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Does the content in the deliverable match the scope and description of the document in the introduction? Does the deliverable cover all data centers within scope? Does the deliverable cover all applications within scope? Are there diagrams summarizing the deployment?
Tools
Deliverable Template
Use the Future Application Deployment template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your business: Introduction Application Rollout Application Deployment Assumptions Application Deployment Selection of the Application Deployment component will prompt you to enter the number of the rollout phase for which you are creating a deployment. If you only have a single phase to your project, leave the
Oracle Method
Rollout Phase variable blank. If you have multiple rollout phases within your project, navigate to the Insert Boilerplate menu option and select the Application Deployment component for this deliverable as many times as you need. Each time you select it, you will be prompted for the rollout phase.
Deliverable
The deliverable for this task is a Reporting Strategy document.
Prerequisites
You need the following input for this task:
G G G G
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture and will indicate the approximate deployment of applications in this architecture model. Architecture Requirements (TA.030)
The Architecture Requirements document provides information about the high-level requirements for the architecture design, and covers various aspects of the application and technical architecture. Future Application Deployment (TA.070)
The Future Application Deployment document provides detailed information about the precise deployment of the applications in the new architecture. Information Access Model (BR.060)
The Information Access Model document provides information about the information access requirements in the architecture. It helps specify
Oracle Method
the information to which the various business organizations and sites need read (reporting) access.
Task Steps
The steps of this task follow: No. 1. Task Step Identify key operational reporting requirements. Identify key decision support requirements. Identify any special report distribution or storage requirements. Design systems to support operational reporting requirements. Design systems to support decision support reporting requirements. Design systems to support report distribution and storage requirements. Create a summary of the new reporting systems architecture. Deliverable Component Operational Reporting
2.
Decision Support
3.
4.
Operational Reporting
5.
Decision Support
6.
7.
Table 3-18
Oracle Method
enabling technology for this type of reporting, not the reporting category. It is usually more strategic in nature and can include: structured reporting across large volumes of historical data analytical (OLAP) style reporting to analyze and dissect business data to understand trends and relationships data mining to discover hidden trends in large volumes of historical data
sites, divisions, and business lines within a single application installation and database sites, divisions, and business lines across multiple distributed applications and databases different statutory and legal reporting requirements to satisfy local legislation and country laws integrated reporting across heterogeneous applications and databases, relational and nonrelational, legacy and third-party vendor packages Senior management may require long-term trend analysis of data for strategic decision support of: forecasting financial modeling and budgeting supply and distribution planning sales and marketing data mining You need to categorize the reporting requirements of different groups and business units within the enterprise before you attempt to propose solutions.
Oracle Method
presentation of the data in the report. However, you should consider the different components depending on the exact function and source of the reporting system. A separate reporting system will often be classified as an architecture subsystem. Data Warehouses A simple definition of a data warehouse is a subject-oriented corporate store of information sourced from one or more systems, applications, or databases. A data warehouse can be an enabling technology for both general categories of reporting. Hence you could envision an operational data warehouse containing consolidated operational data and having a technical design that supports the routine operational reporting needs of the business. More often though, a data warehouse contains a broad range and large volume of historical corporate data, and is the repository for decision support and analytical applications and systems. Data warehouse-based systems are a good example of an architecture subsystem that would be singled out as a standalone component of the overall information systems architecture. For more information, see Define Architecture Subsystems (TA.100). Reference: Oracle Data Warehousing Method, DWM Method Handbooks.
reporting database is a database that is a direct point-in-time copy of the transaction system for the purposes of reporting only. Reporting databases are a valuable technique for offloading processing from the transaction system without expending the resources and time of designing and building a specialized data warehouse or reporting system with a reporting-oriented data model. In order to be useful, there must be reporting groups within the enterprise that can perform their reporting on aged data (i.e., data that does not contain all transactions up to the immediate point-in-time). Increasing the refresh frequency for data in the reporting database can circumvent some of these problems, but it is usually not feasible or cost-effective to keep the data in a reporting database synchronized with the OLTP system in real-time. For more information, see Conduct Reporting Fit Analysis (BR.030). For general system capacity planning issues, see Develop System Capacity Plan (TA.170). Suggestion: If project timing makes this possible, you should collaborate with the business analysts who are performing the reporting fit analysis to determine whether there are groups that can report using aged data and whether the number of such users would significantly offload system resources from the OLTP database server. If the architecture tasks occur in advance of the report mapping task, you need to gather this information yourself, and provide it to the report mapping analysts.
Oracle Method
If you need to provide consolidated operational reporting across multiple installations of the same applications suite or across heterogeneous application products, you will need to consider some special mechanism to enable such organizations to consolidate data from multiple operational environments. The data can be consolidated in one of the applications or installations through the use of custom interfaces. You then perform consolidated reporting out of the consolidating application or instance. Reference: A good example of this requirement in Oracle Applications is the consolidation of general ledger (GL) data from different individual installations of Oracle GL into a Corporate Oracle GL system. Several papers have been published in OAUG conferences on this subject. For more information, see OAUG proceedings from conferences in 1994, 1995, and 1996. Another approach is to design an operational data store, which is an independent standalone database, but which may reside in one of the database instances corresponding to the separate application installations. The data store can be as comprehensive or complex as you wish. Operational Reporting Database If you have special security concerns for reporting users, or wish to offload report processing load to another server, you can use an operational reporting database. This type of reporting database is different from a data warehouse in that it is a direct copy of the transaction database, without a reschematization of the data taking place. When it is copied onto a separate database server, it also offloads processing capacity. Suggestion: If the business can tolerate daily downtime for operational reporting database refreshes, a Unix cold backup file copy mechanism is the simplest way to refresh the database.
creating an ad hoc query environment in which users can be productive requires investment of information systems resources. Do not assume that because you make a report or inquiry development tool accessible to the users that this automatically constitutes an ad hoc query capability that users will be able to use. The main problem is that a relational data model optimized for OLTP performance is not easily understood or decipherable by users. In order to facilitate the use of an ad hoc query tool you may have to create an environment that translates the OLTP data model into the form of business objects that a user understands. End-User Layer (Meta Layer) This technique adds a layer on top of the relational OLTP data model to present the data in the operational transaction system in the form of easily understood and familiar business objects, such as sales orders or purchase orders. You can build this layer on top of the OLTP database directly and allow ad hoc queries in the transaction environment, or you can add the layer to a direct copy of the transaction database that is mounted as a reporting database. Operational Data Warehouse Another type of system that you can use for ad hoc queries on operational data is an operational data warehouse. This type of data warehouse is different from the type that supports strategic reporting or analysis in that it supports operational reporting needs, it may only contain the most recent operational data, and it may not have the summarized views of data that provide a long-term strategic business view. The data in the warehouse is incremented on a regular basis and may be completely refreshed after a certain time period. The warehouse will usually have a report- or query-friendly data model, so programs need to be developed both to extract operational data from OLTP systems and to load data into the data warehouse. An example of where this might be useful is in the consolidation of order entry and point-of-sale information, where you might totally refresh the data every quarter or annually. Attention: A data warehouse where operational reporting is performed and data is refreshed from time-to-time is sometimes referred to as an operational data store to distinguish it from a true data warehouse, where data agglomeration is cumulative for historical analysis.
Oracle Method
Data Marts Data Marts are data warehouses that are smaller in scale than an enterprise data warehouse and are oriented more towards departmentlevel decision support. They may be organizational or functional slices of the complete data set in the enterprise data warehouse. Often they are installed on cheaper workgroup or departmental server machines, which provides a distributed, scaleable, secure environment for either decision support or analytical (OLAP) reporting.
Oracle Method
Intranet Web-based report publishing, where reports are converted into HTML format and can be browsed by users across the internal corporate network Suggestion: The OAUG conferences that take place twice a year usually have a number of presentations devoted to reporting techniques and tools to use with Oracle Applications. The proceedings that OAUG publishes from the conference papers are a valuable reference source of information.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Technical Architect Business Analyst Business Line Manager IS Manager
Table 3-19 Role Contribution for Develop Reporting Strategy
% 50 30 20 * *
Deliverable Guidelines
The Reporting Strategy deliverable helps you define the reporting systems that support reporting needs of system users within your new architecture.
Deliverable Components
The Reporting Strategy deliverable should contain the following components: Summary of Reporting Systems Architecture The summary of reporting systems architecture component should summarize the reporting systems in the future architecture and the functions and organizations they support. If possible, you should include a diagram showing the relationship between the reporting and transaction systems. Operational Reporting The operational reporting component should describe how you will satisfy the operational reporting requirements in the future architecture. If there are cross-application or cross-installation operational reporting requirements, you should describe how these will be met. Describe any special reporting databases needed, how they are to be populated and refreshed, and special reporting tools that users will need to query and report on the data. Decision Support The decision support component should describe how you will satisfy the decision support requirements in the future architecture. It should discuss the decision support system requirements in terms of which business functions and organizations need decision support capability, the domain of enterprise data they need access to, and the architecture of the systems that will support their information needs. You should describe the link to the transaction systems to show how the raw transaction data is gathered and loaded into the decision support systems. If a data warehouse is the intended enabling technology for decision support, you should describe its high-level architecture and usage here also. Report Distribution and Storage The report distribution and storage component should describe how the requirements in this area will be met by the information systems architecture. It should indicate how the architecture solution will satisfy the original goals for the distribution or storage solution, such as obviating the need to rerun reports multiple times, securing the business-critical report execution system from uncontrolled report requests, report self-service, and so on.
Oracle Method
Tools
Deliverable Template
Use the Reporting Strategy template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your systems: Introduction Summary of Reporting Systems Architecture Operational Reporting Decision Support Report Distribution and Storage
Oracle Express Analyzer Oracle Express Objects Oracle Express Objects Reference: Oracle Express Analyzer Reference Guide. Oracle Part Number A43987-1. Also see other Oracle Express product guides and manuals. Oracle Financial Analyzer Oracle Financial Analyzer is an enterprise solution for financial reporting, multi-dimensional analysis, budgeting, and planning. It is integrated with the operational Oracle General Ledger application and includes built-in capability for extracting data out of Oracle General Ledger and loading into the OLAP analyzer engine. Reference: Oracle Financial Analyzer Users Guide. Oracle Part Number A40616. Reference: Integrating Oracle Financial Analyzer with Oracle General Ledger, Version 1.0. Oracle Part Number A43475. Oracle Sales Analyzer Oracle Sales Analyzer is an OLAP-based application that enables a business to perform sales and marketing analysis and reporting. It uses the Oracle Application Data Warehouse as the enabling backend technology. Reference: For more information, you can look in the various guides and manuals that Oracle supplies as documentation to the Oracle Sales Analyzer products. Reference: Oracle Applications Installation Manual for Unix, Release 10.6 (Operating System and Release specific). Oracle Part Number A38153-1. Discoverer/2000 Tools The Discoverer/2000 products can also support some OLAP data manipulation functions, including summaries, data pivoting, and drilldown.
Oracle Method
Deliverable
The deliverable for this task is a revised and accepted Conceptual Architecture document.
Prerequisites
You need the following input for this task:
G G
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture and will indicate the approximate deployment of applications in this architecture model. This is the deliverable undergoing revision in this task. System Availability Strategy (TA.060)
The System Availability Strategy document provides information about the strategies used for providing the level of system availability the
Oracle Method
business needs. If there are special systems or architecturally significant components that will help to maintain the desired availability, this deliverable will contain information about them.
G G G G
The Future Application Deployment document contains details of the precise deployment of the applications in the future application architecture. Reporting Strategy (TA.080)
The Reporting Strategy document provides information about the systems strategies used for meeting the different reporting needs in the business. If there are special systems, applications, or architecturally significant components that provide the reporting capability, this deliverable will contain information about them. Process and Mapping Summary (RD.050)
If a Process and Mapping Summary document is in use in the project to document key process and mapping decisions, it will provide details of the future business model, including business processes and mapping decisions made to date. Information Flow Model (BR.050)
The Information Flow Model document provides details of the key information flows corresponding to the future business model and business processes. Understanding these information flows is an important part of the revision of the conceptual architecture, since they may not have been available when the initial conceptual architecture model was created and are the information flows that support the key business processes. The information flows may have implications for the candidate architectures and/or provide information about the complexity of key interfaces needed.
Task Steps
The steps of this task follow: No. 1. Task Step Review information gathered since creation of the Conceptual Architecture deliverable. Rework Conceptual Architecture deliverable, incorporating relevant new project information and decisions and update all affected components. Review revised conceptual architecture with project management (if applicable) or with select project team leaders. Secure acceptance for final conceptual architecture. Publish Conceptual Architecture deliverable to wider project team audience.
Task Steps for Revise Conceptual Architecture
Deliverable Component
2.
3.
4.
Management Acceptance
5.
Table 3-20
Oracle Method
of the revised conceptual architecture should be a formality. If, however, the new information to incorporate precipitates a rethinking of the architecture approach and strategy, you need to go through the same detailed review procedures that you went through for the initial conceptual architecture.
Examples of mapping requirements that would affect architecture include: changes in how business processes will map onto application functions or onto different applications changes in key business processes based on better understanding by the mapping teams of the way the package applications support specific business functions definition of the Information Flow Model for the movement of information and data within the business decisions about key application setup parameters such as sets of books or inventory organizations extension to the package application security capability to support special application-level security requirements identification of a critical and complex interface that affects the functioning of a major part of the new system For more information about the mapping process and tasks, see the Business Requirements Mapping process. Application and Technical Architecture (TA) Tasks The completion of the following application and technical architecture process tasks provides more detailed information that may affect the Conceptual Architecture: Conduct Technical Architecture Baseline (TA.050) Define Future Application Deployment (TA.070) Develop Reporting Strategy (TA.080) Develop System Availability Strategy (TA.060)
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect % 35
Oracle Method
Role Technical Architect Business Analyst Project Manager IS Operations Staff IS Manager Project Sponsor
Table 3-21 Role Contribution for Revise Conceptual Architecture
% 35 20 10 * * *
Deliverable Guidelines
You use the original Conceptual Architecture deliverable you created for a prior task to record the changes to the architecture. Detail the changes between the original architecture and the revised architecture and document the reasons for the changes. Your documentation of the changes and reasons should be in proportion to the number and extent of changes you need to make. If you need to completely rework your architecture model and revert back to one of the originally unfavored candidate conceptual architectures, your documentation of the changes and the reasons will need to be correspondingly more thorough.
Tools
Deliverable Template
Use the original Conceptual Architecture deliverable to record the changes to the Conceptual Architecture. To secure final acceptance of the Conceptual Architecture key deliverable, use the Acceptance Certificate component of the original template.
Deliverable
The deliverable for this task is the Architecture Subsystems document, which identifies the set of architecture subsystems that need to be incorporated into the architecture.
Prerequisites
You need the following input for this task:
G
The Revised Conceptual Architecture document provides a high-level view of the favored future application and technical architecture, and will indicate any architecture subsystems that might be required for the new architecture.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Identify components of the conceptual architecture that are architecture subsystems. Document each subsystem separately in your deliverable. Gather any further requirements or details you need to complete the analysis of each subsystem. Complete the description and specification of each subsystem. Identify possible approaches for developing or acquiring each subsystem. Subsystem Description Subsystem Description Deliverable Component
2.
3.
4.
5.
Subsystem Description
Table 3-22
global data registry subsystems that distribute key reference business objects across an enterprise (and would need a data distribution subsystem) operational data repository that is synchronized to provide realtime information about the state of business (and would need a data distribution subsystem) a critical third-party application package that needs to integrate with multiple transaction systems at the enterprise level data warehouse receiving input from multiple transaction systems electronic commerce system that processes multiple types of inbound and outbound business documents and transactions intranet interface to application systems for use by business users across the enterprise Typically these types of subsystems are only important in larger scale projects, but the concept of a non-localized, enterprise-level component to an architecture, affecting multiple applications, interfaces or databases is entirely general. The example of the synchronized operational data repository above illustrates the lack of a hard and fast definition of architecture subsystems. In some projects, an interface to a critical third-party application product may be specified and managed within a general interfaces development team. In reality, some interfaces are more complex and stringent in their requirements than others, and the thirdparty application which they link may be tightly integrated into many of the functions in the core application suite. Development of infrastructure to support such interfaces is often better managed in a separate development subproject, where there is visibility to the impact on the overall systems architecture. Because of the possible impact of these subsystems on the overall systems architecture and on multiple individual technical groups working in the project, and because of the risk associated with such complex custom development, it is often prudent to separate the specification, design, and build of these systems into separate subprojects linked to the core Application and Technical Architecture process. Therefore a subsystem may be synonymous with a development subproject, but not necessarily.
Oracle Method
Buy or Build?
The applications or infrastructure components that are classified as architecture subsystems may be sold by package application or system vendors. For example, it is possible to purchase a predefined and built application data warehouse from Oracle that will integrate with Oracle Applications transaction systems. It is also possible to purchase messaging systems that can provide the data transport infrastructure to intelligently link applications together, thereby removing some of the development overhead in creating complex interfacing mechanisms to transfer data between multiple databases. Once the need for an architecture subsystem has been established, the information systems department of the business is then faced with the inevitable buy-orbuild decision. Even if the subsystems components are purchased as prebuilt packaged applications, there may still be significant integration work needed to integrate them.
the degree of sharing of customers and vendors across separate instances is limited, so you may still need a data registry mechanism. Attention: Make sure that you are familiar with the precise functionality and capability of the application release you are implementing before assuming the existence or non-existence of a critical piece of functionality. Reference: Oracle Applications Installation Manual for Unix, Release 10.6 (Operating System and Release specific). Oracle Part Number A38153-1. A data registry can be implemented as a set of database synonyms to one physical table. However, performance requirements may impose restrictions upon cross-instance transactions, especially where the individual instances of an application are physically separated in different databases, linked by a wide area network. This implies that some form of data copying mechanism or replication should be used so that applications can access a local copy of the global data registry. In addition, large companies frequently have many custom and third-party applications that also need access to the global data registry. In this case, it may be more appropriate to specify a custom data model for the business object in the data registry, so that it can record the values of the superset of attributes needed for all Oracle and non-Oracle application data models. Reference: Dettmar, Cedric. Global Data Registries. OAUG Conference Proceedings, Spring 1995.
Oracle Method
reporting data warehouse that is refreshed asynchronously, and maybe only once a day.
the interface synchronizes data across more than two separate databases
Oracle Method
that stores transaction data from multiple different transaction systems over many financial periods. A data warehouse, or decision support system, is a common standalone architecture subsystem that you might custom develop or perform custom integration on.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Technical Architect Team Leader - Architecture Project Manager IS Manager
Table 3-23 Role Contribution for Define Architecture Subsystems
% 30 30 20 20 *
Deliverable Guidelines
This deliverable identifies the requirements for any architecture subsystems you may need as part of the future information systems architecture. Document each subsystem as thoroughly as possible, but keep the discussion to a high level, describing how the subsystem fits into the overall system architecture, how it satisfies any particular
architecture requirements or policies, and what the possible approaches are for developing or acquiring the subsystem, assuming it does not currently exist. If a candidate system does already exist in the application and technical infrastructure, you can discuss how the system may support the identified needs of the new architecture and what extension work might be necessary for the existing system.
Deliverable Components
The Architecture Subsystems deliverable should contain the following components: Subsystem Name Create a separate component for each subsystem that you identify in your architecture with a title of the subsystem name. For each separate subsystem component, you should describe the subsystem requirements, the high-level integration of the subsystem into the architecture (including a diagram), and suggested approaches for custom development or purchase of the subsystem from an application vendor.
Tools
Deliverable Template
Use the Architecture Subsystems template to create the entire deliverable or specific sections of the deliverable. Choose from the following list of sections and modify the content as needed: Introduction Subsystem Name Data Registry Subsystem The template is organized by subsystem, so that there is one subsystem per major section of the deliverable. Individual subsections discuss different aspects of each subsystem. Subsystem Name If you select this component, you will be prompted for the name of the subsystem you wish to describe. If you need to add additional
Oracle Method
subsystems to your architecture (that are not covered by the Data Registry Subsystem template component) navigate to the Insert Boilerplate menu option and select the Subsystem Description component for this deliverable as many times as you need. Each time you select it, you will be prompted for the Subsystem Name. Suggestion: If there is only a single subsystem in your architecture, reorganize your deliverable template and elevate each subsection within the subsystem component to a major section (Heading 2 Style in the Microsoft Word Template). Data Registry Subsystem Use this component if you potentially need a data registry subsystem as part of your architecture. You will need to complete the subcomponent parts of the data registries component: Background Data Registry Requirements Data Registry Integration Diagram Suggested Approaches
Deliverable
The deliverable for this task is an Architecture Subproject Proposal document for each architecture subsystem, component and technical area that is most suitably managed within a separate subproject.
Prerequisites
You need the following input for this task:
G
The Architecture Subsystems document will discuss the high-level specifications of the subsystems for which you may wish to propose architecture subprojects. Whether you choose to propose an architecture subproject for the custom development or integration of the subsystems will depend on your exact project and implementation circumstances.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Identify architecture subsystems that need to be developed or integrated and are candidates for management as subprojects. Create a proposal for each architecture subproject. Submit proposals for review by project management and sponsors if appropriate. Instigate architecture subsystem development subprojects.
Task Steps for Propose Architecture Subprojects
Deliverable Component
2.
3.
4.
Table 3-24
Subproject Proposals
Undertake the task of creating proposals for architecture subprojects after consultation with the project manager. Prior discussion with the project manager enables you to elaborate in detail on the request for the creation of the subproject and the reason why a subproject may be
appropriate for managing the development of a critical and separate piece of the systems architecture infrastructure. Depending on the project circumstances and the nature of the business environment, you may not need to create a formal proposal or justification for the subproject; a simple statement of work may be sufficient. However, the mechanism for initiating the subproject should communicate the need for a subproject structure that recognizes the critical nature of the architecture component the team will develop, and the need for close collaboration with business analysts. The proposed subsystem may be mission-critical in nature and essential for the overall project to cut over into live production. It may also require especially stringent standards for development and testing procedures. Once a subproject proposal is accepted, it should be planned and managed according to the standards and guidelines in Oracles Project Management method. For more information see: Reference: Oracles Project Management Method, PJM Reference Handbooks
Role Contribution
The percentage of total task time required for each role follows: Role Team Leader - Architecture Project Manager IS Manager
Table 3-25 Role Contribution for Propose Architecture Subprojects
% 80 20 *
Oracle Method
Deliverable Guidelines
The Architecture Subproject Proposal deliverable is the means by which you propose the creation of new architecture subprojects to the project managers (and sponsors, if necessary). Develop the deliverable as a proposal for managing the detailed design and build work necessary for an architecture subsystem. The deliverable should contain estimates of the resources required, milestones, and justification for creating the subproject. If the proposals require a formal review and sign off, you need to make them more comprehensive.
Deliverable Components
The Architecture Subproject Proposal deliverable should contain the following components: Executive Summary The executive summary component should summarize the entire proposal for executive consumption. Introduce the architecture subproject you are proposing and then describe its scope, the approach you will adopt, assumptions, project schedule and project organization. You should include enough information for an executive or project sponsor to sign off on the proposal, but not so much as to defeat the need for brevity. Background and Problem Statement The background and problem statement component should identify the circumstances in the architecture project that led to the identification of the need for an architecture subproject, and the architecture gap or problem which the subproject intends to solve. Goals and Objectives The goals and objectives component should describe precisely 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. Scope The scope component should describe the scope of the architecture subproject in as much detail as possible. In this case, the architecture
subproject scope statements can be made in terms of the particular architecture subsystem you need to design and build or purchase and integrate. In addition to discussing the scope, this component should also include a description of the key process milestones, the constraints to which this subproject will be subject, assumptions and risks, and the relationship of the subproject to other architecture projects and/or to the main implementation project. Approach The approach component should describe the method to be used for the development of the subsystem or architectural component solution, the benefits of the solution, and the project deliverables. Assumptions The assumptions component should describe any key assumptions that you have had to make in formulating the architecture subproject and the proposal. The assumptions may include cost, project timeline, interdependencies with other subprojects, resources, technical architecture direction, business requirements, and so on.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Are the project scope and objectives clearly identified? Are specific critical success factors and risks documented? Does this document take into account the impact of dependent projects? Are the architecture subproject requirements clearly defined?
Tools
Deliverable Template
Use the Architecture Proposal template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your project circumstances:
Oracle Method
Executive Summary Background and Problem Statement Goals and Objectives Scope Approach Assumptions Attention: The extension of the architecture process to include separate subprojects is subject to change management control, and you should follow the standards in the quality plan in proposing what might be a change to the project scope. The proposal template is only intended to be a sample and does not conform to the rigorous standards that often exist in businesses for the proposal and acceptance of new subprojects, where there may need to be separate project management, work management, and possibly separate finance arrangements from the main implementation project. If your organization or business has specific, agreed upon practices for this situation, you should follow those practices and use the approved document standards.
Deliverable
The deliverable for this task is an Application Security Architecture document. This deliverable will be highly dependent upon the nature and functionality of the applications being implemented.
Prerequisites
You need the following input for this task:
G G G
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture and will indicate the approximate deployment of applications in this architecture model. Architecture Requirements (TA.030)
The Architecture Requirements document provides information about the high-level requirements for the architecture design, and covers various aspects of the application and technical architecture. Specific high-level architecture requirements may need consideration when you design the security architecture. Information Access Model (BR.060)
The Information Access Model document provides details of the key information access requirements for the business organizations in the future business model. This document represents the organization-level analysis of the security requirements of the business and is a direct source of input for the design of the security architecture.
Oracle Method
G
If a Process and Mapping Summary document is in use in the project to document key process and mapping decisions, it provides details of the future business model, including business processes and mapping decisions made to date. The process and mapping decisions may include discussion of security requirements.
Task Steps
The steps of this task follow: No. 1. Task Step Review security requirements derived from other tasks and deliverables. Review security-related requirements and decisions uncovered in the mapping process. Map security requirements onto standard application functionality and identify requirements not met. Design high-level database security configuration and implementation. Design high-level application security configuration and implementation. Create detailed database security design. Create detailed application security design. Application Security Mapping Deliverable Component
2.
3.
4.
5.
6.
7.
No. 8.
Task Step Review design approach with application mapping and module design and build teams.
Deliverable Component
Table 3-26
Oracle Method
Mapping process typically takes this approach and is concerned with identifying the different types of roles for the new business system and the menus, forms, reports, and batch programs to which each role or user can gain access. It usually has less impact on the basic architecture of the applications than organization-based security. For more information, see Design Security Profiles (BR.120). Business Organization-Based Security This type of security analysis is oriented towards securing the data for a particular business organization or user group. Unlike the Function- or Role-based security, this area typically deals with securing data for organizations as a whole and not just for individuals or roles within an organization. Often, business organizations may be creating rows in the same tables in a database, but do not wish other organizations to be able to view or transact their data in the same table. The division between this approach to security and the Function/Role-based approach is not hard and fast, and it may be possible to satisfy the business organization-based security requirements by judicious use of function/role-based security and the standard application features that support it. The design work in this task may include both function/role-based security and business organization-based security. Generally the details of the function/role-based security are not architecturally significant and are best handled in the Business Requirements Mapping process. The business organization-based security can have architectural significance and should be handled here. If requirements are met using function/role-based security, mention them in the application security architecture design for a complete view of the solution, but refer to the mapping process for details.
Use standard application features that provide organizationbased security. Use standard application function/role-based security to provide the effect of business organization-based security. Use procedures and policies to provide the security. Use limited custom extensions to application modules. Use general database-level custom extensions. Use separate application installations. Many security requirements may be met using standard application features. Before exploring more complex options, be sure to identify the security requirements that can be met by standard application security features for both function/role-based security and organization-based security. The cost and extra risk of custom security mechanisms may force a rethink of whether a particular security requirement is really needed. Attention: In Oracle Applications, you can use various features to meet function/role-based security requirements, such as custom menus, responsibilities and profile options, or report security sets. For more information about the security options in Oracle Applications, consult the System Administrator manuals. Mechanisms for handling the business organization-based security requirements will most likely be related to application-specific setup parameters, such as GL Sets of Books, Subledger Operating Units, Inventory or HR Organizations. If you can map the secure business organizations to these types of setup parameters, you may be able to use the built-in security mechanisms. Reference: Oracle Applications System Administrator Reference Manual, Release 10. Oracle Part Number A12540 Reference: Oracle Applications System Administrator Guide, Release 10SC. Oracle Part Number A23416.
Oracle Method
If the number of data entities that require security is large, there may be many potential permutations of access requirements for each organization, depending on the function being performed. Make sure you limit the actual number of secure ORACLE usernames to a reasonable number. Referential integrity issues may exist between secured and nonsecured entities with foreign keys that require special handling. For business objects with multiple physical tables (e.g., order headers and order lines), you should carefully analyze business processing requirements to determine under what circumstances secure data may be accessed, and make sure that any conflicts between secure and non-secure entities are properly handled. Generally, creating database extensions incurs more risk, and this is particularly true when the custom extensions create a number of custom-secured tables in the database. Careful design is necessary to mitigate this risk, followed by extensive testing. Work closely with the business and technical analysts to draw up comprehensive test plans. Also feed this design work back into the Business Requirements Mapping process.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Business Analyst Technical Analyst
Table 3-27
% 60 30 10
Deliverable Guidelines
This deliverable describes the database and application-level configuration required to implement your security requirements. The Application Security Architecture document should identify the following information: mapping of security requirements to standard features, including gap definitions and solutions the application security configuration, describing approaches that will be used to support the security requirements the database security configuration and use of standard application database security features or modifications to the standard database organization to support the security requirements
Deliverable Components
The Application Security Architecture deliverable should contain the following components:
Application and Database Security Approaches The application and database security approaches component describes the approaches you can use for architecting data-level security for the applications you are implementing. Application Security Mapping The application security mapping component should discuss the mapping of the security requirements to the standard functionality and features of the applications. If the business requirements mapping team has done this already, summarize their findings and identify gaps that may require a more complex architecture solution. Application Security Configuration The application security configuration component should discuss the security requirements that are met by standard functions and setups of the applications and the effect that the requirements will have on the application mapping and setup. Application Security Design The application security design component should discuss the security requirements that will be met by design of custom extensions to the applications. Database Security Configuration The database security configuration component should discuss the security requirements that are met by the standard application database partitioning and logical structure, and should relate this to the Application Security Configuration. Database Security Design The database security design should discuss the security requirements that will be met by design of custom extensions to the database.
Oracle Method
Tools
Deliverable Template
Use the Application Security Architecture template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your security architecture design: Introduction Application and Database Security Approaches Application Security Mapping Application Security Configuration Application Security Design Database Security Configuration Database Security Design
Deliverable
The deliverable for this task is the Application Functional Architecture document. The deliverable will be very dependent upon the nature and functionality of the applications being implemented.
Prerequisites
Required
You need the following input for this task:
G
The Application Security Architecture document provides details of the security requirements for the architecture and the way the architecture will accommodate them. The organization-based security requirements may use the built-in application functionality to secure and partition data, and this may affect the values of some of the critical setup parameters, and hence the overall functional architecture.
Oracle Method
G G
The Future Application Deployment document contains details of the precise deployment of the applications in the future application architecture. Financial and Operating Structure (RD.010)
The Financial and Operating Structure document provides information about the company financial hierarchy, the business organizations, and the functions the organizations perform.
Optional
You may need the following input for this task:
G G
If a Process and Mapping Summary document is in use in the project to document key process and mapping decisions, it will provide details of the future business model, including business processes and mapping decisions made to date. Application Product Reference and Implementation Manuals
The application product reference and/or implementation manuals should contain information about the key application setup parameters and their effect on the functional architecture and behavior of the applications.
Task Steps
The steps of this task follow: No. 1. Task Step Review business requirements and mapping information to establish values of parameters already specified. Deliverable Component
No. 2.
Task Step Establish list of sets of books needed for the implementation and map their interrelationship. Establish list of inventory organizations needed for the implementation and map their interrelationship. Establish list of human resources business groups and organizations needed for the implementation and map their interrelationship. Create the integrated business architecture for the finance, manufacturing, distribution and human resources functions of the business. Map the integrated business architecture to the detailed business functions of finance, manufacturing, distribution, and human resources functions. Review application functional architecture with business analysts.
3.
Inventory Organizations
4.
5.
6.
7.
Table 3-28
Oracle Method
that it is compatible with the overall application and technical architecture. Hence this task requires a high-level view of the detailed mapping work from an architecture standpoint. The task requires the identification and mapping out of the key application setup parameters and the major application system functions to ensure that the overall mapping of the parameters and functions is appropriate for the business processing requirements, but is also compatible with the application architecture envisioned for the new system. The application architect will gather information about the different mapping decisions made within the mapping process, establish the key parameters and functional areas affecting architecture, and map out the high-level interrelationship. Attention: The application architect carries primary responsibility for this task and needs to be experienced and knowledgeable about the application architecture and functionality of the application release and application products being implemented in the project. The application architect must make decisions on how to implement the application and architecture to support the application functional architecture and the data distribution strategy developed in the conceptual architecture. These decisions require a knowledge of the fundamental technical architecture of the applications, and may also require a highlevel understanding of the key business processes involved in different operations and business functions.
the application database. These parameters may affect the internal applications architecture, security, interfaces, application database configuration, and logical partitioning of the data in the database. There are usually tradeoffs to consider in determining how best to configure these parameters. The functional architecture of the applications varies from release to release of the applications, so it is important that you be aware of the functional behavior for the release that you are targeting for your implementation. Attention: The latest Oracle Applications 10SC release has had relatively little effect on the internal data partitioning and fundamental architecture of the application products. The important enhancements in functional behavior are related to the point releases of the Oracle Applications products and are more dependent on the data management and server-side code.
Oracle Method
impact of the mapping on the overall architecture and processing of the system. Consolidation and Communication of Designs The other key reason for performing this task is to consolidate and document the overall application architecture, as well as to communicate it to the entire project team. The application architecture design is a key piece of information for most of the separate processes in an implementation project and should be communicated to the team so that everyone understands the framework that they should be designing for or working within.
The detailed approaches and concerns for this task are closely related to the application products you are implementing, and the remainder of the discussion in this section assumes you are implementing Oracle Applications.
Oracle Method
Reference: Oracle Applications Inventory Reference Manual, Release 10.6. Oracle Part Number A12861-3. HR Business Groups and Organizations An HR Business Group is the largest HR organizational unit you can define to represent your company, enterprise or corporation. It contains all employee and payroll records that you enter into the Oracle HRMS system. You can define organizational hierarchies within a Business Group to represent reporting lines and security hierarchies.
financial subledger products along with Oracle General Ledger Oracle Manufacturing products a corporation with multiple legal entities that consolidate within Oracle General Ledger multiple legal entities with different functional currencies application products within multiple separate data centers with separate applications databases A key decision you need to make in the financial architecture of your implementation is whether to use multiple sets of books for multiple legal entities with the same functional currency, or to manage them within a single set of books and use the balancing chart of accounts segment to denote the different legal entities. This decision should reflect: security requirements in Oracle General Ledger handling of intercompany transactions in Oracle General Ledger consolidation process in Oracle General Ledger security requirements in associated subledger and manufacturing products use of accrual and cash-based accounting specific functionality requirements in financial subledger and manufacturing applications These are examples of factors that influence the functional architecture of implementations and are not necessarily a complete list. Warning: The details of the sets of books architecture depend on the specific release of the applications you are implementing. Determine the specific functional capabilities of the application products and releases you are implementing prior to attempting the application functional architecture. Reference: Oracle Project Accounting Implementation Manual, Release 10. Part Number A13402. Reference: Oracle Manufacturing Implementation Manual, Release 10, Volume 2. Part Number A17006.
Oracle Method
where you could fulfill the business requirements with one or multiple inventory organizations. Again, like the sets of books architecture, it is important to consider all the repercussions of your decision rather than the narrow business requirement. You can create an initial architecture for the inventory organizations by mapping the existing manufacturing plants, warehouses, and distribution centers onto inventory organizations. You need to perform this mapping while also bearing in mind the requirements for the master inventory organization. You can then identify the ramifications of the initial architecture and refine it based on common manufacturing or distribution practices and business processes, data sharing or security requirements, and implications of the architecture for revenue and financial processing in the ledgers. The latter is an important consideration that you must not ignore. Although the sets of books and inventory organizations setup parameters have been discussed separately here, they are mutually interdependent and must be considered together in a full analysis of the application functional architecture. The complexity of the inventory organization architecture will increase with the implementation of the following elements: distribution and/or financial products along with Oracle Manufacturing products a business with multiple manufacturing/distribution units that have different business practices or manufacture different finished goods a business that has a tightly integrated supply chain with other external trading partners a corporation with multiple legal entities, some of which own inventory and generate revenue application products within multiple data centers with separate applications databases A key decision in the manufacturing and distribution architecture of your implementation is whether to use multiple inventory organizations to represent the manufacturing and distribution functions of your business, or to use a single inventory organization with multiple subinventories. This decision should reflect the following possible features:
Oracle Method
security requirements for transactions generated by your manufacturing business units costing methods and rules for different business units multiple manufacturing calendars handling of in-transit inventory and drop shipments forecasting details planning methods handling of common parts across different business units (e.g., different units of measure, costs, lead times, cycle count tolerance, and so on) consignment inventory or external supply-chain requirements This is only a selection of the factors that influence the functional architecture of implementations and not necessarily a complete list. Warning: The details of the inventory organization architecture are very dependent on the specific release of the applications you are implementing. You should determine the specific functional capabilities of the application products and releases you are implementing prior to attempting the application functional architecture.
Operating Unit An operating unit is an operational business unit that performs one or more of the following business functions: Accounts payable Accounts receivable Revenue accounting Order management Customer service Purchasing Receiving This corresponds to a business unit that will have access to, or transact against, one or more of the following Oracle subledger or distribution applications in release 10.6: Receivables (AR) Purchasing (PO) Payables (AP) Order Entry (OE) Cash Management (CE) Sales and Marketing (AS) Service (CS) (The multi-org capability will be added to Projects (PA) in a future release.) You implement the operating unit as a classification of an inventory organization. Reference: Multiple Organizations in Oracle Applications, Oracle Part Number A43688.
Legal Entities
The relationship between a balancing entity and a legal entity is not enforced within release 10.6 of the applications, but is implied by the
Oracle Method
precise setup of the parameters. The concept of the legal entity is not used widely in standard reports and transactions in release 10.6; instead, legal and tax reporting continue to be done through the existing mechanism of reporting based on the balancing segment. This may change in future releases of the applications.
Operating Units
The operating unit parameter provides a means to define secure business units within the Oracle Applications products mentioned above. It does not directly affect the architecture of the manufacturing application products, but has an indirect impact because the manufacturing products communicate with, and transfer data to and from the subledger and distribution products. If you are implementing Oracle financial or distribution products along with the manufacturing products, you need to ensure that the functional architecture of the manufacturing part of the business is properly aligned with the financial and distribution functional architecture. The operating units are also important because of new cross-business unit buying, selling, and shipping functionality in the multi-org architecture. Different business units (that may be in different legal entities) can buy, sell, and ship product from, or on behalf of, each other. A new intercompany accounting process generates the payables and receivable invoices that result from the cross-legal entity transaction. You implement this functionality at the operating unit level, and the need for this capability within the business will be an important factor in the definition of the operating units.
within HR. Make sure that the same organization is correctly defined for the integrated functional architecture. If you are sharing other classifications of organizations in the HR organization hierarchy with financials and manufacturing, it is again important to ensure consistency of operation. HR employee data is also referenced within the financial and manufacturing products, such as Oracle Purchasing and Engineering. If you plan to create an HR functional architecture with multiple business groups, this may have implications for the ability to view employee data within the financial products. Reference: Oracle Human Resources Implementation Manual, Release 10. Oracle Part Number A13130.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Business Analyst
Table 3-29 Role Contribution for Design Application Functional Architecture
% 60 40
Deliverable Guidelines
The Application Functional Architecture deliverable helps you develop the functional architecture for each application installation site (data center) in your architecture. If you have a distributed data implementation of the applications, complete the relevant functional architecture deliverable sections for each site, data center, or separate installation.
Oracle Method
distribution functional architecture. However, because you may still need to share some of the setup parameters across business functions (e.g., the parts master), you may not be able to totally disregard the manufacturing and distribution sections of the deliverable. You may also need to consider the human resources business group(s) that you create to store the employee data, which is shared with other applications.
Deliverable Components
The Application Functional Architecture deliverable should contain the following components: Introduction The introduction component should describe the purpose of the deliverable and list the key application setup parameters that affect the architecture of the application deployment and the partitioning of data in the application database. Application Setup Parameter Description This is a repeating deliverable component, one for each key application setup parameter, that should describe the functional architecture of the applications being implemented in relation to the parameter. Integrated Application Business Architecture The integrated application business architecture should describe the relationship between the key setup application setup parameters, and relate them to the financial and operating structure of the business. Integrated Application Functional Architecture The integrated application functional architecture should describe the relationship between the key setup application setup parameters, and relate them to the main business functions.
Tools
Deliverable Template
Use the Application Functional Architecture template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your design: Introduction Sets of Books Inventory Organizations Human Resources Business Groups and Organizations Integrated Application Business Architecture Integrated Application Functional Architecture Template Examples The template is based directly on functional architecture of Oracle Applications and uses Oracles terminology. The example in the Integrated Application Business Architecture section shows an Oracle multi-organization business structure with sets of books, legal entities, operating units, and inventory organizations. If you are not implementing the multi-org architecture, you may not need to show the operating units on your architecture. However, you may wish to retain the legal entities that you would implement as balancing entities within the chart of accounts, rather than as Oracle organizations with a classification of legal entity. If you are implementing human resources as well, you need to find a way to represent the HR organizations in the manufacturing and financial business architecture. This may require a separate diagram. The example in the Integrated Application Functional Architecture shows just the set of books and inventory organizations across application products (business functions). If you are implementing a multi-org architecture, you need to show the operating units and legal entities also in the same kind of diagram.
Oracle Method
Deliverable
The deliverable for this task is the Logical Application and Database Architecture document. The deliverable is 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.
Prerequisites
You need the following input for this task:
G G
The Application Functional Architecture document provides information about the key critical setup parameters and system functions that affect the precise application and technical architecture of the application installations. Application Security Architecture (TA.120)
The Application Security Architecture document provides details of the security requirements for the architecture and the way the architecture will accommodate them. The architecture will include the definition of key setup parameters necessary for application security and any custom extensions needed to meet extra security requirements beyond what is provided by the base applications.
G G
The Customization Strategy document provides information about the standards for implementing custom extensions that require new application code modules and database objects. Follow these standards in designing file tree structures and database configurations. Future Application Deployment (TA.070)
The Future Application Deployment document contains details of the precise deployment of the applications in the future application architecture across data centers and installations.
Task Steps
The steps of this task follow: No. 1. Task Step Review the design standards for creation of custom code and database objects. Review the standard installation architecture for the package applications you are implementing. Summarize the salient points about the application and database instances within the data centers. Identify the individual installations of applications you need within the data centers. Document the application file structures for each installation. Logical Architecture Summary Deliverable Component
2.
3.
4.
Application Installations
5.
Application Installations
Oracle Method
No. 6.
Task Step Identify how the business organizations will access the different application installations. Define logical database instances and map to application installations. Design the project application development environment if it is within the scope of the architecture project.
7.
8.
Table 3-30 Task Steps for Design Logical Application and Database Architecture
Application Installations
An application installation consists of one or more of the following components: application code files on the database server
client code files that reside on one or more application file servers client code files that reside on the user desktop machines database with its associated logical structure and objects You will need to include the application file structure for both the client code and the server code in your logical architecture design. Attention: If you are implementing the older character mode Oracle Applications Release 10 in an application client-server configuration, you may need to consider the SQL*Forms version 2.3 module files that reside on the application client machines. These application clients are unlike user desktop PCs in that they typically handle the SQL*Forms 2.3 client processing for multiple user logins and are often Unix platforms. As 10SC becomes more widespread, the desire for this type of application client to process the old character mode SQL*Forms 2.3 interface will disappear. For more information about these client-server configurations, see the Overview to the Application and Technical Architecture process.
Oracle Method
Single Vanilla Installation, No Custom Extensions This installation will typically apply to smaller, less complex, fast track implementations where you are not customizing or extending the applications. In this case, generally all you need to do for this task is to document the vanilla installation structure of the file code trees on client and server machines, as well as the database logical architecture, for future reference by the technical architect for physical database design and capacity planning and for reference by the IS organization and staff. Installations with Custom Extensions This is the more usual situation in package application implementations, where new extension components have been designed and built to be part of the overall solution. The application file structure contains custom modules and the database will have custom objects, both of which necessitate extra design work to isolate the custom file modules or database objects from the base installed database files and objects. The Customization Strategy may already have the strategy outlined for this; if not, you should include the design of any extra schemas you might need. Other factors that may contribute to the complexity of the logical applications database design are: multiple distributed applications databases specific applications functional architecture (e.g., implementation of Oracle Applications multi-org releases) custom reporting systems (e.g., End-User Layers that reschematize the OLTP database and present the data to users in an intuitive business object format for ad hoc reporting) implementation of multilingual requirements Attention: In release 10.6 of Oracle Applications, the logical database architecture has changed compared to prior versions. The database has a new standard schema installed, usually labeled the APPS schema, which is used to partition the objects in the application database. The APPS schema contains all code objects, while the regular applications schema contain the data objects. The APPS schema has grants and synonyms (and hence visibility) to all data objects in the individual application schemas.
Attention: This new logical database architecture will help the quality and robustness of patches and upgrades by ultimately minimizing the complex web of grants between the application schemas and will provide other additional benefits, such as the ability to attach any form or form function to any menu. Every applications customer will have all database objects, seed data and schemas for all products installed in the future, regardless of use. This will lead to a standardized database architecture for all applications installations.
Oracle Method
Generally you cannot mix an Asian multibyte language, English, and another language on the same platform (and hence Oracle database). Other language permutations may not work. These are only general rules to show the extent of the problem and are not guaranteed to give the affirmative or negative answer for the particular hardware platform on which you want to install your application database. Attention: Always check with the appropriate hardware product line at Oracle for the availability of a codeset that supports all languages you want to support in your applications database. You can do this through your Oracle Project Manager or through Oracle Worldwide Support.
Translated Data There may be issues with the specific support for data entry in applications in different languages. Lack of support in base application products for the multiple language entry can create extra complexity in the logical architecture. Attention: Oracle Corporation supplies translated versions of the application forms and reports in many foreign languages as standard, but the functionality in the products does not support the entry and display of the same data element in multiple languages. For the latter requirement, Oracle Services has partnered with Oracle Applications development to offer a standard release 10 consulting solution. This solution is called Release 10 Multi-Lingual Support (MLS). You can obtain more information on the Release 10 MLS solution from your Oracle Project or Account Manager.
Role Contribution
The percentage of total task time required for each role follows: Role Application Architect Technical Architect Database Designer Technical Analyst Production Database Administrator % 40 30 10 10 10
Table 3-31 Role Contribution for Design Logical Application and Database Architecture
Deliverable Guidelines
The Logical Application and Database Architecture deliverable helps you document the blueprint for the new application and database deployment architecture. You detail the installations of applications and databases in all affected data centers, and the logical structure of the databases you will install. Remember that this document is important for all the technical aspects of the project, so ensure the accuracy and appropriate level of detail.
Oracle Method
custom developed applications built using Oracle tools and database custom developed architecture subsystems that are part of your new architecture custom developed applications built using another vendors tools and database legacy applications that you will retain in the new architecture packaged applications purchased from other vendors
Deliverable Components
The Logical Application and Database Architecture deliverable should contain the following components: Logical Architecture Summary The logical architecture summary component should summarize the general characteristics of the application installations and the database architecture across all the data centers within the scope of the architecture process. If possible it should also include a diagram. Application Installations The application installations component describes the individual application installations in the future logical architecture. If there are multiple data centers to consider, you may create a separate subcomponent describing the installations for each data center. Organization Access to Installations The organization access to installations component describes the access requirements to the individual application installations and databases by the various business organizations. It should indicate any crossinstallation access by privileged business organizations. Logical Database Architecture The logical database architecture component should describe the logical architecture of the databases within the overall system architecture. It should include a listing of the database instances in relation to the application installations and their internal logical structure, taking into account the standard application package database architecture (for the
release being implemented) and any custom database objects or partitions. Development Environment Architecture The development environment architecture component should describe the application and database architecture of the project development environment. You should include it if the development environment is included in the scope of the architecture process and you wish to document it with the production system logical architecture.
Tools
Deliverable Template
Use the Logical Application and Database Architecture template to create the entire deliverable or specific sections of the deliverable. Choose from the following list of sections and modify the content as needed: Overview Logical Architecture Summary Applications Installations Organization Access to Applications Logical Database Architecture Development Environment Architecture
Oracle Method
The following reference provides information on the application installation on client desktop machines and application client file servers: Reference: Oracle Installation Manual for Windows Clients, Release 10 SmartClient, Production 12. Oracle Part Number A43603. For more information about architecting an environment for Oracle Applications custom extensions, see: Reference: Kodjou, Paule. Architecting Your Applications Environment for the Development and Preservation of Customizations. OAUG Proceedings, Spring 96.
Deliverable
The deliverable for this task is the Physical Database Architecture document. It specifies storage structures and parameters necessary for placement and management of all identified database objects.
Prerequisites
Required
You need the following input for this task:
G G G
The Logical Application and Database Architecture document provides the logical definition of various installed application databases, including their schemas and objects. Hardware and Network Architecture (TA.160)
The Hardware and Network Architecture provides information about the hardware and network deployment that will support the application deployment and the processing of the databases. System Capacity Plan (TA.170)
The System Capacity Plan provides the database sizing metrics needed for estimating the I/O system metrics.
Oracle Method
G
The System Availability Strategy document provides information about the strategies used for providing the level of system availability the business needs. If there are special database architectures and systems needed to provide the desired level of system availability, this deliverable will contain information about them.
Optional
You may need the following input for this task:
G
The Business Volume Requirements document provides the business volumes information. Use it to identify specific volumes you may need for estimating the I/O throughout and database performance, if the System Capacity Plan does not include the level of detail for the metrics that you need.
Task Steps
The steps of this task follow: No. 1. Task Step Review system availability requirements and strategy. Review practices for partitioning a database for high performance. Establish architecture design strategy and principles. Identify characteristics of preferred I/O subsystem hardware. Establish basic architecture standards. Database Architecture Strategy Database Architecture Strategy Deliverable Component
2.
3.
4.
5.
No. 6.
Task Step Identify key database architecture parameters. Map different types of segments to categories of tablespaces. Perform detailed mapping of segments to tablespaces for each segment type. Calculate extent specifications for database objects. Partition tablespaces between operating system files and devices. Determine disk array and stripe sizes, and group files according to striping, array and parity. Estimate I/O throughput rates on each drive using capacity plan metrics. Revise database configuration based on estimated I/O rates and bottlenecks. Revise application and database architecture if necessary. Initiate performance test if throughput risk is high.
7.
8.
Tablespace Partitioning
9.
Tablespace Partitioning
10.
11.
12.
13.
14.
15.
Table 3-32
Oracle Method
detailed discussion assumes that you are architecting an Oracle7 database. Attention: This task requires technical expertise in the physical design of databases. The physical layout of an Oracle database affects performance, ease of management, and the robustness of the database applications against unplanned outages. Once data is loaded into a database, corrective action is much more difficult than at the design stage.
Design Considerations
Although the design of a database architecture is a complex undertaking, fortunately there are methods and standards that experienced Oracle database practitioners have developed and documented. Although these methods have not entirely automated the design process, their use does help mitigate many of the risks. Optimal Flexible Architecture (OFA) The most fundamental Oracle database design method is the Optimal Flexible Architecture method, which has become a de facto standard for the physical design of Oracle databases. By adopting OFA principles,
Oracle Method
you help ensure that the database not only performs well, but that it can be managed by a database administrator without reduced risk of interruption of service or data corruption. Reference: Millsap, Cary V. An Optimal Flexible Architecture for a Growing Oracle Database. White Paper, Revised 1993. Reference: Millsap, Cary V. Optimal Flexible Architecture, Oracle Magazine. Vol. IX, Nos. 5 and 6, 1995. Very Large Database (VLDB) Design In highly centralized processing environments, the potential size of the databases in an architecture increases, and as they gradually transition into the Very Large category, other considerations complicate the more straightforward analysis that is applicable in environments with smaller data volumes. There is no unambiguous definition of the minimum size for a database before it may be considered very large. The relative size depends on the nature and rate of the transactions executed, the relative mix of online and batch transactions, whether there are significant volumes of reporting, availability requirements, and the age of business data retained in the database. As a very rough rule, an applications database that is 10s of GBs in size may be considered small-to-normal, whereas a database that is 100 GB or more is moving towards being considered very large. However, this can easily vary with the industry sector of the business and the practices and operational model. The methodology used for the design of very large databases does not differ fundamentally from that of more conventional-size databases, but the supporting physical hardware needed will be more complex, and the maintenance techniques and procedures that are feasible for smaller data volumes become untenable for very large databases. For an excellent introduction to the principles of Oracle VLDB design, you should read: Reference: Millsap, Cary V. Configuring Oracle Server for VLDB. OAUG Proceedings, Spring 96.
system is the most important consideration to your business, you will design your database and I/O subsystem with that objective overriding any other. In so doing, you incur greater hardware costs and possibly sacrifice some performance to give you the level of confidence in your system and the Mean Time To Failure (MTTF) or Mean Time To Recovery (MTTR) you require. Generally, if the overriding consideration is availability, you will look for a disk mirror I/O subsystem solution. If it is performance, you look for a disk striping solution, and if it is cost, then possibly a higher RAID level solution. In practice the equation is never totally dominated by one factor, so be flexible in your approach and compromise if necessary. Oracle Applications are usually implemented into business or mission critical environments, and larger implementations often have availability and performance as their main concerns. This is even more likely at present, given the trend towards decreasing real cost of disk capacity.
Tablespace Partitioning
Partitioning Segments According to OFA standards, database segments fall into one of several types: System Temporary Data Index Rollback Tools Miscellaneous User Categorize your segments according to the constraints above and then partition them across different tablespaces to facilitate database administration, optimize system availability, and efficiently use the disk space available to the database. Constraints Affecting Tablespace Partitioning A number of constraints affect how you partition your segments into tablespaces: I/O performance
Oracle Method
Resilience to system outage Space management Quota Management Keep these constraints in mind as you design your tablespace structure and map to physical datafiles. Mapping Tablespaces to Physical Datafiles Having partitioned the segments into tablespaces, you then need to map the tablespaces to operating system files. You will need to factor in key database architecture strategies that were identified to satisfy the competing system availability, the performance requirements, and the cost requirements, and architect the different categories of tablespaces accordingly. Examples of these strategies include: use of RAID technology use of disk mirroring striping For more information, see Develop System Availability Strategy (TA.060).
Distributed Data Option you will need to modify the architecture design to take into account the special requirements and behavior of these features. You should review any special Oracle documentation accompanying these features or options and design accordingly.
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Production Database Administrator Technical Architect IS Operations Staff
Table 3-33
% 80 20 *
Deliverable Guidelines
The Physical Database Architecture document describes the physical layout of all the Oracle databases in the system architecture. In an Enterprise Architecture scope project, this deliverable describes the standards and principles for the design of the individual databases. At the detailed site implementation level, complete the deliverable to sufficient detail so that a database administrator can configure the database from this document alone.
Deliverable Components
The Physical Database Architecture deliverable should contain the following components: Database Architecture Strategy The database architecture strategy component should describe the strategies, practices and methods that you will use to design the physical database architecture. Areas that you should cover in this component include strategies for: Design methods and techniques Preferences for types of I/O subsystems Disk device mapping Strategies for disk striping and multiplexing Database Architecture Standards The database architecture standards component should describe the standards that will be used for the physical database architecture work. The Architecture Strategy deliverable may already contain discussion of these standards, in which case this component can either reference the component in the Architecture Strategy deliverable or for ease of use, can reproduce that text here. Similarly, if the standards are detailed in another document, you should reference that other documentation. Areas that you should cover in this component include standards for: File system mount points File categories Database files Tablespaces Database Architecture Parameters The database architecture parameters component should describe the main database parameters, their settings, and the rationale for each production database instance. For an Oracle database this would include at least the Oracle block size and values of other key init.ora parameters. You may document all of the init.ora parameters in this component or segregate them into an Appendix to the deliverable.
Oracle Method
Tablespace Partitioning The tablespace partitioning component should describe the partitioning of the logical database storage across Oracle tablespaces for each production database instance. The discussion should describe how this partitioning fulfills the database strategy. Tablespace File Mapping The tablespace file mapping component should describe the mapping of the Oracle database tablespaces to the file system. This defines the physical data storage at the operating system level. I/O Throughput Estimates The I/O throughout estimates component should contain estimates of the database I/O throughput, based on the defined physical layout. It should identify the key processing scenarios for which the throughput is estimated in terms of the transactions and user or batch sessions that the database will support. Appendix A Init.ora Listing This is a full listing of the parameter settings for the database you are designing. In the case of an Oracle database, this would correspond to a listing of the Init.ora parameters.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Is the strategy used for the database architecture clearly defined? Was a methodology used for the design? Are the key database parameters and their values documented? Is there evidence of the consideration of cost, system availability requirements, performance and database maintenance?
Tools
Deliverable Template
Use the Physical Database Architecture template to create the entire deliverable or specific sections of the deliverable. Choose from the following list of sections and modify the content as needed: Introduction Database Architecture Strategy Database Architecture Standards Database Architecture Parameters Tablespace Partitioning Tablespace File Mapping I/O Throughput Estimates Appendix A Init.ora Listing
Oracle Method
Deliverable
The deliverable for this task is the Hardware and Network Architecture document. The deliverable describes the deployment of the key hardware and network components of the new system and their relationship to the application and database architecture.
Prerequisites
You need the following input for this task:
G G G
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture. It contains a conceptual view of the hardware and network configuration for the new system. Logical Application and Database Architecture (TA.140)
The Logical Application and Database Architecture document provides the logical definition of various installed application databases, including their schemas and objects. System Availability Strategy (TA.060)
The System Availability Strategy document provides information about the strategies used for providing the level of system availability the business needs. If special hardware and network architectures or components are intended to provide the desired level of system availability, this deliverable will contain information about them.
G
The Technical Architecture Baseline document provides a consolidated inventory of the applications, databases, interfaces, hardware, and networks in the existing information systems infrastructure.
Task Steps
The steps of this task follow: No. 1. Task Step Gather technical requirements not addressed by prior tasks. Document hardware and network standards. Define the enterprise-level aspects of the hardware and network architecture. Create overview of the technical architecture for each data center. Define the detailed hardware architecture for each data center. Define the detailed network architecture for each data center. Hardware and Network Standards Enterprise Hardware and Network Architecture Deliverable Component
2.
3.
4.
5.
6.
Table 3-34
Oracle Method
this as the basis for the design, you can expand the details of the architecture using architecture deliverables created after the conceptual architecture. If gaps in the detailed hardware and network design are not covered by requirements already captured in the architecture process, you need to discuss these areas with the IS Operations Staff and IS Manager. Once you create the architecture design, have the project manager and IS manager review it. Consider the following architecture components when you design the hardware architecture: data servers for OLTP, reporting, and data warehouse systems file servers web servers and internet commerce/EDI entry points failover servers and standby servers/data centers gateways connecting applications and databases disk farm arrays used by key servers client desktop machines and for network architecture: local area networks and subnets wide area network connections routers and bridges network protocol and topologies
Tight Linking with Physical Database Design and System Capacity Planning
The tasks of designing the hardware and network architecture, designing the physical database architecture, and developing a System Capacity Plan (TA.170) are tightly linked. You will often work on these tasks together as a group within a project. The exact hardware and network architecture you choose depends on whether they can support the system capacity plan requirements, and how the databases are physically laid out across disks and I/O subsystems. You may need to perform iterations of each of these tasks before you arrive at a selfconsistent solution to the detailed technical configuration of the system.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Architect System Administrator Network Administrator Production Database Administrator IS Operations Staff IS Manager
Table 3-35 Role Contribution for Design Hardware and Network Architecture
% 45 35 10 10 * *
Oracle Method
Deliverable Guidelines
The Hardware and Network Architecture document describes the physical deployment of hardware and networks to support the application and database deployment already designed within the architecture process. The objective of the deliverable is to plan the hardware and network layout in relation to your existing technical infrastructure and the logical application and database architecture. The deliverable should contain the necessary details to facilitate implementation. It can either include just the changes to the infrastructure for the new systems, or, if the deliverable is intended to be a complete architecture, it can include both the new systems and the existing systems. Suggestion: Diagrams are an excellent way to communicate the new hardware and network architecture. You should use a diagram wherever possible in the deliverable.
Deliverable Components
The Hardware and Network Architecture deliverable should contain the following components: Hardware and Network Standards The hardware and network standards component should describe the enterprise or data center standards to which the architecture needs to conform. The discussion should make clear who owns the standards
and their scope. For example, if data centers are autonomous in their choice of standards, you should indicate their standards ownership. The Architecture Strategy deliverable may already contain discussion of these standards, in which case this component can either reference the component in the Architecture Strategy deliverable or, for ease of use, can reproduce that text here. Similarly, if the standards are detailed in another document, you should reference that other documentation. Enterprise Hardware and Network Architecture The enterprise hardware and network component should describe the high-level enterprise architecture, covering one or more individual data centers, sites or installations. For example, it could show the geographical data center deployment, the business organizations they service, and the network links between data centers. Inclusion of this component is entirely dependent on the scope of the architecture process. If the architecture process only covers a single site or data center, you may not wish to include this component in the deliverable. Data Center Hardware and Network Architecture This is a repeating component that describes the detailed hardware and architecture for each data center. There will be one component for each data center in the scope of your design. The areas that you should include in your discussion include: Technical configuration in the data center Database and other servers Data center network configuration Desktop client environments supported by the data center Deployment of printers and other peripheral devices Suggestion: If you are only creating an architecture for a single installation of applications or for a single data center, you should elevate the data center subsections to be the components of the deliverable.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable:
Oracle Method
Does the content in the deliverable match the scope and description of the document in the introduction? Is there a clear distinction between the enterprise-level aspects of the hardware and network architecture and the more detailed data center architecture? Does the deliverable define the technical configuration in the data centers, the architecture for the data servers, and the desktop client environment?
Tools
Deliverable Template
Use the Hardware and Network Architecture template to create the entire deliverable or specific sections of the deliverable. Choose from the following list of sections and modify the content as needed: Introduction Hardware and Networks Standards Enterprise Hardware and Network Architecture Hardware and Network Architecture for Data Center Hardware and Network Architecture for Data Center When you select this component, the deliverable template prompts you for the name of the data center. If you have more than one data center, you can easily add further data center components after creating the deliverable, by selecting the Insert Boilerplate menu option, and repeating the insertion of the Data Center Hardware and Network Architecture component.
Oracle Method
Deliverable
The deliverable for this task is a System Capacity Plan document. It contains the system capacity requirements for database servers, networks, client desktop machines, and application client file servers.
Prerequisites
Required
You need the following input for this task:
G G G
The Business Volume Requirements document provides the business volumes information on user counts, transaction rates and volumes of data needed. Hardware and Network Architecture (TA.160)
The Hardware and Network Architecture provides information about the hardware and network deployment that will support the application deployment and the processing of the databases. Technical Architecture Baseline (TA.050)
The Technical Architecture Baseline document provides a consolidated inventory of the applications, databases, interfaces, hardware and networks in the existing information systems infrastructure.
G G
The Architecture Strategy document may contain information about the strategy to be used for the system capacity planning activities in the project. Conceptual Architecture (TA.040)
The Conceptual Architecture document provides a high-level view of the favored future application and technical architecture. The conceptual architecture document will contain any initial system capacity estimates performed. These initial estimates can be the basis for a more detailed and accurate capacity plan.
Optional
You may need the following input for this task:
G
The IS organization may already have a system capacity strategy in place and should be able to provide copies of documents that discuss the strategy.
Task Steps
The steps of this task follow: No. 1. Task Step Review any existing strategy for system capacity planning, taking into account architecture design work to date. Document the capacity planning strategy. Capacity Planning Strategy Deliverable Component
2.
Oracle Method
No. 3.
Task Step Confirm existing business volumes information and the predictions for future user headcount and business volumes. Summarize the business volume requirements. Establish minimum lifetime of new technical architecture and hence identify capacity planning horizon. Research capabilities of production database server machines. Perform sizing exercise for production servers. Document recommendations for current or future capacity shortfall. Research capabilities of development and training database server machines, if within scope. Perform sizing exercise for development and training servers, if within scope. Document recommendations for current or future capacity shortfall. Research application requirements for desktop client machines.
Deliverable Component
4.
5.
6.
7.
8.
9.
10.
11.
12.
No. 13.
Task Step Document recommendations for desktop client machines. Research application requirements for client file server machines. Document recommendations for client file server machines. Research capabilities of network segments. Perform sizing exercise for network segments. Document recommendations for current or future network capacity shortfall. Document assumptions in capacity plan. Document risks in capacity plan. Summarize capacity planning results and recommendations. Review deliverable with project and business management. Secure acceptance for deliverable.
14.
15.
16.
17.
Network Capacity
18.
Network Capacity
19.
Assumptions
20.
Risks
21.
Executive Summary
22.
23.
Management Acceptance
Table 3-36
Oracle Method
Warning: Many performance problems that occur after a system has gone into production can be traced back to poor planning of processing capacity (CPU, memory) in critical servers. At least part of the reason for this are the inherent obstacles to accurate system capacity planning in modern open systems (see below). A detailed and thorough system capacity plan is a critical success factor for the architecture of any implementation, especially one that involves the replacement of business- or mission-critical ERP system applications. When a comprehensive and detailed system capacity plan is performed, it is a major factor in mitigating a major source of risk to projects. System capacity planning for ERP system implementation requires technical expertise and familiarity with the problems of capacity planning for large, complex, tightly integrated, critical systems. If the implementation does not have the required expertise for planning Oracle systems capacity, contact your Oracle project manager or account representative for assistance.
Oracle Method
number of CPUs needed amount of RAM needed amount of disk space needed for installed code, data files, and swap files I/O subsystem capacity needed When capacity planning for network segments, you need to consider: latency (round trip time) maximum rated bandwidth actual network throughout
Oracle Method
Analogous Implementations A very sure way of planning your capacity is to find another implementation project that is implementing the same type of business, in an identical technical environment and of roughly the same business volumes and user counts. This is a rare occurrence, so you may be forced to look for other implementations that are analogous in some way, but do not directly match your implementation. If you can find another implementation that does not have precisely the same technical environment or the same business needs, but is implementing on the same database server platform (including operating system version), you may be able to make useful comparisons and get direct empirical capacity planning information. If the operating system version, or the CPU ratings in two machines from the same vendor are different, this reduces the usefulness of the empirical metrics you might obtain, and you will need to conduct your metrics gathering exercise for your specific configuration. Rule-of-Thumb Method The simplest way of planning capacity for machines is to use rule-ofthumb metrics for memory per user and batch process, and TPS or TPCC per user and batch process; the Oracle Applications database server sizing spreadsheets supplied with AIM use this method. While this technique is better than nothing, it is extremely unsophisticated and can only give order of magnitude estimates of CPU capacity with a high degree of risk. For memory and network bandwidth estimation, this type of approach is somewhat better, but should still be treated with caution. Warning: While this technique is better than doing no capacity planning at all, it is not much better, and is an extremely unsophisticated tool. At best, it may give some rough indication about the class of database server you may need to purchase from your hardware vendor, but it cannot give accurate predictions of numbers of CPU boards needed or how much spare online or batch capacity you will have on a machine before performance starts to suffer. Statistical Summation Method This method attempts to discover meaningful linear mathematical relationships between a few measurements of key system resource metrics and individual system or user processes (transaction flows). It
is more complex than the estimation model and requires experience and technical expertise to perform. System Modeling A more detailed analysis would look at the major transaction flows to be executed in the system and determine the system resource usage by transaction flow. Multiplication of these resource usages per flow by the number of sessions executing the flow will give a better system capacity estimate, especially when a CPU queuing model is built into the study. This is also a complex mathematical technique that requires experience and technical expertise to perform. Capacity Planning by Simulation This is the ultimate capacity planning technique: you build a simulation of the system to the level of complexity required for a certain degree of confidence in the results and measure the system resource usage directly. It is the technique that is most able to generate accurate, reliable results, but it can be costly and time-consuming to obtain a high degree of accuracy. This technique is discussed in detail in the Performance Testing process, and capacity planning studies is one reason you might seek to instigate a system performance test.
Oracle Method
of the CPU capacity required for a database server requires the other more subtle and complex techniques briefly mentioned above.
planning for peak processing periods; for example, quarter end or heavy nighttime batch processing other applications that are currently processing on the same servers as Oracle Applications or will move there at some point in the future For more information about identifying scenarios for performance testing/capacity planning, see Identify Performance Test Scenarios (PT.030).
Oracle Method
Hardware or Operating System Upgrade If the shortfall is in database server CPU and/or memory, it may be possible to purchase extra CPU boards or memory for your server to relieve the shortfall. A careful analysis of the capacity requirements versus the maximal capability of the database server should indicate whether the increase in capacity requirements can be met by server upgrades over the lifetime of the plan. If the business capacity requirements exceed the maximum capability of a database server in CPU and/or memory, the capacity need will necessitate some other (potentially more costly) solution. If the hardware vendor has scheduled dates for the release of a new server (with faster CPUs and/or more memory available), or is releasing a new version of the operating system which promises higher SMP scalability, you may be able to continue with the existing server and then migrate to the new server when it becomes available. This demands that you will have sufficient system capacity for production cutover, followed by the ability to migrate your applications to the new processing platform at some point in the future, before the capacity shortfall becomes chronic. This solution introduces a dependency of the business on the hardware vendor release schedules and is not often acceptable, unless there is a high degree of confidence that the new hardware will be available when it is needed. Use of Reporting Server A reporting server configuration attempts to create extra processing capacity on a database server by offloading the reporting load to another server with a copy of the transaction database or an operational data warehouse. The simplest technique is a periodic refresh or load of OLTP data to the reporting database. This approach can offload a significant percentage of the overall application processing load, but the exact amount is dependent on the exact business demands and the ability of the heavy-reporting users and programs to endure the use of aged data. Alternative OLTP Technical Configurations Another means of offloading limited system resources is to use alternative technical configurations, but still retain the integrity of the single OLTP database. N-tier configurations. By splitting the processing across an extra physical computing tier, it is possible to distribute CPU and memory processing
resources across multiple physical machines. The precise characteristics of the processing distribution and the load balancing are highly dependent upon the application. Attention: In older, character-mode releases of Oracle Applications, the three-tier architecture (presentation clientapplication server-database server) was often a feasible way to provide extra memory resources to a memory-bound database server (offload of CPU processing was less efficient). This approach is less likely to be possible for 10SC, although PC architectures are evolving that enable the presentation processing to be split off to a separate PC client. Multi-Threaded Server. This is a way to relieve memory shortages on a memory-bound database server (and can also help with the resource management of system processes in a system with unduly large numbers of process connections to the server). It needs special database tuning skills and monitoring to mitigate the risk of negative performance effects from an extra database resource bottleneck. Oracle Parallel Server (OPS). This is a way to distribute the processing across database servers that combine to provide total system resources to process a database. Users or batch programs can be partitioned across the individual machines in an OPS cluster with inter-node locking and memory management handled transparently. This approach can provide greater scalability and can distribute the total load across multiple database servers, but does have the drawback of having higher hard costs for extra hardware, and higher soft costs for training or hiring of expertise in tuning and management. Partition to Distributed Database Generally the least desirable approach is to partition a single integrated OLTP database into a distributed database architecture. If you need to share data for reporting or consolidation, or if cross-database transactions are necessary to support the business processes, custom modules for interfaces and reporting must be built. This approach provides a scaleable solution, but can also be costlier to build and manage.
Disk Sizing
Planning the capacity of disk space is usually one of the less riskier aspects of capacity planning, unless the implementation hardware budget has slim margins for error, and the disk space needs to be
Oracle Method
calculated very accurately. The trend towards decreasing real cost of disk capacity means that the amount of disk purchased from disk vendors for new implementation projects has grown to ensure enough safety margin in the estimates. If disk estimates are performed by the technical architect as part of the conceptual architecture design, they are likely to be based on initial business volume estimates with only an approximate idea of archive or purge cycles. At the conceptual architecture stage of the process, the benefit derived from the disk sizing exercise may be to identify what the likely disk requirements are to a margin of, for example, 50%. Hence it may identify an approximate figure for the required disk space but not much better than this. As the project proceeds, the required business volume information, archive, and purge processes will be better characterized and the disk estimates correspondingly better. As with the processing capacity, the disk capacity requirements should be estimated for production cutover, and then for a prescribed period of production operations with business growth of transactions included, if possible. The volumes of data converted in the conversion process are important for estimating the initial disk capacity required, but may be irrelevant for the disk estimates after the prescribed period of operations. One or more archive or purge cycles for transaction data may remove the initial extra volumes from converted data, so that the disk space required for a particular data entity is a function of the maximum volume prior to archive or purge. This needs to be addressed on an entity by entity basis. It may also be possible to omit some data entities that contribute minimal disk space to the overall total, and only focus on the main entities for each application product that contribute 90% of the total disk space. Production Monitoring of Disk Space The IS operations staff can closely monitor disk space during production operations and set a minimum free space volume that triggers purchase of new disk space. For example, in a small-tomedium implementation, if the free disk space falls below 1GB, this could trigger a new purchase of extra disk space. The exact free space trigger value will be determined by the disk purchase lead time and the rate at which the business uses disk space.
Role Contribution
The percentage of total task time required for each role follows:
Role Technical Architect Database Administrator System Administrator Network Administrator IS Operations Staff IS Manager
Table 3-37 Role Contribution for Develop System Capacity Plan
% 50 20 20 10 * *
Deliverable Guidelines
The System Capacity Plan deliverable helps you develop the system capacity plan for each of the data centers or application installation sites in your architecture.
Deliverable Components
The System Capacity Plan deliverable should contain the following components:
Oracle Method
Executive Summary The executive summary component should summarize the system capacity planning work for executive consideration. It should introduce the capacity planning study and then describe its scope, the results and conclusions. Overview The overview component should describe the purpose of the deliverable and the scope of the system capacity planning work. The scope should describe the technical infrastructure components included in the study. Capacity Planning Strategy The capacity planning strategy component should describe the strategy that will be used for the system capacity planning work. The Architecture Strategy deliverable may already contain discussion of this strategy, in which case this component can either reference the component in the Architecture Strategy deliverable or, for ease of use, can reproduce that component here. In particular, this component should identify the capacity planning horizon. Business Volume Requirements The business volume requirements component should summarize the key business volume information used for the capacity planning work. It should include any projections for future headcount or transaction rates. The information recorded here may have been captured by the Business Requirements Definition process team. If this is the case, you should refer to the Business Volume Requirements deliverable from that process here, and summarize the main metrics you will use for the capacity planning. Production Database Server Capacity The production database server capacity component should describe the capacity planning work performed on the production system database servers. Depending on the scope of the capacity planning task, it may include capacity planning of: Processing Capacity Server Class and CPUs Memory Requirements Disk Capacity Requirements
Project Database Server Capacity The project database server capacity component should describe the capacity planning work done on other database servers for the project if they are within the scope of the architecture process. The project database servers could include training and development servers, for example. Desktop Client Machines The desktop client machines component should summarize the capacity planning assessment of the requirements for the desktop client machines in the new architecture. It should include an assessment of the specifications for these machines depending on the type of user and the processing capacity needed. Application Client File Servers The application client file servers component summarizes the capacity planning assessment of the requirements for any application client file server machines that are part of the new architecture. This should include both the processing and the disk space requirements. Network Capacity The network capacity component summarizes the capacity planning work done on the local and wide area networks that are part of the network infrastructure for the future system, including estimates of the bandwidth needed and assessment of latency requirements. Assumptions The assumptions component should describe the assumptions made in the course of capacity planning (e.g., assumptions made because of the timing of the architecture project or missing volumetric information). Risks The risks component should describe the risks inherent in the system capacity plan analysis and in the volume metrics used for the work.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable:
Oracle Method
Does the content in the deliverable match the scope and description of the document in the introduction? Is there a clear strategy for the system capacity planning? Does the system capacity plan cover database server process and disk requirements? Does the system capacity plan address capacity issues after live production cutover? Has the system capacity plan taken account of future business growth and other applications or systems that will compete for the same system resources? Have the client machines or networks been considered?
Tools
Deliverable Template
Use the System Capacity Plan template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your plan: Executive Summary Overview Capacity Planning Strategy Business Volume Requirements Production Database Server Capacity Project Database Server Capacity Desktop Client Machines Application Client File Servers Network Capacity Assumptions Risks Acceptance Certificate
Project Database Server Capacity When you select this component, the deliverable template prompts you for the name of the project database server. If you have more than one project database server to plan capacity for, you can easily add further database server components after creating the deliverable by selecting the Insert Boilerplate menu option and repeating the insertion of Project Database Server Capacity component.
Oracle Method
number of flexfield segments utilized initial database sizing factors length of text fields entered additional indexes or tables in the database If you have more accurate metrics for the row sizes for your tables in bytes, you can copy and update the spreadsheet calculations to reflect the individual row size values that are more precise for the specific circumstances of your implementation.
Connects/User the number of open sessions for the applications that the user has on his or her workstation. If the user activates a zoom in character-mode release 10, this also creates an additional user process. CPs per User the number of concurrent processes per user. This is a technique to estimate the number of concurrent processes based on user count. Spreadsheet Usage The spreadsheet cells are color-coded to indicate their usage. Red cells are formulas, so you should not modify them. The green cells are sizing parameters that you should only modify if you have better information. The cyan cells are the ones you need to fill in with user count information based on your implementation. Assumptions and Caveats This spreadsheet is based on very rough rules of thumb and yields only a rough approximation for server requirements. Every implementation is different, and sizing varies substantially for equal numbers of users on the same applications. TPC-C ratings are a very rough proxy for application load. Because of this approximation, tpm/user will vary from hardware vendor to hardware vendor. These assumptions were derived on large systems and may not scale well to systems with small numbers of users. The spreadsheet estimates the number of active concurrent manager processes as 10 - 20% of the active user count. If you have better estimates, you should use them. TPC-C calculations include the load only for running the applications. You should allow for additional processing power to cover other activities on the database server, such as nonOracle applications, miscellaneous user activities, and operating system overhead.
Oracle Method
Memory (RAM) calculations do not include space required for the operating system, database SGA, and other non-Oracle applications. Be sure to include these in total RAM estimates. Typical values for operating system requirements vary from 16 MB to 100 MB, depending on the vendor and the size of the machine. Typical values for the SGA vary from 40 MB to 500 MB, depending on the activity level in the database. CPU and RAM requirements vary by application and concurrent process, so the spreadsheet accommodates this variation. The application-specific values that appear for tpm and memory are only approximations based on the general knowledge that the Oracle Manufacturing Applications require more resources than the Oracle Financial Applications, and that Oracle Order Entry requires the most resources. As more specific data becomes available, future versions of this spreadsheet will have more accurate values for resource requirements. Release 10 Character-Mode Running on a Single Server The first set of data is where the R10 Char Mode Host parameter is Yes, and this is for a host-based technical configuration where all processing takes place on a single machine. This configuration is appropriate for small-to-medium size implementations that will not use 10SC. Release 10 Character-Mode with Database and Application Server The second set of data is where the R10 Char Mode C/S parameter is Yes, and this is where all processing takes place on the database server, except SQL*Forms 2.3 processing. This set of data sizes the database server. See the Application and Concurrent Manager Servers section for sizing the application servers. This configuration is appropriate for large implementations that will not use 10SC. A variation is where the Concurrent Manager runs on a client machine also. To size this variation, you need to reduce the resource requirements by the amount off-loaded to the concurrent manager server. You should see the Application and Concurrent Manager Servers section below. Release 10SC Database Server The third set of data is where the 10SC parameter is Yes, and this is where all processing takes place on the database server, except the 10SC client activity that runs on PCs. This configuration is appropriate for all size implementations except the largest. A variation that can be used for the largest implementations is where the Concurrent Manager runs
on a different server from the database server. To size this variation, use data from the Application Server section. Application and Concurrent Manager Servers The fourth set of data is where the Application Server parameter is Yes, and this is for sizing application and concurrent manager servers to be used in combination with the other configurations. Application servers can only be used with Release 10 Character Mode. Concurrent manager servers can be used with any configuration to free up capacity on the database server. To size an application server, use the sizing values under the User Requirements heading as the total capacity requirement for the application server. To size a concurrent manager server, use the sizing values under the heading Concurrent Process Requirements. Subtract these values from the resource requirements of the database server to account for the off-loading. Use the values under the heading Total Requirements only if you are combining the application server and concurrent manager server on the same machine.
Oracle Method
Attention: The rated bandwidth for a network segment should be treated as a theoretical maximum, rather than the actual bandwidth you can expect for the network segment in normal operation. In the absence of any better estimate or empirical assessment by the network support staff, an approximate rule of thumb is that a network segment will support 40% of its actual rated bandwidth before significant performance degradation begins to occur because of competition for bandwidth. The degradation of the actual maximum bandwidth as compared to the theoretical maximum is dependent on the network topology, protocol, network interfacing and routing mechanisms, and packet collisions. The spreadsheet has the following sections: Definitions Release 10 Character Mode Avg keystrokes/minute/user the average number of keystrokes per minute that each user executes against the network segment. Avg bytes/keystroke the average number of bytes that a keystroke generates. Avg screen redraws/minute/user the average number of redraws of a screen performed by each user per minute. Screen redraws typically take place when a user navigates between screens in an application. Avg bytes/screen redraw the average number of bytes generated by a screen redraw. Percent active to total logged on users the percentage of users that are logged on to a system and are active at a point in time. Site the site group of users that are generating keystroke-based transactions against a network segment. You can either enter the sites that contribute to a single network segments traffic, or use the same parameters for a group of sites that connect via different network segments, and size them all together using the same base parameters. Users the total number of users logged on at a site.
Definitions Release 10SC The spreadsheet uses a capacity estimation model based on empirical measurements of network bandwidth within Oracle development and in implementations. You will need to run this spreadsheet once for each network segment to size. Active Users the number of users active for a particular application Bytes/Round Trip the average number of bytes transferred down the network segment for each network round trip Round Trips/Sec the average number of round trips per second Spreadsheet Usage The spreadsheet cells are color-coded to indicate their usage. Red cells are formulas, so you should not modify them. The green cells are sizing parameters that you should only modify if you have better information. The cyan cells are the ones you need to fill in with user count information based on your implementation. Wide Area Network (WAN) Latency The spreadsheet does not address WAN latency issues. This is the time for a message to make a roundtrip on the network. You can measure latency between two machines using the Unix ping utility. Latency affects response time for the user and should be less than 300 milliseconds for acceptable performance, and ideally below 200 milliseconds. This means that frame relay is the slowest acceptable protocol. X.25 and satellite links have excessive latency for Oracle Applications. T1 links and frame relay networks will generally provide very good performance within the continental US and to most developed nations around the world. You should work with the network administrator to determine the latency of their network and the capability of the WAN vendor to provide what is needed. Assumptions and Caveats Calculations made using the spreadsheet do not consider non-Oracle Applications network traffic. You should find out what traffic already exists on the network and subtract it from network capacity. The results you get from using the spreadsheet are approximations, so you should allow plenty of margin to ensure good performance. As with all capacity planning exercises, remember to size for peak load periods,
Oracle Method
such as end of quarter when financial and manufacturing processing is at a maximum. Many of the metrics in the spreadsheet are extrapolations based on other Oracle Applications products and may change as further application tuning is performed in future releases. You should always use the metrics appropriate for your application release version.
Deliverable
The deliverable for this task is the Performance Risk Assessment document. This is an assessment of the performance risks associated with the application and technical architecture.
Prerequisites
You need the following input for this task:
G G
The prior deliverables provide information about the approaches taken for specific architecture tasks, the analyses, and the designs created for the architecture process. Business Volume Requirements (RD.060)
The Business Volume Requirements document provides information about business volumes. You use this to identify specific processing risk areas based on the volumes.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Review deliverables from the architecture process and other supporting documentation. Identify risk areas in the architecture. Identify suggested risk mitigation approaches. Review risks and mitigation with project and business management. Create summary of risks and mitigation approaches. Confirm risk mitigation approaches. Establish plan for instigation of risk mitigation activities.
Task Steps for Assess Performance Risks
Deliverable Component
2.
Risk Areas
3.
Risk Mitigation
4.
5.
Executive Summary
6.
7.
Table 3-38
Custom Integration or Subsystem Components Whenever custom extensions are designed and built in projects, a performance risk is associated with that development. Inadequate or Inaccurate Business Volume Metrics The business volume metrics may be incomplete or unavailable. The business metrics are important for the assessment of the performance of any components in a system, so if these are inaccurate or incomplete, this will cause general risk in all aspects of system performance assessment. Capacity Planning There is always risk associated with the capacity planning exercise in an architecture project and in particular, planning the capacity of the database server and the number of CPUs required. The reasons why this might lead to risk include: Only a high-level capacity planning exercise was performed Capacity planning is unable to determine the precise dynamic effects that occur in a system, especially in a high-volume batch parallel processing environment The database server is identified as having insufficient capacity at some future time, with uncertainty about the precise timing of the future capacity shortfall Inaccurate business volume metrics High-Volume Processing Environments In addition to the risk of inadequate or unknown capacity requirements, high-volume processing environments are intrinsically more prone to performance risks. The Critical Processing Periods can be a useful tool for identifying potential bottlenecks during critical processing timeframes such as the end of a quarter. This worksheet indicates the day that key processes are run during a critical time span. Projects where these details can be determined in advance can reduce the risk of unanticipated performance problems. By identifying potential bottlenecks early in the implementation cycle, you have more time to identify potential solutions.
Oracle Method
Wide Area Network Configurations If the technical architecture includes client-server configurations separated by a wide area network connection, there can be performance issues if the capability of the WAN segment is not sufficient for the application characteristics and user load from remote business sites. Attention: This is especially relevant for Oracle Applications Release 10SC implementations. If custom extensions will be deployed over a WAN connection, include these within the risk discussion. Advanced Database and Hardware Features If the technical architecture includes Oracle Parallel Server or Multithreaded Server configurations, there is additional technical performance risk because of tuning and configuration requirements that should be mentioned.
Mitigating Risk
The following sections list a few typical performance risk mitigation approaches. This list is incomplete, and the approaches adopted will depend on the precise nature of the risk and the project circumstances. Detailed Capacity Planning A more detailed capacity study may be necessary to mitigate capacity planning risks. The capacity planning efforts can continue after production cutover using metrics from production system by way of a continuous monitoring of capacity requirements. High-Volume Processing Environments Review the Business Volumes document that was produced in the Gather Business Volumes task. The Oracle Project or Account Manager can help gather information about other similar implementations to determine whether the transaction volumes are within the bounds of other known similar production sites. Oracle user groups can also be a source of this information. Prototype Architecture Components of Concern If there are particular architecture configurations or components that cause performance concerns, build a prototyping exercise and formal performance test into development or deployment schedules.
Performance Testing In some cases, reliable predictive information may not be available for large processing requirements. This can be due to the availability of a new application release, new hardware platform, or other factors. If project resources are available, a performance test is a very good way to provide performance data based on the planned production configuration and usage patterns. Conducting a performance test also provides a hands-on training opportunity for production system and database administrators before the production cutover date. For more information, see the Performance Testing process.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Architect Application Architect Team Leader - Architecture IS Manager Project Sponsor
Table 3-39 Role Contribution for Assess Performance Risks
% 50 25 25 * *
Oracle Method
Deliverable Guidelines
The Performance Risk Assessment deliverable helps you present the performance risks associated with the architecture design and some possible ways to mitigate the risk.
Deliverable Components
The Performance Risk Assessment deliverable should contain the following components: Executive Summary For the benefit of executive management or project sponsors, the executive summary component should summarize the analysis of performance risk areas in the architecture, the results of the analysis, and the recommended risk mitigation approaches. Risk Areas The risk areas component should describe the performance risk areas associated with the architecture design. Identify the risk areas and the reasons why there are concerns. Risk Mitigation The risk mitigation component should discuss the risk mitigation approaches possible for the performance risk areas and indicate which of the approaches is preferred.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Does the content in the deliverable match the scope and description of the document in the introduction? Does the deliverable cover the performance risk areas across the entire architecture process? Does the deliverable suggest risk mitigation approaches?
Tools
Deliverable Template
Use the Performance Assessment template to create the entire deliverable or specific sections of the deliverable. Choose from the following list of sections and modify the content as needed to represent your risk assessment: Executive Summary Overview Risk Areas Risk Mitigation
Oracle Method
Deliverable
The deliverable for this task is the System Management Procedures document. This is a list of system management procedures and tools that the IS Operations Staff will use to manage and monitor the new system.
Prerequisites
Required
You need the following input for this task:
G G G
The Hardware and Network Architecture provides information about the hardware and network deployment that will support the application deployment and the processing of the databases. Logical Application and Database Architecture (TA.140)
The Logical Application and Database Architecture document provides the logical definition of various installed application databases, including their schemas and objects. System Capacity Plan (TA.170)
The System Capacity Plan provides the database sizing metrics needed for estimating the I/O system metrics.
G G
The System Availability Strategy document provides information about the strategies for achieving the level of system availability the business needs. If special database architectures and systems are needed to provide the desired level of system availability, this deliverable will contain information about them. Technical Architecture Baseline (TA.050)
The Technical Architecture Baseline document provides a consolidated inventory of the applications, databases, interfaces, hardware and networks in the existing information systems infrastructure.
Optional
You may need the following input for this task:
G
The IS operations staff may have documentation, manuals or guides on the current tools and procedures in place to manage the existing systems. You can use these documents to understand the existing tools and procedures.
Task Steps
The steps of this task follow: No. 1. Task Step Review existing system management procedures, tools and strategy. Identify missing requirements and gather appropriate information. Deliverable Component
2.
Oracle Method
No. 3.
Task Step Summarize system management policies and preferences. Identify all possible failure scenarios for databases in the new architecture. Design database backup strategy and schedule. Design procedures to recover from database failure scenarios. Identify database management and monitoring tools needed. Design login security mechanisms for database servers. Design application login security mechanisms. Design procedures for password validation and management. Identify possible security breaches. Design security monitoring and protection procedures. Design procedures for adding a new user hire to the system. Identify scheduling management requirements and techniques.
4.
Database Management
5.
Database Management
6.
Database Management
7.
Database Management
8.
9.
10.
11.
Security and Accounts Management Security and Accounts Management Security and Accounts Management Scheduling Management
12.
13.
14.
No. 15.
Task Step Identify all possible scheduling failure scenarios. Design procedures to recover from scheduling failure scenarios. Identify monitoring tools for scheduling systems. Identify hardware and networks management requirements and techniques. Identify all possible hardware and networks failure scenarios. Design procedures to recover from hardware and networks failure scenarios. Identify hardware and networks management and monitoring tools needed. Design change control procedures for hardware and networks. Identify software management requirements and techniques. Identify tools needed to manage software. Identify capacity planning and performance management monitoring necessary in production system.
16.
Scheduling Management
17.
Scheduling Management
18.
19.
20.
21.
22.
23.
Software Management
24.
Software Management
25.
Oracle Method
No. 26.
Task Step Identify capacity planning and performance monitoring tools needed. Summarize planned outage schedule for the system, taking into account all sources of outages. Summarize the system management tools that will be used for the management of the system.
27.
28.
Table 3-40
amount of work to put in place the new procedures increases dramatically, especially when the systems replacement is accompanied with a change in technology. The tools and procedures required to maintain a new system are often not considered until the tail end of implementation projects, leaving little time for testing, refinement, documentation, and training in the new procedures. The result is that the operations staff are not fully prepared for the new system cutover, and procedures that may look viable on paper are unfeasible in practice because they have not been tested and optimized. By considering the design of the system management procedures and tools as part of architecture, you can design the procedures as you design the technical architecture of the system and can assess the system management impact during this process. The other benefit is that the architecture process naturally occurs early in projects so you will have designed procedures in place earlier in a project, giving you time to refine, test and document later.
Oracle Method
Database Management Security and Accounts Management Scheduling Management Hardware and Network Management Software Management Capacity Planning and Performance Management Other groupings are possible as well. The administrator responsible for defining the procedures and tools for an area should consider the following subtopics and identify those that are relevant: Proactive and Reactive Monitoring Normal Management and Maintenance Procedures System Failure Analysis and Recovery Long Term Resource Planning Tools and Utilities
Database Management
The following list gives some brief suggestions for things to focus on within the overall Database Management area: Proactive and Reactive Monitoring space utilization and management database fragmentation communication of exception conditions or system failures to the appropriate operations administrator Normal Management and Maintenance Procedures backup procedures archive and purge procedures Oracle cost-based optimizer analysis of tables System Failure Analysis and Recovery diagnosing different database errors
recovery after loss of an Oracle data file recovery after loss of a redo log file recovery after loss of a control file recovery after operator or administrator error recovery after disk failure recovery after server failure Tools and Utilities backup tools database monitoring tools data storage media (e.g., magnetic tapes, COLD [Computer Output to Laser Disk], Optical jukeboxes) Specific procedures for managing the database components of a system are documented in: Reference: Millsap, Cary V. An Optimal Flexible Architecture for a Growing Oracle Database. White Paper, Revised 1993. Reference: Velpuri, Rama. Oracle Backup and Recovery Handbook. Oracle Press. Osborne McGraw-Hill, 1995.
Oracle Method
Normal Management and Maintenance Procedures authorization of accounts for a new hire cancellation of system access for a terminated employee automated password expire single network login Tools and Utilities firewalls to protect corporate systems security systems (e.g., kerberos and network encryption services) remote access authentication
Scheduling Management
The following list gives some brief suggestions for things to focus on within the overall Scheduling Management area: Proactive and Reactive Monitoring monitoring of batch queues, backlog and timing communication of exception conditions or system failures to the appropriate operations administrator Normal Management and Maintenance Procedures batch processing and queue stop and restart for scheduled outage events System Failure Analysis and Recovery system cleanup after batch job failure stop and restart of batch processing after server, database, disk, or network failure Tools and Utilities batch queue monitoring automated stop and restart of batch queue processing
Attention: In Oracle Applications, the batch processing is managed within the Concurrent Manager, and this automates much of the batch queue management and job submission and resubmission. The Concurrent Manager still needs monitoring and is often overlooked in implementations.
Software Management
The following list gives some brief suggestions for things to focus on within the overall Software Management area:
Oracle Method
Proactive and Reactive Monitoring system infection by viruses communication of exception conditions or system failures to the appropriate operations administrator Normal Management and Maintenance Procedures testing of software patches prior to migration into production migration of software patches to production database servers migration and distribution of software patches to production user client desktop machines and file servers software upgrade procedures backup of production system software source control for system software Tools and Utilities client software distribution tools source control systems configuration management systems
analysis of online usage metrics and software program efficiency Long-Term Resource Planning projected future usage of system resources identification of future system capacity constraints strategies to manage future system capacity demands Tools and Utilities system resource usage restriction of the maximum number of online sessions per user the governors for system resource usage by programs and ad hoc queries Production Monitoring of Disk Space It can be effective for the IS operations staff to closely monitor disk space during production operations and set a minimum free space volume that triggers purchase of new disk space. For example, in a small-to-medium implementation, if the free disk space falls below 1 GB, this could trigger a new purchase of extra disk space. The exact free space trigger value will be determined by the disk purchase lead time and the rate at which the business uses disk space. Cost-Based Optimizer and ANALYZE If you are using the Oracle7 cost-based optimizer for the SQL statements in your applications, you should schedule reanalysis of the affected tables on a periodic basis to maintain continuing good performance. Attention: In the current release 10 of Oracle Applications, Oracle7 rule-based optimizer (RBO) is the default optimization method used, but a small percentage of SQL queries use cost-based optimizer (CBO) hints. To maintain continuing optimal performance for these queries, you should schedule to run the ANALYZE facility against the affected tables on a regular basis (e.g., once per month), but the precise frequency will depend on how the business populates the affected tables. Reference: ORACLE7 Server Administrators Guide. Oracle Part Number 6694-70-1292.
Oracle Method
Reference: ORACLE7 Server Application Developers Manual. Oracle Part Number 6695-70-1292.
Role Contribution
The percentage of total task time required for each role follows: Role System Administrator Network Administrator Production Database Administrator Technical Architect Application Architect IS Manager IS Operations Staff
Table 3-41
% 40 20 20 10 10 * *
Deliverable Guidelines
The System Management Procedures deliverable is an integrated record of all of the designs for the procedures and tools needed to manage the new system environment. It is important to distinguish this deliverable from the System Management Guide that is created within the documentation process or from any documentation that Help Desk support staff may use to diagnose an exception condition or issue that a user reports. This deliverable is a design document and does not discuss the procedures in detail or in a reference guide format. It is produced primarily by the technical systems management experts in the project, who are responsible for creating workable procedures and selecting appropriate tools for the management of the new systems. The
resulting deliverable is a primary input to the System Management Guide, which is a separate manual produced by a technical writer. For more information, see Produce Initial System Management Guide (DO.090) and Complete System Management Guide (DO.130).
Deliverable Components
The System Management Procedures deliverable should contain the following components: System Management Standards and Policies The system management standards and policies component should describe the standards and policies to which the system management aspects of the architecture must conform. The discussion should make clear who owns the standards and policies and their scope. The Architecture Strategy deliverable may already contain discussion of these standards, in which case this component can either reference the component in the Architecture Strategy deliverable or, for ease of use, can reproduce that text here. Similarly, if the standards are detailed in another document, you should reference that other documentation. Planned Maintenance Schedule The planned maintenance schedule component should summarize all planned maintenance that will affect the system across system management areas. System Management Tools Summary The system management tools component should summarize the tools that will be used for managing the production systems across all system management areas.
Oracle Method
Database Management The database management component should discuss the procedures and tools needed for managing data and databases in the new system. It should cover both normal maintenance of the databases, as well all possible failure scenarios. It should also describe the tools that will be needed, both those developed in-house and those that must be purchased. Security and Accounts Management The security and accounts management component should discuss the procedures and tools needed for managing access to systems and accounts and for preventing and responding to security breaches. Scheduling Management The scheduling management component should discuss the procedures and tools needed for managing the job scheduling functions in the new systems, including interfaces and batch scheduling. The discussion should consider both normal maintenance operations and abnormal failure scenarios. Hardware and Networks Management The hardware and networks management component should discuss the procedures and tools needed for management of the hardware and network configuration of the new system. It should include discussion of procedures for the change management and testing of technical configurations. Software Management The software management component should discuss the procedures and tools needed for management of all the software components of the new system. It should include configuration management of clients and servers, source control, and patch and upgrade procedures. Capacity Planning and Performance Management The capacity planning and performance management component should discuss the procedures and tools needed for managing the performance of the new systems and the proactive future planning of system capacity.
Quality Criteria
Use the following criteria to ensure the quality of this deliverable: Is the deliverable comprehensive in its coverage of different systems management areas? Does the deliverable address the various types of procedures and tools needed? Are the procedures documented to a degree of detail consistent with the scope of the architecture process?
Tools
Deliverable Template
Use the System Management Procedures template to create the entire deliverable or specific deliverable components. Choose from the following sections and modify the standard text as needed to represent your design work: Introduction System Management Standards and Policies Planned Maintenance Schedule System Management Tools Summary Database Management Security and Accounts Management Scheduling Management Hardware and Networks Management Software Management Capacity Planning and Performance Management
Oracle Alert
Oracle Alert is a valuable mechanism for monitoring aspects of the Oracle Applications environment. It is an alert mechanism that that can track applications database events as they occur or on a periodic condition. It can track database-level exception conditions and can alert
Oracle Method
Oracles System Management Tools Oracle offers a number of system management tools that are intended for the administration and management of Oracle databases in a networked environment. These tools include the modules: Enterprise Manager Enterprise Manager Performance Pack (for performance tuning) Replication Manager Network Manager Oracle Client Software Manager Oracle Enterprise Backup The Oracle system management platform, which these tools are built on, supports the Simple Network Management Protocol (SNMP) and the integration of different agents. Oracle databases can be monitored through a central console alongside other distributed network components, such as hosts, routers and bridges. The adoption of the protocol standard also means that Oracles products can be launched through the products of other vendors. For information about Oracles System Management products, you should consult the following references: Web Site: Oracles World Wide Web Home page http://www.oracle.com/. Reference: Oracle Systems Management. Managing the Oracle Environment. White Paper, May 1995. Oracle Part Number A34068. For information about Oracle Enterprise Manager, see: Reference: Oracle Enterprise Manager Concepts Guide. Oracle Part Number A43550. For information about the use of Oracle Client Software Manager with Oracle Applications, consult the version of the following reference manual appropriate for your Release 10 SmartClient Production release number:
Oracle Method
Reference: Oracle Installation Manual for Windows Clients, Release 10 SmartClient. Oracle Part Number A41021. There are many sources for discussions of systems management tools and techniques. The International Oracle User Group holds conferences every year (IOUW) at which papers are presented and many of these papers deal with the issues and techniques for managing and monitoring Oracle-based systems. For a sample of papers, you can refer to the following: Reference: International Oracle User Group Internal Oracle User Week Conference Proceedings. Fall 94, 95. Reference: Oracle Magazine Vol VIII, No. 6. Fall 94/95.
Oracle Designer/2000 If you are using Designer/2000 to develop your custom code you may be able to use this to track your configuration. Intersolv PVCS Intersolvs PVCS software configuration management products are integrated with Oracle Developer/2000 products and can be used to manage the code developed using the Oracle products. Web Site: For more information see Intersolvs World Wide Web home page, http://www.intersolv.com/
Oracle Method
CHAPTER
Figure 4-1
Oracle Method
Process Flow
Module Design and Build (MD)
PJM.CR.010: Scope, Objectives, and Approach ID.000 MD.020: Define and Estimate Custom Extensions BR.020: Business Requirement Mapping Form BR.040: Integration Fit Analysis BR.070: Master Report Tracking List RD.070: Business Requirement Scenarios ID.000 Database Designer RD.050: Process and Mapping Summary MD.050: Design Database Extensions MD.060: Module Functional Design ID.000 MD.060: Create Module Functional Designs
Module Designer
Programmer
Tester
Figure 4-2
Technical Expert
Module Designer
Database Designer
Programmer
ID.000 MD.110: Develop Custom Modules ID.000 TE.070: Perform Unit Test
ID.000 Tester TE.080: Perform Link Test MD.100: Custom Database Objects
Figure 4-2
Oracle Method
Approach
Module Design and Build focuses on the design and development of custom extensions to satisfy functionality gaps identified during Business Requirements Mapping. These custom extensions include: new forms new reports modified forms modified reports new concurrent programs database triggers zooms descriptive flexfields alerts new database objects extensions to existing database objects web pages application modules built with other tools Module Design and Build tasks are only required if the project team identifies gaps that cannot be satisfied with an acceptable combination of application features, manual steps, and procedural changes. Many projects commence with the goal of using the Applications in their vanilla configuration, with no customizations. However, even noncode customizations such as flexfields and alerts should be designed, implemented, and tested with the same rigor as other customizations. Attention: We use the terms customization and custom extension interchangeably to refer a custom solution to a business requirement. However, a customization may have many components and each is referred to as a module.
Choosing a Strategy
Select an appropriate customization strategy and communicate it to the project team. The acceptable level of customization and the design constraints will affect many mapping decisions. Decide first whether to consider customization. Prohibiting customizations produces the fastest and lowest cost implementation, but may force you to adjust your business policies and practices to fit the constraints of the Applications. Permitting or encouraging customizations will lead to a longer and more expensive implementation, but will give users exactly what they want. Unfortunately, any customizations will increase the effort each time you upgrade the Applications (including patches). If customization is allowed (or you discover that you ultimately require it), you must select the tools, define the process, and implement appropriate control mechanisms.
2. 3.
4.
5.
Oracle Method
6.
Module designers write a Module Functional Design (MD.060) and a Module Technical Design (MD.070) for each customization. One customization may include multiple modules. Module Designers create Link Test Scripts (TE.030) for each customization and Unit Test Scripts (TE.020) for each module. Programmers create Module Source Code (MD.110) for each customization. Testers Perform Unit Testing (TE.070) and Link Testing (TE.080) on the custom modules.
7. 8. 9.
Figure 4-3 shows the deliverables that support the identification, specification, construction, and testing of customizations and how they relate to one another.
Module A-1 Module A-2 Technical Design A Link Test Unit Test A A-1
Business Requirement Scenarios BRM BRM Forms BRM Forms Forms Solution Document
Functional Design A
Link Test A
Functional Design B
Technical Design B
Module B-1
Module B-3
Module B-2 Link Test Link Test A Link Test A Unit Test A B-1
Module B-4
Database Design
Link Test B
Figure 4-3
Designer/2000
CASE (Computer Aided Software Engineering) tools like Oracle Designer/2000 can both simplify and complicate the process of designing and building custom extensions. If you have many customizations or complex requirements, a CASE tool provides a shared repository of information that is easy to modify as requirements change. If you have very few customizations, you may not be able to justify the additional software costs, training expenses, and
administrative overhead required to use CASE tools productively. However, you can use Designer/2000 to facilitate the customization design and development in numerous ways: Take advantage of Designer/2000s shared repository for all design information. Generate a large portion of the technical design as reports from the Designer/2000 database. Design an integrated data model showing both standard and custom entities. Analyze how multiple modules use shared tables. Perform impact analysis to determine what modules are affected by database changes in a new release of Oracle Applications. Generate DDL (Data Definition Scripts) scripts to create custom database objects. Use the Applications Designer/2000 database from Oracle Development as a starting point for extensions. Attention: There are restrictions on the availability and use of the Applications Designer/2000 database. Contact Oracle Services or Oracle Applications Development for more information. If you already use Designer/2000 for other custom development, your developers can continue to use the same tools. Generate custom Forms and Reports from design information stored in the repository. Warning: The code you generate from Designer/2000 may require modification to be fully compliant with Oracle Applications standards. Designer/2000 does not support the following features: regeneration of the standard forms and reports included with Oracle Applications support for elaborate textual design information smooth integration with word processing tools
Oracle Method
automatic configuration of Applications setups or other features (such as menus, responsibilities, flexfields, alerts, and zooms) Designer/2000 has the following disadvantages: It requires specialized training. It consumes additional system resources. It may take longer to document simple customizations. Reference: Pirie, Mark. Designer/2000 for Oracle Applications Users Implementing and Customizing Release 10SC. Oracle White Paper, 1996. This paper is available from Oracles home page on the World Wide Web http://www.oracle.com/.
and link it to an existing form with a zoom. Database triggers can often be used to implement changes to processing logic. You can avoid the upgrade problems associated with code changes by building extensions, but you must still analyze the effects of database changes if your custom extensions access standard Applications tables. Also, the Applications may implement a new business rule that uses an existing database column in a different way. Configuration The safest technique is to use the features that Oracle has built into the Applications for customization. Upgrading the Application automatically preserves the flexfields, alerts, and zooms. However, you must still consider the effect of database changes on these modules. Reference: Kodjou, Paule. Architecting Your Applications Environment for the Development and Preservation of Customizations. OAUG Conference Proceedings, Spring 1996.
Oracle Method
Diagrams and examples can help clarify complex issues. The format and style is similar to the standard Oracle Applications reference manuals. The Module Technical Design (MD.070) includes all the detail that a programmer needs to build the required modules. This level of detail is important, even if the same person performs both the designer and programmer roles, because the documentation will be part of the Technical Reference Manual for the new system. You can use Designer/2000 or other CASE tools effectively to capture the technical specifications for custom modules, particularly the integration points with the database.
Scope Control
Scope creep (a gradual increase in scope) with no control mechanism can be a major challenge with custom development. Users like bells and whistles and programmers enjoy adding them; however, during mapping the entire project team must keep in mind the objective of minimizing customizations. Someone accountable for the project schedule and budget should approve the work estimates included in the Solution Documents. Thereafter, any changes that increase the estimated work must be reapproved. Likewise, approval of the Functional Design effectively freezes the functionality described therein. After design approval, a formal Change Request Form (PJM.CR.060) must be submitted by any users or team members who desire new functionality. Attention: Your projects Control and Reporting Procedures (PJM.CR.020) describes the formal change request process. Keep track of all requested changes and other unexpected conditions that affect the time required to design and build custom extensions. This helps you predict and control time overruns and will be useful when analyzing estimated versus actual effort. Reference: Work Management process, PJM Process and Task Reference.
Performance Considerations
An often overlooked aspect of custom design is the performance of the code. Developers may have the attitude: I will get it working and then
worry about performance. Unfortunately, due to time pressures, no one addresses the issue which causes problems in production. Designers and programmers must be familiar with performance tuning techniques for the tools they are using. Designers are responsible for designing the customizations with performance in mind and documenting potential performance issues in the Module Technical Design. This can be challenging because following the guidelines for upgrading customizations does not always lead to designs that optimize performance. Developers must work closely with the team conducting performance testing to make sure that custom modules with performance risks are included in the performance tests, as documented in the Performance Testing chapter of this book.
Oracle Method
ID MD.010 MD.020 MD.030 MD.040 MD.050 MD.060 MD.070 MD.080 MD.090 MD.100 MD.110 MD.120
Task Name Prepare Customization Strategy Define and Estimate Custom Extensions Define Design Standards Define Build Standards Design Database Extensions Produce Module Functional Design Produce Module Technical Design Review Detailed Designs Prepare Development Environment Implement Database Extensions Create Custom Modules Create Installation Routines
Table 4-1
Deliverable Name Customization Strategy Solution Document Design Standards Build Standards Database Extensions Design Module Functional Design Module Technical Design Approved Designs Development Environment Custom Database Objects Module Source Code Installation Routines
Objectives
The objectives of the Module Design and Build process are as follows: Design extensions to satisfy business needs not met with the standard Applications. Design solutions that you can easily maintain and upgrade to future releases of the Applications. Build modules according to the design specifications.
Key Deliverables
The key deliverables of this process follow: Deliverable Custom Database Objects Description New tables, indexes, views, sequences, grants, and synonyms required to support the custom extensions. A component of this deliverable is the scripts to create the new database objects in the production environment. A model and definition of the new and changed database objects and their relationships to standard application database objects. Operating System shell scripts, SQL Loader, or terminal keystroke files to install and configure custom extensions in the production environment. This may also include not easily scripted documented manual procedures for on-line setup that cannot be easily scripted. A description of the custom modules that is expressed in user terms. The User Reference Manual will incorporate this material Forms, Reports, SQL, PL/SQL, C and other code for the new modules. For non-coded modules such as flexfields and alerts, this represents the on-line implementation of these solutions.
Installation Routines
Oracle Method
Description Specifications for the program modules with sufficient technical detail that programmers can develop modules.
Table 4-2
Key Responsibilities
The following roles are required to perform the tasks within this process: Role Business Analyst Responsibility Provide requirements details to designer. Review functional designs. Design the database schema to support custom extensions. Define, estimate, and design custom extensions. Build the custom modules and perform initial unit tests. Provide direction on customization strategy. Final approval of proposed customizations. Prepare the development environment for build activities. Organize and direct design and build activities. Schedule and manage work and resources. Perform quality assurance reviews.
Database Designer
Module Designer
Programmer
Project Sponsor
System Administrator
Team Leader
Responsibility Responsible for the overall customization strategy and standards. Provide requirements details to designer. Review functional designs.
Module Design and Build Key Responsibilities
User
Table 4-3
Oracle Method
Reference: Kodjou, Paule. Architecting Your Applications Environment for the Development and Preservation of Customizations. OAUG Conference Proceedings, Spring 1996. Reference: Pirie, Mark. Designer/2000 for Oracle Applications Users Implementing and Customizing Release 10SC. Oracle White Paper, 1996. This paper is available from Oracles home page on the World Wide Web http://www.oracle.com. Reference: Kirwin, Ed. The Fine Line Between Pleasure and Pain Creating and Managing Oracle Applications Modifications. OAUG Conference Proceedings, Spring 1995. Reference: Kent, Daniel. Keeping It Clean: How to Customize Oracle Financials. OAUG Conference Proceedings, Spring 1995. Reference: Schrader White, Debi. Release 10 Customizations: Friend or Foe? OAUG Conference Proceedings, Spring 1995. Reference: Turner, Mark. Customize without Customizing. OAUG Conference Proceedings, Fall 1994. Reference: Sanders, Mike. Modifying Oracles Package Applications with No Software Changes. OAUG Conference Proceedings, Spring 1994.
Deliverable
The deliverable for this task is the Customization Strategy document.
Prerequisites
You need the following input for this task:
G G
The Scope, Objectives, and Approach describes the high-level customization approach and may include a list of known customization requirements. Quality Plan (PJM.CR.030)
The Quality Plan describes the quality assurance process for custom designs and programs.
Task Steps
The steps of this task follow: No. 1. 2. Task Step Review background materials. Define the customization policy. Determine the design tools you will use. Customization Policy Deliverable Component
3.
Design Tools
Oracle Method
No. 4.
Task Step Determine the development tools you will use. Describe the design and development process. Describe the approach to identifying solutions to functionality gaps. Define the estimating approach. Describe the Testing Process. Describe Upgrade Procedure.
5.
Development Process
6.
Mapping Approach
7.
Estimating Approach
8. 9.
Table 4-4
Query Tools If you plan to use an end-user reporting and query tool, your customization strategy should describe it and explain storage and catalogue procedures for user-developed reports and cataloged. Some query tools require significant setup and maintenance. You must also deal with database changes in new releases just as you would with any other custom reports. Flexfields Technically, flexfields are customizations, although fully supported by Oracle. Descriptive flexfields can vary in complexity from a few nonvalidated fields on a form to context-sensitive flexfields with complex validation rules. If your strategy includes the use of flexfields, emphasize the importance of standards and careful documentation. Extensions Only If you limit customizations to reports and other pure extensions, your strategy should make a distinction between extensions and modifications. Extensions add modules to the solution but do not change any code in the base application. Modifications change code in the Application and require significant analysis during upgrades. Because it is additive, some people may consider adding a field to a form or report to be an extension, but this is a pure modification that should be avoided. When you build new components and integrate them with the Applications, you take on the responsibility of maintaining and supporting the new components for your users. A formal help desk can ensure that help requests and problems are routed to the appropriate group for resolution (internal help desk versus Oracle Worldwide Support). For more information, see Implement Support Infrastructure (PM.060), Production Migration process. Full Customization When all types of customizations are permitted, your strategy should provide guidelines for when each type is appropriate. A modification should only be considered when the business need is vital, there are no procedural workarounds, and all other alternatives have been exhausted.
Oracle Method
Whenever you modify a standard application component, treat the modified module as if it is a custom component that you have designed and built from scratch. The original source and executable code must remain in its original location. The storage of the modified version must be in a custom directory structure and registered in the Application Object Library (AOL) as part of a custom application.
Database Objects
In special cases you must replace existing modules with customized versions to implement custom functionality. For example, to implement zooms in Smart Client forms, you must add code to a special code library provided with the Applications.
Analyzing the Impact of Upgrades Some of the possible impacts an upgrade or patch can have on various types of customizations are as follows: Custom Reports Custom Forms The underlying tables may change. The underlying tables may change. Shared library functions may change. The standard module may change and you must reapply your changes to the new version of the module or choose to keep your version and implement improvements to your code. The underlying tables may change. The business rules that cause the trigger to fire may change. The business rules that act on the data in tables you update may change. Same as Database Triggers. The underlying tables may change. The business rules that act on the data in tables you update may change. Oracle may eliminate functions that are included in your menus or add functions that you need to include. Oracle may eliminate menus or add new ones that affect your responsibilities. Zooms are highly dependent on the internal structure of a form and the order of fields, all of which may change. Oracle may add support for the functionality. You must decide how to migrate your data and procedures to the new standard functionality.
Database Triggers
Alerts Interfaces
Custom Menus
Custom Responsibilities
Zooms
Any Extension
Oracle Method
Reference: Kodjou, Paule. Architecting Your Applications Environment for the Development and Preservation of Customizations. OAUG Conference Proceedings, Spring 1996.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Expert Team Leader - Customization Project Sponsor
Table 4-5 Role Contribution for Prepare Customization Strategy
% 75 25 *
Deliverable Guidelines
The Customization Strategy should cover the following: general customization policy design tools and how they will be used development tools and how they will be used design review process and who must approve customizations valid approaches to resolve various types of functionality gaps estimating methodology and metrics testing process process to follow for patches and upgrades Some information in the Customization Strategy overlaps with the Scope, Objectives, and Approach (PJM.CR.010), the Quality Plan (PJM.CR.030), and the Testing Strategy (TE.010). However, the general
material found in those tasks contains greater detail in this deliverable and is available specifically for developers. Do not attempt to describe standards in the Customization Strategy because Design Standards (MD.030) and Build Standards (MD.040) are separate deliverables. The strategy focuses on policy, scope, techniques, and procedures. After you write the Design Standards and Build Standards documents, you may wish to combine them with the Customization Strategy and publish the set as an Application Customization Developers Guide. Make each deliverable a chapter of the consolidated document. This provides a single document that new developers on the project can read and reference.
Tools
Deliverable Template
Use the Customization Strategy template to create the entire deliverable or specific components of the deliverable. Choose from the following list of components and modify the content as needed: Customization Policy Design Tools Development Tools Development Process Mapping Approach Estimating Approach Testing Process Upgrade Procedure
Oracle Method
Deliverable
The deliverable for this task is a Solution Document. A Solution Document summarizes the business need that Oracle Applications features cannot meet and proposes a solution that includes a combination of custom components, manual workarounds, and existing application features. It also includes work estimates for designing, building, and testing the solution.
Prerequisites
You need the following input for this task:
G G G
The Customization Strategy provides guidance on the approach and extent of customization you can recommend. Business Requirements Mapping Form (BR.020)
The Business Requirements Mapping forms describe the detailed requirements of business requirements that standard functionality does not satisfy. Integration Fit Analysis (BR.040)
Integration Fit Analysis identifies the interfaces needed to meet integration requirements.
G G
Reporting Fit Analysis identifies new reports or report modifications needed to meet reporting requirements. Acceptance Certificate (BR.090)
Confirmation and approval of a business solution must be obtained before defining and estimating custom extensions.
Task Steps
The steps of this task follow: No. 1. 2. 3. Task Step Review detailed requirements. Determine potential solutions. Review alternatives with analysts and users. Select preferred solutions. Review estimating guidelines. Document estimating assumptions. Describe the custom components required for the business solution. Estimate the effort to design, build, and test customizations. Estimate the maximum number of resources that could work concurrently on each development task. Introduction Deliverable Component
4. 5. 6.
7.
Solution Section
8.
Solution Section
9.
Solution Section
Oracle Method
No. 10.
Task Step Summarize the custom extensions to the applications. Review final solutions and estimates with analysts, users, and management. Secure approval from all parties.
11.
12.
Table 4-6
the database. You have identified a missing entity if you have a set of information about an existing business object that can occur multiple times for each object. An example is shipping rates associated with a shipping method. The application supports shipping methods, but you need to store multiple rates for each method to support automated ship method selection. Data Elements Data elements are attributes of a supported business entity such as customers or inventory items. Descriptive flexfields can usually satisfy this need. Relationships Missing relationships such as associating a customer with preferred suppliers are actually a class of missing data elements and a descriptive flexfield can usually satisfy this need. However, if the relationship is many-to-many, the solution may require a new table to store the intersecting relationship. Basic data modeling techniques are helpful to clarify the requirements. Keep in mind that new tables will require custom forms to enter the information. Descriptive flexfields will often lead to report customization requirements. Reference: Barker, Richard. CASE*Method Entity Relationship Modeling. Addison-Wesley, 1990. Oracle Part Number 5456V1.0. Functionality Gaps Functionality gaps can vary in scope from missing business rules in a function that is supported, to missing functions or even missing systems. Business Rules If the gap is at the business rule level and procedural changes cannot address the situation, determine whether an event triggers invocation of the rule. If so, an alert or database trigger may suffice. If the required logic is part of a function that executes as a concurrent program, you may be able to create a new program that runs before or after the existing program. You can combine standard and custom concurrent programs using Report Sets.
Oracle Method
Reference: Application Object Library Reference Manual. Oracle Part Number A12535. You can use views to dynamically transform the representation of data in standard tables so that standard application functions operate on the altered data to produce a new result. For example, if you wanted the cost roll-up process in Oracle Cost Management to use a different accumulation rule, you could use a view of a Bills of Material table to present altered values for the columns included in the calculation. You have not modified the standard tables nor the cost roll-up program, but you have implemented a new processing rule. Reference: Mercer, David. Views That Masquerade as Tables. OAUG Conference Proceedings, Spring 1995. Oracle Applications includes a number of special PL/SQL routines specifically designed to allow you to add your own custom logic to adjust the processing logic of standard functions. For example, if you need to modify the information that the MRP process in Oracle Master Scheduling/MRP collects during the snapshot phase of the planning process, you can add logic to the PL/SQL stored procedure called Mrp_user_defined_snapshot_task. This procedure is an empty procedure that the MRP process calls before beginning the detailed planning process. Thus, you can alter the inputs to MRP without changing any of the internal MRP code. The source code that you must copy and modify is located in $MRP_TOP/install/sql/mrppl07.sql. Attention: Consult your Application Technical Reference manuals for more information on this and other supported customization hooks. Functions You can supplant missing functions with standalone forms, reports, or concurrent programs. You can integrate custom forms with standard forms using zooms. Systems Missing systems or large collections of related functions may require a supplemental CDM (Custom Development Method) subproject to design, build, test, and integrate with the core applications. Another alternative is to procure a third-party package that addresses the requirements.
Timing
You need not wait until all mapping is complete to begin defining and estimating customizations. You can begin writing parts of the solution document as soon as you identify a gap and propose a custom solution. You will identify some gaps early during Requirements Definition while others may not surface until you begin testing business solutions.
Estimating Guidelines
For each business requirement not fully satisfied by the standard Oracle Applications, summarize the amount of effort you estimate it will take to build custom extensions that close the functionality gaps. Identify Components In order to accurately estimate the effort, you must first identify all of the custom elements which can include any of the following: new or modified forms new or modified reports new or modified programs (SQL*Plus, PL/SQL, Pro*C) database triggers user exits SQL*Loader scripts Standard Report Submission parameters alerts new tables descriptive flexfields zooms Some relatively simple requirements actually translate into several components to implement correctly. For example, the implementation of adding a new zone to a form should be as a new form with a zoom (to avoid direct modification of the original form). A new table is also required if the information in the zone represents a many-to-one relationship.
Oracle Method
Assign Complexity For each component, rank the complexity as very easy (VE), easy (E), moderate (M), or complex (C). For estimating purposes, consider stored procedures, database triggers, user exits, and SQL*Loader scripts as programs. Treat alerts as reports, unless they serve primarily as database triggers, in which case you should treat them as programs. Classify zooms, descriptive flexfields, and setting up Standard Report Submission parameters as form modifications. Basic guidelines for ranking each type of module are listed in tables 4-7 through 4-9. Form Rating Very Easy New Low risk, single-block form with 8 or fewer columns. No special functional logic required. Modified Minor change such as changing form text or navigation. No changes to form processing or underlying table structure. Also, simple descriptive flexfield definitions are classified as Very Easy form modifications. Changes to form processing (field validations, formats) or adding fields. Descriptive flexfields with lookup table validation or crossvalidation. Many new fields, logic, or table structures are being redesigned and built.
Easy
Single or multiple block (2-3 blocks) with 20 or fewer columns. Minor functional logic (simple edits, cross edits, simple calculations, totals or subtotals) required. Single or multiple block (2-3) with greater than 20 columns. Significant functional logic (edits, calculations, calling other forms, flexfield validations).
Moderate
Rating Complex
New Multiple block (3 or more) with more than 20 columns. Requires extensive or complex functional logic, one or more user exit calls (user exits should be estimated separately as programs). Navigation or display logic which is unusual for Oracle Forms or Application Object Library.
Modified Major changes to form processing, many additional fields or additional zones, changes to base tables, and so on. Rarely done due to complexity and risk. Usually better to start over with a new custom form.
Table 4-7
Attention: The design philosophy for Release 10SC is based on an object-oriented paradigm where a single gateway form allows you to perform any function you need for a given business object. If you are designing a new 10SC form for a new business object, estimate the gateway form and each sub-function as separate forms. Report Rating Very Easy New Simple report consisting of one SQL statement. Minimal formatting. Some formatting and processing logic of one or two tables. Modified Changes to the format only.
Easy
Changes some formatting, adding one or two columns with little or no changes in processing logic.
Oracle Method
Rating Moderate
New Several tables queried (perhaps master-detail) and significant processing logic or formatting. Complex processing logic and report formatting. Multiple table reporting hierarchy or crosstabulation.
Modified Many changes to report format and or reported data. Perhaps accessing additional tables. Major changes to report format and processing. Often better to begin fresh with a new report.
Complex
Table 4-8
Program Rating Very Easy New Script which operates on a single table. A database trigger that inserts a row into another table would be an example. Updates to 2-3 tables with minimal conditional logic or looping. Updates to 3 or more tables with some conditional logic, calculations, and looping. Updates to 5 or more tables with sophisticated conditional logic, calculations, and looping.
Complexity Guidelines for a Custom Program
Easy
Moderate
Complex
Table 4-9
Attention: The rating of Pro*C programs should be one level higher than other types of programs due to the inherent complexity of linking and debugging. Use your own judgment for menu and table complexity.
Calculate Base Estimates Consult your Customization Strategy (MD.010) for the proper estimating parameters for your project. It should have a table listing raw design and build numbers for each combination of type and complexity. Calculate the total effort in person days for design and build by multiplying the number of modules of each type by the base estimates. If you think a new form, report, or program is very complex (more difficult than the complex rating), use an appropriate estimate based on your past experience. Although the base metrics and guidelines are useful, they are not a substitute for experience. Sometimes a relatively minor customization requires significant testing because it is in a complex business area or requires significant preliminary setup to test (such as material requirements planning). If you are working with a beta release of the Applications or are planning to implement new development tools and technology, increase the default estimating factors to allow for the learning curve and potential instability of your environment. Make sure you identify all custom components. If new tables are a requirement, you will probably need new forms to maintain them (unless they are interface tables). Each report and concurrent program requires Standard Report Submission parameters or a custom launch form. Calculate Extended Estimates For simplicity, the base metrics in the Customization Strategy supply only raw design and build numbers. However, you must extend these to estimate the effort of the other development tasks. Use your totals to calculate the effort for other tasks according to the formulas in Table 410. Task Module Design and Build Process Produce Module Functional Design Produce Module Technical Design Create Custom Modules .75 * design .6 * design build Estimating Formula
Oracle Method
Task Create Installation Routines Business System Testing Process Prepare Unit Test Scripts Prepare Link Test Scripts Perform Unit Test Perform Link Test
Table 4-10 Formulas to extend base estimates to other development and testing tasks
Recommend Staffing Limits For each development task, indicate the maximum number of resources that could reasonably work on the modules of the customization simultaneously. This is purely a judgment call. If a single customization requires several forms and reports, you might be able to divide the design and development work between two or three resources without losing efficiency.
Project Planning
After management has approved the customizations, add new tasks to the project plan using your calculated estimates as the basis for work effort. If multiple people will perform the design and/or build, you may want to divide the build task into sub-tasks for each component of the customization so that you can assign resources individually and perform accurate resource leveling.
Role Contribution
The percentage of total task time required for each role follows: Role Module Designer % 70
% 30 * * *
Deliverable Guidelines
You describe and estimate all modifications, custom extensions, and interfaces using the Solution Document. Typically you will create one solution document for each major business area or process plus one each for interfaces, reports, and custom support systems. Attention: The Data Conversion process of AIM includes tasks to estimate the effort to design, build, and test conversion programs. The solutions outlined in the Solution Document should be brief no longer than one or two pages each. Include enough detail to identify all the custom components and make it clear how the components work together, but do not attempt to write a complete design document. Use the Business Requirements Mapping Form (BR.020) to derive and summarize the requirements for each solution. Describe the total solution and include basic references to the following elements: standard Oracle Applications features manual procedures custom extensions In your solution summary, communicate the overall approach and present one or more alternatives to filling these functionality gaps. Each approach may have pros and cons as well as time and cost differences.
Oracle Method
Management, analysts, and users may not be able to choose the preferred approach until you provide detailed estimates for each option. In the Solution Document, it is acceptable to use a mixture of functional and technical language. The goal is to communicate concisely the nature of the customization. Include the following information: the amount of effort required to analyze, design, build, and test custom code the time required to upgrade the customizations to a future release of Oracle Applications a summary of the total solution effort As a summary, create a list of all custom solutions in the document. This list (Master Custom Extension Worksheet) shows the following information: unique identifier brief description of requirement assignment and staffing lists subtotal of all customization design, development, and build work subtotal of upgrade estimates target due date The subtotals become an input to planning the detailed design, build, and testing tasks.
Tools
Deliverable Template
Use the Solution Document template to create this deliverable. The Solution Document template includes the following components: Introduction Solution Section Master Custom Extension Worksheet
Suggestion: To improve your understanding, use the Solution Document template while reading the instructions below. Solution Section Each time you insert a Solution Section, a prompt will ask you for the name of the Business Issue and a Unique Identifier for the issue, as shown in Figure 4-4.
Figure 4-4
The unique identifier should come from the BRS or BRM form. Insert additional business issues by selecting Insert Boilerplate from the OM pull-down menu. Be sure you move your cursor to the correct location in your document before inserting the new section. Estimating Worksheet The Solution Section includes an estimating worksheet (it is a standard Word table, not an embedded Excel worksheet). Use the estimating section to estimate the number of person days required to implement the solution. Use this table to describe the modules and assign complexity ratings. Position your cursor in the Type or Rating column and press Ctrl-L to select from a list of customization types and complexity ratings, respectively. The template will automatically insert the estimating factors for design, build, and upgrade activities from the table in the Introduction section. When you finish, double click on the red button to update the totals. Table 4-12 shows one custom form with base and extended metrics.
Oracle Method
Rating M
Design 3
Build 5
Upgrade 1.6
SUBTOTALS
1.6
Design Create Functional Design Create Technical Design Develop Link Test Scripts Develop Unit Test Scripts Create Custom Modules Perform Unit Tests Perform Link Tests Create Installation Routines TOTALS 4.0 2.25 1.8
Build
Test
GRAND TOTAL TOTAL UPGRADE Table 4-12 Sample Solution Document Estimating Worksheet
12.3 1.9
Recommended Staffing In the last part of the Solution Section you enter recommended staffing levels. Enter the maximum reasonable number of people who could work on each development phase simultaneously. The project manager uses this information to plan the customization activities and schedule resources, as shown in Table 4-13.
Development Task Create Functional Design Create Technical Design Develop Link Test Scripts Develop Unit Test Scripts Create Custom Modules Perform Unit Tests Perform Link Tests Create Installation Routines Table 4-13
Functional 1
Technical
1 1 1 1 1 2 1
Master Custom Extension Worksheet Use the Master Custom Extension Worksheet to maintain a high-level record of all customizations to the Applications.
Oracle Method
Deliverable
The deliverable for this task is a Design Standards document.
Prerequisites
You need the following input for this task:
G G G G
The Customization Strategy defines the development tools and valid scope of customizations and will dictate what standards you need to document. Solution Document (MD.020)
The Solution Document defines all of the customizations and establishes the requirements of the modules. Quality Plan (PJM.CR.030)
The Quality Plan includes general documentation and review standards that also apply to design documents. Company-Specific Standards
Consider any standards that your company has already defined for custom development.
G G
Oracle Applications Object Library Reference Manual (Oracle Part Number A12535)
The Oracle Applications Object Library Reference Manual provides general guidelines for designing customizations to the Applications. Oracle Applications User Interface Standards (Oracle Part Number A31209)
Oracle Applications User Interface Standards describes the standards for building forms using Oracle Forms 4.5.
Task Steps
The steps of this task follow: No. 1. Task Step Determine source(s) of standards. Review existing Oracle and company standards. Define Design Document components. Define Topical Essay standards. Define form cosmetic standards. Define report cosmetic standards. Define database design standards. Define interface standards (messages, error codes, dialog interaction). Design Document Components Topical Essay Standards Deliverable Component
2.
3.
4.
5.
6.
7.
8.
Interface standards
Oracle Method
No. 9.
Task Step Review standards with the project team. Configure Designer/2000 preferences (if applicable).
Deliverable Component
10.
Table 4-14
consistent is consistent with existing standards and your development philosophy; it is self-consistent as well easy to use leverages off of existing standards and tools and increases your productivity; it is not awkward or impractical
Oracle Method
Reference: Oracle Applications User Interface Standards. Oracle Part Number A31209. Note: Oracle Applications User Interface Standards only covers standards for building forms with Designer/2000. It does not include report standards.
Designer/2000
If you are using Designer/2000 to design custom modules and plan to generate default forms and reports, this task includes a step to configure the preferences information that determines the layout and logic of default modules. Reference: Designer/2000 Documentation Bundle. Oracle Part Number A34876.
Role Contribution
The percentage of total task time required for each role follows: Role Technical Expert Team Leader - Customization
Table 4-15 Role Contribution for Define Design Standards
% 90 10
Deliverable Guidelines
The Design Standards document is the deliverable for this task. This document describes the standards you adopt for designing future customizations and extensions to Oracle Applications. Include the following important information in this document: cosmetic and content standards for design documents description of design environment (file system structure and tool) naming standards user interface and cosmetic standards sample documents and/or templates When making customizations to Oracle Applications, follow the cosmetic and coding standards of the Applications as closely as possible. Reference: Oracle Applications Object Library Reference Manual. Oracle Part Number A12535. Reference: Oracle Applications User Interface Standards. Oracle Part Number A31209. Reference: Oracle Applications Coding Standards. Oracle Part Number C10070.
Oracle Method
Tools
Deliverable Template
Use the Design Standards template to create the deliverable for this task. Select from the following choices to represent the standards you will use for designing customizations: Overview Design Document Components Topical Essay Standards Form Cosmetic Standards Report Cosmetic Standards Database Design Standards Interface Standards
Deliverable
The Build Standards document is the deliverable for this task.
Prerequisites
You need the following input for this task:
G G G G G
The Customization Strategy defines the development tools and valid scope of customizations and dictates what standards you need to document. Design Standards (MD.030)
The Build Standards must support and compliment the Design Standards. Company-Specific Standards
Consider any standards that your company has already defined for custom development. Oracle Applications User Interface Standards
This document is an input to Define Design Standards (MD.030), but also includes information relevant to Define Build Standards (MD.040). Oracle Applications Coding Standards
The Oracle Applications Coding Standards defines the standards followed by developers at Oracle to build Oracle Applications. Your standards should reference these standards as the basis for all development and
Oracle Method
define only those standards that are different or are not defined within this manual and the Oracle Applications User Interface Standards.
Task Steps
The steps of this task follow: No. 1. Task Step Determine source(s) of standards. Review existing Oracle and company standards. Define forms coding standards. Define report coding standards. Define SQL standards. Define PL/SQL standards. Define database trigger standards. Define coding standards for any other tools. Define Comment Standards. Define installation routine standards. Prepare module templates and examples. Review standards with development team.
Task Steps for Define Build Standards
Deliverable Component
2.
3.
4.
5. 6. 7.
8.
9. 10.
11.
12.
Table 4-16
Oracle Method
For Applications Release 10SC, the definition of standards for building graphical forms with Oracle Forms 4.5 is in the Oracle Applications Coding Standards Manual. Your standards should incorporate and extend the standards defined by Oracle. Reference: Oracle Applications Coding Standards Manual. Oracle Part Number C10070 Oracle has not documented the standards for writing other types of modules, but you can examine the source code provided with the Applications to derive common standards. Source code is provided for: Oracle Reports PL/SQL stored procedures and triggers SQL*Plus and PL/SQL concurrent programs Alerts Flexfields Zooms Messages
Role Contribution
The percentage of total task time required for each role follows: Role Technical Expert Team Leader - Customization
Table 4-17 Role Contribution for Define Build Standards
% 90 10
Deliverable Guidelines
Your Build Standards document organization should be such that developers can find the information they need easily. Your document can cover the following topics for each type of module: naming conventions standard file headers comments structure and style debugging techniques variable naming and usage performance improvement techniques exception handling error messages porting considerations
Code Samples
If possible, include samples of programs that follow the standards as an appendix. For modules that do not have a text representation of source code, you can use screen shots or reference a sample file on the development server.
Tools
Deliverable Template
Use the Design Standards template to create the entire deliverable or specific components of the deliverable. Choose from the following list of components and modify the content as needed: Overview Forms Coding Standards Report Coding Standards
Oracle Method
SQL Standards PL/SQL standards Database Trigger Standards Other Coding Standards Comment Standards Installation Routine Standards
Deliverable
The deliverable for this task is the Database Extensions Design. It includes an Entity Relationship (ER) diagram, definitions of new database objects, and a description of how the new modules will access these objects.
Prerequisites
You need the following input for this task:
G G G G
The Solution Documents include information on required database extensions to support the defined solutions. Design Standards (MD.030)
The Design Standards include a component called Database Design Standards that govern how you design new database objects. Business Data Mapping Form (BR.030)
The Business Data Mapping Form includes a list of attributes for each business object that the Oracle Applications does not support. Descriptive flexfields or new tables can satisfy these requirements. Oracle Technical Reference Manuals
The Technical Reference Manuals for the Applications contain database diagrams and table descriptions for each Applications product.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Review customization data requirements. Create integrated data model. Define logical database. Define indexes. Define physical database parameters. Create flexfield design. Review design with module designers.
Task Steps for Design Database Extensions
Deliverable Component
2. 3. 4. 5.
Data Model Logical Database Design Index Design Physical Database Design
6. 7.
Flexfield Design
Table 4-18
Descriptive Flexfields
Descriptive flexfields are a type of database extension that do not require any new tables or columns. However, because several modules may use flexfields on the same table for different reasons, it is important
Oracle Method
to have a single point of contact to manage the flexfield definitions for application entities. Coordinate with business analysts who need to define flexfield setup parameters as part of Define Application Setups (BR.110). In a multi-site implementation, this activity is very important because each site may have different requirements for descriptive flexfields and you may need a single definition that satisfies all requirements. You may need a global data registry to fully satisfy your requirements. For more information, see Application and Technical Architecture process.
Role Contribution
The percentage of total task time required for each role follows: Role Database Designer Module Designer
Table 4-19 Role Contribution for Design Database Extensions
% 60 40
Deliverable Guidelines
Deliverable Components
Your Database Design must capture and document both the logical data representation and the physical database design. It should include the following components: Data Model Logical Database Design Index Design Physical Database Design Flexfield Design
Data Model The data model provides a graphical representation of new business objects and entities in the form of an E/R Diagram. Include existing application entities and the relationships between standard and new entities. Logical Database Design In the logical database design, you transform the business data model into the specific tables and columns required to support the requirements. You transform relationships into foreign key columns or intersection tables. If your custom solution involves views, grants, and synonyms, you must include definitions for each. Because of the nature of business requirements mapping, you may actually start with the logical design because your analysis is already at a very granular level and work backwards to construct the data model to provide a graphical business view. Index Design After defining the tables and columns, decide what columns to index and the type of index required. Your decisions will be based on the specific data usage by custom modules and anticipated data volume. Physical Database Design The physical database design assigns the specific Oracle tablespace and sizing parameters for each table and index. You must consider the growth and usage properties of the data. For large tables with high query loads, you should consider disk striping strategies. Flexfield Design Use the Flexfield Design component to record common flexfield definitions across business areas. Some flexfield requirements may not surface until later when module designers are preparing the functional or technical design documents. This component acts as an ongoing repository of information throughout the design process.
Oracle Method
Suggestion: If you do not have other database extensions, you can rename this deliverable Flexfield Design since that will be the primary content. Your primary input will be the Solution Document (MD.020) and the Business Data Mapping Form (BR.030).
Tools
Deliverable Template
Use the Database Design template to create the entire deliverable or specific components of the deliverable. Choose from the following list of components and modify the content as needed: Overview Data Model Logical Database Design Index Design Physical Database Design Flexfield Design
Designer/2000
Use Designer/2000 to create the integrated data model and transform it into the logical database design. You can also specify the Index Design and Physical Database Design. Assemble your document by printing Designer/2000 reports and assembling them for review and approval. Use Designer/2000 to generate DDL scripts from the information in the Designer/2000 database. If you later need to make changes to the database definitions, you should modify the information in Designer/2000 first and then generate new DDL scripts for future installations.
Visio
You can use the Oracle Entity Relationship Diagramming template to create your integrated data model.
Deliverable
The deliverable for this task is a Module Functional Design document that describes each customization in business and user terms. Users and business analysts are the audience for this deliverable. Therefore, it must communicate all the features provided by the customization in non-technical terms.
Prerequisites
Required
You need the following input for this task:
G G G G
Business Requirement Scenarios describe requirements in the context of business flows. Business Requirement Mapping Form (BR.020)
Business Requirement Mapping Forms provide detailed business requirements for functionality gaps. Solution Document (MD.020)
The Solution Document describes the high-level solution and required custom components to solve each functionality gap. Design Standards (MD.030)
Design Standards define the format and content of design deliverables, plus cosmetic and interface standards for forms and reports.
Oracle Method
Optional
You may need the following input for this task:
G G
Process Narratives include the detailed process steps that users will follow to perform their jobs. You only need the narratives corresponding to the processes that have functionality gaps. They should already incorporate steps that correspond to custom components identified in the Solution document. Application Setup Document (BR.110)
The Application Setup document defines setups that may affect the logic and business rules you define. You also need to know what options will be available for QuickPicks in custom forms and standard report submission parameters.
Task Steps
The steps of this task follow: No. 1. Task Step Review Business Requirements Mapping deliverables. Write the topical essay. Document forms. Document reports. Document concurrent programs. Describe technical approach. Review high-level design with analysts and key users. Topical Essay Form Descriptions Report Descriptions Concurrent Program Descriptions Technical Overview Deliverable Component
2. 3. 4. 5.
6. 7.
No. 8.
Table 4-20
Oracle Method
only gives the readers a format that they understand and are comfortable with, it also allows you to easily compile the User Reference Manual (DO.100) for custom modules. As you write, consider your eventual reader as someone who must understand the new functionality, but who has not participated in any mapping sessions or discussions that led to this design. Include useful information on each form field so that they can read your description while using the form (or reading a report) and know where and how the information they see is used (or how it was derived). The form, zone, and field descriptions you write may be converted into on-line help text. Indicate whether each field is required, if a list of values (QuickPick) is available, and if so, the meaning of each possible value. If the requirements call for special validation or enforcement of business rules, explain these features clearly. Ask yourself if what you write would be helpful to someone using the form for the first time.
Developer/2000
Use Developer/2000 to lay out new forms and reports and then incorporate screen shots into your design document. For simply laying out a basic form, Oracle Forms is as easy to use as your word processor and gives you a jump start on the build tasks.
Role Contribution
The percentage of total task time required for each role follows: Role Module Designer Business Analyst Users
Table 4-21 Role Contribution for Produce Module Functional Design
% 80 20 *
Deliverable Guidelines
Deliverable Components
A functional design consists of the following components: Topical Essay Form Descriptions Report Descriptions Concurrent Program Descriptions Topical Essay The topical essay introduces the functionality provided by the customization in the context of the underlying business process. It provides an overview that is easy to read and understand and the format is familiar to anyone who has read the Oracle Applications Reference Manuals. A topical essay includes the following elements: basic business needs major features user procedures
Oracle Method
You can also add any of the following to clarify issues: process flow examples business rules charts and tables data flow diagram entity relationship diagram assumptions Form and Report Descriptions Form and report descriptions are important Functional design components because they are the external elements that are most visible to system users. These components must fit into the bigger picture of business process flows. The Functional Design deliverable helps users see this fit and understand the functionality in the context of business processes. Consider the following features when creating functional designs: report and screen layout size constraints complexity and readability of information (field sizes) order in which information is presented QuickPick options hints or text identifying data sort options (if any) query criteria (if any) source of data standard layout conventions design standards mandatory and optional input parameters data manipulation rules (create, read, update, delete) naming conventions
Use the Form Description format to describe descriptive flexfields. Concurrent Program Descriptions Concurrent programs are similar to reports (reports are actually a type of concurrent program), but the primary function of a concurrent program is to update data in the database. The output is typically a log of actions performed. Your functional description will focus on several factors: when to run the program launch parameters business rules implemented log output restart procedures Technical Overview An optional component of the Functional Design is a technical overview describing the implementation of the functionality. This is most useful when the solution requires a combination of flexfields, alerts, database triggers, or views to achieve the desired results. A technical overview is also the first component of the Technical Design, so you can transfer whatever you include in the Functional Design directly to the Technical Design and expand on it.
Tools
Deliverable Template
Use the Module Functional Design template to create this deliverable. Choose from the following list of components and modify the content as needed: Topical Essay Form Description Report Description Concurrent Program Description
Oracle Method
Technical Overview Open and Closed Issues Select the Insert Boilerplate option under the OM menu to add form, report, and concurrent program descriptions for each custom module. Include other components only once.
Deliverable
The deliverable for this task is a Module Technical Design document for each customization that includes all the technical details for each module. The audience for this document is a programmer. It must provide all the information that a programmer needs to code the custom components.
Prerequisites
You need the following input for this task:
G G G G
Database Extension Design defines custom database objects required for custom extensions. You do not create these database objects during this task, but you may need sizing information to allocate database space. Module Functional Design (MD.060)
The Module Functional Design describes the functionality that the technical design must support. Every feature and business rule described in the functional design must have supporting logic detailed in the technical design. Design Standards (MD.030)
Design Standards define the format and content standards for design deliverables. Build Standards (MD.040)
Build Standards define the standards for building custom modules. Some standards may impact the technical design.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Review Module Functional design document. Describe high-level approach. Define detailed program logic for modules (forms, reports, and programs). Document integration issues. List installation requirements. Update Module Functional Design as needed.
Task Steps for Produce Module Technical Design
Deliverable Component
2. 3.
4. 5. 6.
Table 4-22
Designer/2000
Much of the design can be entered directly into a Designer/2000, but you may need to combine Designer/2000 reports with descriptive text
you create outside of the tool into a final document for distribution and review. You can find the specific guidelines on the format and content of the design document, including the use of Designer/2000 or other CASE tools, in the Design Standards document for your project.
Prototyping
Prototyping is a technique that uses development tools to interactively design custom modules. It is different from the prototyping technique used in the mapping process. During mapping, prototyping uses the standard applications to confirm and demonstrate support for business processes. With custom design, prototyping uses partially created code to design and illustrate new functionality. Prototyping components of the solution can be a good way to review and validate the concepts with users. This is most useful with forms because users can interact with the design instead of merely reading a static description. Prototypes may not include all of the required logic, but can illustrate the basic look and feel. If a Designer/2000 Generator will be used to build the final forms, you can also generate preliminary prototypes easily. Prototyping is useful for components such as database triggers when you are not sure if a proposed trigger will produce the desired result. The prototype may be a quick and dirty test that you will refine in the final version. Reference: For more information on prototyping techniques, refer to the CDM Method Handbook. Oracle Part Number C10983-1.
Oracle Method
a new form with the required zone information and build a zoom to link the two forms. Use descriptive flexfields whenever you need additional data elements instead of modifying standard tables. Reference: Turner, Mark. Customize Without Customizing. OAUG Conference Proceedings, Fall 1994. Custom ORACLE IDs An ORACLE ID identifies a registered database user that is in the Application Object Library. Each standard Oracle Application has a corresponding ORACLE ID. Define all custom tables in an ORACLE ID you create for your custom application. Use a prefix such as CSTM or an appropriate acronym for your company to distinguish custom ORACLE IDs and tables from standard ones. For example, if you create a custom Purchasing form that updates a custom table, you would create the table in the CSTMPO ORACLE ID and name the table something like CSTMPO_HEADER_DETAILS. Grants and synonyms allow your form and other custom programs to access the custom table. In release 10.6 and beyond, all Applications access tables from the APPS ORACLE ID. This special ORACLE ID primarily contains synonyms to access tables in other ORACLE IDs. You also need grants from your custom ORACLE ID to APPS and corresponding synonyms in APPS so your forms and programs can access your custom tables. Reference: Application Object Library Reference Manual. Oracle Part Number A12535. Database Triggers and Post-Processors If a change in the standard processing logic must take place, consider using a database trigger or post-processor that runs after a standard program to implement the required logic. This is an extremely powerful technique that allows you to implement special rules without changing any standard application code.
Designer/2000
One of the best ways to use Designer/2000 is to capture custom module definitions. You can define basic module information and the module to table relationships (create, read, update, and delete). You can even capture this information at the column level. This allows you to run
reports to determine what custom modules are affected by changes to tables and columns during an upgrade. Oracle publishes a Database Changes Manual with each major Applications upgrade. Use this manual together with the information in your Designer/2000 repository to perform impact analysis.
Role Contribution
The percentage of total task time required for each role follows: Role Module Designer Programmer
Table 4-23 Role Contribution for Produce Module Technical Design
% 90 10
Deliverable Guidelines
Deliverable Components
The technical designs provide a road map for building and testing custom system modules. Technical design components are very specific; they use a technical language to describe the construction of form and program logic, database entities, and system integration. Technical Design Your Technical Design should include the following components: form logic report logic program logic flexfield definitions zoom definitions integration issues
Oracle Method
installation requirements Form, report, and program logic components include: input and output parameters tables accessed structured English pseudo-code selection and sort criteria calls to other function libraries default values source files and tables destination files and tables performance issues conversion issues This is a technical task that requires highly specialized skills. You may need to subcontract external resources to help you with this task.
Tools
Deliverable Template
Use the Module Technical Design template to create the deliverable for this task. Choose from the following components to create your document: Overview Form Logic Program Logic Database Design Integration Issues Installation Requirements Open and Closed Issues
Select the Insert Boilerplate option under the OM menu to add new components for each custom module. Include other components only once. Add the Implementation Notes component after building the customization. For specific information on each component of the design document, consult the Design Standards (MD.030) for your project.
Designer/2000
Oracles suite of CASE products provides the features you need to support the development of customizations. At a minimum, use Designer/2000 to document database extensions and record module-totable cross references for upgrade impact analysis. Suggestion: It is possible to integrate CASE information with Microsoft Word for Windows using Dynamic Data Exchange (DDE) and Oracle Glue, but the current AIM deliverable templates do not exploit this technology.
Oracle Method
Deliverable
The deliverable for this task is Approved Designs. Confirmation of the approvals is an Acceptance Certificate (PJM.CR.080) for each design. The Acceptance Certificate should be signed by at least the following individuals: business Analyst who identified the requirements user (a representative of the people who will be using the new functionality) programmer who will code the modules (or an alternate representative who can confirm that the design contains adequate technical detail)
Prerequisites
Required
You need the following input for this task:
G G
This is the primary document that business analysts and users will review. Module Technical Design (MD.070)
G
Optional
Contains the estimated work effort to complete build and testing. You will need to confirm or adjust these estimates based on information learned during the design tasks.
G
Describes the original requirements for the customizations. You may need to reference these to resolve issues.
Task Steps
The steps of this task follow: No. 1. Task Step Distribute designs prior to meeting. Present an overview of each design. Address issues and questions. Walk through the detail with developers. Update designs as needed. Obtain approval from developers and team. Signed Acceptance Certificate Deliverable Component Review Comment List
2.
3. 4.
5. 6.
Table 4-24
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Business Analyst Module Designer Programmer Team Leader - Customization Business Line Manager % 30 30 30 10 *
Role User
Table 4-25 Role Contribution for Review Detailed Designs
% *
Deliverable Guidelines
This deliverable represents an acknowledgment that all relevant parties involved have reviewed the design documents and agree on the approach, content, and functionality described therein. The deliverable serves as a formal record of the parties agreement and authorizes the project to move forward to subsequent build and test activities. The parties usually note any desired changes and agree on a course of action to implement those changes. Include the following information in the meeting notes: name of deliverable being confirmed type and status of deliverable objectives of deliverable agreements (expressed in terms of planned future actions or policy changes) key decisions key assumptions exceptions or references to components requiring changes control (signatures of approvers and initiators, dates, revisions, and so on) future direction You can file this document as an appendix to the complete design to clarify any issues encountered later. You can prepare a separate Acceptance Certificate for each design or use the signature area on the front of the documents (if you use an
Oracle Method
Acceptance Certificate you should delete the signature area from the documents).
Tools
Deliverable Templates
Use the following Project Management templates to support this task: Review Comment List Acceptance Certificate Review Comments List (PJM.QM.020) Use the Review Comments List template in the Project Management -> Quality Management menu to record comments and required actions identified during the review. You can include a Review Comments List with the design documents when you distribute them prior to the review session. Reference: Review Comments List (PJM.QM.020), Resource Management process PJM Deliverable Reference. Oracle Part Number C10978-1. Acceptance Certificate (PJM.CR.080) Use the Acceptance Certificate template in the Project Management -> Control and Reporting menu to prepare the final design Acceptance Certificate. Reference: Acceptance Certificate (PJM.CR.080), Control and Reporting process. PJM Deliverable Reference. Oracle Part Number C10978-1.
Deliverable
The deliverable for this task is a Development Environment with supporting documentation. Document the new environment by creating an Installation Plan and Record (PJM.RM.050) document.
Prerequisites
You need the following input for this task:
G G G G G
This PJM deliverable outlines the plan for all computer environments needed to support the implementation, including the development environment. Application Setup Document (BR.110)
The Application Setup documents required setups to support the business solutions. Design Standards (MD.030)
Design Standards describe design tools that you must install and configure in the development environment. Build Standards (MD.040)
Build Standards describe development tools that you must install and configure in the development environment. Database Extensions Design (MD.050)
Database Extensions Design defines custom database objects required for custom extensions. You do not create these database objects during
Oracle Method
this task, but you may need sizing information to allocate database space.
Task Steps
The steps of this task follow: No. 1. Task Step Determine the need of a new Applications install or if an existing environment is usable. Confirm application and database sizing for development environment. Install development servers. Install operating system on servers. Connect servers to network. Create operating system user accounts on servers. Configure file system on servers. Completed Application Sizing Summary Deliverable Component
2.
3. 4.
Installed servers Installed operating systems on servers Servers connected to network User accounts on servers
5. 6.
7.
File systems configured for development operations. Disk Device Map Installed Database instance(s)
8.
Install Oracle database on database servers. Install Oracle Applications on clients and servers.
9.
Installed Oracle Applications; Application Load Estimate; Tablespace Worksheet; User Account List Verified Concurrent Managers
10.
No. 11.
Task Step Verify functioning of Oracle Applications and Database functioning. Install and configure design tools. Install and configure development tools. Install and configure source control software. Create directories for custom applications and extensions. Register custom applications.
Deliverable Component Verified Oracle Applications and Database Installation QA Checklist Installed design tools
12.
13.
14
15.
16.
Table 4-26
Installations
All installations should follow the Optimal Flexible Architecture (OFA) standard. Reference: Millsap, Cary V. Optimal Flexible Architecture. Oracle Magazine, Vol. IX, Nos. 5 and 6, 1995.
Oracle Method
The Physical Resource Plan (PJM.RM.040) prepared early in the project outlines the required systems for the entire project, but you may need to reevaluate the plan and consider new issues at this time. Reference: Establish Physical Resource Plan (PJM.RM.040), Resource Management process. PJM Process and Task Reference. Oracle Part Number C10979-1.
Multiple Environments
The development environment is typically very volatile since programs are constantly changing and there may be temporary test data. Also, with the availability of database triggers and stored procedures, the only way to unit test some programs is to install them in the database. Therefore, the development database must be separate from any other testing environment particularly if any mapping or testing is taking place simultaneously. Interface programs may be developed and tested in the development environment or in a separate environment. Interface testing may involve loading large batches of data and then deleting the data and starting over. If testing the interfaces could disrupt other development activities, create a separate environment, as documented in Prepare Testing Environments, Business System Testing process.
Software Tools
Create the directory structures to hold custom source code and register custom applications in Application Object Library . You need a script or documented procedure to create this structure on each environment that requires custom extensions (Business System Testing, Performance Testing, User Training, Production). Implement the source code control software and verify that it functions as indicated in the Build Standards (MD.040). Install design and development tools and verify that they function as required.
Upgrades
Throughout the course of the implementation, you may implement major and minor upgrades. The development environment may be the first environment where the application of an upgrade takes place in order to test and update customizations.
Role Contribution
The percentage of total task time required for each role follows: Role System Administrator Project Database Administrator Applications Administrator Technical Expert Team Leader - Customization IS Operations Staff
Table 4-27 Role Contribution for Prepare Development Environment
% 35 25 15 15 10 *
Deliverable Guidelines
Document all of your installation and configuration steps. To maintain the integrity and performance of the system, complete a thorough log documenting the changes and updates to all environments. Execute queries against system tables and capture the output to document tablespaces, database files, and users. Use available worksheets and checklists to plan, track, and verify the installation process.
Tools
Deliverable Template
Use the following templates for this task: Development Environment
Oracle Method
Installation Plan and Record Development Environment Use the Development Environment template to plan, execute, and verify the installation. Choose from the following components: Disk Device Map Application Load Estimate Tablespace Worksheet User Account List Installation QA Checklist Installation Plan and Record (PJM.RM.050) Use the Installation Plan and Record template in the Project Management -> Resource Management menu to record your installation steps and results. Reference: Installation Plan and Record (PJM.RM.050), Resource Management process, PJM Deliverable Reference. Oracle Part Number C10978-1.
Deliverable
The deliverable for this task is a set of Custom Database Objects in the development environment and the supporting Data Definition Language (DDL) scripts to create the database objects in the production environment.
Prerequisites
You need the following input for this task:
G G
Database Extensions Design defines the custom database objects that you must create. If the design is held in Designer/2000, then you need privileges to access the information. Development Environment (MD.090)
The configured Development Environment provides the database and Applications installation.
Task Steps
The steps of this task follow: No. 1. Task Step Review database extension design. Create new database users. Deliverable Component
2.
Oracle Method
No. 3. 4.
Task Step Register new ORACLE IDs. Build or generate database object creation scripts. Run database object creation scripts. Confirm database objects.
Deliverable Component
5.
6.
Table 4-28
Role Contribution
The percentage of total task time required for each role follows: Role Project Database Administrator Database Designer
Table 4-29 Role Contribution for Implement Database Extensions
% 80 20
Deliverable Guidelines
The deliverable is complete with a set of database object creation scripts. The completion criteria for this deliverable includes: set of object creation scripts script code consistent with design and build standards all tables, indices, views, and columns created correctly all objects accessible from the APPS ORACLE ID (Release 10.6 and beyond)
Tools
Designer/2000
In Designer/2000 (or other CASE tools that support Oracle), you can create the necessary database objects by simply selecting the appropriate Create Database option in the tool.
Oracle Method
Deliverable
The deliverable for this task is a completed Module Source Code with corresponding executables.
Prerequisites
Required
You need the following input for this task:
G G G G
The design documents provide the information you need to code the custom modules. Development Environment (MD.090)
The configured development environment provides the operating system directories, tools, database, and applications you need to develop and debug program modules. Custom Database Objects (MD.100)
Custom tables, views, and sequences referenced in the Module Technical Design.
Optional
You may need the following input for this task:
G G
The test scripts provide additional confirmation of the required functional logic and guide the debugging process.
Task Steps
The steps of this task follow: No. 1. Task Step Review detailed design documents. Code modules. Configure non coded modules in Application Object Library. Register custom modules in Application Object Library. Perform initial unit tests. Configure custom menus and report security groups to access custom forms and reports. Perform initial link tests. Update design documents as needed. Link Test Results Unit Test Results Source Code Deliverable Component
2. 3.
4.
5. 6.
7. 8.
Oracle Method
No. 9.
Deliverable Component
Table 4-30
Testing
Creating a source module is an iterative process. You code a portion of the module, test, apply bug fixes, and retest. Then you add more functionality and repeat the process. When you have incorporated all required functionality and believe that no defects remain, you formally submit the module for quality control and testing. Figure 4-5 illustrates the iterative nature of coding and unit testing.
Start
Code Program
Unit Test
Problems?
Yes
No
Add Functionality
No
Module Complete?
Yes
Finish Figure 4-5 The Incremental Code and Unit Test Cycle
You should be confident that your code will pass formal unit and link tests with flying colors when you turn the code over to someone else for testing. For more information, see Business System Testing process.
Design Review
If you did not design the custom modules, meet with the designer and review the design documents in detail. Although you may have participated in a design review, it included a larger audience and its primary purpose was to secure approval. It may not have covered the detail necessary to prepare for coding.
Designer/2000 Generator
If you used Designer/2000 to design custom forms and reports, you can generate the first-cut version automatically. You can then add
Oracle Method
additional logic as required to each module. Part of your development process will be to configure Generator preferences and special rules for each module. Warning: To successfully generate forms for Oracle Applications 10SC, the version of Oracle Forms must be the same in Designer/2000 and Oracle Applications. Under no circumstances must the version used in Designer/2000 be ahead of that used by Oracle Applications. You can incorporate support for the following features in Forms 4.5 by properly configuring the default form template and module specification in Designer/2000: descriptive flexfields who columns inter-block navigation buttons You will need to modify the generated forms or create a module-specific attached library to add support for the following elements: properly formatted window titles pop-up calendar on date fields current row indicator message dictionary for messages alternate regions Reference: Pirie, Mark. Designer/2000 for Oracle Applications Users Implementing and Customizing Release 10SC. Oracle White Paper, 1996. Attention: Beginning with Designer/2000 release 1.3, Generator supports many of the Applications GUI standards and features such as correct default window titles, pop-up calendar for date fields, current record indicators, and alternate regions.
Role Contribution
The percentage of total task time required for each role follows: Role Programmer Module Designer
Table 4-31 Role Contribution for Create Custom Modules
% 90 10
Deliverable Guidelines
While building custom modules, give special consideration to the following issues: Does code adhere to coding standards? Does code support the business purpose described in the Module Functional Design? Did you use appropriate tools? Have you updated documentation for technical or design changes you identified during development? Did you place source code under version control? Does the code meet all performance, maintenance, and integration requirements? The creation of custom programs also covers modifications to standard Oracle Applications products. Follow these guidelines when developing these modifications: Code is protected from standard Oracle Applications upgrades. Code does not alter the behavior of standard functions and features other than specified in design source code. Code is compatible with other integrated subsystems. Software patches can be applied to modified code.
Oracle Method
Suggestion: Patches can overwrite many hours of development work, and systems can crash and delete soft copies of custom code. For safety, regularly print a list of the custom code and always include a list of the final module names, with annotations, in the Implementation Notes section of the Module Technical Design document.
Tools
Developer/2000
Use the Oracle Developer/2000 tools to develop custom forms and reports. The Customization Strategy (MD.010) for your project defines the specific tools you will use.
Deliverable
The deliverable for this task is a set of Installation Routines and documented instructions to install all of the custom modules in the production environment. Not all customizations can be installed with an automated script, so the instructions may include manual steps as well.
Prerequisites
You need the following input for this task:
G G G
Module Source Code are completed custom modules configured in the development environment. Approved Designs (MD.080)
Approved Designs are functional and technical design documents with any updates identified during coding. Build Standards (MD.040)
Follow the Build Standards when building SQL*Plus, PL/SQL, and other scripts to automate custom module installation.
Oracle Method
Task Steps
The steps of this task follow: No. 1. Task Step Determine the installation technique for each module. Confirm proper installation and configuration of modules in development environment. Export data for components supported by a seed data loader. Create PL/SQL scripts for supported APIs. Write lookup seed data population scripts. Initialize test environment. Test discrete installation steps. Package scripts and commands into an operating system script. Document manual steps. Refresh test environment. Test final installation process. Place finished routines under source control.
Task Steps for Create Installation Routines
Deliverable Component
2.
3.
4.
PL/SQL Scripts
5.
6. 7. 8.
9. 10. 11. 12
Installation Instructions
Table 4-32
Environment Preparation
Before you can install individual custom modules into a new environment, you must prepare the target environment for customizations. You can automate some of the steps, but you must perform others manually. To prepare a new environment you must perform these actions: 1. 2. 3. 4. 5. 6. Create a directory structure for each custom application. Add environment variables for the root directory structures to the application environment file (APPLSYS.env). Register custom applications with Application Object Library. Shut down and restart the concurrent manager. Create custom database users. Register custom ORACLE IDs. Suggestion: If you have a master setup instance that you plan to import into future environments, you can preconfigure the master setup instance with the required custom applications.
Module Installation
Although you can simply copy some types of source and executable code to the proper destination directory, most Applications extensions require you to register the modules in Application Object Library or perform some other configuration. For example, to install a custom report you need to perform the following actions: 1. 2. Copy the source and executable report files to the proper custom directory. Register the executable file in Application Object Library.
Oracle Method
3. 4. 5. 6. 7. 8.
Create custom value sets for program arguments. Register the concurrent program and arguments. Create a custom report set. Add new report to custom report set. Add other standard reports to report set Associate report set to a custom responsibility.
Although you can perform all steps manually in each target environment, this is tedious and error prone. Program Files Installing the actual source and executable program files is the easy part. Use one of the following techniques to move or install these files: Direct copy over the network Archive and restore utilities Oracle Installer Oracle Client Software Manager Application Object Library You can use several techniques to register the proper information in Application Object Library: supported Open Interface supported command-line utility supported PL/SQL API (Application Programming Interface) custom SQL*Plus scripts keyboard capture and playback manual entry
Supported Tools
Table 4-33 shows the supported techniques and tools you can use to install common module types. The tools indicated are available with Oracle Applications Release 10.6, but Oracle may add additional utilities in the future. Module Type Forms Reports and Concurrent Programs Descriptive Flexfields Technique Form registration utility Concurrent Program API Flexfield Value Set API Descriptive Flexfield API Flexfield Value Set API Function Security Loader User Profile Loader User Profile Value Loader Message Dictionary Generator Manual Entry Copy CUSTOM library file Package creation script Trigger creation script Compilation and Linking Manual Entry Manual Entry DDL Script SQL Script
Table 4-33
Tool FNDFMREG command fnd_program package fnd_flex_val_api package fnd_flex_dsc_api package fnd_flex_val_api package FNDSLOAD command FNDPLOAD command FNDVLOAD command FNDMDGEN command Keystroke playback utility none SQL*Plus SQL*Plus Unix make command Keystroke playback utility Keystroke playback utility SQL*Plus SQL*Plus
Module Installation Techniques and Tools
Messages Zooms (Forms 2.3) Zooms (Forms 4.5) PL/SQL packages Database Triggers C programs Responsibilities Report Sets Database Objects Lookup Codes
Oracle Method
Role Contribution
The percentage of total task time required for each role follows: Role Programmer
Table 4-34 Role Contribution for Create Installation Routines
% 100
Deliverable Guidelines
You can package multiple commands and scripts for a customization into a single, easily executed operating system script (such as a UNIX Bourne shell script). You should be able to re-execute all scripts without errors even if custom modules are already installed. Apply the same quality criteria to installation routines as you do to other custom modules. Include standard headers and use comments liberally. Follow build standards for SQL*Plus scripts and PL/SQL procedures.
Tools
Deliverable Template
Use the Installation Instructions template to create the written instructions that accompany your installation routines.
Oracle Method
Runtime file (.msb) to Database Runtime file (.msb) to Script File (.msg) For installation routine development you generally use only the Database to Script file to create the installation script. Your master installation script can then use the Script file to Database and Database to Runtime file options to install the messages. User Profile Loader The User Profile Loader (FNDPLOAD) is a concurrent program that can move Oracle Applications user profile information between database and text file representations. Specifically, you can: Download database information to a text file. Upload (merge) the information in a text file to the database. With these download and upload capabilities you can easily propagate custom user profile information that is defined in one database to other databases. The User Profile Loader only moves the profile options themselves, not the associated values. User Profile Value Loader The User Profile Value Loader (FNDVLOAD) is a concurrent program that can move Oracle Applications user profile values between database and text file representations. Specifically, you can: Download database information to a text file. Upload (merge) the information in a text file to the database. These download and upload capabilities allow you to easily propagate user profile settings from one database to another. The User Profile Value Loader only moves the profile values; it will not create profile options that do not exist in the destination database.
PL/SQL APIs
Oracle Applications includes the following PL/SQL Application Programming Interfaces to facilitate loading or migrating configuration information: Concurrent Program API Concurrent Manager API
Descriptive Flexfield API Descriptive Flexfield Value Set API Concurrent Program API The Concurrent Program API allows you to register concurrent programs using a PL/SQL script. It is implemented as a PL/SQL package called FND_PROGRAM. The procedures in this package implement the functionality provided by the corresponding Application Object Library forms. The procedures in the FND_PROGRAM package allow you to: add and delete executables. add and delete concurrent programs. add and delete program parameters. add and delete incompatibility rules. add and delete request groups. add and delete request sets. add and delete request set parameters. add and remove concurrent programs to and from request sets. add and remove request sets to and from request groups. The concurrent program API cannot export information from the database so you must construct PL/SQL scripts manually to call the API functions. Attention: You must call the package procedure set_session_mode() with the parameter customer_mode before calling other procedures in the package. Descriptive Flexfield API The Descriptive Flexfield API allows you to create descriptive flexfield definitions, contexts, and segments. It is implemented as a PL/SQL package called FND_FLEX_DSC_API. The procedures and functions in this package allow you to: Determine whether a flexfield already exists. Register and delete flexfields.
Oracle Method
Enable flexfield columns. Create and delete segments. Create and delete contexts. For customizations, you generally only manipulate segments and contexts. Use caution when using this package because it performs slightly less validation than the corresponding Application Object Library forms. The Descriptive Flexfield API cannot export information from the database so you must construct PL/SQL scripts manually to call the API functions. Attention: You must call the package procedure set_session_mode() with the parameter customer_mode before calling other procedures in the package. After loading flexfield information, compile the flexfield by running the Flexfield Compiler concurrent program (FDFCMP). Flexfield Value Set API The Flexfield Value Set API allows you to create flexfield value sets for use in descriptive flexfields, key flexfields, and concurrent program parameters. It is implemented as a PL/SQL package called FND_FLEX_VAL_API. The procedures and functions in this package allow you to: Determine if a value set exists. Create, delete, and replace value sets. Support all validation types. Add events for special and pair validation types. The Flexfield Value Set API cannot export information from the database so you must construct PL/SQL scripts manually to call the API functions. Attention: You must call the package procedure set_session_mode() with the parameter customer_mode before calling other procedures in the package.