41 KiB
InfoTechCanon Landscape Model
Short Name: ITC-LAND
Former Working Name: Canonical IT Landscape Model (CILM)
Document Status: Seed Standard Release Candidate 1
Version: RC1-seed
Date: 2026-05-22
Repository Context: info-tech-canon
Document Type: InfoTechCanon Domain Standard
Intended Audience: Enterprise architects, platform engineers, DevSecOps teams, network architects, security architects, service owners, CMDB/ITSM owners, knowledge-system builders, standards authors, and agentic tooling.
1. Purpose
The InfoTechCanon Landscape Model defines a canonical seed model for representing information-technology landscapes across services, software systems, delivery pipelines, runtime environments, infrastructure, networking, security posture, observability, data, governance references, and operational evidence.
It is intended to be the first practical seed standard of the broader InfoTechCanon information space.
Its purpose is not to finish the complete canon. Its purpose is to provide a coherent starting point from which related standards, patterns, mappings, profiles, and assimilation workflows can grow.
This standard provides:
- a stable semantic spine for IT landscape knowledge,
- a first hierarchy of landscape concepts,
- clear concept-ownership boundaries,
- extraction seams for future standards,
- mapping hooks to external standards and products,
- seed pattern references,
- profile hooks for concrete implementations,
- and retrieval-friendly structure for humans, agents, and markdown-based infospaces.
2. Position in InfoTechCanon
The Landscape Model is a domain standard within InfoTechCanon.
It depends on the future InfoTechCanonCore for general canon mechanisms such as:
- concept ownership,
- artifact metadata,
- mappings,
- assimilation,
- profiles,
- patterns,
- provenance,
- versioning,
- conformance,
- and retrieval conventions.
Until InfoTechCanonCore is fully specified, this seed standard declares the assumptions it uses and marks concepts that should later be extracted into their proper owning standards.
InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel <-- this standard
├── InfoTechCanonOrganizationModel <-- extraction candidate
├── InfoTechCanonGovernanceModel <-- extraction candidate
├── InfoTechCanonSecurityModel <-- extraction candidate
├── InfoTechCanonTaskModel <-- related external/internal dependency
├── InfoTechCanonTaggingStandard <-- related external/internal dependency
├── InfoTechCanonPatternLanguage
└── Application Profiles
3. Seed Standard Design Stance
This document deliberately acts as a seed standard, not a final domain closure.
A seed standard shall:
- define enough canonical concepts to be useful immediately,
- avoid pretending adjacent domains are already fully solved,
- mark extraction candidates clearly,
- define mapping and assimilation hooks,
- remain readable as Markdown,
- remain retrievable by agents,
- provide examples and profiles,
- and support future refactoring without semantic collapse.
The Landscape Model should therefore be read as:
A first stable landscape spine
+ domain seeds
+ extraction seams
+ mapping hooks
+ pattern anchors
+ profile starting points
4. Scope
4.1 In Scope
This standard covers canonical representation of:
- IT landscapes,
- services and service relationships,
- software systems and solution components,
- source repositories and delivery pipelines,
- artifacts, deployments, and runtime resources,
- environments, platforms, clusters, workloads, compute, storage, and middleware,
- network domains, endpoints, segments, paths, flows, and policies,
- data objects and data stores as landscape-relevant entities,
- observability and operational signals,
- security posture as it relates to landscape entities,
- ownership and governance references,
- evidence and provenance for landscape claims,
- state distinctions between intended, declared, applied, observed, historical, and assessed reality,
- and external mappings to standards, products, frameworks, and regulations.
4.2 Out of Scope
This standard does not fully define:
- the general InfoTechCanon meta-model,
- organization theory,
- governance theory,
- project management,
- task management,
- canonical tagging,
- detailed access-control semantics,
- detailed legal or regulatory interpretation,
- complete security-control frameworks,
- complete observability semantic conventions,
- complete network configuration schemas,
- complete software architecture notation,
- or a mandatory database schema.
Those areas may be referenced, mapped, profiled, or marked as extraction candidates.
5. Normative Language
The following terms are used normatively:
- SHALL indicates a mandatory rule for conformance.
- SHOULD indicates a recommended practice.
- MAY indicates an optional capability.
- MUST NOT indicates a prohibited practice.
- SEED marks a concept that is defined provisionally here but may later move to another standard.
- EXTRACT marks a concept or section expected to be moved into another standard when mature.
6. Core Principles
6.1 Landscape as a Graph
An IT landscape SHALL be modeled as a graph of entities and relationships, not merely as a tree.
Hierarchies MAY be used for abstraction and navigation, but relationships SHALL remain first-class.
6.2 Concept Ownership
Every canonical concept SHOULD have a clear owning standard.
When the owning standard does not yet exist, this standard MAY temporarily define the concept as a seed concept and mark it as an extraction candidate.
6.3 Imported Concepts Are Not Redefined
This standard SHOULD import concepts from other InfoTechCanon standards once they exist.
It MUST NOT permanently redefine concepts that are clearly owned by another standard.
6.4 External Standards Are Mapped, Not Obeyed
The Landscape Model MAY map to external standards and products such as ArchiMate, CSDM, CIM, NetBox, Backstage, YANG, SPDX, CycloneDX, SLSA, OpenTelemetry, NIST, ITIL, or similar frameworks.
It MUST NOT subordinate its internal semantics to any single external standard.
6.5 Declared Reality Is Not Observed Reality
The model SHALL distinguish intended, declared, applied, observed, historical, and assessed state.
6.6 Evidence-Carrying Claims
Important landscape claims SHOULD carry source, confidence, time, and evidence metadata.
6.7 Profiles Make the Model Practical
Concrete implementation contexts SHOULD be expressed through application profiles.
Examples:
- Kubernetes landscape profile,
- GitHub / GitLab delivery profile,
- ServiceNow CSDM mapping profile,
- NetBox network source-of-truth profile,
- Backstage software catalog profile,
- small SaaS platform profile.
7. Canonical Architecture
The Landscape Model is organized into four layers:
InfoTechCanonLandscapeModel
├── Landscape Core
├── Landscape Domains
├── Landscape Patterns
└── Landscape Profiles
7.1 Landscape Core
The Landscape Core defines concepts that are needed across all landscape domains:
LandscapeEntity
LandscapeRelationship
LandscapeClaim
LandscapeState
LandscapeSource
LandscapeEvidence
LandscapeView
LandscapeProfile
7.2 Landscape Domains
Landscape domains define specialized landscape concepts.
Initial seed domains:
Strategy and Capability
Service and Product
Software and Solution
DevSecOps Delivery
Runtime and Platform
Network
Data and Information
Security Posture
Observability and Operations
Physical and Facility
Organization Reference
Governance Reference
7.3 Landscape Patterns
Landscape patterns describe recurring ways to combine concepts.
Seed patterns include:
Service Spine
Capability-to-Workload Trace
Commit-to-Runtime Trace
Declared-vs-Observed State
Source-of-Truth Boundary
Network Reachability Slice
Evidence-Carrying Finding
Landscape Impact Trace
Profile Not Fork
7.4 Landscape Profiles
Landscape profiles constrain the model for specific tools, platforms, domains, or use cases.
A profile SHALL declare:
- included concepts,
- required relationships,
- required metadata,
- external mappings,
- validation rules,
- source-of-truth assumptions,
- and known deviations.
8. Canonical Seed Metadata
Every canonical landscape artifact SHOULD support structured metadata.
Recommended front matter:
---
id: itc-land:ApplicationService
type: concept
standard: InfoTechCanonLandscapeModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonLandscapeModel
extraction_status: stable-in-landscape
preferred_label: Application Service
related:
- itc-land:BusinessService
- itc-land:RuntimeWorkload
mappings:
- itc-map:application-service-to-csdm
---
Recommended artifact statuses:
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
Recommended concept statuses:
proposed
experimental
candidate
canonical
deprecated
retired
Recommended extraction statuses:
stable-in-landscape
seed-owned-here
import-when-available
extract-to-organization
extract-to-governance
extract-to-security
extract-to-task
extract-to-tagging
extract-to-data
extract-to-observability
9. Landscape Core Concepts
9.1 LandscapeEntity
A LandscapeEntity is an identifiable thing relevant to understanding, operating, governing, securing, or changing an IT landscape.
Examples:
- business service,
- application service,
- software component,
- repository,
- artifact,
- workload,
- cluster,
- subnet,
- endpoint,
- vulnerability finding,
- metric,
- incident,
- owner reference.
Required attributes:
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
Recommended attributes:
owner:
steward:
criticality:
classification:
source_confidence:
valid_from:
valid_to:
tags:
external_references:
9.2 LandscapeRelationship
A LandscapeRelationship is a typed, directional, evidence-aware connection between landscape entities.
Relationships SHALL be first-class records when used for integration, impact analysis, automation, security, or governance.
Required attributes:
id:
relationship_type:
source_entity_id:
target_entity_id:
source_system:
created_at:
updated_at:
Recommended attributes:
confidence:
criticality:
state_context:
valid_from:
valid_to:
evidence_ids:
attributes:
Root relationship types:
composes
part_of
depends_on
realizes
serves
supports
uses
produces
consumes
deployed_to
deployed_as
hosted_on
connected_to
routes_to
exposes
protects
governs
observes
generates
affects
owned_by
operated_by
changed_by
evidenced_by
mapped_to
9.3 LandscapeClaim
A LandscapeClaim is an assertion about an entity, relationship, state, risk, mapping, or observation.
Claims are useful when the model needs to preserve uncertainty or conflicting sources.
Example:
id: itc-claim:prod-api-depends-on-db
claim_type: relationship-claim
subject: itc-land:workload:prod-api
predicate: depends_on
object: itc-land:database:customer-db
state_context: observed
source_system: opentelemetry
confidence: 0.84
evidence:
- itc-evidence:trace-sample-2026-05-22
9.4 LandscapeSource
A LandscapeSource identifies the origin of a claim, entity, relationship, mapping, or observation.
Examples:
- ServiceNow,
- NetBox,
- Backstage,
- Kubernetes API,
- Git repository,
- Terraform state,
- CI/CD platform,
- SBOM repository,
- vulnerability scanner,
- OpenTelemetry backend,
- manual architecture decision record.
9.5 LandscapeEvidence
LandscapeEvidence is information used to support a claim.
Examples:
- discovery record,
- API response,
- scan result,
- deployment log,
- SBOM,
- attestation,
- trace sample,
- configuration file,
- architecture decision record,
- audit record.
9.6 LandscapeState
A LandscapeState describes the truth context in which an entity or relationship is asserted.
Required state contexts:
intended
declared
applied
observed
historical
assessed
Meaning:
| State | Meaning |
|---|---|
intended |
Desired by strategy, architecture, policy, or design. |
declared |
Submitted to a source system or control plane. |
applied |
Accepted and acted on by a control plane. |
observed |
Discovered or measured in runtime reality. |
historical |
True or asserted at a known point in the past. |
assessed |
Inferred by analysis, risk evaluation, or compliance assessment. |
This distinction is mandatory for mature landscape modeling.
10. Root Landscape Taxonomy
The seed taxonomy is:
LandscapeEntity
├── CapabilityEntity
├── ServiceEntity
├── SoftwareEntity
├── DeliveryEntity
├── RuntimeEntity
├── NetworkEntity
├── DataEntity
├── SecurityPostureEntity
├── ObservabilityEntity
├── PhysicalEntity
├── OrganizationReferenceEntity
└── GovernanceReferenceEntity
The taxonomy is intentionally not exhaustive. It is a starting point for growing the information space.
11. Domain: Strategy and Capability
Ownership Status: Seed concepts. Likely future extraction or alignment with strategy / organization / governance standards.
11.1 Purpose
The Strategy and Capability domain connects landscape entities to business direction, capabilities, value streams, constraints, and transformation initiatives.
11.2 Seed Concepts
Goal
Driver
Constraint
Principle
BusinessCapability
ValueStream
Initiative
RoadmapItem
ArchitectureDecision
Transformation
11.3 Key Relationships
BusinessCapability realized_by BusinessService
Initiative changes ApplicationService
ArchitectureDecision constrains SoftwareComponent
Constraint governs LandscapeEntity
Goal motivates Initiative
11.4 Extraction Notes
These concepts SHOULD eventually be reviewed against:
- organization theory,
- enterprise architecture practice,
- strategy modeling,
- ArchiMate motivation and strategy concepts,
- portfolio management,
- product management,
- and governance models.
The Landscape Model should keep only landscape-relevant references once a dedicated strategy/capability standard exists.
12. Domain: Service and Product
Ownership Status: Core landscape domain.
12.1 Purpose
The Service and Product domain provides the service spine that connects business meaning to software, runtime, operations, and risk.
12.2 Seed Concepts
Service
BusinessService
ApplicationService
TechnicalService
ServiceOffering
ServiceInstance
ServiceLevelObjective
ServiceConsumer
ServiceProvider
SupportGroup
CatalogItem
Product
ProductCapability
12.3 Distinctions
BusinessService
A business-consumable capability delivered as a service.
ApplicationService
A running or supportable application capability.
TechnicalService
A reusable technical capability such as identity, logging, Kubernetes,
networking, storage, database, or backup.
ServiceOffering
A consumable package of a service with scope, SLA, cost, support model,
and availability constraints.
ServiceInstance
A concrete instance of a service in a specific environment, region,
tenant, or customer context.
12.4 Key Relationships
BusinessService served_by ApplicationService
ApplicationService supported_by TechnicalService
ServiceOffering offers Service
ServiceInstance instance_of Service
Service has_slo ServiceLevelObjective
Service consumed_by ServiceConsumer
Service operated_by SupportGroup
12.5 Canonical Rule
Service concepts MUST NOT be collapsed into a generic Application concept.
The model SHOULD distinguish:
business-consumable service
application capability
technical capability
offering
instance
implementation component
runtime workload
13. Domain: Software and Solution
Ownership Status: Core landscape domain with future alignment to software architecture standards.
13.1 Purpose
The Software and Solution domain represents logical and design-time software structures.
13.2 Seed Concepts
SoftwareSystem
Application
Solution
SoftwareComponent
DeployableComponent
Module
API
Endpoint
Interface
IntegrationFlow
EventType
MessageContract
DataObject
DataSchema
Dependency
Library
RuntimeConfiguration
13.3 Key Distinction
The Landscape Model SHALL distinguish:
Logical software component
Deployable artifact
Deployment record
Runtime workload
Network endpoint
Example:
Logical component: billing-api
Artifact: ghcr.io/org/billing-api@sha256:...
Deployment: billing-api v1.8.2 deployed to prod-eu
Runtime workload: Kubernetes Deployment/billing-api in cluster prod-1
Network endpoint: https://billing.example.com
13.4 Key Relationships
SoftwareSystem composed_of SoftwareComponent
SoftwareComponent exposes API
SoftwareComponent consumes API
SoftwareComponent uses Library
SoftwareComponent produces EventType
SoftwareComponent reads DataObject
SoftwareComponent writes DataObject
DeployableComponent realizes SoftwareComponent
14. Domain: DevSecOps Delivery
Ownership Status: Core landscape domain with future alignment to DevSecOps / supply-chain standards.
14.1 Purpose
The DevSecOps Delivery domain connects source code, build systems, artifacts, security evidence, releases, deployments, and runtime reality.
14.2 Seed Concepts
Repository
Branch
Commit
PullRequest
BuildDefinition
Pipeline
PipelineStage
PipelineJob
PipelineRun
Artifact
ArtifactVersion
ContainerImage
Package
IaCModule
HelmChart
SBOM
Provenance
Attestation
Signature
PolicyGate
ScanResult
Finding
DeploymentPlan
DeploymentRecord
Release
ChangeRequest
14.3 Key Relationships
Commit produces ArtifactVersion
PipelineRun produces ArtifactVersion
ArtifactVersion described_by SBOM
ArtifactVersion attested_by Attestation
ArtifactVersion signed_by Signature
ScanResult generates Finding
Finding affects ArtifactVersion
Release includes ArtifactVersion
DeploymentRecord deploys ArtifactVersion
DeploymentRecord instantiates RuntimeWorkload
PolicyGate blocks PipelineRun
ChangeRequest authorizes DeploymentRecord
14.4 Canonical Rule
A deployment MUST be modeled as a historical event or record, not merely as the current state of a workload.
A runtime workload may currently run an artifact, but the deployment record explains how it got there.
15. Domain: Runtime and Platform
Ownership Status: Core landscape domain.
15.1 Purpose
The Runtime and Platform domain represents the environments where software and technical services operate.
15.2 Seed Concepts
Environment
Tenant
Account
Subscription
Region
AvailabilityZone
RuntimePlatform
PlatformService
KubernetesCluster
Namespace
Node
Workload
Pod
Container
Function
VirtualMachine
BareMetalHost
OperatingSystem
Runtime
Middleware
DatabaseInstance
Queue
Cache
ObjectBucket
Volume
SecretReference
CertificateReference
15.3 Suggested Hierarchy
Tenant / Account / Subscription
└── Region
└── Environment
└── RuntimePlatform
└── Cluster / Host Group
└── Namespace / Segment
└── Workload
└── Runtime Unit
15.4 Key Relationships
RuntimePlatform hosts Workload
Workload runs ArtifactVersion
Workload part_of ApplicationService
Workload uses DatabaseInstance
Workload uses Queue
Workload exposes Endpoint
Workload emits ObservabilitySignal
Workload subject_to SecurityPolicy
16. Domain: Network
Ownership Status: Core landscape domain with future alignment to detailed network standards.
16.1 Purpose
The Network domain represents addressability, topology, routing, connectivity, exposure, reachability, and network policy.
16.2 Subdomains
Network Inventory
Addressing
Topology
Routing and Connectivity
Policy and Intent
Flows and Paths
Exposure
16.3 Seed Concepts
NetworkDomain
NetworkFabric
NetworkZone
NetworkSegment
Subnet
VLAN
VRF
NetworkDevice
Router
Switch
Firewall
Gateway
LoadBalancer
WAF
Interface
Port
Link
Circuit
Path
Endpoint
IPAddress
Prefix
DNSZone
DNSRecord
RouteTable
Route
Peering
NAT
NetworkPolicy
NetworkIntent
NetworkRule
SecurityGroup
ACL
FirewallPolicy
ServiceMeshPolicy
Flow
ObservedFlow
Exposure
16.4 Required Distinctions
The model SHALL distinguish:
Intent
Policy
Configuration
State
Flow
Path
Exposure
Definitions:
Intent
Desired network outcome in business or technical language.
Policy
Formal rule expressing allowed, denied, required, or constrained behavior.
Configuration
Concrete device, platform, or service setting.
State
Observed or applied network reality.
Flow
Actual or modeled traffic relation.
Path
Realized or modeled route across topology.
Exposure
A reachable surface presented to consumers or attackers.
16.5 Key Relationships
Endpoint assigned_ip IPAddress
IPAddress part_of Prefix
Prefix belongs_to NetworkSegment
NetworkSegment part_of NetworkDomain
Device has Interface
Interface connected_to Interface
Workload exposes Endpoint
Endpoint reachable_via Path
Policy permits Flow
Policy denies Flow
Intent realized_by Policy
Policy realized_by Configuration
Configuration applied_to Device
ObservedFlow violates Policy
Exposure affects Service
17. Domain: Data and Information
Ownership Status: Seed domain. Likely future extraction into InfoTechCanonDataModel.
17.1 Purpose
The Data and Information domain represents data objects, datasets, schemas, classification, residency, lineage, and retention as landscape-relevant concerns.
17.2 Seed Concepts
DataDomain
DataProduct
Dataset
DataObject
Schema
Field
DataStore
DataClassification
DataResidency
RetentionRule
DataFlow
DataLineage
ProcessingPurpose
DataOwner
17.3 Key Relationships
ApplicationService processes Dataset
Dataset classified_as DataClassification
Dataset stored_in DataStore
DataFlow moves Dataset
DataLineage derived_from Dataset
RetentionRule applies_to Dataset
Control applies_to Dataset
17.4 Extraction Notes
This domain should later align with:
- data architecture,
- data governance,
- privacy,
- data lineage,
- AI readiness,
- data product thinking,
- and compliance requirements.
18. Domain: Security Posture
Ownership Status: Seed domain. Likely future extraction into InfoTechCanonSecurityModel and InfoTechCanonAccessControlModel.
18.1 Purpose
The Security Posture domain represents the landscape-visible security condition of systems, artifacts, identities, policies, secrets, certificates, vulnerabilities, controls, and risks.
18.2 Seed Concepts
Identity
Principal
HumanUser
ServiceAccount
WorkloadIdentity
Group
Role
Permission
Entitlement
SecurityPolicy
Control
Secret
Key
Certificate
Vulnerability
Weakness
Misconfiguration
Finding
Threat
AttackPath
Risk
Mitigation
Exception
Evidence
AuditEvent
18.3 Key Relationships
Principal has Role
Role grants Permission
Permission applies_to Resource
Secret used_by Workload
Certificate protects Endpoint
Finding affects LandscapeEntity
Risk aggregates Finding
Control mitigates Risk
Evidence supports Control
Exception waives Control
AttackPath traverses LandscapeEntity
18.4 Extraction Notes
The Landscape Model should retain security posture references but should not become the owner of detailed access-control theory, policy theory, or security-control frameworks.
Those belong in dedicated standards.
19. Domain: Observability and Operations
Ownership Status: Seed domain. Likely future extraction or alignment with observability and IT operations standards.
19.1 Purpose
The Observability and Operations domain connects runtime and service reality to telemetry, incidents, changes, health, and operational response.
19.2 Seed Concepts
Metric
LogStream
Trace
Span
Event
Alert
SLO
SLI
Incident
Problem
Change
Runbook
HealthSignal
ErrorBudget
Dashboard
Observation
OperationalState
19.3 Key Relationships
Workload emits Metric
Endpoint emits Trace
Alert triggered_by HealthSignal
Incident affects Service
Change changes LandscapeEntity
Runbook resolves IncidentType
SLO applies_to ServiceOffering
Observation supports LandscapeClaim
19.4 Canonical Rule
Observability data SHOULD be linked to landscape entities through stable identifiers wherever possible.
Telemetry that cannot be attached to a landscape entity remains operationally useful but has limited canonical landscape value.
20. Domain: Physical and Facility
Ownership Status: Optional core landscape domain depending on deployment context.
20.1 Purpose
The Physical and Facility domain represents physical infrastructure where relevant.
20.2 Seed Concepts
Site
Building
Room
Rack
RackUnit
PhysicalDevice
Cable
PatchPanel
PowerFeed
PDU
CoolingUnit
Sensor
20.3 Key Relationships
PhysicalDevice installed_in Rack
Rack located_in Room
Cable connects Port
PowerFeed supplies Device
Sensor observes FacilityCondition
21. Organization Reference Domain
Ownership Status: Extraction candidate for InfoTechCanonOrganizationModel.
21.1 Purpose
The Landscape Model needs to reference organizational responsibility without becoming a full organization model.
21.2 Seed Concepts
Organization
OrganizationalUnit
Team
Person
Role
Responsibility
Ownership
Stewardship
21.3 Landscape Usage
These concepts are used to express:
Service owned_by Team
Workload operated_by Team
Dataset stewarded_by Person
Control accountable_to Role
Incident assigned_to Team
21.4 Extraction Rule
When InfoTechCanonOrganizationModel exists, these concepts SHOULD be imported from it.
The Landscape Model should then keep only landscape-specific relationship guidance.
22. Governance Reference Domain
Ownership Status: Extraction candidate for InfoTechCanonGovernanceModel.
22.1 Purpose
The Landscape Model needs to reference governance constraints, risks, evidence, policies, and decisions without becoming a complete governance standard.
22.2 Seed Concepts
Policy
Standard
ControlObjective
Control
Risk
Exception
Decision
Evidence
Audit
ComplianceRequirement
22.3 Landscape Usage
These concepts are used to express:
Policy governs Service
Control applies_to Workload
Risk affects BusinessService
Evidence supports Finding
Decision constrains Architecture
Exception waives Control
22.4 Extraction Rule
When InfoTechCanonGovernanceModel exists, these concepts SHOULD be imported from it.
The Landscape Model should then own only the landscape-specific usage patterns.
23. Mapping Model for the Landscape Standard
Mappings relate InfoTechCanon landscape concepts to external standards, frameworks, products, and regulations.
23.1 Mapping Types
Recommended mapping types:
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
23.2 Mapping Record
Example:
id: itc-map:application-service-to-csdm-application-service
source_concept: itc-land:ApplicationService
target_body: ServiceNow CSDM
target_version: "5.x"
target_concept: Application Service
mapping_type: closeMatch
scope:
- service-centric operational modeling
not_valid_for:
- software source-code module boundaries
- deployment artifact identity
rationale: >
Both concepts represent a supportable application capability, but external
implementations may vary in how they distinguish services, instances,
offerings, and technical components.
confidence: medium
status: candidate
owner: InfoTechCanonLandscapeModel
23.3 Seed Mapping Targets
The Landscape Model SHOULD maintain mapping folders for:
ArchiMate
ServiceNow CSDM
DMTF CIM
NetBox
Backstage Software Catalog
Kubernetes API
OpenTelemetry
SPDX
CycloneDX
SLSA
YANG / IETF topology models
NIST CSF
ITIL
COBIT
Cloud provider asset models
23.4 Mapping Rule
Mappings are adapters, not foundations.
External standards may influence InfoTechCanon through assimilation, but they do not directly define internal semantics.
24. Assimilation Hooks
The Landscape Model SHALL be able to receive new bodies of knowledge through the InfoTechCanon assimilation process.
24.1 Assimilation Triggers
Assimilation may be triggered by:
new external standard
new regulation
new product data model
new internal project model
new repository schema
new operational practice
new integration conflict
new recurring ambiguity
24.2 Landscape Assimilation Output
A landscape assimilation SHOULD produce:
source summary
extracted landscape concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions
24.3 Assimilation Example
Assimilate: Backstage Software Catalog
Expected outputs:
- mapping from Component/API/Resource/System to landscape software/service concepts
- gap analysis for ownership and lifecycle metadata
- profile proposal for Backstage catalog ingestion
- warnings about where Backstage semantics should not be treated as full runtime truth
25. Landscape Patterns
Patterns describe recurring combinations of landscape concepts.
25.1 Pattern: Service Spine
Context: An organization needs to connect business value to technical implementation.
Problem: Systems are modeled as isolated applications, infrastructure, or projects, making impact analysis difficult.
Solution: Use BusinessService, ApplicationService, TechnicalService, ServiceOffering, and ServiceInstance as a service spine connecting business, software, runtime, operations, and risk.
Used Concepts:
BusinessService
ApplicationService
TechnicalService
ServiceOffering
ServiceInstance
RuntimeWorkload
SLO
Incident
Risk
25.2 Pattern: Commit-to-Runtime Trace
Context: A deployed workload must be traceable to source code and supply-chain evidence.
Problem: Runtime systems often cannot answer which source revision, build, artifact, scan, and approval produced a running workload.
Solution: Model the chain:
Commit
-> PipelineRun
-> ArtifactVersion
-> SBOM / Attestation / ScanResult
-> Release
-> DeploymentRecord
-> RuntimeWorkload
25.3 Pattern: Declared-vs-Observed State
Context: Configuration and runtime reality diverge.
Problem: Treating declared state as truth hides drift, failed deployment, shadow infrastructure, and exposure.
Solution: Model intended, declared, applied, observed, historical, and assessed state separately.
25.4 Pattern: Source-of-Truth Boundary
Context: Multiple systems claim authority over overlapping landscape entities.
Problem: Duplicate authority causes conflicting data and integration fragility.
Solution: Declare source-of-truth boundaries per concept, relationship, and state context.
Example:
NetBox owns intended network inventory.
Kubernetes owns observed workload state.
Git owns declared deployment manifests.
OpenTelemetry owns observed trace relations.
ServiceNow owns service support ownership.
25.5 Pattern: Profile Not Fork
Context: A use case needs a constrained model.
Problem: Teams fork the standard and create incompatible variants.
Solution: Create an application profile that constrains the standard without redefining its concepts.
26. Landscape Profiles
26.1 Profile Format
A Landscape Profile SHALL declare:
id:
profile_name:
status:
implements:
- InfoTechCanonLandscapeModel
target_context:
included_concepts:
required_relationships:
required_metadata:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:
26.2 Seed Profile: Small SaaS Landscape Profile
Purpose:
Provide a minimal profile for a small SaaS platform moving toward production readiness.
Included concepts:
BusinessService
ApplicationService
TechnicalService
ServiceOffering
SoftwareComponent
Repository
Pipeline
ArtifactVersion
DeploymentRecord
Environment
RuntimePlatform
Workload
Endpoint
NetworkPolicy
Finding
Incident
Team
Policy
Evidence
Required relationships:
BusinessService served_by ApplicationService
ApplicationService realized_by SoftwareComponent
SoftwareComponent built_from Repository
Pipeline produces ArtifactVersion
DeploymentRecord deploys ArtifactVersion
Workload runs ArtifactVersion
Workload exposes Endpoint
Finding affects Workload
Incident affects ApplicationService
ApplicationService owned_by Team
Policy governs ApplicationService
26.3 Seed Profile: Kubernetes Landscape Profile
Purpose:
Map Kubernetes runtime objects into landscape concepts.
Example mappings:
Cluster -> RuntimePlatform / KubernetesCluster
Namespace -> Namespace
Deployment -> Workload
ReplicaSet -> RuntimeController
Pod -> RuntimeUnit
Container -> Container
Service -> InternalEndpoint / ServiceEndpoint
Ingress -> ExternalExposure / Endpoint
NetworkPolicy -> NetworkPolicy
ConfigMap -> RuntimeConfiguration
Secret -> SecretReference
26.4 Seed Profile: Backstage Catalog Profile
Purpose:
Map developer portal catalog concepts into landscape software and ownership concepts.
Example mappings:
System -> SoftwareSystem
Component -> SoftwareComponent
API -> API
Resource -> RuntimeResource / DataStore / PlatformResource
Group -> Team
User -> Person
Owner -> Ownership reference
26.5 Seed Profile: NetBox Network Profile
Purpose:
Map network source-of-truth concepts into the Network domain.
Example mappings:
Site -> Site
Rack -> Rack
Device -> NetworkDevice / PhysicalDevice
Interface -> Interface
Cable -> Cable / Link
Prefix -> Prefix
IPAddress -> IPAddress
VLAN -> VLAN / NetworkSegment
VRF -> VRF
Circuit -> Circuit
27. Canon Interface Card Usage
Subsystems that implement or produce landscape knowledge SHOULD publish a Canon Interface Card.
Example:
subsystem: landscape-importer-netbox
implements:
- InfoTechCanonLandscapeModel
- NetBoxNetworkProfile
produces:
- NetworkDevice
- Interface
- Link
- Prefix
- IPAddress
- VLAN
- Site
consumes:
- Team
- Service
relations:
- Interface connected_to Interface
- IPAddress part_of Prefix
- Device installed_in Site
source_of_truth:
intended_network_inventory: NetBox
known_deviations:
- does not model observed packet flows
Canon Interface Cards help subsystems snap into the broader information space.
28. Retrieval Requirements
The Landscape Model is designed for markdown-based infospaces.
28.1 Required Retrieval Properties
Every major section SHOULD provide:
- stable headings,
- stable concept names,
- examples,
- relationship lists,
- extraction notes,
- mapping hooks,
- and profile references.
28.2 Agent Brief
Each mature standard SHOULD include an agent-brief.md file with:
purpose
scope
owned concepts
imported concepts
do / do not rules
core relationship patterns
minimal examples
common mistakes
profile list
mapping list
28.3 Indexes
The landscape information space SHOULD provide indexes by:
concept
relationship
domain
profile
pattern
mapping target
source system
state context
status
extraction candidate
29. Conformance Levels
29.1 Reference-Conformant
A document or system is reference-conformant if it uses Landscape Model terminology consistently but does not implement structured metadata or validation rules.
29.2 Metadata-Conformant
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
29.3 Graph-Conformant
A system is graph-conformant if it represents entities and relationships as queryable graph-like records.
29.4 Evidence-Conformant
A system is evidence-conformant if important claims include sources, confidence, timestamps, and evidence references.
29.5 Profile-Conformant
A system is profile-conformant if it implements a declared Landscape Profile and passes its validation rules.
29.6 Assimilation-Conformant
A system or repository is assimilation-conformant if it can accept external concept bodies through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
30. Validation Rules
Initial validation rules:
VAL-LAND-001: Every LandscapeEntity SHOULD have an id, entity_type, canonical_name, lifecycle_state, and source_system.
VAL-LAND-002: Every LandscapeRelationship SHOULD have a relationship_type, source entity, target entity, and source_system.
VAL-LAND-003: Relationship types SHOULD come from the canonical relationship vocabulary or a declared profile extension.
VAL-LAND-004: Every imported external concept SHOULD be represented through a mapping record, not by silently reusing external terminology.
VAL-LAND-005: Concepts marked as extraction candidates SHOULD identify the likely future owning standard.
VAL-LAND-006: A profile MUST NOT redefine a canonical concept. It may constrain it.
VAL-LAND-007: Declared state and observed state MUST NOT be collapsed in mature landscape implementations.
VAL-LAND-008: Every non-trivial mapping SHOULD include scope, target version, mapping type, rationale, and confidence.
VAL-LAND-009: Service, software component, artifact, deployment, workload, and endpoint SHOULD be modeled as distinct concepts.
VAL-LAND-010: Source-of-truth assumptions SHOULD be explicit for every profile.
31. Anti-Patterns
31.1 One Giant CMDB
Trying to model every detail in a single central database without profiles, ownership, provenance, or source boundaries.
31.2 Application Means Everything
Using Application to mean product, service, codebase, deployment, runtime workload, and business capability at the same time.
31.3 Declared State as Truth
Assuming Terraform, Kubernetes manifests, network configuration, or CMDB records are reality.
31.4 External Standard Subordination
Bending the internal model to fit one external standard so tightly that future improvement becomes difficult.
31.5 Profile Forking
Creating local variants of the standard instead of declared application profiles.
31.6 Invisible Ownership
Modeling services and systems without accountable owners, stewards, or operators.
31.7 Relationship as Comment
Storing critical dependencies as free-text notes instead of first-class relationships.
32. Initial Repository Placement
Recommended repository layout:
info-tech-canon/
standards/
landscape/
InfoTechCanonLandscapeModel.md
agent-brief.md
concepts/
relationships/
patterns/
profiles/
mappings/
assimilation/
examples/
validation/
Seed files:
standards/landscape/InfoTechCanonLandscapeModel.md
standards/landscape/agent-brief.md
standards/landscape/concepts/service.md
standards/landscape/concepts/software.md
standards/landscape/concepts/runtime.md
standards/landscape/concepts/network.md
standards/landscape/patterns/service-spine.md
standards/landscape/patterns/commit-to-runtime-trace.md
standards/landscape/profiles/small-saas-landscape-profile.md
standards/landscape/profiles/kubernetes-landscape-profile.md
standards/landscape/mappings/csdm.yaml
standards/landscape/mappings/backstage.yaml
standards/landscape/mappings/netbox.yaml
33. Roadmap
Phase 1: Seed Stabilization
- Rename CILM to
InfoTechCanonLandscapeModel. - Mark concept ownership and extraction seams.
- Add mapping, profile, pattern, and assimilation sections.
- Define seed profiles.
- Define validation rules.
Phase 2: Core Extraction
- Create
InfoTechCanonCore. - Move generic concepts such as Concept, Mapping, Pattern, Profile, Provenance, Versioning, and Conformance into Core.
- Adjust Landscape Model to import them.
Phase 3: Organization and Governance Extraction
- Create
InfoTechCanonOrganizationModel. - Create
InfoTechCanonGovernanceModel. - Move organization and governance seed concepts to their own standards.
- Keep landscape-specific usage guidance.
Phase 4: First Assimilations
Recommended first assimilation candidates:
ServiceNow CSDM
Backstage Software Catalog
NetBox
Kubernetes API
NIST CSF
SPDX / CycloneDX
Phase 5: Tooling Integration
- Generate concept indexes.
- Generate agent briefs.
- Generate machine-readable YAML/JSON exports.
- Add validation scripts.
- Integrate with markdown infobase tooling.
- Use in real subsystem Canon Interface Cards.
34. Summary
The InfoTechCanon Landscape Model is the first seed standard for growing the InfoTechCanon information space.
It provides a practical canonical spine for IT landscapes while deliberately exposing seams for future standards, mappings, profiles, patterns, and assimilation workflows.
Its most important commitments are:
Model services, software, delivery, runtime, network, security posture,
observability, and evidence as connected landscape knowledge.
Keep concepts externally mappable but internally autonomous.
Use profiles instead of forks.
Treat declared and observed reality separately.
Make landscape knowledge retrievable by humans, agents, and tools.
Grow the canon through assimilation rather than blind adoption.
This makes the Landscape Model not only a data model, but a seed crystal for a larger, evolving, interoperable InfoTechCanon.