IMHO, each Master Data artifact (incl. its dependencies and attributes) needs to have one owner, one source of truth (aka System of Record), and one solution in which it is maintained (aka System of Engagement). As a guiding principle, a master data artifact can best be kept in the solution that is the dominant consumer of that Master Data.
One could choose Apptio to hold the TBM master data (and use the egress connector of Apptio to make that data available to other solutions). However, one could also rightfully consider Salesforce, SAP, Oracle, or ServiceNow as a data source for (a portion of) the TBM data.
The objects (incl. its contents) that TBM defines, IMHO, are common Master Data Artifacts that are (to be) used throughout the Enterprise., e.g., for managing Plan, Code, Build, Test, Release, Deploy, Operate, Service, and Monitor (or Plan, Build, Deliver, Run and Support, if your Enterprise embraced IT4IT).
Hardly any large enterprise customer uses only one solution to manage all, no solution has 100% market share, and no solution perfectly covers all domains within an enterprise. Ideally, each enterprise solution would (optionally) cater to compliance with TBM and then (optionally) deliver the solution with relevant content of TBM. After that, the vendors could provide their customers with content packs with relevant updates of the TBM content. The vendors could apply the same conceptual approach for artifacts as defined in/by other frameworks such as SAFe, SIAM, or IT4IT.
Large Enterprises may prefer to use a separate Master Data Management (MDM aka xDM) Platform instead, which holds all common master data that is to be consistently used within and throughout the Enterprise. In this case, TBM content (incl. its custom enterprise-wide add-ons) should also be in that MDM platform. Then the MDM becomes the single truth source for all Shared Master Data. In this scenario, one could still make Apptio the system of engagement for some of the TBM data. Alternatively (or additionally), some of the TBM master data can also be maintained in ServiceNow, Oracle ERP, etc., or -maybe even better- directly in the MDM platform.
------------------------------
Jeroen van Craaikamp
Interim Manager
JAVC Management & Consultancy
+31-643583097
------------------------------
Original Message:
Sent: 12-22-2022 14:11
From: Michael Enslein
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
@Matt Temple @Jeroen van Craaikamp Do you think this is a good use case for using the egress connector from Apptio to ServiceNow?
------------------------------
Michael Enslein
System Admin
Tenet Healthcare Corporation
Dallas TX
+1.469.893.2200
Original Message:
Sent: 12-21-2022 19:51
From: Matt Temple
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
@Ed Hayman can you help ensure continued attention on this topic from the Standards Committee?
I am happy to continue in my role on this topic.
Some elements Jeroen mentions may be better suited for Apptio, ServiceNow, and others.
@Jeroen van Craaikamp...something to keep in mind...ServiceNow is expected to publish significant changes to its next generation of CSDM. The results of which will have equally significant change to any guidance to map a ServiceNow CMDB (reflecting CSDM 5) with TBM.
------------------------------
Matt Temple
Transformation Excellence Manager
Accenture US - Partner
Long Beach CA
(714) 349-6102
Original Message:
Sent: 12-21-2022 19:31
From: Jeroen van Craaikamp
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
I have read the presentation, and the excellent news is that parties appear aligned in the general direction.
If this is not done already, it needs to be decided if TBM Council wants to take formal ownership of a mapping of TBM content into ServiceNow CSDM. Also, it needs to be established if/how ServiceNow intends to contribute to this initiative. E.g., if ServiceNow wishes to use TBM content in its OOTB deployments, ServiceNow could also maintain the mapping and ServiceNow data sets.
After that is made clear, the logical next steps could be:
- Assign a workgroup that will create tangible TBM-CSDM mapping deliverables.
- Consensus on which ServiceNow plugins should be activated as a prerequisite to load TBM content
(e.g., Digital Portfolio Mngt, Service Builder, Service Owner Workspace, etc.) - Consensus on which ServiceNow tables/attributes/relations can/shall be populated with TBM content
- A demo video of how TBM content is populated in an OOTB ServiceNow (Tokyo?) Instance
- A demo video on how to "build a service" in ServiceNow, incl. its links to the TBM Taxonomy
- A set of XML files (exports) with TBM content that can be uploaded into any ServiceNow instance (e.g., for POCs)
- A mapping document that describes in detail what in TBM should go where in ServiceNow
- Get sign-off on the above from relevant stakeholders and manage the deliverables of the TBM-CSDM workgroup in the future...
The approach above assumes the CSDM tables, ITSM processes, and user roles are deployed as recommended in the ServiceNow Best practices so that the way of working in ServiceNow does not need to be defined/amended to use TBM content.
I would appreciate better examples and guiding principles on populating and naming other service artifacts in CSDM, but I would not expect this from the TBM council.
I'm new here. Would the above align with how TBM Council wants to govern these things? Or is there a process that we should follow?
------------------------------
Jeroen van Craaikamp
Interim Manager
JAVC Management & Consultancy
+31-643583097
Original Message:
Sent: 12-19-2022 13:15
From: Matt Temple
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
Hi @Jeroen van Craaikamp, please take a look at the presentation given at TBM Conference on behalf of the TBM Council's Standards Committee.
I'm happy to discuss further via a Teams/Zoom meeting. If interested, let me know via direct message.
------------------------------
Matt Temple
Transformation Excellence Manager
Accenture US - Partner
Long Beach CA
(714) 349-6102
Original Message:
Sent: 12-18-2022 13:33
From: Jeroen van Craaikamp
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
------------------------------
Jeroen van Craaikamp
Interim Manager
JAVC Management en Consultancy
Amstelveen
+31643583097
Original Message:
Sent: 12-17-2022 13:24
From: Jeroen van Craaikamp
Subject: Mapping of (some of) TBM 4.0 on ServiceNow CSDM 4.0.
Hi,
I have been working with the ServiceNow Platform for a long time and recently also became a member of this TBM community. As many of you, I have used TBM artifacts/definitions in the ServiceNow CSDM concept.
I've enclosed my thoughts on mapping (some of) TBM 4.0 on ServiceNow CSDM 4.0. I appreciate any comments/feedback you may have.==//==
INTRODUCTION
ServiceNow is a cloud-based service management platform that enables enterprise organizations to improve operational efficiencies by streamlining and automating routine work tasks. With roots in IT Service Management, ServiceNow has become the enterprise service management platform for organizations, uniting all business functions from customer service to HR to security. In 2018, ServiceNow published its first Common Service Data Model (CSDM), a customizable Service metadata model that may be used to deploy ServiceNow. Since then, the CSDM has evolved into CSDM version 4.0, CSDM 3.0 (September 2020), and CSDM 4.0 (January 2022) are very similar. Service Taxonomy. ServiceNow and its implementation partners provide enterprises consultancy on how the CSDM may be best populated for specific ServiceNow Implementations. Since ServiceNow may be used for multiple purposes by companies of different sizes having different preferences, implemented by other partners, a standard 1-size-fits-all implementation of the CSDM does not (yet) exist.
Since 2012, Apptio has defined and maintained a Technology Business Management (TBM) taxonomy to be used in/for Apptio's products. In 2016, information experts drafted an open standard document that the TBM Council maintains with the support of an active TBM community. The TBM Taxonomy paper describes a metadata model for businesses and provides standardized definitions of the hundreds of artifacts used in that model. The fourth version of the TBM Taxonomy standard was published in December 2020.
The TBM 4.0 Taxonomy document was produced with the support of Apptio in the same period as when CSDM 3.0 was made with the help of ServiceNow. In the TBM documents, different terms are used than in CSDM documents and v.v. The TBM and CSDM models overlap and have quite a few conceptual similarities. However, they also have some differences and areas that cannot be mapped. Even though most enterprises nowadays want to deploy ServiceNow Out of the Box. Almost every ServiceNow platform instance is still unique by nature. Having said this, many enterprises have already started to use (a subset of) the artifact names/definitions of TBM Taxonomy 4.0 when populating their CSDM master data tables in ServiceNow. As with most master data, keeping it accurate, consistent and fit-for-purpose is quite challenging for organizations, independent of the platform(s) used.
Since Apptio and ServiceNow each offer different/overlapping solutions for Enterprise Architecture, Cloud, Finance, and Portfolio Management Communities, it is unlikely that CSDM and TBM will merge. Some customers will use Apptio, some will use ServiceNow, and some will use both (or something else). Enterprises, especially those that use both the Apptio platform and the ServiceNow platform, need to reconcile the differences and map content between TBM and CSDM to manage all stages of the Enterprise IT lifecycle consistently.
SO, HOW TO MAP TBM 4.0 CONTENT TO CSDM 3.0/4.0 CONCEPT?
TBM defines foundational data objects: Business Units, Business Architecture (Business Processes and Business Capabilities), and Customers & Partners (Product Lines and Digital Platforms).
- As defined in TBM, the Business Units are modeled in ServiceNow as Business Units. Larger Enterprises may consist of multiple companies, each also being (part of a) business unit.
- Business Processes in ServiceNow can be populated but are not used in ServiceNow except in the Strategic Portfolio Management (SPM) Application of ServiceNow, which may be used to manage the Enterprise Business Architecture.
- Customers and Partners are (contacts, departments, or groups of) Companies in ServiceNow. As a parent object for Product Lines and Digital Platforms, they do not exist in ServiceNow.
- Product Lines and Digital Platforms are typically company-specific, and the artifacts are not named/defined in TBM. In ServiceNow, Product Lines and Digital Platforms are not seen as specific CSDM classes.
TBM defines Solutions (applications, products, or services) as what IT delivers to end consumers: business leaders, end users, and often external parties such as customers and partners. The TBM Solutions are broken into six so-called solution types: 3 are customer-facing, and 3 are internally facing. The 6 solution types are broken down into a total of 26 Categories. The Categories are broken down into 121 well-defined Names. The (service) Names may be broken down into specific (service) Offerings, albeit the Offerings are not defined/named in the TBM. ServiceNow CSDM fundamentally differentiates between customer-facing artifacts and internally-facing artifacts. When mapping TBM artifacts to CSDM artifacts, this needs to be considered.
Depending on governance and ownership, I believe three approaches may be justified on how to register TBM solution artifacts in ServiceNow:
- One TBM Portfolio for the whole enterprise
- 6 (Level 1) Taxonomy nodes in ServiceNow; one CSDM Taxonomy node for each of the 6 TBM Solution types.
- 26 (Level 2) Taxonomy nodes in ServiceNow; one CSDM Taxonomy node for each of the 26 TBM Solution Categories.
- 1 Business Service for each of the 66 Defined TBM Solution Names that are customer-facing, each Service has at least one Business service offering
- 1 Technical Service for each of the 55 Defined TBM Solution Names that are internally facing, each Service has at least one Technical service offering
- Two TBM Portfolios, one for the customer-facing Business Portfolio and one for the internally-facing Technical Portfolio,
- 6 (Level 1) Taxonomy nodes in ServiceNow; one CSDM Taxonomy node for each of the 6 TBM Solution types.
- 26 (Level 2) Taxonomy nodes in ServiceNow; one CSDM Taxonomy node for each of the 26 TBM Solution Categories.
- 1 Business Service for each of the 66 Defined TBM Solution Names that are customer-facing, each Service has at least one Business service offering
- 1 Technical Service for each of the 55 Defined TBM Solution Names that are internally facing, each Service has at least one Technical service offering
- Six TBM Solution Portfolios, one for each of the 6 TBM Solution Categories, with
- 26 (Level 1) Taxonomy nodes, one CSDM Taxonomy node for each of the 26 TBM Solution Categories, each node linked to its relevant portfolio.
- 1 Business Service for each of the 66 Defined TBM Solution Names that are customer-facing, each Service has at least one Business service offering
- 1 Technical Service for each of the 55 Defined TBM Solution Names that are internally facing, each Service has at least one Technical service offering
In TBM 4.0, Towers and sub-towers are the basic building blocks of solutions. Examples include compute (e.g., servers, Unix, mainframe), network, application (e.g., application development, application support, and operations), and IT management. TBM defined 11 Towers and 55 Sub-towers. A TBM (sub)tower is a logical group of similar CMDB Configuration items (CIs). In ServiceNow. For each (sub)tower, I define a CI Group in ServiceNow and have it automatically linked to relevant CIs in relevant CI classes (using queries). To be able to differentiate TBM (sub)Towers from other CI Groups in ServiceNow, I associate the 11 + 55 Standard TBM groups with custom CI Group types "TBM Tower" and "TBM Subtower." Since the Dynamic CI Group is also a CI in ServiceNow CMDB, the (sub)towers can be used by those practices in ServiceNow that refer to or use CMDB CI's (e.g., Incident Mngt, Asset Mngt, reporting, etc.).
Cost pools are low-level categories often aligned easily to general ledger accounts. Not only do cost pools make cost allocations easier, but they also enhance reporting because they can be traced through the model to reveal the composition of costs. For example, application total cost of ownership (TCO) can be broken down into hardware, software, internal and external labor, outside services, facilities, and telecom costs. In TBM 4.0, 9 Cost Pools and 30 Sub-Cost Pools are defined. I use the names/definitions of the TBM 4.0 (sub) Cost Pools, but I have not yet loaded/added them as artifacts in ServiceNow tables.
By mapping TBM solutions/towers this way, ServiceNow's Out of the Box CSDM concept remains 100% intact. Standardized artifact names/definitions can be used in ServiceNow, e.g., in Digital Portfolio Management, Service Portfolio Management, and Service Builder. ServiceNow functionality (metadata configuration) is increasingly deployed out of the box, after which the master/portfolio data is populated/loaded, and CMDB content is automatically discovered/federated. By settling CSDM content with the artifacts that TBM defines, enterprises can save months lead time from deploying an OOTB market standard. Enterprises that manage, Plan, Build, Deploy and Operate, incl. its Support using multiple platforms/frameworks, will appreciate a (more) common vocabulary with well-defined and well-named artifacts. Those who have integrated Apptio with ServiceNow will benefit most from a common.
==//==
I look forward to hearing from you.
The mapping of (registration/management of) Applications, Application Components, API's/Microservices, Information Objects, Infra Containers, etc., including their interdependencies, is not covered herein, but of course, is an exciting topic (on its own) as well, especially when considering the exchange/collaboration between the IT4IT Plan, Build, Deploy and Operate Value Chains.
Best regards,
Jeroen A. van Craaikamp
The Netherlands