HP Configuration Management System

Best Practices Library

Consumer Onboarding

Revision 2, June 3, 2010

Planning and Design Guides

2

Documentation Updates

Table 1 Document Changes

Chapter Version Changes

Revision 1 Initial document

Rev2 Rev2 updates

3

Contents

Consumer Onboarding ................................................................ 4

Overview .................................................................................................................................................. 4

Audience .................................................................................................................................................. 4

Prerequisites ............................................................................................................................................ 4

Chapters Summary .................................................................................................................................. 4

Related Documents ................................................................................................................................. 5

Qualifying a New Consumer ........................................................ 6

Thorough Documentation of Consumer Identity .................................................................................... 6

Rationalization of the Consumership ...................................................................................................... 6

Declining a Consumer .............................................................................................................................. 6

Documented Use Case(s) and Data Requirements .................................................................................. 7

Consumer Conduits ...................................................................... 8

Regulation ................................................................................................................................................ 9

Consumer Onboarding Process ................................................... 10

New Consumers ..................................................................................................................................... 10

Adding Scope to existing Consumers ..................................................................................................... 14

Consumer Decommissioning ....................................................... 15

Triggers for Decommissioning Evaluation ............................................................................................. 15

Reference Process ................................................................................................................................. 15

Index ....................................................................................... 17

4

Consumer Onboarding

Overview

This CMS Best Practices library is a series of documents and artifacts providing a comprehensive and consistent, and intersecting set of guidelines for creating processes and integrations using a Configuration Management System, or CMS, as defined by ITIL v3.

This approach is defined by a model called the Consumer/Owner/Provider model. This model shows how the CMS provides managed configuration data to consumers in a way that makes the providers transparent to the consumers and maintains a high level of data integrity. This underlying theme of data integrity, and the benefits it affords to IT service management, is what makes these best practices “best”: a CMS created without data integrity at the forefront will be no more than a CMDB forced into service as a data integration platform.

This document is focused on the Consumer side. During initial deployment of the CMS, the first few consumers are onboarded. After the CMS deployment attains production status, the same processes are used to allow new consumers and use cases to obtain configuration management data.

The best CMS is one that is created for users and their use cases – by the business itself. A successful CMS not only houses configuration data, but establishes lines of communication to talk to the business on a continuous basis. Keep consumers interested in the CMS, let them know what benefit they can get out of it, give them the ability to use a test system with assistance from configuration management.

The preferred position to drive the CMS is from the bottom up (consumers) instead of from the top down (senior Management). Management should support and sponsor the consumers, but not necessarily come up with the need for a CMS. This should be a warning for CMS architects. “Go build a CMS because we need one” is a dangerous tautology which should be avoided until firm use cases are understood. This document explains how to approach CMS from a consumer-driven perspective.

Audience

This document is for CMS architects and implementers who need to understand, create, modify, or document processes related to onboarding new consumers and use cases to the CMS.

Prerequisites

The reader should be familiar with the CMS Strategy Guide and the section on Process Governance, which describes the Consumer/Owner/Provider Model as documented in the CMS Best Practices Library.

Chapters Summary

Chapter 1 Introduces basic consumer onboarding document.

Chapter 2 Discusses the qualifications for a new consumer, and how to document and rationalize new consumer requirements.

Chapter 3 Explains the types of consumption, when to use them, and the pros and cons of each choice.

Chapter 4 Describes a reference process for consumer onboarding.

Chapter 5 Discusses the decommissioning of a consumer in terms of CMS and CMDB.

5

Related Documents

This document is part of the CMS Best Practices Library. Other documents may refer to this document and this document may refer to others in the library.

A good starting point is the the CMS Strategy Guide document.

A companion document to this document, “Provider Onboarding”, describes how to properly add content to the CMS.

Other documents in the CMS Best Practices library may apply as well, for example, how to plan and deploy DDM discovery and integration patterns.

6

Qualifying a New Consumer

New consumers should be properly qualified and documented before being granted access to the CMS, and before very much work is done to do the onboarding.

Existing consumers should have a “fast track” process to request and consume additional configuration data after being onboarded.

At a minimum, new consumers should provide the following information:

Thorough Documentation of Consumer Identity

Who is the consumer? What is the consumer’s role in the organization? Enough specifics should be provided as to provide accountability for all interaction with the CMS. For example:

- Name and Identity of Consumer

- Consumer representative Contact information

- Consumer Location information (may be multiple locations if the consumer is a group of users or a distributed set of applications representing a single business function)

- Which ITSM process this consumer represents

Rationalization of the Consumership

