当記事はServiceNowのCMDBならびにCSDMについて、筆者が日本向けにわかりやすく説明するため、解釈を加え言語化し整理したものです。ServiceNowのOOTBの説明文の和訳とは異なる場合が存在します。予めご了承ください。
はじめに
こんにちは。トドです。このQiitaを開いたあなたは、CMDB:構成管理データベースというキーワードに何かしらの関心があり、または苦戦されている、そもそも何もわからない、そんなあなたな気がします。ServiceNowのプロジェクトで1.5年ほどCMDBかっならびにCommon Service Data Modelに取り組んで参りました。今回は共通データモデルであるCSDMを中心に記事を書いてみようと思います。
・ServiceNowのCMDBの全体像が分からない
・CSDMの各用語がわかりづらくどのテーブルを何に使えば良いか分からない
・どんな順番で始めれば良いか、何を気を付けるべきか分からない
・結果的にデータモデリングに手がつかない
こんなお悩みをよく聞きます。お悩みの最初の一歩を突破する様な、そんなQiitaになれば幸いです。
CSDMとは?①なぜデータモデルが必要なのか?
CSDM(Common Service Data Model)はご存じの方はいらっしゃるかもしれませんが、ServiceNowのマスターデータのデータモデルです。まずServiceNowにデータモデルがなぜ必要なのか?少し前置きを置かせてください。
ビジネス観点:デジタルに関連するデータへのニーズが多様化している
昨今、DXというキーワードが流行った様に、デジタルはIT部門の為だけのものではなく
様々な業務ユーザーにとって活用ニーズが高いものと言えます。
活用ニーズが高まることによってIT、デジタルの情報はインフラだけでなく、ビジネス視点での管理や、リスクセキュリティの担保やサービスレベルの品質向上と言った多様な観点での管理、維持が必要になっています。
ServiceNowはCSDMを時代のニーズに合わせてアップデートし続けています。様々なステークホルダーにとって業務に必要な情報を届けるためにデータモデルを進化させてきました。ステークホルダーによってニーズは異なるため、ニーズに適したデータモデルが必要になるのです。
製品観点:ITSMやITOMなどのソリューションのマスターデータの必要性
OOTBの重要性は某方の記事の通りですが、特にITSMやITOM、SPMとITのライフサイクル全体を管理したい企業ユーザーに置かれましては、Common Service Data Modelの理解は必須と言ってもいいです。
それぞれのServiceNowソリューションが連携し本来の価値を発揮するためには、ServiceNowが提供する共通データモデルに則ってITSM、ITOM、SPMといった製品を運用していく必要があるからです。
CSDMとは?②ServiceNowのCMDBは構成情報だけを指しているのではない。
さて本題です。
Common Service Data Modelとは、ServiceNowのマスターデータの共通データモデルであり、広義のCMDBのデータモデルと言えます。
広義のCMDBとは、企業のサービスやアプリケーション、最新ではもっと広義にデジタルの生産物=デジタルプロダクツ(Digital Products)を表現するためのデータのことです。
…いきなり何のこっちゃい?と思いましたか?デジタルプロダクツはやや先進的な概念であり、現在の日本ではCSDMは企業のITにおけるライフサイクルでのユースケースが多いため一旦は、
企業が持つサービスやアプリを定義し、ユーザーの立場や目的に適した情報を提供するためのデータモデル
と定義させて下さい。
ServiceNowはITやデジタルの管理ニーズに基づき、CMDBがサーバーやインフラストラクチャの情報だけでなくCMDBをより拡張してService Graphという上位概念を定義しています。Service Graphにはインフラ情報だけでなく企業のアプリやサービスをビジネスの視点やライフサイクルを考慮した基礎データが含まれています。
たとえば、
・企業として提供されるサービス
・アプリケーションの中でもビジネスとして必要な情報(コストや保守期限など)
・構成情報のまとまりである環境≒インスタンス
などが含まれます。つまりServiceNowのCMDBは構成情報=たとえばサーバーやルータなどの機器情報だけを指しているわけではありません。(広義のCMDB)
・一般的なCMDB
サービスを構成する構成情報のデータベースのこと
・ServiceNowにおけるCMDB
厳密にはService Graphであり、構成情報だけではなく企業が提供するデジタルの生産物を構成するためのデータベース
と考えてください。お願い、まだここで心折れないで。
このQiitaでは出来るだけ全容をとらえやすい様に細かい話に入らず大枠をわかりやすく日本語に解釈して言語化します。どうかお付き合いください。
CSDMとは③Common Service Data Modelの概要
5つのドメイン
CSDMはまず、ドメイン=目的別のデータモデルの領域があります。
ドメインは5つに分かれます。ドメインと簡単な説明を以下に記載します。
それぞれがITのどのライフサイクルをターゲットとするか少しイメージを持ってもらえればと思います。
・Foundation‐会社の組織や場所、といった基礎情報を持つ
・Design‐ITの計画、コスト、デザインに関わるクラスが配置されている
・Build‐DevOpsや開発で使用するクラスが配置されている
・Manage‐運用関連の情報、インスタンスや環境を表現するクラスが配置されている
・Consume‐ユーザー向けのサービス、SLAを持つものを表現するクラスが配置されている
の5つです。次項から、このドメインの具体例を示しながら解説します。
よく利用されるDesign、Manage、Consumeを中心に説明します。
Design‐ITの計画、コスト、デザインに関わるドメイン
Designはビジネス情報、IT企画系のユーザーやエンタープライズアーキテクトが使用するクラスです。代表的なクラスのBusiness Applicationには、アプリを製造した製造元や現在の購入ベンダー、提供形態(SaaSかオンプレか?)や利用者数などの情報が含まれます。
IT企画部門がアプリの開発や置き換え、廃止の計画をする際に利用する情報と理解して貰えれば良いと思います。
ビジネスアプリケーションの可視化‐アプリケーションの棚卸
ビジネスアプリケーションを可視化すると少しイメージが湧くのですが、例えばServiceNow Enteprise Architecture(旧称APM)のEA Workspaceでは以下の様なイメージでITの企画部門がアプリの棚卸や分析に役立てることができます。
・全アプリのうち、SaaSで提供されているアプリの数とオンプレの数は?
・アプリはどのPlatformで動いているのか?
・利用者数の多い/少ないアプリは?その内訳は?
など、様々な切り口でビジネス判断に使うクラスと言えます。そして、Business Applicationの情報はIT運用の情報としては使いません。ITSMでは利用しないこともポイントです。
Manage‐運用関連の情報、インスタンスや環境を表現するドメイン
Manageは環境情報、アプリケーションを運用の視点で見ていくドメインです。
Application Service(アプリケーションサービス)を中心に解説します。
つまり、Application Service(アプリケーションサービス)は構成情報をまとめ、一つのインスタンス≒環境を表現します。なので私は『環境情報』や『インスタンス』と表現することが多いです。ITにおける開発環境や本番環境をイメージすると分かりやすいです。Designで先ほど説明したBusiness Application(ビジネスアプリケーション)と対の関係になります。ビジネスと運用の情報が紐づくわけですね。
CMDBといえばDiscoveryで自動収集だという話題になり実際効果もありますが、収集したConfiguration Item(構成情報)はApplication Service(環境情報)と紐づけることでどのアプリの配下にある構成情報なのか、依存関係を作ることが出来ます。またService Mappingを使うことでよりMappingを強化しApplication Serviceを自動作成出来たり…と言う話はまたいつかとしておきつつ、この運用関連のManageの説明を終わります。
依存関係マップのイメージ(いつものやつ)
Consume ユーザー向けのサービスやSLAを表現するドメイン
さてConsumeです。代表的なクラスはBusiness Service(ビジネスサービス)と言いますが
あれ、これのクラス馴染みがありませんか?そうです。日本のユーザーがServiceNowでITSMで触れることになる(とよく聞く)クラスです。まさしくインシデント、変更などのキーに使用します。
サービスとサービスオファリングの関係は何となくわかっていただけたかと思うのですが、
そもそも日本はITの仕組みのことを何と言いますか?「システム」と言いませんか?
アプリとサービス
欧米ではアプリとサービスを分けて考えるので、まず、日本流でシステムの一覧をどの様に分解してアプリとサービスそれぞれをServiceNowに投入して管理していくことに苦労すると思われます。
サービスは本来ユーザー向けのサービスそのものではありますが、ITにフォーカスして考える際はインシデントや変更のSLAを管理するデータクラスと割り切って考えることも有効です。ユーザーによっては社内向けのサービス名をBusiness Serviceで管理、インフラ情報はApplication Serviceで管理、製品名はBusiness Applicationで管理と考えている方もいました。これは次項の具体例を見ていただくと少しイメージが湧くと思います。
理解しやすくするためTechnical Service Offeringをこの項で解説していますが、本来Technical Service OffferingはManageに配置されています。Technical Service Offfering(テクニカル関連のサービス)の役割は、Application Serviceを通してBusiness Service Offering(ビジネス向けのサービス)を支援することです。この関係性の理解を並行でしていくとやや混乱しやすいため、ここでは割愛します。
CSDMの具体例とエクササイズ
ここまでCSDMを解説してきたので、具体例を持って説明します。
CSDMの具体例
お題は「財務会計システムは決算処理と経費精算にサービスが分かれ、SAP S/4 HANAとConcurを利用しており本番環境、開発環境の二つを持つ。S/4HANA部分は本番はオンプレ、開発環境はIaaSとそれぞれ構築しており、ConcurはSaaSとして運用している」です。
こんな状況、日本でも当たり前にありますよね?
・IT企画ユーザーはビジネス機能とビジネスアプリケーションを分析し、
・運用担当者はインスタンスとインフラを保守する
・サービスマネージャーはサービスの品質を管理する。
これらの多様化するニーズをカバーするため、CSDMはそれぞれのユーザー向けのデータモデルを用意し、かつ関連性を持っています。
企業が持つサービスやアプリを定義し、ユーザーの立場や目的に適した情報を提供するためのデータモデルという点を少し掴んでいただけたら嬉しいです。(前項と行ったり来たりして見ていただけると嬉しいです。)
Configuration Item(構成情報)とAsset(資産情報)は違う
Applicaton Serviceの配下にあるConfiguration Itemで起こりがちな誤解は
CI(構成情報)とAsset(資産情報)は違うということです。ServiceNowではCIとAssetを双方管理することが出来ます。
アプリケーションと資産情報の連携
資産情報は当たり前ですが会計やコストに関連する情報なのでここまでのクラスで行くとBusiness Applicationと関連が強いです。ServiceNow EA(旧称APM、また出てきた)を活用するとソフトウェア情報の保守期限や現行バージョンをアプリ情報と連携させ、アプリケーションのライフサイクル(取り換え時期)を把握することに役立てることが出来ます。
ソフトウェア資産管理(SAM)
Assetのもう一つの具体例ですが、SoftwareのAsset情報はSAM(Software Asset Management)のソリューションのマスタとしての役割もあります。ソフトウェアのインストール情報と契約情報を紐づけると、この様にソフトウェアの棚卸やコンプライアンス対策に役立てることが出来ます。
まとめ:まとめきれない
ServiceNowのCMDBとCSDMについてまとめましたが、CMDBは目的が大事と言われる理由が分かったと思います。そもそも目的に応じてデータクラスが用意されているわけですから。
ServiceNowのベストプラクティスでも企業の組織、役割、ロールを理解して段階的に進めるべきとのガイダンスがあります。とある方は「CSDMは情シスの組織論」とおっしゃる方もいました。Business CapailityやBusiness Applicationの概念はEnteprise Architectureの理論でも出てくる概念であり、CSDMを突き詰めると企業全体のエンタープライズアーキテクチャを表現することとなります。要は道のりは長いのです。
今回は狭義の構成情報(Configuration Item)やBuildやFouncationの説明やITOMとの連携の説明には至りませんでしたが、ServiceNowの各ソリューション(ITSM、SPM、APM、SecOps、ITAM)とも密接に絡むため、正しく理解し運用し、目的に応じて価値を出していけるといいですね。…覚える製品とデータクラスの数が多いんですが、どうしたらよいですかねServiceNowさん。
以上、CMDBとCSDM、ServiceNowでのエンタープライズアーキテクチャを(何とか)わかりやすくでした。