documenting the enterprise using oracle9i designer · organizational structure special event...

Documenting the Enterprise Using Oracle9i Designer An Oracle White Paper July 2002

Documenting the Enterprise Using Oracle9i Designer

Executive Overview.......................................................................................... 3 Introduction ....................................................................................................... 3 Recording Enterprise Level Information....................................................... 4

Information Content Storage...................................................................... 5 Use of Designer User Extensions.......................................................... 5 Segregation of Enterprise Information................................................. 5 Content Storage Formats ........................................................................ 6

Enterprise Level Information Items............................................................... 6 Overall Enterprise Items ............................................................................. 7 Function Focused Business Items.............................................................. 8 Organization Focused Business Items..................................................... 10 Geography Focused Business Items ........................................................ 11 Event Focused Business Items ................................................................. 11 Data Focused Business Items ................................................................... 12 Function Focused Technical Items.......................................................... 14 Data Focused Technical Items ................................................................. 15 Infrastructure Focused Technical Items.................................................. 17

Publishing Enterprise Information Items.................................................... 17 Conclusion........................................................................................................ 19



EXECUTIVE OVERVIEW Documenting the business needs, information requirements, or systems implementation of an overall enterprise requires a higher level of abstraction than when performing the same task for an individual application system. However, there are a number of correlations between information definitions at the enterprise level and those at a lower level for application specific, logical or physical system information. By carefully considering these correlations, and allowing for some unique interpretations, Oracle9i Designer can readily support the documentation of enterprise level information. This paper illustrates the specific manner in which you can use Designer elements can be used to record and model this enterprise level information. Therefore, the same tool can serve the information recording and modeling needs of the CIO’s office, the business analysts and data architects, as well as the application developers and DBAs.

INTRODUCTION In documenting or modeling an application system for an enterprise, analysts consider two levels of information. The first is the logical (or conceptual) level, which describes the system from a business requirements perspective. It includes information about data content, business functions, data usage, and business rules. The other is the physical (or implementation) level, which defines the system from a technical deployment perspective. It includes detailed definitions for data storage structures, application modules, and business processing/validation routines.

There is a third level of information though, which considers the enterprise from an overall perspective. This enterprise level information is a level above, or a precursor to, the conceptual level. The information is developed from a number of studies or sources. It is part of the deliverables from an Enterprise Architecture study, represents the details of an IT Strategic Plan, or may be a result of a determination of Enterprise Scope and Objectives. Regardless of source, the enterprise level information consists of details regarding data content, functional requirements, business restrictions, and the implementation of systems to support the enterprise.


The enterprise level view is somewhat unique in that it encompasses both business and technical information. The business focused enterprise information contains items like business functions and data content. At the enterprise level, there is a broader focus and less rigorous definition of elements than at the lower levels. More emphasis is placed on restrictions and interactions than with the logical level information. The technically focused information at the enterprise consists of items such as application systems, databases, and server locations. Here the emphasis is on an inventory and description of technical items, rather than the detailed implementation described in the physical level information.

The enterprise level information items encompass a broad range of conceptual areas with varying information content requirements. Its storage must provide for textual information content as well as structured classification content. A key feature of enterprise level information is the relating of specific items between conceptual areas (i.e. identifying Application System responsibility for Data Subject Areas). Therefore, the element storage must also enable highly granular element cross-association (and its matrix presentation).

RECORDING ENTERPRISE LEVEL INFORMATION The Designer tool set is noted for its capabilities in separating and differentiating between an application system’s logical and physical level information. It does this by providing discrete elements for recording each type of information. For example, it provides separate elements for recording data entity information and database table information. At the same time, it allows for the association or referencing of information within a level and also between levels. Examples of this include the recognition of business function usage of data entities within the logical level, as well as those physical level database table implementations that represent these data entities.

However, there is no discrete set of Designer elements targeted specifically at enterprise level information. There are a number of logical level Designer elements that can be applied to an application, as well as to the overall enterprise. Most of these elements allow for the description of business restrictions and overall needs. This includes information such as Goals & Objectives, Critical Success Factors, and relevant Assumptions. For other types of enterprise level information, such as Functional Areas, Data Subject Areas, or Application Systems, there is less of a clear-cut choice as to the best place to record the information.

