Business Glossary workflow management update for version 9.1

Business Glossary workflow management update for version 9.1


Let’s learn how to create and update business
glossary assets using Business Glossary Workflow, which was introduced in InfoSphere Business
Glossary 8.7 and enhanced in a patch to InfoSphere Business Glossary 9.1. The patch has been
available since April 2013. The two main benefits of Workflow are: Number
1: we can develop glossary content—terms, categories, policies, and rules– in a separate
logical partition, without touching the glossary that ordinary users access. And number 2:
the glossary changes in this development environment can be reviewed, approved and published before
they can be viewed by the general audience. Let’s get up and running in 3 steps. First, while logged in as a Business Glossary
Administrator, we find the Workflow management screen and turn it on. Second, we add Business Glossary users as
workflow participants and assign Editor, Reviewer, Approver, and Publisher workflow roles to
the glossary and governance team members. Each workflow role gives users certain capabilities.
Editors create and update content. Reviewers can review the content. Approvers approve
the content, and after it is approved and is ready for deployment throughout the enterprise,
Publishers publish that content. As we can see when assigning workflow roles,
not all users can be assigned to all workflow roles. The Business Glossary security role
of the user controls what workflow roles are available. Editors and Publishers must have the Business
Glossary Author security role. Reviewers and Approvers can have the less privileged Business
Glossary User security role. Here, we’ll give Eddie the Editor role, Anne
the Approver role, and we’ll make Pat the Publisher. And, although they are not required
to make the workflow feature operable, we’ll enable other users to review—in other words,
they will be able to see and comment upon, but not change, items in the development glossary. Notice that it’s also possible for one user
to have a combination of workflow capabilities. Here, for example, we give Omni the Editor,
Approver, and Publisher roles, so that she can fully control the lifecycle of her content
by herself. Once enabled, we can see that our single glossary
duplicated itself and we now have a Development Glossary in addition to a Published Glossary. Now let’s move to Step Three — determining
subject area ownership with Development Glossary Permissions. Per category, I can declare that only certain
users or groups will be responsible. To be listed here, users and groups must have a
workflow role, such as we just assigned. Let’s say that Eddie, Anne, and Pat are on
the governance team for the Claims category. We’ll give them and all of the reviewers permissions
to that category and all of its subcategories. Omni, though, has permissions to the Legal
category. This separation of ownership ensures not only
that the right people are working in their areas of expertise, but that no toes are stepped
on and there are no dependencies between departments, projects, or any other division within the
glossary team. We’re done setting up now. We’ve enabled workflow,
assigned capabilities, and assigned development glossary category permissions, so let’s get
to work. We’ll log out and then come back in as Eddie,
one of our Editors. Let’s watch Eddie as he updates an existing
term and then creates a new one. For the term Agent, he simply needs to add
a steward. And the new term, Broker, he adds to the Claims
category. These two terms are now in the Draft state,
the first of three workflow states that new or changed content must pass through before
being published. Drafts can be Sent for Approval one at a time
or in a batch as we see here. A brief comment will help the reviewers and approver—anyone
who views the asset within the development glossary—understand the context, intention,
or specifics of the changes. Any user who has a workflow role can view
assets in the development glossary. Let’s look at the 2 terms we are working on from
the point of view of reviewer Rita. In the assets pending approval, Rita notices
that the term Broker was created without a description. She enters a comment mentioning
this. Notice that users with any workflow role can
view and comment upon assets that are in any workflow state.
When Eddie looks at the development log for the term Broker, he can see this comment from
Rita. He returns the term to draft so that he can
edit it. Eddie enters the missing description, and
sends the term for approval. Let’s switch to the point of view of Anne,
the approver who works with Eddie. She needs to review the 2 terms that are Pending Approval.
The first term looks good, worthy of approval. We can see that “Agent” has changed states
from Draft to Pending Approval. Some Reviewers had some issues with the definition
of Broker, which we can see from their comments in the development log. All users with workflow roles can see comments
from each other, enabling collaboration among as large a group of users as needed.
Now, Anne makes her own comment on this and sends “Broker” back to draft. Back to Eddie’s perspective: We see there
are no more items pending approval, but here is the term that was returned to draft by
Anne. Eddie makes his changes….Saves….And sends
it once again for approval. Back to Anne, who checks her items pending
approval and approves this latest change. Now, Pat, our Publisher, can publish the approved terms.
Pat goes ahead and publishes the changes. Now the job is done. We see our new and revised
terms in the published glossary. Our controlled, governed development process, now enabling
participation by more members of the enterprise, has yielded trustworthy new content for the
benefit of all.

You May Also Like

About the Author: Oren Garnes

Leave a Reply

Your email address will not be published. Required fields are marked *