The goal of rationalization is to ensure the consumer needs CMS data and is a valid consumer and has a valid use case which the business or IT wishes or needs to pursue. This can be documented in use cases, business cases, justification, proposal, or whatever form is customary and determined by the IT organization. For example:

Assertion of the authority under which the consumer is acting. This may be in the form of management sponsorship, business case, initiative authority, imperatives such as data center transformations or compliance/audit, etc.

Assertion of the business value generated by the consumership.

Security perspective of the consumership, any risk introduced, etc.

List of specific persons and applications that will have access to the consumer conduit.

If the data will be stored (and not just used) by the consumer, enough documentation to maintain the chain of integrity and security as required by Security Management, as appropriate according to:

o the type and sensitivity of the data to be stored o how it will be stored (what physical and logical mechanism) o limits on how long any data can be held o how long it will be stored o how it will be purged or discarded securely

Declining a Consumer

It is the configuration manager’s responsibility to accommodate consumer requirements, if the consumer is rationalized properly. However, the case may arise where a consumer requests access to the CMS, and fails to pass one of the steps. For example, the consumer’s use case is not strategic to ITSM or the business. A very relatable (but possibly unrealistic) example: let’s suppose the mainframe owner wishes to copy the CMS contents to punch cards. The configuration manager is responsible for the process of gracefully declining the consumer request and providing options. The configuration manager, at their discretion, may:

7

Suggest alternative sources of data or alternative conduits of CMS consumption

Suggest alterations to the consumer’s requirements

Suggest an alternate way of accomplishing the consumer’s goals

Identify a particular requirement which invalidates the consumership

Postpone the request to a later time as technology/budget/etc. improves

The consumer may then accept the configuration manager’s resolution or escalate the issue.

Documented Use Case(s) and Data Requirements

Use Case documentation has robust processes already defined. The important thing is to treat a use case as a Service or part of a Service. This way, the use case benefits from a defined structure for services (provided by ITIL), and generates optimization of consumer onboarding (via the Continual Service Improvement process).

This should include, at a minimum, the following:

An exact list of the data to be consumed. This should include a list of CI types, attributes for each CI type, and any relationships that will be consumed or expected to accompany the consumed CIs. For example:

o Node consumption:

Nodes representing Windows or UNIX servers Attributes: OS type, Host name, OS version, Owner, Production Status, Physical Location, and cost basis

(this will obviously require some federation to occur but this is not the concern of the consumer) For each node

The number and speed of CPUs

Amount of installed memory

Total amount of local hard drive space installed For each node:

Any relationships representing dependencies which are normally constantly connected

Example of documenting what CMS data will be consumed.

Documented flow of data from CMS, through the consumption process. This should include inputs, outputs, and a

basic description of the processes which act on the data.

List of process interactions and transitions.

Whether this consumer is a provider as well.

Document which Processes consumer is involved in.

Document Process transitions to other consumers or providers Document Process transitions to other consumers or providers Service / process transitions – who the consumer gives the data to, if any. If the data is used only internally to the consumer, consider requiring this to be stated as well.

8

Consumer Conduits

The process should document the type of conduit expected to be used, and the type of consumer connection to the conduit. Here are some examples of the most common consumer conduits:

Conduit Consumer

Type When to Use Examples

Consumer Example

Pros and Cons Service or Process Example

UCMDB UI

Person Internal config mgt. only. Not end users

-Configuration Manager

-Hard to validate except at class model level (see data modeling guide) -overhead +out of box +flexible ad hoc queries

Configuration Management

PDF Report

Person Non-tech Business consumers or straightforward requirements

-Provisioning Technician

+secure +simple to create +user-pullable

Release Management

CSV Report

App External report writing, interoperability with another application’s import mechanisms

-Crystal Reports -External Analysis system

+simple to create +user-pullable

XML Extract

App Application/program consumers

-Asset Analysis System

+easy to create -requires knowledge to create

Asset Management

DDM Push

App Application/program consumers

-Service Desk sync.

+flexible, versatile -requires knowledge to create +can “push” updates via integration adapters as well (not only discovery)

Incident Management

Java API and SDK

App Complex rqmts. for reconciling

-RC Impact Analysis

+faster than web service – uses native Java interface +Richer set of methods and properties +clients can be written in any language or scripting environment

Change Management

Web Service

Person inside app

-Impact analysis - Topology Visualization of a service or application

-Model Launch-in-Context

-not as rich in functionality as java API -slower than java API +works over http(s) +can be used from web browser (human-consumable) +clients can be written in any language or scripting environment

Problem Management

9

Regulation