Therefore, the purpose of this paper is to suggest how best to use Designer to document the enterprise level information. This includes how to:

• Specify enterprise level information items

• Identify specific Designer elements for each enterprise level item

• Describe mechanisms for supporting the access and publication of these elements


These suggestions for the capture of enterprise level information are provided as metadata mappings from enterprise level items to Designer elements. The mappings identify specific Designer elements and element properties to use for each enterprise level item. Optional mappings are provided where there is significant benefit from alternative approaches but no clear “best way”. Recommended mechanisms to manipulate and publish the elements are also described in detail where a specific tool will provide superior presentation results.

Information Content Storage As stated, few of the Designer elements are naturally targeted at enterprise level information, although they may be readily used at that level of abstraction. Therefore, to document the enterprise level information, we must adapt our conceptual usage of the repository elements.

Use of Designer User Extensions1

The metadata mapping suggestions are made from the perspective of enabling the broadest range of enterprise level information content, while limiting the “mis-use” or extension of the Designer elements. However there is a need for Designer User Extensions for complete coverage. Therefore, it may be desirable to place the enterprise level information in a separate Designer repository. Alternatively, application developers using the same repository can ignore the User Extensions. Of course the User Extensions can be left out completely and lesser enterprise level information coverage accepted.

Segregation of Enterprise Information

To guarantee that enterprise level definitions are not mixed up with standard application level definitions, a separate container and workarea should be used. The enterprise oriented content can thus have separate access rights granted to it. As well, its usage can be clearly delineated so staff does not misconstrue it later on.

The information in the enterprise level elements can be re-used though, even if in a separate container. This can be done through manual cut-paste operations if there is not much content volume. Where large volumes of content are required (e.g. using enterprise Information Entity content to initialized application level Entity elements) simple Designer API based utilities can be written to perform the requisite read-write activity.

1 Designer User Extensions are created using the Repository Administration Utility. They provide extra elements, element properties, or element associations within a Designer repository. Once defined and published, they are available within all models in that repository. Further information regarding User Extensions is available in the Designer on-line help.


Content Storage Formats

The information content that is stored in elements in the Designer repository is stored as simple text in repository database columns. There is also a need for more formatted or visual oriented content. This information can be stored directly as files in the repository and should adhere to standard file types to improve access and usability. For example:

• Image files could be stored as GIFs or JPEGs.

• Document files could be stored as DOCs, XLSs, or PDFs

• Drawing files could be stored as VSDs

ENTERPRISE LEVEL INFORMATION ITEMS The following sections provide suggestions for each enterprise level information item and its individual content requirements. Each item is identified as to the specific Designer elements, or element extensions, that should be used. The information content requirements are then described with the appropriate Designer element property, association, or secondary element identified. Utilities that can be used to aid or automate the creation of information items are also described as appropriate.

Technically Oriented

Business Oriented


Business Oriented


Business Oriented

Function Function FocusedFocused

Data Data FocusedFocused

Context ProcessFunctional AreaBusiness Function

Information CategoryInformation EntityBusiness Data Model

Information CategoryInformation EntityLogical Data StorePhysical Data Store

Application SystemInfrastructure ComponentLogical Business LocationPhysical Business Location

Organizational StructureSpecial Event

Enterprise Mission / VisionGoal / Objective / StrategySuccess Factor / Performance Measure

Figure 1. Enterprise Level Information Items


Overall Enterprise Items

Enterprise Vision/Enterprise Mission

“Enterprise Information” Container

The Vision and Mission can be defined as part of the information for the “Enterprise Information” container that holds all the other elements described herein. The Description property should be used for the Enterprise Mission and the Objectives property for the Enterprise Vision.

OR Document and Attached Element > File

