5 Modify Asset Types and Taxonomies

The fifth step in getting started with Governance is to review and modify asset types & taxonomies to meet stakeholder needs.

The term "asset" refers to anything that is stored in Oracle Enterprise Repository. This can include - but is not limited to- business processes, services, patterns, frameworks, applications, components and data services. Different asset types include:

An asset is more than just code; in fact it may not be code at all. An asset could be a process, the IT road map, or any number of documents. Flexible asset types support the following:

One of Oracle Enterprise Repository's unique features is the ability to model any asset type. The Type Manager provides a user-friendly tool for modifying the asset types supplied with the solution packs, changing their look and feel in order to define new asset types. The Type Manager provides a wide range of element/display types and the ability to arrange these types in a way that makes sense for the organization, from an Asset Consumer and Asset Creator/Editor perspective.

Users assigned to the "Registrar Administrator" role in Oracle Enterprise Repository can create new asset types, modify asset type metadata, create new categories, and new tabs and add any number of new elements to each tab.

The following best practices are helpful when modifying asset types to meet stakeholder needs.

  1. Retain a copy of the original metadata

    • Make copy of the original asset type.

    • Rename the copy by adding a prefix of "z" and make the copy inactive.

    • Make desired changes to the original.


    It is important to follow this best practice, particularly if you are automatically harvesting assets. Oracle Enterprise Repository harvests the assets into a pre-defined model. The model leverages the Unique Identifiers associated with the out-of-the-box asset types. The harvester does not populate copies of the original assets, as those copies have a different Unique Identifier.
  2. Use templates when working with stakeholders to identify the metadata fields that they will need on each asset. We've found that it's easier for stakeholders to look at a list of metadata to initially identify the metadata fields. After stakeholders have identified the metadata that they would like to see on each asset, a prototype can be developed in Oracle Enterprise Repository, and the prototype can be validated and revised by stakeholders.

    • Appendix A provides a list of out-of-the-box metadata for each Oracle Enterprise Repository asset type. Use this as a template for identifying the metadata that is needed by the stakeholders identified in Chapter 4, "Identify Stakeholders".

  3. Oracle Enterprise Repository offers two views of asset metadata. The Viewer identifies the metadata that is visible to all users of the system. The Editor is a template-based view available to those who are entering or editing asset information. Organize metadata in the Editor in a way that makes it easy for those who are entering or editing asset information to know which metadata fields they need to populate.

    • The Editor can have multiple, customizable tabs. We recommend organizing these tabs by user role, such that users can quickly identify the asset metadata they need to provide.

    • As an alternative, you can organize tabs according to SDLC state. This clarifies the metadata that is needed at each stage of the asset's lifecycle.

    • Note that Oracle Enterprise Repository's automated workflows use the Tabs to process assets. This means that you should maintain consistency across your asset types so that there is consistency in the way that they are processed by the workflows.

Oracle Enterprise Repository harvests assets according to an underlying model. For example, when harvesting from JDeveloper 11g, Oracle Enterprise Repository harvests the project into an underlying composite asset model. The model determines which assets appear in Oracle Enterprise Repository, as well as the relationships that appear between the assets. As discussed in Chapter 3, "Visibility", the harvested assets display the implementation details.

Figure 5-1 shows one of the composite assets that ships with SOA Suite. The diagram on the right is a representation of the underlying model. When the composite is harvested, it is interpreted according to the underlying model. The results are displayed in Figure 5-2.

Figure 5-1 JDeveloper Composite and Resulting Oracle Enterprise Repository Composite Model

Description of Figure 5-1 follows
Description of "Figure 5-1 JDeveloper Composite and Resulting Oracle Enterprise Repository Composite Model"

Figure 5-2 Composite Harvesting Results

Description of Figure 5-2 follows
Description of "Figure 5-2 Composite Harvesting Results"

The Solution Packs provide the underlying models that define how harvested assets are displayed in Oracle Enterprise Repository. The Oracle Enterprise Repository Base asset types and the asset types in each of the solution packs can be extended to include additional metadata fields needed to support the stakeholder information requirements.

Categorizations are a unique way of classifying or categorizing assets and projects within Oracle Enterprise Repository. They provide the ability to not only appear as metadata within an asset but also provide very robust searching capabilities. These are demonstrated both in the Browse Tree searches and Advanced Search capabilities. Categorizations can be represented as anything that is hierarchical or taxonomical; examples include Architecture Reference Models, Asset Lifecycle Stages, Lines of Business, Domains, Business Capabilities, etc.

Oracle Enterprise Repository ships with a number of categorizations. These can be customized to reflect the concepts that are relevant to your organization.

For more information about customizing taxonomies, see "Configuring Oracle Enterprise Repository Categorizations in the UDDI Mappings File" in Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository.