In this article, I will explain what I have done to make CSDM 5 fit better for the purpose and make it fit for a broader audience, whilst leaving CSDM Out of the Box. The objective is to provide a well-structured visibility of what is (to be) authorized, what is (to be) deployed, what may be consumed, and how these things are related, so that consumers of the CSDM data can use that information in their work.

The founding principles are:

  • Data Stewards maintain shared data in the agreed-upon platforms using agreed-upon processes, from which platform the shared/foundational data shall be consumed.
  • Service Owners define the Services, including the variants thereof that may be offered, incl. their commitments and entitlements,
  • Architects define the (lifecycle of) Products that may be procured, built, integrated, and provided “as (part of) a Service”
  • DevOps engineers design, develop, test, maintain, and deploy the Components of the Approved Product.
  • IT Operations tools automatically detect/retrieve and register what is deployed for/by the company, including. Its tags and dependencies.
  • DevOps Engineers provide and maintain the Platform’s Configuration and Integrations, as agreed with the product/platform owner.
  • Process Owners define/govern the Process, including polcies and guidelines, and monitor Data Quality and Process Adherence.
  • Process Managers and Process Fulfillers fulfil their defined process roles.

The data that is made available may be consumed by

  • The ITSM community that raises incidents, problems, and changes on the deployed items
  • The ITAM community that tracks the status, whereabouts, and usage of the deployed assets
  • The Project teams that manage transitions, incl. all that is required to do so.
  • The DevOps team that develops, innovates, implements, integrates, maintains, and monitors what is deployed
  • The SecOps team that manages security issues/risks on what is deployed
  • The Architects who manage the lifecycle/roadmap of the Products in the Portfolio.
  • Agents and Large Language Models of Artificial Intelligence

To achieve this, support for the following Digital Portfolio Management Processes must be implemented.

  • Foundational Master Data Management
  • Product Portfolio Management
  • Service Portfolio Management
  • Service Instance Portfolio Management
  • Project Portfolio Management
  • IT Operations Management (CMDB Discovery, Federation, and Mapping)

Furthermore,

  • These processes (incl. their roles, governance, prerequisites, and KPI’s) must be defined, implemented, managed, and improved.
  • The platforms that enable these processes must be selected, procured (or developed), implemented, integrated, and tested.
  • The data models in the platforms that enable these processes need to be defined, configured, integrated, and populated.
  • The individuals assigned to specific roles in these processes require training tailored to their responsibilities.
  • The data needed for these processes must be gathered and (if required) cleansed.
  • Reporting re. Performance, quality, maturity of People, Process, Technology and Data must to be implemented.

Recommended CSDM 5+ mplementation Guidelines:

  • Populate the Foundation Tables, using data that is extracted from the authorized source, ideally via automated interfaces
    • Do not manually create additional records or change the source data. If necessary, the date should be cleansed in the source.
    • Do not load portfolio data until clean foundation data is loaded (do not let staff get used to polluted data)
  • Create one Service Portfolio for the Enterprise Services and their offerings
    • Register TBM 5.0 Solution Types and Solution Categories as L1 and L2 services in the Service Portfolio;
    • Leave their Taxonomy node empty, so that only the L3 Services have their Taxonomy Node and its parent filled in.
    • Register TBM 5.0 Solution Types and Solution Categories as Taxonomy Nodes in the Service Portfolio
    • Register a L3 Service per Product that is to be provided “as a Service” and relate it (many-to-many) to the L2 Services that make use of it.
      A product may be an Application, a group of Applications, a portion of an Application, or a technical product (e.g., “Windows Server” or “IOS Phone”);
  • Create one or more Application Portfolios (e.g., one portfolio per tribe, tribe lead being the owner of the portfolio)
    • Register TBM 5.0 Solution Types, Names, and Categories, as Business Capabilities in the Application Portfolio
    • For each Business Application, register one Application in the Application Portfolio.
    • Use the same application names/abbreviations as the vendor uses in their product brochures and/or website.
    • For each Set of components managed by a DevOps Team using a backlog, create an application in the Application Portfolio.
    • When a platform has more than eight teams working on it, consider splitting the platform up into smaller platforms.
    • Instead of using platform host and platform applications, model all applications as applications. Relate the apps with each other using “Contains” CI relations.
  • Create one or more Service Instance Portfolios, ideally using the same portfolio name as for applications.
    • For each deployed instance of the platform, create a Service Instance
  • Create Project Portfolios aligned with the tribe/squad structure of the company
    • Create demands, per application, bu or program.

