Cloud Services

ModernOps configuration

Context
Published On Sep 04, 2024 - 11:25 AM

Context

Learn about context, which is the refining element that promotes proper routing, permissions, and visibility.
Context exists because:
  • Context links business needs with performance of cross-functional and interdepartmental tasks in the Kyndryl Modern Operations Applications.
  • A group of users should be able to order only a subset of services from Enterprise Marketplace.
  • Specific services need to be approved by specific approvers (both technical and financial).
  • Orders placed for specific services are assigned to specific budgetary buckets.
  • Orders placed for specific services are provisioned using the asset credentials that are assigned to that group.

Context type and context value

Context is a construct in Kyndryl Modern Operations Applications that is used for the following purposes:
  • Setting up authorization (defining scope of authorization).
  • Establishing approval routing.
  • Associating credentials with an order.
  • Associating credentials with a business entity.
  • Associating a budget with an order.
  • Setting up catalog visibility policies for services in Enterprise Marketplace.
Context has two parts to it:
  • represents a business entity such as a project, an environment, or a cost center. Context type may be associated with one or multiple context values. Managing context types is limited to System Admins and User Admins.
  • Context value
    represents the different values for the context type. Each context value is associated with one and only one context type.
Context types come in two strains:
  • An
    independent
    context type has no dependency on any context value from other context types.
  • A
    dependent
    context type has dependency on context values from other context types.
Example:
Project
is an
independent
context type with potential context values of
Proj1
and
Proj2
.
Cost Center
is a
dependent
context type with potential values of
CostC1
,
CostC2
,
CostC3
, and
CostC4
.
Project
Cost Centers
Cost Centers
Proj1
CostC1
CostC2
Proj2
CostC3
CostC4
If project
Proj1
is selected, then cost center values should be set to
CostC1
and
CostC2
.
If project
Proj2
is selected, then cost center values should be set to
CostC3
and
CostC4
.
Dependent context types will always be sourced from an external system.

Context in authorization

In Kyndryl Modern Operations Applications, a role is used to define the actions that you can perform. In this case, context is used to identify the business objects on which you can perform actions.
Example:
User2
is a member of the
Team2
and has the role
Technical Approver
for the organization
Org=O1
. The context type-value pair is
Org=01
. User
User2
can perform all team
Team2
functions for which the
Technical Approver
role has permissions when the context is
Org=01
.
The following examples include definitions established in the table below.
User
Team
Role
Context type
Context value
Contexts (type-value pairs) to set up
Notes
User1
Team1
Buyer
Team
Team1
Team=Team1
User1 is a Buyer for Team1 and the
Refactoring
project
User2
Team2
Technical Approver
  • Org
  • Environment
  • 01
  • Dev
  • Org=01
  • Environment=Dev
User2 is a Technical Approver for the O1 org and the Dev environment
User3
Team3
IT Financial Controller
Project
Proj1
Project=Proj1
User3 is an IT Financial Controller for the Proj1 project

Context in approval routing

In approval routing, Kyndryl Modern Operations Applications uses context to route approvals to the correct set of users. For example, in Enterprise Marketplace, context is used to route an order to the correct team for approval.
Example:
User1
orders services for
Team1
, which needs approval from the
Dev
environment (
User2
). The order should be routed to the
Dev
architects team (
User2
) for technical approval because
Environment=Dev
is the context type-value pair.
Solution:
User1
with the role of
Buyer
can place orders for
Team1
and environment
Dev
, routing the order through the Dev architects team for technical approval.

Context in provider account management

Context is also used to associate a credential to a business object. For example, in Enterprise Marketplace, context is used to associate a credential to an order.
Example:
User1
can order services for
Team1
and the
Refactoring
project. The credential
Refactoring Credential
should be used for this service offering instance (SOI).
Solution:
User1
with the role of
Buyer
can order services for
Team1
and the
Refactoring
project using
Refactoring Credential
as the credential for the SOI.

Context in budget management

Context is used to associate a credential to a business object in this example too. In Enterprise Marketplace, for example, context is used to allocate the spend for an order to a specific budgetary unit.
Example:
User1
can order services for
Team1
and for the
Refactoring
project. Spend for
Refactoring
project orders should get allocated to the
Refactoring
budgetary unit.
Solution:
User1
with the role of
Buyer
is associated with contexts
Team1
and
Environment=Dev
.
User1
orders for the
Refactoring
project, allocating the spend to the
Refactoring
project's budgetary unit.

Context in catalog visibility policies in Enterprise Marketplace

In Enterprise Marketplace, context is used to determine which services are made visible to different users in Enterprise Marketplace. Currently, only out-of-the-box context types (context types
Team
and
Org
) are supported in Catalog Visibility Policies.

Team-based visibility policy

Example:
Services
A
and
B
should be made visible to
Team1
.
Services
C
and
D
should be made visible to
Team2
.
Solution:
Create catalog personalization policy
CPP1
, set services
A
and
B
to be visible to
Team1
. Create catalog personalization policy
CPP2
, set services
C
and
D
to be visible to
Team2
.

Org-based visibility policy

Example: Services
A
and
B
should be made visible to
Org=O1
.
Services
C
and
D
should be made visible to
Org=O2
.
Solution:
Create catalog personalization policy
CPP1
, set services
A
and
B
to be visible to
Org=O1
.
Create catalog personalization policy
CPP2
, set services
C
and
D
to be visible to
Org=O2
.
Do you have two minutes for a quick survey?
Take Survey