The Vision and Mission can be described in a separate file. This file is uploaded and then identified as such. File element: • Created by file upload into repository • Name set by upload action • Short Description as appropriate Document element: • Name, Author, Status as appropriate • Format = file type • Description as appropriate Document > Attached Element • Associates descriptive Document element with physical file

element • Associates Document element with other elements (i.e.

“Enterprise Context” Business Function element) as desired

Enterprise Goal

Objective Objectives can be subordinated. Enterprise Goals are all top-level Objective elements. • Objective Type = GOAL • Name, Description as appropriate

Enterprise Objective

Objective Each Enterprise Objective is subordinated to a specific Enterprise Goal. • Parent = Objective element representing Enterprise Goal • Objective Type = OBJECTIVE • Name, Description as appropriate

Enterprise Strategy

Objective Each Enterprise Strategy is subordinated to a specific Enterprise Objective. • Parent = Objective element representing Enterprise Objective • Objective Type = STRATEGY • Name, Description as appropriate


Enterprise Critical Success Factor

Critical Success Factor

Critical Success Factors may have as much information as appropriate entered for them. They can also be subordinated to other Factor elements. • Name as appropriate • Comment = short description of Factor • Description = optional longer description if needed • Parent = higher level Factor • Critical, Priority as appropriate • Other properties as required

Performance Measure

Key Performance Indicator

Key Performance Indicators must have identifiable target values. They can be subordinated to other Indicator elements. • Name as appropriate • Comment = short description of Measure • Description = optional longer description if needed • Target Value, Unit of Measure as appropriate • Responsibility, Measured By, Set By if known

Correlate Goals/Objectives/Strategies, Factors, Measures

Element Usages for each

The inter-relations between these information items are recorded as Element Usage information between appropriate item pairs. Factors and Indicators should use similar Units of Measure for consistency. Objective <> Critical Success Factor Objective <> Key Performance Indicator Require a User Extension Critical Success Factor <> Key Performance Indicator association

Function Focused Business Items

Context Process

Business Function

Each Context Process is defined in relation to the other context level processes. An “Enterprise Context” Business Function element is the top-level for the hierarchy that contains all the Context Processes. • Label = enterprise abbreviation suffixed by “Context”. • Short Definition = “Enterprise Context” • Parent Function = none • Description as appropriate

Out-of-Context Items

External These out-of-context items are displayed graphically with the Enterprise Context item to provide an understanding of enterprise scope and interaction. • Name, Short Name (abbreviation), Comment (short

description) as appropriate


Enterprise Context Model

Data Flow Diagram

A Data Flow Diagram depicts the “Enterprise Context” Business Function element and all the “Out-of-Context” External elements with which it interacts. • The interactions between the Externals and the Business

Function are depicted as Data Flows between the elements • This Data Flow Diagram does not get decomposed. It exists

for the topmost level only

Functional Area (Enterprise Business Process)

Business Function

Each Functional Area is subordinated to the context level process. The “Enterprise Context” Business Function element is the top-level for the hierarchy that contains all the Functional Area elements. • Label = enterprise abbreviation suffixed by functional area

abbreviation. Use “-“ as a separator • Short Definition = functional area name • Parent Function = the “Enterprise Context” Business

Function • Sequence in Parent = ascending sequential display order of

the elements (left to right, top to bottom) • Description as appropriate

Functional Area (Enterprise Business Process) Interactions

Process Model Diagram

A Process Model Diagram depicts the interactions between the Functional Areas. • The diagram “base process” is the Enterprise Context

element • The interactions between the Functional Areas are depicted

as Data Flows between the elements • This Process Model Diagram does not get decomposed. It

exists for this level of the function hierarchy only

Business Function

Business Function

Each Functional Area is decomposed into further Business Functions that describe the details of the functions or processes conducted within that Functional Area. • Label = functional area abbreviation suffixed by an identifier

number. Use “-“ as a separator • Short Definition = functional or process name • Parent Function = the Functional Area Business Function • Sequence in Parent = ascending sequential display order of

the elements (left to right, top to bottom) • Description as appropriate • Use various BPR properties as desired for relevant

information


Functional Area Decomposition to Business Functions

