Configuration Management Concepts: Oracle Utilities Application Framework (4.4.0.0.0)

Configuration
Management
Concepts
Oracle Utilities Application Framework (4.4.0.0.0)
WHITE PAPER / JANUARY 2019

DISCLAIMER
The following is intended to outline our general product direction. It is intended for information
purposes only and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.
2 W HITE PAPER / Configuration Management Concepts - Oracle Utilities Application Framework (4.4.0.0.0)
Table of Contents
Introduction .................................................................................................. 5
Configuration Management Overview.......................................................... 5
Aspects of Configuration Management ........................................................................................ 6
Why is Configuration Management so important? ....................................................................... 7
How to Read this series ............................................................................................................... 8
Configuration Management Concepts ......................................................... 9
Assets .......................................................................................................................................... 9
Base Product ............................................................................................................................... 9
Extensions ..................................................................................................................................10
Baselines ....................................................................................................................................10
Automatic baselines ...................................................................................................................11
Non-Automatic baselines ............................................................................................................12
Versions .....................................................................................................................................12
Releases ....................................................................................................................................12
Configuration Management Approach ....................................................... 12
Guidelines For Effective Configuration Management................................. 13
Treat each environment like a production environment ..............................................................13
Management tasks are no different ............................................................................................14
Begin with the end in mind .........................................................................................................14
Assume an environment for change ...........................................................................................14
Minimize the number of environments ........................................................................................14
Keep the solution simple as possible..........................................................................................15
Don’t release unless documentation is complete........................................................................15
Do not assume a tool is a silver bullet ........................................................................................15
INTRODUCTION
Configuration Management is set of policies and processes for managing

product and operational extensions effectively for on-premise, hybrid and
Oracle Cloud implementations. Before understanding the specific set of
policies and processes, common concepts need to be understood.
CONFIGURATION MANAGEMENT OVERVIEW

Configuration Management, also known as Software Configuration Management, is a set of policies and
processes that assist in the management of the set of components that constitute a delivery of
extensions or a product. This means managing the component from the time is being developed, fixed,
tested and implemented so that the correct version of the component, and its related components, are
present in the right places at the right times.
The aim of Configuration Management is to deliver a physical product to a customer as agreed with that
customer. In terms of an Oracle Utilities Application Framework based product implementation, that
product is a copy of the base product, supplied by Oracle, and all the custom extensions performed by
the implementation. This constitutes the implementation for a customer with the extensions as well as
the version having the functionality agreed for that customer. The amount of extension, known as the
extension spectrum1, will vary with the individual requirements of the customer. The figure below
illustrates this relationship:
Figure 1. Extension Spectrum
The extension spectrum has the following attributes:
• Extensions can overlap base product functionality. For example, you may be replacing a base
provided algorithm with a custom version. Another example is taking a base provided extract and
modifying it for a customer’s purpose.
• Extensions are based upon base functionality but can create new functionality. If the base
product does support a new business process, adding new functionality may be required. At the base
level, the extension will extend the Oracle Utilities Application Framework functionality to ensure it
tightly integrates with the rest of the product.
This series of whitepapers will focus on Configuration Management for extensions (code and data) for
on-premise, hybrid and cloud implementations of Oracle Utilities Application Framework based products.
Aspects of Configuration Management

Configuration Management is divided into a series of aspects. The aspects are organized around roles,
with back office aspects needed to manage the process, operational aspects to perform Configuration
Management activities against and extension aspects that operate on individual extension assets or
groups of extension assets. The figure below summarizes the set of policies and practices associated
with each of the aspects:
Figure 2. Aspects of Configuration Management
• Concepts. There are a set of key concepts that constitutes Configuration Management.
• Environment Management. To support the extension aspects of Configuration Management you

need a copy of the product installation to extend. Environment Management is about the
establishment, configuration and lifecycle processes associated with the product environment to
support Configuration Management.
• Version Management. During development multiple versions of individual extension assets are
created in a team environment using Oracle Utilities SDK and/or ConfigTools. Version Management
is a set of policies and processes to manage these individual versions of the extension assets to
support extension activities of individual or teams of developers.
• Release Management. A collection of extensions is a release which might represent an individual