What makes this implementation of CSDM 5+ special?

  • Services are connected many-to-many with each other, avoiding the creation of separate services per node and enabling services to be contained by multiple services.
  • The number of Services is kept to an absolute minimum,
  • For each service, one or more offerings may be defined, each having its own commitments, subscriptions, and DevOps teams.
  • The applications, as procured from the vendor, can be grouped or split into multiple interlinked applications, allowing each application (also known as a Product) to be managed by a single Agile DevOps team. This also allows the projects/products/demand in the Agile portfolio to be organised around Applications and their Agile DevOps teams.
  • The Application instance portfolio contains instances related to service offerings, which the end-user may want to raise incidents/changes for.
    If needed, a fulfiller may associate other/additional configuration items with the incident via the Service Operations Workspace or backend GUI.
  • Service Owners can define custom capabilities (not being enterprise-wide capabilities) for each service offering and assign planning items to them.

    BROWSE THROUGH THE PICTURES HEREIN TO SEE THE MODEL/DATA IN ACTION

APPENDIX
The following Artefacts are to be defined/gathered:

  • Foundational Data
    • Locations
      • Continents/Regions [ISO-3166]
      • Countries [ISO-3166)
      • States/Provinces [ISO 3166-2]
      • Employee Locations (HR)
      • Data Center Locations
      • Asset Locations (floors, rooms, desks/tiles, etc)
    • Companies
      • internal legal entities
      • vendors,
      • manufacturers
      • service providers
    • Organisation
      • Business Units
      • Departments
      • Cost Centers
    • Assignment Groups
      • Groups incl. their Roles and Types.
      • Group Members
    • People/Identities
      • Employees
      • Contractors
      • Contact persons
      • Service Accounts
    • Shared Data
      • Languages (ISO 639.2)
      • Time Zones (ISO 8601)
      • Currencies (ISO 4217)
      • Historical Exchange rates (ECB)
      • Airport codes (IATA)
      • Fiscal Periods (SN)
    • Relations with objects above
  • Service Portfolio for Business & Technology Management Services/offerings
    • L1 Services (solution type)
    • L2 Services (solution category
    • L3 Services (product level)
    • Service Offerings
    • Relations with Services and Offerings
  • Application/Product Portfolio
    • L1 Business Capability (solution type)
    • L2 Business Capability (solution name)
    • L3 Business Capability (solution category)
    • Business Application Host/Platform
    • Business Application/Product
    • Relations with Business Capabilities/Applications
  • Component Portfolio
    • Components
    • Relations with Components
  • Application Instance Portfolio
    • Application Instances
    • Mapped Configuration items
    • Relations with Application Instances
  • Configuration Management Database (CMDB)
    • Federated/Discovered System Delivery Systems (also known as Configuration Items) and their associated tags, approximately.1300 tables, e.g.
      • End User Devices
      • Facility/Office Devices
      • Application Resources
      • Middleware
      • Compute
      • Cloud Services
      • Data center facilities
    • Relations with/between Configuration items
  • Asset Management Database
    • Assets
      • Hardware Assets
      • Software Assets
      • Cloud Assets
      • SAAS Assets
      • Consumable Assets
      • Peripheral Assets
    • Asset Models
    • Asset Model Categories
    • Software/SAAS Contracts
    • Software License (Models)
    • Software Packages (Models)
    • Discovered Software Instances