Function Hierarchy Diagram

The Functional Area Decomposition is depicted with a Function Hierarchy Diagram. This tree-structure diagram starts with the Context Process at the top and shows the Functional Areas and then their details below that. • Can be filtered to show a single Functional Area and its

detailed Business Functions • Visual separation between levels and between groups (i.e.

between “support” and “primary” areas) is done though color coding

• The amount of information content can be controlled

Correlate Functional Areas/Business Functions to Goals/Objectives, Factors, Measures


The high-level Functional Areas and/or detailed Business Functions can be mapped to the Goals, Objectives, Measures, and Factors through the Element Usages for each item pair. Thus, the function’s importance in satisfying goals, or their requirement to support key indicators, can be assessed. Business Function <> Objective Business Function <> Key Performance Indicator Require a User Extension Business Function <> Critical Success Factor association

Organization Focused Business Items

Enterprise Organizational Structure

Business Unit The Enterprise Organizational Structure can be defined and decomposed to the level desired. A Business Unit element can be subordinated to another Business Unit in a tree hierarchy. • Short Name = “ORG_” suffixed by the organization’s

abbreviation • Name, Comment (short description) as appropriate

Correlate Functional Areas/Business Functions to Organizational Structure


The Business Function elements can be associated to the Business Unit elements with the Performing/Performed By usage. • Each Functional Area item must only be associated to a

single Organizational Structure. This association will be depicted on the Functional Area Interactions diagram

• Each Business Function item should only be associated to a single Organizational Structure, but multiple associations can be defined

Require a User Extension Property of Comment to hold the type of usage information on the association element.


Geography Focused Business Items

Logical Business Location

Business Unit A top-level “Logical Locations” Business Unit should be defined. A Business Unit element can be subordinated to another Business Unit in a tree hierarchy. The Logical Business Locations can be defined and decomposed to the level desired. • Short Name (top level) = “LBL” • Short Name (others) = “LBL_” suffixed by the logical

location’s abbreviation OR a numeric identifier • Name, Comment (short description) as appropriate

Physical Business Location

Business Unit A top-level “Physical Locations” Business Unit should be defined. A Business Unit element can be subordinated to another Business Unit in a tree hierarchy. The Physical Business Locations can be defined and decomposed to the level desired. • Short Name (top level) = “PBL” • Short Name (others) = “PBL_” suffixed by the physical

location’s abbreviation OR a numeric identifier • Name, Comment (short description) as appropriate

Correlate Business Functions to Logical Locations/Physical Locations


The Business Function elements can be associated to the Business Unit elements with the Performing/Performed By usage. • Functional Area items must not be associated with Logical or

Physical Location items. This association would cause an error in the Functional Area Interactions diagram. Instead, document the appropriate detailed Business Function’s locale

• Each Business Function item may be associated with multiple Logical or Physical Location items, and vice versa

Re-use the User Extension Property of Comment to hold the type of usage information on the association element.

Event Focused Business Items

Special Events

Process Events

The Process Events can be defined and reported with information regarding frequency and triggering conditions. • Name, Description as appropriate • Type = choice from list • On Condition as appropriate • Use various Time properties as desired for relevant

information


Correlate Business Functions to Special Events


The Business Function elements can be associated to the Process Event elements with the Triggering/Triggered By usage. • Functional Area items must not be associated with Special

Event items. This association would cause display complications in the Functional Area Interactions diagram. Instead, document the event’s effect on the appropriate detailed Business Function.

• Each Business Function item may be associated with multiple Special Event items, and vice versa

Data Focused Business Items

Data Subject Area (Business)

Entity A Data Subject Area item is defined as an Entity element from the enterprise level perspective. This depiction allows for associations to functional elements required to verify the enterprise architecture. • Name, Description as appropriate • Entity > Relationships represent Data Subject Area

associations • Entity > UIDs are not defined for Data Subject Area elements • Entity > Sub-Types should not be used for Data Subject

Areas. They should be rendered as separate Entities and any relevant details duplicated for later resolution during application system focused projects