change, group of changes or represent the whole extension spectrum. Release Management is a set
of policies and processes that allow the creation of installable releases and the related co-ordination
activities to prepare them for installation.
• Distribution. One a release is built and ready for release; Distribution is the policies and processes
for co-ordination of the installation of that release whether the destination is local or remote.
1
Term used for publishing purposes
• Change Management. In Configuration Management the process of deciding what is released is
decided in the policies and processes for Change Management. This back-office aspect drives the
operational and extension aspects.
• Defect Management. Out of the other processes including related processes like testing, defects are
raised to be corrected. Defect Management is the policies and processes that dictate how defects are
handled within the Configuration Management activities.
• Configuration Status. At any point in the lifecycle the status of all the activities and assets needs to
be able to be performed to report to interested parties. Configuration Status is a set of policies and
processes to enable effective reporting of state.
Why is Configuration Management so important?

Poor Configuration Management often causes the most frustrating software problems. The problems
are frustrating because they take time to fix, they often happen at the worst time (at the customer site),
and they are totally unnecessary. They often taint all the effort that has been done already to make sure
the system is functionally correct.
Do any of the following situations apply to you?
• A difficult bug that was fixed at great expense suddenly reappears. If a bug fixed in a version of
a program and implemented without tracking, then in future changes you may introduce an earlier
version reintroducing a bug. This can be frustrating for a customer who thought that a bug has been
solved for good.
• You cannot track what code is running in what environment. This can prevent implementation of
fixes and performing upgrades. There is a story of an implementation where the development team
onsite did not keep track of their code since they started developing. The team basically compiles
their code and then transfers the compiled object to production not tracking which source code it came
from. Over the period, it got to the state where it was almost impossible to determine which version of
the source belonged to which object in Production. Not only does this introduce the risk of
reintroducing already fixed problems back into production, it throws a doubt on upgrading and even
taking single fixes. If a recompile is required by an upgrade or single fix, then the risk is exposed and
can result in not taking an upgrade or fix for an issue. The only resolution for this type of situation is
to spend time attempting (i.e. guessing) to identify the correct version of the source for the object and
realigning all the code. This will take time (i.e. in search time and retesting time) and still not guarantee
success as you may not guarantee that the source matches the object.
• The relationships between code and data are not tracked leading to pieces of functionality not
working as expected or not at all. All the Oracle Utilities Application Framework based products are
primarily data driven products, key data must be provided to the product to recognize customizations
and operate customizations as expected.
• You are unable to track which environment has which release or which patch has been applied.
This can be critical in determining upgrade impact across the environments that a site has
implemented.
• The documentation delivered with the software does not match or is so out of date it is useless
to your customers. Releases include all types of assets and if one is not consistent with the other
then misunderstandings and negative impacts ensue.
All these situations (and more) are issues caused by ineffective or non-existent Configuration
Management practices. If you do not experience any of these problems or problems of a similar nature
you are either very lucky, do not have a Configuration Management problem or your Configuration
Management solution is either complete or so simple that is self-sustaining.
Configuration Management helps to reduce (or eliminate) these problems by offering a solution for
tracking and management of assets and releases.
How to Read this series

This series of documentation has been designed to educate all roles in an implementation about the
importance of Configuration Management for the success of the implementation and post
implementation. Individual parts of the series are targeted at diverse groups of individuals:
• Managers. Project Managers, Project Directors and Team Leaders.
• Configuration Management Personnel. Configuration Management personnel (managers and staff

who create releases and distribute them).
• Architects/Developers/Others. Any other role in the implementation.
The suggested reading order and components that are applicable to different groups are illustrated in
the table below:
Suggested Reading Guide
ORDER DOCUMENT MANAGER CONFIG MGMT OTHERS
1 Concepts ■ ■ ■
2 Environment Management ■ ■ ■
3 Version Management ■ ■
4 Release Management ■
5 Distribution ■
6 Change Management ■ ■
7 Defect Management ■ ■
8 Configuration Status ■ ■
9 Implementing Single Fixes ■ ■
10 Implementing Service Packs ■ ■
11 Implementing Upgrades ■ ■ ■
12 Preparing for the Cloud ■ ■ ■
Note: The ■ icon indicates that that group of people should read that component of the Configuration
Management Series. All groups are welcome to read outside this suggested reading guide.
CONFIGURATION MANAGEMENT CONCEPTS
For Configuration Management to be effective during an implementation and after, a number of key
concepts need to be understood.
Assets
An asset (also known as a Configuration Item) is a component (code, data or other) of the
implementation managed by Configuration Management. This can be something developed or acquired
by any other means (such as input directly), onsite or offsite.
The level of asset can get quite detailed with smaller and smaller levels of asset that can be managed
individually. The key to success is choosing the level you want to manage your assets to exhibit the
appropriate level of control. This concept will be discussed in the Version Management part of this series.
Base Product
The base product is the Oracle Utilities Application Framework based product assets delivered by the
Product Development team at Oracle. These are delivered at specific intervals in the form of the initial
installation of the product, upgrades, rollups and single fixes. The table below outlines the common
assets delivered with the product as part of the base product:
Base Product Asset Types
AREA ASSETS COMMENTS
Runtime Java SE, Database, This is either an operating system or provided with Oracle
PERL etc WebLogic, Oracle Database and/or Oracle Coherence.
Base Software Base Services Underlying base services delivered in Java archive format
including libraries.
Base Algorithms Algorithms available in compiled2 and source code format

