documenting the enterprise using oracle9i designer · organizational structure special event...
Post on 16-Mar-2020
12 Views
Preview:
TRANSCRIPT
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
Documenting the Enterprise Using Oracle9i Designer Page 2
Documenting the Enterprise Using Oracle9i Designer
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.
Documenting the Enterprise Using Oracle9i Designer Page 3
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
Documenting the Enterprise Using Oracle9i Designer Page 4
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.
Documenting the Enterprise Using Oracle9i Designer Page 5
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
Technically Oriented
Business Oriented
Technically 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
Documenting the Enterprise Using Oracle9i Designer Page 6
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
Documenting the Enterprise Using Oracle9i Designer Page 7
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
Documenting the Enterprise Using Oracle9i Designer Page 8
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
Documenting the Enterprise Using Oracle9i Designer Page 9
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
Element Usages for each
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
Element Usages for each
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.
Documenting the Enterprise Using Oracle9i Designer Page 10
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
Element Usages for each
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
Documenting the Enterprise Using Oracle9i Designer Page 11
Correlate Business Functions to Special Events
Element Usages for each
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
Element Usages for each
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
Documenting the Enterprise Using Oracle9i Designer Page 12
Correlate Data Subject Areas to Organizational Structures
Element Usages for each
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
Element Usages for each
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
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 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.
Documenting the Enterprise Using Oracle9i Designer Page 13
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
Element Usages for each
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
Element Usages for each
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
Documenting the Enterprise Using Oracle9i Designer Page 14
Correlate Business Application Systems to Logical Locations/Physical Locations
Element Usages for each
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
Documenting the Enterprise Using Oracle9i Designer Page 15
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
Optional User Extension Element Usages for each
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
Element Usages for each
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
Documenting the Enterprise Using Oracle9i Designer Page 16
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
Element Usages for each
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
Element Usages for each
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.
Documenting the Enterprise Using Oracle9i Designer Page 17
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.
Documenting the Enterprise Using Oracle9i Designer Page 18
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 Page 19
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.
top related