Information Entity (Business)

Entity > Attribute

An Information Entity is a data item detail for a Data Subject Area, and thus is subordinated to it. This subordinate detail should be defined using Entity > Attribute elements. • Name, Description as appropriate

Enterprise Data Model

Entity Relationship Diagram

An Entity Relationship Diagram depicts the items and the relationships between them. • The relationships between the Data Subject Areas are

depicted as Entity > Relationships on the diagram(s) • The detailed Information Entities may be shown as part of

the Data Subject Area items on the diagram(s)

Correlate Data Subject Areas/Information Entities to Business Functions


The Business Functions elements can be associated to the Entity elements or to the Attribute elements as appropriate for the level of reference detail desired. • Each Business Function item may be associated with multiple

Data Subject Area items, and vice versa • In addition, each Business Function item may be associated

with multiple Information Entity items, and vice versa • Use CRUD properties as appropriate on the association

element


Correlate Data Subject Areas to Organizational Structures


The Business Unit elements can be associated to the Entity elements. • Each Organizational Structure item may be associated with

multiple Data Subject Area items, and vice versa Require a User Extension Property of Comment to hold the type of usage information on the association element.

Correlate Information Entities to Organizational Structures

Optional User Extension Element Usages for each

A User Extension may be built to allow the Business Unit elements to be associated with the Entity > Attribute elements. This would only be needed if this level of reference detail were required. • Each Organizational Structure item may be associated with

multiple Information Entity items, and vice versa Would require a User Extension Property of Comment to hold the type of usage information on the association element if it were built.

Correlate Data Subject Areas to Logical Locations/Physical Locations


The Business Unit elements can be associated to the Entity elements. • Each Business Function item may be associated with multiple

Data Subject Area items, and vice versa Require a User Extension Property of Comment to hold the type of usage information on the association element.

Correlate Information Entities to Logical Locations/Physical Locations


A User Extension may be built to allow the Business Unit elements to be associated with the Entity > Attribute elements. This would only be needed if this level of reference detail were required. • Each Business Function item may be associated with multiple

Information Entity items, and vice versa Would require a User Extension Property of Comment to hold the type of usage information on the association element if it were built.


Correlate Data Subject Areas/Information Entities to Special Events

Process Event > Entity / Attribute

The Process Event element can be associated to an Entity element, as well as an Attribute element, whose change triggers the event or whose content is used by the event. • Each Special Event item may be associated with a single Data

Subject Area or Information Entity item. In turn, they may be referenced by multiple Special Event items

• System Description = type of usage information Any broader cross-references between Special Events and Data Subject Areas or Information Entities would require the use of User Extension associations to be built. Would require a User Extension Property of Comment to hold the type of usage information on the User Extension association element (if built).

Function Focused Technical Items

Business Application System

Module A Business Application System item is defined as a Module element from the enterprise level perspective. This depiction allows for associations to other data and functional elements required to verify the enterprise architecture. • Short Name = application system abbreviation • Name, Description as appropriate • Language = SQL (in order to enter further details

appropriately) • Use various Planning properties as desired for relevant

information

Correlate Functional Areas to Business Application Systems


The Business Function elements can be associated to the Module elements with the Implementing/Implemented By usage. • Each Business Function element may be associated with one

or more Module elements, and vice versa • The Functional Area item <> Business Application System

associations do not have to be consistent with the Business Function item <> Business Application System associations (if both are defined)

• Comment = type of usage information

Correlate Business Functions to Business Application Systems


The Business Function elements can be associated to the Module elements with the Implementing/Implemented By usage. • Each Business Function element may be associated with one

or more Module elements, and vice versa • The Business Function item <> Business Application System

associations do not have to be consistent with the Functional Area item <> Business Application System associations (if both are defined)

• Comment = type of usage information


Correlate Business Application Systems to Logical Locations/Physical Locations


The Module elements can be associated to the Business Unit elements with the Implementing/Implemented By usage. • Each Business Application System item may be associated

with multiple Logical or Physical Location items, and vice versa