for use in configuration. Any ConfigTools based objects are
delivered in data as Meta Data.
Base Batch Jobs Batch Programs supplied with the product.
Base Utilities Utilities supplied with the product for operations and
configuration purposes. These are typically used by the IT
group.
Database Base Schema Product delivered database schema including tables, views,
materialized views, sequences, indexes etc.
Base System Data Data provided that is necessary for the product to operate
at a base level.
Base Meta Data Data provided for product shipped functionality and assets
including any ConfigTool based assets.
Base Cloud Accelerator Prebuilt Meta Data and related configuration for Oracle
Utilities Cloud Services.
Base Demonstration Data Optional data used for product demonstration or product
familiarization activities. Also contains samples for reuse.
Other Base Documentation Online and downloadable documentation covering user,
configuration and administration roles.
Base Templates Product delivered configuration templates used for technical

configuration
Development Oracle Utilities SDK Java based development for non-Oracle Utilities Cloud
Service implementations
Extensions
An extension is any asset introduced, changed or removed as part of an implementation to implement
the customers’ business rules, practices and standards. In general, the following asset types are to be
considered extensions:
Extension Asset Types
AREA ASSET COMMENTS
Data Custom Meta Data Data configuration as well as any ConfigTools objects
Database Custom Schema Custom database objects including tables, views,