Conduits are commonly shaped by legal and regulatory boundaries. For example, air-gap (physically isolated) data centers, Sarbanes-Oxley (SOX) compliance, and the Payment Card Industry Data Security Standard (PCI-DSS). Regulation overrides any best practice, such as entering in data manually in an air-gap data center, if no other means are possible or allowed.

In no way should any recommendations or practices herein be construed or used as an attempt or opportunity to circumvent any law. Fortunately, many regulations contain language to allow risk mitigations, such as compensating controls, or are sufficiently general as to allow for many implementations or interpretations. For example, if a regulatory element forbids a single point of failure for a critical system, this leaves much room for interpretation, which can be problematic without further precedent and/or clarification. What is “critical” (this language must be accurately defined)? Would simply duplicating a system containing a single point of failure into a DR facility comply (what are the service levels agreements in place)? Two organizations could implement compliance in very different ways, yet successfully pass an audit of this compliance.

Consumer Onboarding Process

This section describes how to provide the CMS service to a consumer. This is a minimal process, and will probably need to be tailored to the specific needs of your environment and use cases.

Sample Consumer Onboarding Process.

Each of the decision points along the rationalization and onboarding process generates workstreams to validate and deploy the use case. When the use case is fully tested and compliant, the consumption is staged to production using existing processes.

New Consumers

The following is an example process for onboarding a new consumer. This process should be refined to meet the needs of specific implementations and organizations. However, nothing should be omitted: each step in the process should be accounted for in the final version.

1. Qualify the consumer as described in Chapter 2.

2. Once the data requirements are understood assess the current capabilities of the CMS in terms of what can be provided. If the consumer data requirements call for data which is not already present in the CMS, the process should generate a new process for provider onboarding. This process is described in the Provider Onboarding document in the CMS library.

3. Determine which conduit (method of consumption) will be used, as described in Chapter 2.

11

4. Document where the responsibility lies within the documented flow of data. For example, if developing an API client for a Tivoli application and the code resides on the Tivoli application server, it must be decided beforehand who is responsible for maintaining the code, such as the configuration manager or the application owner.

5. Initiate the process to implement the conduit. Each type of conduit should have a process created for implementation and deployment. Here are examples for each example listed above. In practice, there may be multiple conduits, and advanced requirements may necessitate additional steps for configuration or setup. For each example conduit, the following steps should be accounted for:

Conduit Implementation Checklist

UI 1. Identify which security group (role) the user will be part of

2. Create the User ID (internally, or via LDAP)

3. Add the user to the appropriate security group

4. If necessary, create any folders required to hold the consumed TQLs, views, etc.

5. If necessary, create the TQLs, views, etc. which represent the consumed data. Do this only if the user is not going to create these. If these already exist, skip this step

6. If the user is going to create the TQLs and views themselves, ensure all data that can possibly be consumed is documented the same as being specifically required. Meaning, if the consumer wants general access, but cannot justify why a particular attribute or CI type should be allowed access, this should not be allowed.

7. As appropriate, authorize the user to the views, TQLs, reports, etc, which will represent the consumed data

8. Test as required

9. Provide the link to the server, userid/password, etc. to the user, securely, so they can begin using the UI

10. Ensure the user has training to properly consume the data

Caution: do not use the UI for general-purpose consumption! Use a web service browser or other low-overhead conduit for most users. Generally, only the configuration management roles should be directly exposed to the UCMDB UI.

Report 1. Identify the report requirements for content and structure.

2. Determine if a system report should be developed, or if an existing report is already available.

3. If necessary, Develop the report TQL, node layout, sorting options, included attributes, etc.

4. Generate the URL to be given to the consumer (UCMDB does this for you after the report is generated).

5. If necessary, follow the steps in the UI section for creating a user id and password for the consumer, if they will generate the report themselves or be within the UI

6. Test the link or report for accuracy and function.

7. Give the link to the consumer.

Example

An example using the wget method of report “pulling” is shown here. The user-supplied parameters are the output file, the UCMDB server name and port, the name of the report, and credentials to log in to the UCMDB server. Note that as is always the case in UCMDB, the customerID is always “1” and is not an alterable parameter.

12

wget technique D:\>wget -O wget_output.txt

"https://ucmdbservername:8443/ucmdb/rfw/newReportFromURL.do?cmd=ShowTopologyRepor

t&filter.reportName=rpt.PG.all_hosts&navigation=false&interfaceVersion=8.0.0&cust

omerID=1&reportID=systemreport&autoGenerate=true&populateAnyway=true&displayMode=

csv&userName=topology_reports&userPassword=$UCMDBReports$"

--18:54:21—

