Data Cookbook specification workflow cheat sheet

• About workflows
• IU standard specification approval
  • Underlying assumptions
  • Stages of standard specification approval
  • Canceled specifications

About workflows

Workflow definition

In Data Cookbook, a workflow is a predefined process for approving an object or a request for information. Data Cookbook includes a customizable workflow engine. Custom workflows specific to Indiana University were created and tested for adoption by the IU Data Cookbook community during the first quarter of 2017.

Workflow types

Data Cookbook includes three basic workflow types: definition approval, specification approval, and information request resolution. At IU, Data Cookbook only uses workflow for definitions and specifications.

Workflow stages and steps

Stages

Each workflow has several stages that represent a point in the process that requires specified action from one or more users or groups of users.

Happy path

In Data Cookbook, "happy path" is a term that describes the most common approval process. In project management terminology, this would be the critical path. Steps with green-colored transition action buttons are the happy path for the stage.

Steps

In a stage, steps represent available tasks and/or groups of actions. Steps can be required or optional and may be assigned to specific users or user groups based on the workflow object's attributes.

Transition actions

Transition actions are associated with steps within stages and represent what a user does to move an object from one stage to another. These actions appear as buttons on the definition or specification. The transition actions available to a user will depend on both the user's role and the workflow stage that contains the object.

In the following example, two transition actions are available; you can send the definition to QA or reject it:

Conditions

Conditions function as "where" clauses for workflows. Conditions let you specify appropriate workflows or steps based on criteria such as functional area, data system, or classification code.

Note:

IU Data Cookbook currently doesn't use conditional criteria. For ease of understanding and maintenance, the current implementation defines a flexible standard approach to workflow. Direct experience and business requirements will dictate future revisions to workflows or the creation of conditional workflows.

Workflow permissions

Workflow stages, steps, and transition actions are governed by permissions handled by interactions between user groups, assignment mappings, and named roles.

User groups

User groups are the primary means for granting permissions within Data Cookbook, especially in the absence of workflow integration. You can grant user groups permissions for definitions, specifications, and technical information based on functional area. For specifications and definitions, these permissions are manager, editor, and viewer. For technical information, these permissions are editor, view, and hidden. Any user assigned to the group will have the permissions associated with the group.

Note:

Workflow stages and steps can override user group permissions both positively and negatively. For example, during the quality assurance stages of workflows, only staff associated with QA functions are allowed to make modifications. Conversely, data stewards or data managers may sometimes delegate authority to user groups to edit or approve definitions.

User groups of moderators and editors are associated with definitions; user groups of specification managers and specification developers are associated with specifications.

Assignment mappings

Assignment mappings are a way to create "super groups" of users for assigning steps in a workflow. They allow workflow standardization and let you create correlations between attributes such as functional areas, data systems, or specification types so that you can assign user groups to specific steps in workflow stages.

As mentioned in the Conditions section, the current implementation of Data Cookbook defines a standardized workflow that uses assignment mappings based on functional area. Direct experience and business requirements will dictate future revisions to this approach.

Named roles

Named roles allow you to define a "pool" of users who may be added to a workflow step when the step is initiated. These users are assigned by another defined "pool" of users who receive notification to make an assignment. If you are tasked with managing an assignment, named roles let you assign an individual user to a step in a workflow stage.

Note:

At this time, named roles can't be mapped to functional areas and are not being used. Instead, IU Data Cookbook uses assignment mappings and user groups to associate specification managers and developers to workflow stages and steps in the appropriate functional areas.

IU standard specification approval

Underlying assumptions

The stages of the IU standard specification approval workflow were created using the following assumptions:

• The fewer the variations that exist, the more understandable and maintainable the workflows will be.
• Data managers and data stewards are not necessarily directly involved in the workflow unless they have requested or are overseeing the specification under development.
• Product owners, functional managers, and business analysts will be responsible for initial drafts and/or approval as appropriate.
• Quality assurance is necessary for good governance to ensure a solid body of consistent standardized information; however, QA should not adversely affect the workflow.
• All stages will have explicit steps that allow designated workflow administrative users to intervene and "unstick" the workflow as needed. This step will not be included in subsequent documentation.
• Data stewards grant approval of security classification at the specification level outside Data Cookbook via existing systems and channels (for example, ACM).

Stages of standard specification approval

At IU, approval of a standard specification proceeds through the following stages; see below for a visual representation of these stages:

1. Initial Draft
2. Development
3. QA Initial Review
4. Approval Requested
5. QA Final Review
6. Approved

Note:

To see the transition action buttons for a particular specification, to the far right and near the top of the specification, select the Workflow tab:

1. Initial Draft

Specifications are created and revised during the initial draft stage. In this stage, you'll create a request for a report and flesh out its business requirements. This stage's primary step is draft specification.

a. Draft Specification

Access to the "Draft Specification" step is available to members of the "Spec Drafters by Functional Area" assignment mapping. By default, this step is mapped to the moderator user groups; note, however, that it is not assumed that this step is the responsibility of the moderator or data manager. In areas where EBI has ongoing or anticipated future development, the EBI business analysts and the EBI AM360 product owner are also mapped to this step. Additionally, for the financial and budget areas, the EBI KPI product owner is mapped to this step. Mapping of user groups to this step will be updated appropriately based on adoption and need. As user groups for specification managers by functional area are incrementally built, they will also be mapped to this step.

After you've completed the initial draft stage, move the report to the development stage for potential assignment to a specific person for development. To take a transition action on the specification, under "Step(s): Draft Specification", click Submit or Cancel:

2. Development