materialized views, indexes etc,
Custom Schedule Custom DBMS Scheduler based schedule
Code Custom Batch Jobs Java based batch jobs
Custom XSL Style sheets used for Inbound Web Services or External
Systems
Custom JSP JavaScript (JSP) based screens or libraries
Custom Utilities Custom operational utilities
Custom Templates Custom configuration templates
Custom Algorithms Java based algorithms
Baselines
A baseline is the sum of completed assets at a point in time, also known as a checkpoint. That point in
time will usually be around a release event, upgrade or significant date, such as coinciding with a phase
of the implementation. At that point the relevant assets are prepared for release and become the new
base on which each subsequent release is based against. Baselines can be automatic, triggered by
certain events, and non-automatic.
2
Compiled code is Java based assets only
Baselines are important as they provide a realization that the base of an implementation can move
during an implementation so that rework is not necessary (i.e. by considering previous baselines). For
example, when an upgrade of the base product arrives on site, that latest version becomes the new
base for any future work. Older baselines become obsolete and can be effectively forgotten and
removed. This is important as it affects release retention as outlined in the Release Management
whitepaper in this series. Baselines become restore points in case of problems.
In any Oracle Utilities Application Framework based product implementation there is in fact are two
distinct streams of baselines:
• Product Baseline. This baseline is associated with product releases and upgrades. A product
baseline is a copy of the base product at a certain release level and associated patches.
Note: A single fix release is not a baseline as the original version of the product is required for the single
fix to be applied against. The combination of the base and patches becomes the baseline, not the single
fix on its own.
• Customization Baseline. This baseline is associated with the customizations implemented during an
implementation and post implementation.
The Product Baselines and Customization Baseline are closely associated by the fact that when a
Product Baseline is implemented the corresponding Customization Baseline is recommended to be
assembled. This is because the assets in the Customization Baseline reuse some of the Product
Baseline assets. For example, base libraries are used in customizations to provide interfaces to base
modules.
It is very easy to confuse baselines with releases as baselines are associated so closely with releases
but there is a crucial difference. Once a baseline is taken all previous baselines become obsolete, where
releases can always be reversed out if necessary. In terms of effort baselines are not much extra effort
on an implementation:
• A Product Baseline is created when a new base version or upgrade is installed with all its follow-up
consequences, such as recompilation of customizations etc. All past versions, that are not active, now
become obsolete for basing any customizations against.
• A Customization Base is created when you recompile all customizations and do not wish to retain
older releases, which are not active. All subsequent work on customization is based upon that release.
These principles have been incorporated into the processes and principles outlined in the Release
Management whitepaper in this series.
Automatic baselines
There are a certain number of situations that, by their very nature, dictate that a baseline be taken
automatically. The following table outlines the typical automatic baselines:
Typical Automatic Baselines
PRODUCT BASELINES EXTENSION BASELINE
Initial Installation Initial delivery of extensions
Mandatory Rollup/Service Pack Major delivery of extensions
Upgrade including database and operating system
Non-Automatic baselines
During an implementation other events may require a baseline to be created for extensions3. Whether
a baseline is created in these situations is up to the Development Manager, Project Manager and/or
Project Director considering whether past baselines are still valid.
Situations that generate a potential Customization baseline include:
• The release of an important piece of functionality that is significant in functionality terms but is not
considered a major release (due to size).
• An operating system or database patch that is considered significant.
• A single fix from base product that includes changes to copybooks used by customizations.
• A significant data event such as completing the loading of control data.
Versions
A version is a variation of an individual extension asset. The processes employed to manage these
versions is outlined in the Version Management whitepaper in this series. Versions are usually
managed at the development level.
Releases
A release is a collection of assets ready for deployment associated with a baseline or any release event
including bug fixes (also known as emergency releases). The processes employed to manage these
versions is outlined in the Release Management whitepaper in this series. Releases are managed at
the appropriate level and become an asset itself which is tracked, once created.
CONFIGURATION MANAGEMENT APPROACH

During implementation and post implementation the approach to configuration management can be
summarized as follows:
• The assets from the customization are built using the relevant tools. Individual assets are version
controlled and stored in a configuration management repository, if necessary. This is the realm of the
development team who can use the repository to track the correct versions for the work they are
performing (e.g. fixes, upgrades or functionality releases) and mark the relevant assets as ready. This
aspect of Configuration Management will be covered in the Version Management whitepaper of this
series.
• The contents of a CM package will be influenced by what changes are to be implemented and what
defects are found during testing and post implementation. These aspects of Configuration
Management are covered in the Change Management and Defect Management whitepaper,
respectively, of this series.
• When ready, the relevant assets are extracted from the repository and placed ready for packaging
into a release or a single fix. The process includes the extract, transfer and packaging process to
produce a releasable unit known as a CM package. Typically, the CM package for a release a sum of
all the customizations, including data, up to the current date. This aspect of Configuration
Management will be covered in the Release Management whitepaper of this series.
• A set of environments are established to support all the activities required in the implementation and
any support activities after implementations. These will need to receive CM packages as required.
This aspect of Configuration Management will be covered in the Environment Management
whitepaper of this series.
• Once a CM package is available and set of environments are established the CM package will need
to be distributed and installed in these environments according to local conventions and processes.
This aspect of Configuration Management will be covered in the Distribution whitepaper of this
series.
• To check on all of the aspects of Configuration Management to ensure that the relevant CM packages
contain the relevant assets and the CM packages are implemented into the relevant environments at
the correct times a set of processes to audit and report the progress are required. This aspect of
Configuration Management will be covered in the Configuration Status whitepaper of this series.
GUIDELINES FOR EFFECTIVE CONFIGURATION MANAGEMENT

The following are a set of guidelines to guide you in designing and using a better Configuration
Management solution. Each of these guidelines should be somehow incorporated into every procedure
and plan that you build for Configuration Management in your project.
Treat each environment like a production environment

