generated from coulomb/repo-seed
1939 lines
41 KiB
Markdown
1939 lines
41 KiB
Markdown
# 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.
|
|
|
|
```text
|
|
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:
|
|
|
|
1. define enough canonical concepts to be useful immediately,
|
|
2. avoid pretending adjacent domains are already fully solved,
|
|
3. mark extraction candidates clearly,
|
|
4. define mapping and assimilation hooks,
|
|
5. remain readable as Markdown,
|
|
6. remain retrievable by agents,
|
|
7. provide examples and profiles,
|
|
8. and support future refactoring without semantic collapse.
|
|
|
|
The Landscape Model should therefore be read as:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
LandscapeEntity
|
|
LandscapeRelationship
|
|
LandscapeClaim
|
|
LandscapeState
|
|
LandscapeSource
|
|
LandscapeEvidence
|
|
LandscapeView
|
|
LandscapeProfile
|
|
```
|
|
|
|
## 7.2 Landscape Domains
|
|
|
|
Landscape domains define specialized landscape concepts.
|
|
|
|
Initial seed domains:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
---
|
|
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:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended extraction statuses:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```yaml
|
|
id:
|
|
relationship_type:
|
|
source_entity_id:
|
|
target_entity_id:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
confidence:
|
|
criticality:
|
|
state_context:
|
|
valid_from:
|
|
valid_to:
|
|
evidence_ids:
|
|
attributes:
|
|
```
|
|
|
|
Root relationship types:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Goal
|
|
Driver
|
|
Constraint
|
|
Principle
|
|
BusinessCapability
|
|
ValueStream
|
|
Initiative
|
|
RoadmapItem
|
|
ArchitectureDecision
|
|
Transformation
|
|
```
|
|
|
|
## 11.3 Key Relationships
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Service
|
|
BusinessService
|
|
ApplicationService
|
|
TechnicalService
|
|
ServiceOffering
|
|
ServiceInstance
|
|
ServiceLevelObjective
|
|
ServiceConsumer
|
|
ServiceProvider
|
|
SupportGroup
|
|
CatalogItem
|
|
Product
|
|
ProductCapability
|
|
```
|
|
|
|
## 12.3 Distinctions
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Logical software component
|
|
Deployable artifact
|
|
Deployment record
|
|
Runtime workload
|
|
Network endpoint
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Tenant / Account / Subscription
|
|
└── Region
|
|
└── Environment
|
|
└── RuntimePlatform
|
|
└── Cluster / Host Group
|
|
└── Namespace / Segment
|
|
└── Workload
|
|
└── Runtime Unit
|
|
```
|
|
|
|
## 15.4 Key Relationships
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Network Inventory
|
|
Addressing
|
|
Topology
|
|
Routing and Connectivity
|
|
Policy and Intent
|
|
Flows and Paths
|
|
Exposure
|
|
```
|
|
|
|
## 16.3 Seed Concepts
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Intent
|
|
Policy
|
|
Configuration
|
|
State
|
|
Flow
|
|
Path
|
|
Exposure
|
|
```
|
|
|
|
Definitions:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
DataDomain
|
|
DataProduct
|
|
Dataset
|
|
DataObject
|
|
Schema
|
|
Field
|
|
DataStore
|
|
DataClassification
|
|
DataResidency
|
|
RetentionRule
|
|
DataFlow
|
|
DataLineage
|
|
ProcessingPurpose
|
|
DataOwner
|
|
```
|
|
|
|
## 17.3 Key Relationships
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Metric
|
|
LogStream
|
|
Trace
|
|
Span
|
|
Event
|
|
Alert
|
|
SLO
|
|
SLI
|
|
Incident
|
|
Problem
|
|
Change
|
|
Runbook
|
|
HealthSignal
|
|
ErrorBudget
|
|
Dashboard
|
|
Observation
|
|
OperationalState
|
|
```
|
|
|
|
## 19.3 Key Relationships
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Site
|
|
Building
|
|
Room
|
|
Rack
|
|
RackUnit
|
|
PhysicalDevice
|
|
Cable
|
|
PatchPanel
|
|
PowerFeed
|
|
PDU
|
|
CoolingUnit
|
|
Sensor
|
|
```
|
|
|
|
## 20.3 Key Relationships
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Organization
|
|
OrganizationalUnit
|
|
Team
|
|
Person
|
|
Role
|
|
Responsibility
|
|
Ownership
|
|
Stewardship
|
|
```
|
|
|
|
## 21.3 Landscape Usage
|
|
|
|
These concepts are used to express:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
Policy
|
|
Standard
|
|
ControlObjective
|
|
Control
|
|
Risk
|
|
Exception
|
|
Decision
|
|
Evidence
|
|
Audit
|
|
ComplianceRequirement
|
|
```
|
|
|
|
## 22.3 Landscape Usage
|
|
|
|
These concepts are used to express:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
```
|
|
|
|
## 23.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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:**
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
Provide a minimal profile for a small SaaS platform moving toward production readiness.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
BusinessService
|
|
ApplicationService
|
|
TechnicalService
|
|
ServiceOffering
|
|
SoftwareComponent
|
|
Repository
|
|
Pipeline
|
|
ArtifactVersion
|
|
DeploymentRecord
|
|
Environment
|
|
RuntimePlatform
|
|
Workload
|
|
Endpoint
|
|
NetworkPolicy
|
|
Finding
|
|
Incident
|
|
Team
|
|
Policy
|
|
Evidence
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Map Kubernetes runtime objects into landscape concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Map developer portal catalog concepts into landscape software and ownership concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Map network source-of-truth concepts into the Network domain.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
landscape/
|
|
InfoTechCanonLandscapeModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|