Once you've made your request and added the initial requirements to the specification, the development stage begins. The development stage is made up of the primary "Initial Development" step, as well as two optional steps, "Edit Specification - Manager" and "Edit Specification - Drafter".

a. Initial Development

Access to the "Initial Development" step is available to members of the "Specification Developers by Functional Area" assignment mapping. Once the specification is under development, any developer in this group can edit the specification to reflect the iterative development and refinement of requirements. When complete, click Request QA to submit the specification for QA:

During the development stage, the manager and the specification drafter have the option to edit the specification:

• Edit Specification - Manager: Access to the "Edit Specification - Manager" step is available to members of the "Specification Managers by Functional Area" assignment mapping. The specification manager can edit and take various transition actions on the specification in this step. To take a transition action on the specification, under "Step(s): Edit Specification - Manager", click Request QA, Back to drafting, Cancel, or QA Final Review:
  
• Edit Specification - Drafter: Access to the "Edit Specification - Drafter" step is available to members of the "Specification Drafters by Functional Area" assignment mapping. The user group that drafted the specification can edit and take various transition actions on the specification in this step. To take a transition action on the specification, under "Step(s): Edit Specification - Drafter", click Request QA, Back to drafting, or Cancel:
  

3. QA Initial Review

During the QA initial review stage, specifications are checked for compliance with naming conventions and adherence to IU's Data Cookbook standards. Only administrators are able to edit a specification in the QA initial review stage, to ensure that QA is not being done on a moving target. In general, standards and formatting are overseen by the QA role, while the actual specification content is overseen by the product owner or specification manager role. The EBI team within UITS is the service owner for Data Cookbook, and staff from the EBI team are currently responsible for QA. A specification that passes QA is submitted for approval; if it does not pass QA, it will be returned to the previous stage for further revision.

The QA initial review stage is made up of the primary "QA Initial Review" step, with an optional "QA Return for Revision" step.

a. QA Initial Review

QA occurs during the "QA Initial Review" step. To take a transition action on the specification, under "Step(s): Request Approval", click Request Approval or Return for Revision:

• QA Return for Revision: The "QA Return for Revision" step is an optional step allowing members of the "Specification Managers by Functional Area" assignment mapping to intervene and return the specification for further development or refinement. To take this transition action on the specification, under "Step(s): QA Return for Revision", click Return for Revision:
  

4. Approval Requested

During the approval requested stage, members of the "Specification Manager by Functional Area" assignment mapping review the specification and then either approve it or return it (and, by extension, return the associated report/object) to development. Note that this step represents approval of the specification itself, not data manager security approval for the report/object, which is handled via regular processes.

The approval requested stage is made up of the primary "Approve Specification" step (associated with the specification manager), and the optional "AC Return for Revision", "Spec Drafter Delegation" and "Cancel" steps. Only the original report requester has the option to cancel at this point.

a. Approve Specification Step

In the "Approve Specification" step, the specification manager reviews work to date on the specification and the associated report/object, and then either approves it or sends it back to development for modifications. For DSI-related specifications, this approval is associated with the product owner. To take a transition action on the specification, under "Step(s): Approve Specification", click Approve, Cancel, or Return for Revision:

• AC Return for Revision: In the "AC Return for Revision" step, agile coaches can return the specification to the development stage, allowing them to correct issues they or the product owner have identified without the PO having to take action. To take this transition action on the specification, under "Step(s): AC Return for Revision", click Return for Revision.
  
• Spec Drafter Delegation: In the "Spec Drafter Delegation" step, the user group associated with drafting specifications for the associated functional area can choose to return the specification for revision or to cancel it. To take a transition action on the specification, under "Step(s): Spec Drafter Delegation", click Cancel or Return for Revision:
  

5. QA Final Review

During the QA final review stage, the specification gets a final check for compliance with naming conventions, adherence to IU's Data Cookbook standards, and completeness. Only administrators are able to edit a specification in the QA final review stage, to ensure that QA is not being done on a moving target. In general, standards and formatting are overseen by the QA role, while the actual specification content is overseen by the product owner or specification manager role. The EBI team within UITS is the service owner for Data Cookbook, and staff from the EBI team are currently responsible for QA. A specification that passes final QA is approved and becomes the current official version.

The QA final review stage is made up of the primary "QA Final Approval" step, with optional "Return to Spec Manager" and "QA Return for Revision" steps.

a. QA Final Approval

Final QA occurs during the QA final approval step. To take a transition action on the specification, under "Step(s): QA Final Approval", click QA Final Approval, Return for Revision, or Return to Approval:

• Return to Spec Manager: In the "Return to Spec Manager" step, the product owner can return the specification to the previous stage, in order to correct any identified issues or perform any other actions available in the "Approve Specification" step. Note that the user in this step may be a member of both the specification managers and the specification drafters groups; this will not be uncommon. To take a transition action on the specification, under "Step(s): Return to Spec Manager, Return for Revision", click Return for Revision or Return to Approval:
  
• Return for Revision: In the "Return for Revision" step, the user group associated with managing specifications for the associated functional area can choose to return the specification for revision or, where there is an assigned product owner, to act on behalf of the PO. To take a transition action on the specification, under "Step(s): Return for Revision", click Return for Revision or Return to Approval:
  

6. Approved

The approved stage is the final stage of the specification workflow. A specification that reaches this point has received approval for both content and format, and is the current official version for the IU Data Cookbook community. Any subsequent revision to an approved specification requires a new version of the specification to be created, and those new versions must go through the above workflow and be approved in their turn.

Canceled specifications

At various stages and steps in the workflow, appropriate users can choose to cancel a specification for any reason (for example, duplication of specifications, discovery that the specification is not required).