This principle may seem obvious but when designing a solution this principle is often ignored. When you
design any procedure to use in the Configuration Management it is a clever idea to assume that every
environment is a production environment for the following reasons:
• It tests the procedures from initial stages in lifecycle rather than at the later stages. For example, if
you treat your test environments as a production environment then the same (or similar) migration or
change procedures would be used, as for production. When the production migration happens, the
procedures would be used, tested and hopefully all problems ironed out. If you contrast this with
having different procedures for test and production, you will have no opportunity to test but in the
customer environments. If there any problems, then it would seem the developers are less than
professional and put the release in bad light. The customers would remember there was a problem
with delivery rather than the superior quality of the product or the fact that we may have delivered on
time or within budget.
• Production environments have unique characteristics that assist in making procedures more robust
and flexible:
• Assume that all data already in the database is to be kept. Any database changes or reference/system
data additions must be designed.
• All migrations and changes are done with minimal downtime or disruption to the users of the system.
• All changes should not compromise the integrity of the non-changed parts of the system or the stability
of other software/hardware on the same machines.
• Include processes and procedures for reversing out changes.
• Development activities should be performed in a minimum number of environments.
3
Product baselines are generally automatic as they are dictated by Oracle or the business in an upgrade situation.
• Reduce the amount of junk existing in the environment. For example, one off programs used by the
programmer to debug something or dummy database files.
• The availability requirements for a production system are usually quite high and there is no reason
why other environment should not have similar requirements during high activity. Just as a customer
would not appreciate a productions system down at a critical moment you would not want, say a
development environment, down when you are at a critical stage in the programming.
Management tasks are no different

During the planning, design and execution of any project activity, managers will use goals and objectives
to drive the project, have a management plan which they follow and use to manage the activities,
manage issues with developers and customers and manage risks on a day to day basis. Configuration
Management is no different. The techniques that any manager uses would apply to the Configuration
Management discipline but would only vary slightly to compensate for the type of work that Configuration
Management demands.
Remember Configuration Management produces output and output needs to be managed to be

successful. Of course, with any project, the amount of formalized management will vary with the size
and complexity of the project.
To this end a Configuration Manager should be appointed to manage the Configuration Management
aspects of the project.
Begin with the end in mind

The focus of delivery management is to deliver successfully. Firmly focusing on this when conducting
delivery management activities will make sure all the procedures are moving the project in the right
direction.
Assume an environment for change

Change is both inevitable and constant. As with any procedure or process in any development project,
refinements and changes in circumstances tend to result in corrections and updates. Configuration
Management is no different. In fact Configuration Management is all about change, managing change
and implementing change. Procedures and processes in Configuration Management should be both
easily adaptable to and robust to change.
All procedures and processes should be designed with change in mind and executed with change in
mind.
Minimize the number of environments

The number of environments to use should be minimized. Adding extra environments adds extra effort
to maintain and they keep up to date. If there is a requirement for an inordinate number of environments,
you might want to charge extra per unique environment. This would make the requestor of the unique
environment examine the need rather than the convenience.
In one real life situation, one customer insisted in having multiple testing environments to simulate
differing time periods. After examining the requirement rather the need for extra environments, it was
found that other alternatives could be found such as changing the system time, logically not physically
or restructuring the data to satisfy the requirement. The need to have the multiple environments was
eliminated but the requirement was satisfied.
Keep the solution simple as possible
For projects that are simple in nature the Configuration Management solution should be simple. For
projects that are complex there is no reason why the solution should also not be simple. Ensure that any
solution used for Software Configuration Management at your site can be maintained by the available
staff.
Don’t release unless documentation is complete

Do not release to any environment until all documentation, whether it is related to Configuration
Management or not, is complete and in line with what you are releasing. Gone are the days where
documentation was written retrospectively several weeks, months or years after it has been released.
The advantages of updating your documentation are obvious but need to be discussed:
• Other implementations may want to reuse your code and need documentation to understand and
customize it for their needs. If there is no up to date documentation this greatly reduces the likelihood
of documentation.
• End Users are more likely to ask for complete documentation.
Do not assume a tool is a silver bullet

