To incorporate CICS® Configuration Manager into your workflow, it is useful to consider the
different types of CICS Configuration Manager user. The users and the workflow described here
represent only one possible scenario. Some types of user may not apply to
your organization, and your organization may have types of user not listed
here. Keep in mind that one person may perform the roles of several types
of user.
- CICS Configuration Manager administrator
- It is recommended that you nominate one person as the CICS Configuration Manager administrator.
Only this person should be authorized to create or update CICS configurations,
migration schemes, approval profiles, and transformation rules. (These are
the definitions under ISPF dialog option 1 Administer.) This will help to ensure
consistent naming of these definitions.
Typically, the CICS Configuration Manager administrator
is an experienced CICS administrator.
- Security administrator
- The security administrator might not actually use CICS Configuration Manager, but is responsible
for updating the security database (for example, RACF®) to meet CICS Configuration Manager security requirements.
For details, see Security.
Defining approval profiles
may involve both the CICS Configuration Manager administrator and the security administrator.
The CICS Configuration Manager administrator defines the approver roles in the approver profiles;
the security administrator must update the security database to recognize
these approver roles.
- Application developers
- Application developers may need to create resource definitions for new
applications, or edit resource definitions to match changes to existing applications.
Application developers may also need to package resource definitions (add
them to change packages) to assist their migration to other environments.
Edit once, migrate many times:
Although you can use CICS Configuration Manager to edit resource definitions directly in any CICS environment, one benefit of CICS Configuration Manager is that you can edit resource definitions
in one environment only, and then use change packages to migrate those edits
to other environments. For example, you might choose to edit resource definitions
only in your development environment, and then use change packages to migrate
those edits to your test environment, and then to production. This allows
you to separate the responsibility for editing resource definitions from migrating
those edits between environments.
- CICS administrators
- CICS administrators may need to edit resource definitions to reflect
changes in CICS systems, such as changes in the topology of CICS regions, or
upgrades to new versions of CICS.
- Project managers
- Project managers need to coordinate how changes to resource definitions
are introduced into the "life cycle" of CICS environments. To do this, project managers
can create change packages in CICS Configuration Manager, then direct application developers
and CICS administrators to add new or changed resource definitions to the
appropriate change package. When all edits to the resource definitions in
a change package are complete, the project manager marks the change package
as ready. The ready change package can be approved or disapproved, if required.
- Approvers
- Approvers can approve or disapprove change packages. Approvers should
be the "stakeholders" in a change package. For example, this could include:
- Developers who are responsible for approving a change before it is migrated
from their development environment to the test environment.
- Testers (members of a "quality assurance" team) who are responsible
for approving a change before it is migrated from their test environment to
the production environment.
- Users who could be affected by a change package being migrated to their
production environment.
- Change administrators
- Change administrators need to control and audit changes to the system
environment. After a change package has been approved, the change administrator
can migrate it to the target CICS environment (for example, from development
to test, or from test to production). If the migrated changes cause problems
in the target CICS environment, the change administrator can undo the
changes by backing out the change package.
Figure 1. Workflow and types of user: a possible scenario