Re-use the User Extension Property of Comment to hold the type of usage information on the association element.

Correlate Business Application Systems to Special Events

User Extension Element Usages for each

A User Extension of Triggering/Triggered By usage must be built to allow Module elements to be associated to the Process Event elements. • Each Module item may be associated with multiple Special

Event items, and vice versa

Data Focused Technical Items

Data Subject Area (Technical)

Table A Data Subject Area is an enterprise level data element. These Technical representations are copied from the Business representations (see note below) and thus should not be directly maintained. • Name, Description as copied • Table > Foreign Keys represent Data Subject Area

associations and are copied from Relationships • Table > Primary Keys are defined by default by Designer but

are not relevant for Data Subject Area elements NOTE: The Database Design Transformer utility is used to create Table elements that mirror the Entity elements. The Transformer can be run initially in “default” mode. Subsequent iterations will have to set the transformation options appropriately to cause the Tables to reflect changes to the Entities.

Information Entity (Technical)

Table > Column

An Information Entity is a data item detail for a Data Subject Area, and thus is subordinated to it. This subordinate detail is defined using Table > Column elements, which are copied from the corresponding Entity > Attribute elements. • Name, Description as copied


Correlate Data Subject Areas/Information Entities to Business Application Systems

Module Component > Table Usages / Bound Item Usages

The Module elements can be decomposed into multiple Module Component elements. Then each of these can be associated to a Table element as a Table Usage. Optionally the Module Component may reference one or more Column elements through Table Usage > Bound Item Usages. This depends on the level of reference detail desired. • Each Business Application System item may be associated

with multiple Data Subject Area items, and vice versa • In addition, each Business Application System item may be

associated with multiple Information Entity items, and vice versa

• Use CRUD properties on the Module Component element for Data Subject Area type of usage information

• Use CRUD properties on the Bound Item Usage element for Information Entity type of usage information

Logical Data Store

Datastore The Logical Data Stores can be defined to the level of detail desired. • Short Name = “LDS_” suffixed by the logical data store’s

abbreviation OR a numeric identifier • Name, Comment (short description), Description as

appropriate

Physical Data Store

Datastore The Physical Data Stores can be defined to the level of detail desired. • Short Name = “PDS_” suffixed by the physical data store’s

abbreviation OR a numeric identifier • Name, Comment (short description), Description as

appropriate

Correlate Data Subject Areas to Logical Data Stores/Physical Data Stores


A User Extension must be built to allow the Entity elements to be associated with the Datastore elements. This would only be needed if this level of reference detail were required. • Each Data Subject Area item may be associated with multiple

Logical and Physical Data Store items, and vice versa

Correlate Information Entities to Logical Data Stores/Physical Data Stores


The Entity > Attribute elements can be associated to the Datastore elements with the Datastore Attribute Usage. • Each Information Entity item may be associated with

multiple Logical and Physical Data Store items, and vice versa

Correlate Business Application Systems to Logical Data Stores/Physical Data Stores

User Extension Element Usages for each

A User Extension must be built to allow the Module elements to be associated with the Datastore elements. • Each Business Application System item may be associated

with multiple Logical and Physical Data Store items, and vice versa


Infrastructure Focused Technical Items

Infrastructure Component

Node A Node element allows for the definition of various types of Infrastructure Component items. • Name, Comment (short description), Description as

appropriate • Type = user definable classification (i.e. platform, operating

system, topology) • Availability = user definable value • Use various Specification and Responsibility properties as

desired for relevant information

Correlate Infrastructure Components to Business Application Systems


The Node elements can be associated to the Module elements with the Processing/Processed By usage. • Each Infrastructure Component item may be associated with

multiple Business Application System items, and vice versa

Correlate Infrastructure Components to Logical Locations/Physical Locations


The Node elements can be associated to the Business Unit elements with the Using/Used By usage. • Each Infrastructure Component item may be associated with

multiple Logical and Physical Location items, and vice versa