Do not assume that buying a Configuration Management Tool will solve all your problems. They
automate most of the processes, but they are no replacement for the checks and balances (i.e. decisions
and sign off in formal change control and organization responsibilities) that is best served by human
interaction.
Tool vendors do not assist at all as they promote the tools as full lifecycle and solving all problems
(including world hunger…). They also typically will try to sell generic processes with the tool to illustrate
the full lifecycle or total solution aspect of the tool. Typically, the processes are basic and are applicable
as a starting point for the final processes, but do not cover the management aspects of anything but
basic projects. They are promoted as the Software Configuration silver bullet.
This series has purposely steered away from discussing tools to any detail for the above reason and the
fact that the facilities available in tools in constantly changing.
ORACLE CORPORATION
Worldwide Headquarters
500 Oracle Parkway, Redwood Shores, CA 94065 USA
Worldwide Inquiries
TELE + 1.650.506.7000 + 1.800.ORACLE1
FAX + 1.650.506.7200
oracle.com
CONNECT W ITH US
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at oracle.com/contact.
blogs.oracle.com/theshortenspot linkedin.com/in/theshortenspot twitter.com/theshortenspot
Copyright © 2007 - 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof
are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed
orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be
reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of
Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0119
Configuration Management Concepts - Oracle Utilities Application Framework
January 2019

Configuration Management Concepts: Oracle Utilities Application Framework (4.4.0.0.0)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuration Management Concepts: Oracle Utilities Application Framework (4.4.0.0.0)

Uploaded by

Copyright:

Available Formats

Configuration

WHITE PAPER / JANUARY 2019

Configuration Management Overview.......................................................... 5

Aspects of Configuration Management ........................................................................................ 6

Why is Configuration Management so important? ....................................................................... 7

How to Read this series ............................................................................................................... 8

Configuration Management Concepts ......................................................... 9

Base Product ............................................................................................................................... 9

Automatic baselines ...................................................................................................................11

Non-Automatic baselines ............................................................................................................12

Configuration Management Approach ....................................................... 12

Guidelines For Effective Configuration Management................................. 13

Treat each environment like a production environment ..............................................................13

Management tasks are no different ............................................................................................14

Assume an environment for change ...........................................................................................14

Minimize the number of environments ........................................................................................14

Keep the solution simple as possible..........................................................................................15

Don’t release unless documentation is complete........................................................................15

Do not assume a tool is a silver bullet ........................................................................................15

Configuration Management is set of policies and processes for managing

CONFIGURATION MANAGEMENT OVERVIEW

Figure 1. Extension Spectrum

The extension spectrum has the following attributes:

Aspects of Configuration Management

Figure 2. Aspects of Configuration Management

• Environment Management. To support the extension aspects of Configuration Management you

• Release Management. A collection of extensions is a release which might represent an individual

Why is Configuration Management so important?

Do any of the following situations apply to you?

How to Read this series

• Managers. Project Managers, Project Directors and Team Leaders.

• Configuration Management Personnel. Configuration Management personnel (managers and staff

• Architects/Developers/Others. Any other role in the implementation.

Suggested Reading Guide

ORDER DOCUMENT MANAGER CONFIG MGMT OTHERS

9 Implementing Single Fixes ■ ■

10 Implementing Service Packs ■ ■

12 Preparing for the Cloud ■ ■ ■

Base Product Asset Types

AREA ASSETS COMMENTS

Base Algorithms Algorithms available in compiled2 and source code format

Base Batch Jobs Batch Programs supplied with the product.

Base Templates Product delivered configuration templates used for technical

Extension Asset Types

AREA ASSET COMMENTS

Database Custom Schema Custom database objects including tables, views,

Custom Schedule Custom DBMS Scheduler based schedule

Code Custom Batch Jobs Java based batch jobs

Custom JSP JavaScript (JSP) based screens or libraries

Custom Utilities Custom operational utilities

Custom Templates Custom configuration templates

Custom Algorithms Java based algorithms

Typical Automatic Baselines

PRODUCT BASELINES EXTENSION BASELINE

Initial Installation Initial delivery of extensions

Mandatory Rollup/Service Pack Major delivery of extensions

Upgrade including database and operating system

Situations that generate a potential Customization baseline include:

• An operating system or database patch that is considered significant.

• A significant data event such as completing the loading of control data.

CONFIGURATION MANAGEMENT APPROACH

GUIDELINES FOR EFFECTIVE CONFIGURATION MANAGEMENT

Treat each environment like a production environment