=> `wget_output.txt'

Resolving ucmdbservername... done.

Connecting to ucmdbservername[1.2.3.4]:8443... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/csv]

[ <=> ] 3,472,593 464.74K/s

18:54:57 (464.74 KB/s) - `wget_output.txt' saved [3472593]

XML File Extract

1. If the XML will be report-generated, follow the steps in the Report section above.

2. If the XML will be TQL-generated:

a. Set up the TQL to produce the data. Ensure only the required nodes and relationships are included. Test the results at the CI level first using the calculator icon in the UI.

b. Configure the TQL attributes using the Advanced Layout for each node. Ensure only the required attributes are selected. Use one of the methods below to generate and extract the data.

c. Wrapper.jar technique: Ensure one of the integration packages for DDM is installed. This means, one of the packages which contains the “wrapper.jar” capability for DDM to execute a TQL and export the results in XML. If the XML is required to be formatted with specific names or structure, the Atrium-Remedy Integration Adapter package should be used, so the mapping layer may be applied to change the XML as required. The documentation for using wrapper.jar technique is contained in each integration. These integration packages can be obtained from your local HP person, or by joining the UCMDB/DDM/CMS Practitioner’s forum (again contact your local HP person to initiate this process).

d. wget Report Generator technique: follow the same process as the “Report” process above, except change the displaymode parameter from “csv” to “xml”, e.g.:

Before:

…Anyway=true&displayMode=csv&userName=…

After:

…Anyway=true&displayMode=xml&userName=…

DDM Push Prerequisites

a) DDM subject matter expert must be available who is capable of writing a DDM pattern.

b) The consumer’s target must be understood in technical detail. For example, if DDM will push to a consumer database, the database schema must be understood. If DDM will push to a consumer via the consumer application API, documentation must be available so the DDM pattern can be properly created.

Onboarding Process

1. Follow the DDM Content Development process, documented in the UCMDB product

13

documentation, to create, test, and package the DDM pattern. DDM 8.0 and later versions contain template DDM patterns which can be used to accelerate the development process.

2. The pattern should be scheduled to run only as frequently as required by the consuming process. Near-real-time data, especially for large amounts of data, can consume significant resources and could impact performance of other critical tasks, so this must be carefully and objectively evaluated.

3. The consumer must verify the correct data is being pushed in the correct way.

Java API and SDK

Prerequisites:

a) Java version 1.6.0.x

b) Client must be able to communicate with server on specific port. By default the UCMDB RMI port is 4009

c) The client requires an API Jar library “ucmdb-api.jar”. This file can be obtained from the UCMDB server itself by extraction from: Error! Hyperlink reference not valid.

d) Use credentials of a DDM user who has been granted permissions to execute TQL based queries. (User would have rights to execute all TQL queries or specific ones)

Onboarding Process This is very similar to the DDM Push process above, except for the following:

1. The subject matter expert should have experience in Java as well as the UCMDB API.

2. The client must handle scheduling or wake up on its own, UCMDB does not schedule these outside of DDM.

3. Proper security access must be granted, similar to the UI consumer onboarding above. The userid to be used by the java API should not be used by an actual user. It may be acceptable to allow multiple API clients to share the same userid.

4. To expedite the development process, and for simplicity and clarity, the parts of the java client which access the CMS should be tested as much as possible independently of the logic that gives the CMS data to the consuming application.

Web Service, including Browser or Application-based cross-launch (launch-in-context)

Prerequisites:

a) Java version 1.5.x or higher

b) Pre-configured TQL query in the UCMDB server (based on what you are interested in exporting, e.g. SAP topology)

c) A list of client side Jars are required which can be extracted from a specific location, for example: Error! Hyperlink reference not valid.. Instructions on how to deploy any client-side files should be documented and included in the onboarding instructions.