PUBLISHING ENTERPRISE INFORMATION ITEMS The requirements for the publication of enterprise level information encompass the complete set of items. Each item’s content must be clearly presented with the information details and associations to other items. These associations are the basis for the cross-reference presentations that are a key component of the enterprise level content.

The following is a set of suggested reports or displays that would serve to publish the enterprise level information content in a complete and cohesive manner. Many are standard Designer reports that come installed with the tool set.

Publish findings, issues, and drivers for enterprise change The standard “Strategic Considerations” report shows the details of Objectives, Critical Success Factors, and Key Performance Indicators elements. This report can be used as is, serve as the basis for a text document, or be referenced by a text document.

Associations between these elements, as well as to Business Functions/Documents can be displayed and printed in the Matrix Diagrammer. Alternatively, the standard Detailed <Element> Definition report shows the primary text content for an element and all the elements associated to it.


Map Organizational Structures to Functional Areas, Business Functions, Data Subject Areas, and Information Entities The standard “Business Unit Definition” report shows the details of all these cross-references except to Information Entities. This extra information could be added to the report.

Associations between these elements can also be displayed and printed in the Matrix Diagrammer, except for the association to Information Entities.

Map Logical Locations and Physical Locations to Functional Areas, Business Functions, Business Application Systems, Data Subject Areas, and Information Entities The standard “Business Unit Definition” report shows the details of all these cross-references except to Information Entities. This extra information could be added to the report.

Associations between these elements can also be displayed and printed in the Matrix Diagrammer, except for the association to Information Entities.

Map Functional Areas and /or Business Functions to each other and to Logical Locations, Physical Locations, Business Application Systems, Data Subject Areas, and Information Categories Entities The standard “Function Definition” report shows the details of Functional Area Interactions, Functional Area Decomposition, Functional Area and Business Function cross-references to Logical and Physical Locations, as well as the Functional Area and Business Function usage of Data Subject Areas and Information Entities. The standard report does not show Functional Area and Business Function cross-references to Business Application Systems, but this could be added to it.

Cross-references between these elements can also be displayed and printed in the Matrix Diagrammer. The Matrix Diagrammer will not show the Functional Area Interactions (use the Process Model Diagram as described) or the Functional Area Decomposition (use the Function Hierarchy Diagram as described).

Map Business Application Systems to Functional Areas, Business Functions, Logical Locations, Physical Locations, Data Subject Areas, Information Entities, and Data Stores The standard “Module Definition” report shows the details of all these cross-references, except the cross-reference to Data Stores. This information could be added to the report.

Associations between these elements can also be displayed and printed in the Matrix Diagrammer, except for the association to Data Stores.


Map Special Events to Business Functions, Business Application Systems, Data Subject Areas, and Information Entities The standard Detailed <Element> Definition report will show the primary text content for a Special Event (Process Event element) and all the standard and User Extension elements associated to it.

Associations between these elements cannot be displayed in the Matrix Diagrammer.

Map Data Subject Areas and Information Entities to Logical and Physical Data Stores The standard “Datastore Definition” report shows the details of the cross-references to Information Entities, but not to Data Subject Areas. This extra information could be added to the report.

Associations between these elements can also be displayed and printed in the Matrix Diagrammer, except for the association to Data Subject Areas.

All other associations are reported via reports focused on the other end of the association or via the Matrix Diagrammer.

CONCLUSION This paper illustrates how you can capture, store and present enterprise level information using primarily standard Oracle9i Designer elements. You can keep this information separately from application level information, but re-use it as needed to initiate application design. By making use of a powerful standard information management tool such as Designer, and using primarily standard element types (which adapting the conceptual usage of the Designer elements), the training time for both learning to capture and learning to interpret the information is minimized.

By also using the inherent cross-reference capabilities of Designer, the ability to relate and then present the associations between items is available at little or no extra effort. You can document, present and analyze information about the enterprise as a whole, in a manner similar to that used for individual applications, which can greatly improve the understanding of enterprise requirements.


Documenting the Enterprise Using Oracle9i Designer July 2002 Author: Robert Gauf Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright © 2002 Oracle Corporation All rights reserved.