Workflow and types of user

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