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