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