d) Use credentials of a DDM user who has been granted permissions to run discovery. (User would have rights such as CMDB Admin – Discovery – ‘Execute’ which allows Activate Discovery jobs, run the Discovery wizards, define a schedule for a Discovery job, override Discovery pattern behaviour, and edit Discovery TQLs.

Onboarding Process

1. Process for authorizing the consumer should follow the same steps as for the UI access above. The web service may share the same access as other consumers, as long as that userid is not used by humans, and the access requirements are the same data. Otherwise, separate accounts should be

14

created.

2. Develop and test the TQLs and associated analytics (View, Impact Analysis, Report, etc.)

3. To expedite the development process, and for simplicity and clarity, the web service should be tested as much as possible outside the application, for example, in a web browser, before embedding into a consuming application.

Example onboarding steps depending on the method of consumption

Adding Scope to existing Consumers

Here is an example of a “fast track” process to add scope of CMS data to an existing consumer. Most of the identity and basic documentation will already exist. Only the use cases and rationalization for the new data must be accounted for.

1. Determine what new data is required

2. Assess how the new data will be used, and if the existing conduit works for the new scope of data. Each conduit will have a different way of implementing the new consumership. For example, TQL-based consumption would involve adding nodes, relationships, and attributes to an existing TQL. Possibly, additional TQLs and views may need to be created. This is different from; for example, a java API client, whose internal logic would be modified to include the additional data according to how the client is organized (could involve modifying code, or simply adding lines to an XML file or a data table, etc.)

3. Test and validate the extensions as above.

4. Document and turn over the additional capabilities to the consumer.

15

Consumer Decommissioning

Consumer decommissioning is easy to overlook in favor of effort required for new or current projects. However, consumers who are no longer consuming present security risks, waste resources, and complicate maintenance. All that is really needed is an efficient process for decommissioning.

Triggers for Decommissioning Evaluation

The process should be triggered by any event which affects ongoing consumership, including:

Human Consumers

Leave the company

Change roles

Expand or Shrink scope or responsibility in same role

New projects

Automation (human consumership replaced by app)

New Middleware (human still end consumer but middleware consumes from CMS and consumer consumes from the middleware)

Application / Non-Human Consumers

Replaced by new application

Version upgrade changes need for consumership

Expand or Shrink scope or responsibility for same app (logical change)

Transformation changes location (physical change)

App is deprecated and not needed (function consolidated to other app)

Reference Process

The following steps serve as a best practice as a basis for creating an actual practice that meets the needs of individual organizations. Once the decommissioning trigger even has been rationalized (verified that a consumer in fact should be decommissioned):

1. Security: Consumer’s access to CMS data should be revoked. If the consumer shares a common userid with other consumers (such as “the” id used for applications to consume from CMS), then the password should be changed for all consumers using that userid, even if the consumers are non-human. This protects the CMS from any interference from humans who may try to take advantage of the decommissioned consumer’s access to CMS.

2. Sole Provider: If a consumer is decommissioned who is the only consumer of an attribute or CI type, then that provider should be decommissioned as well. That is, the provider itself may not need to be decommissioned; rather the provider conduit should be decommissioned.

3. Conduit Deactivation: The consumer conduit should be removed. This may include:

a. Removing the DDM schedule for a DDM-push pattern

b. Removing wrapper.jar from the DDM probe’s CLASSPATH

c. Removing a java client .jar

16

d. Cleanup of folders created to hold extract files

e. Removing any ETL or other intermediary constructs, such as Connect-It scenarios and schedules

f. Removing a consumer’s UID from UCMDB

g. Removal and archiving any TQLs, views, enrichments, impact analysis, reports, enumerations, classes, or links from UCMDB and DDM, which are used only by that consumer

h. Removal and archiving any DDM patterns used only by that consumer

4. Proper Archival:

UCMDB/DDM Package Archival: Any DDM or UCMDB constructs removed (such as, items 3g or 3h above) should be exported to a package for ease of archival. The packages should be removed (if present) from the UCMDB customer_packages folder in the UCMDB server.

Properly archive: The decommissioning event should be documented in whatever appropriate journaling or archiving facility is appropriate for that organization. At least a “paper trail” should be maintained and filed for future reference. Decommissioning should be considered a memorialized event and treated as part of the company history.

5. Continual Service Improvement: Any valuable experience, lessons learned, or how-to knowledge created for or by the consumer, in terms of CMS, should be extracted and preserved by the Configuration Management group, for Continual Service Improvement purposes.

17

Index

Attribute, 7

Conduit, 8, 9, 11, 15

Configuration Item, 7, 11, 12, 15

Configuration Management, 1, 4, 8, 16

Configuration Management Database, 4, 5, 14

Configuration Management System, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 16

configuration manager, 6, 7, 11

Consumer, 1, 4, 5, 6, 8, 10, 14, 15

Data Model, 4, 5, 8

HP Discovery and Dependency Mapping, 5, 8, 12, 13, 14, 15, 16

HP Universal CMDB, 8, 11, 12, 13, 14, 16

Implementation, 11

Integration, 12

IT Information Library, 4, 7

IT Service Management, 6, 7

Onboarding, 1, 4, 5, 10, 11, 13, 14

owner, 7, 11

Process, 7, 8, 10, 13, 14, 15

provider, 7, 11, 15

Rationalization, 6

Security, 6, 9, 15

service, 4, 8, 9, 10, 11, 14

Service Asset and Configuration Management, 7, 8, 14, 16

Use Case, 7