View raw markdown

PRISM/I — Infrastructure Landscape Framework

Version: 1.0.0 Status: Draft Licence: CC BY-SA 4.0

1. Overview

PRISM/I is a framework for describing, governing, and evolving infrastructure landscapes. It answers a specific class of question that PRISM (Enterprise Architecture) does not: what infrastructure runs the enterprise, who owns it, and where is it going?

PRISM/I is intentionally vendor-agnostic. Cloud, on-premises, colocation, hybrid, bare-metal: all are valid PRISM/I subjects. AWS, GCP, Azure, VMware, Kubernetes, Nomad — these are implementations. PRISM/I describes the landscape they form, not the technology itself.

Relationship to PRISM (Enterprise Architecture)

PRISM EA and PRISM/I are independent frameworks. They share authoring conventions but have separate dimensions, artifact types, and schemas.

PRISM EA's Reality/systems dimension lists what systems exist. PRISM/I describes how those systems are hosted, connected, and operated. They cross-reference by system ID but neither imports the other's schema.

2. The Six Dimensions

PRISM/I organizes infrastructure concerns into six dimensions. Each dimension answers one question.

Why six and not more?

Who and Where are separate because ownership and location answer different governance questions. Who owns infrastructure (team accountability) is independent of where it runs (region, compliance zone, jurisdiction). Splitting them makes ownership auditable separately from geography — particularly important when compliance zones (GDPR EU regions, SOX-scoped accounts) need to be queryable independently of team structure.

Runtime and State are separate because execution and persistence have different failure modes, scaling concerns, and ownership patterns. Conflating them produces landscapes where "the database" and "the service that queries it" share the same operational thinking — they don't.

Control stands alone because access and network policy are cross-cutting. A firewall rule spans Runtime and State. IAM governs all dimensions. Burying Control inside another dimension obscures the governance surface.

Operations is last because it operates on everything above it. CI/CD pipelines deploy Runtime. Monitoring covers State and Control. A separate dimension makes it possible to audit the delivery and observability posture independently.

3. Foundational Principles

PRISM/I inherits three principles from PRISM EA. They are not optional.

3.1 YAML for Artifacts, JSON for Schemas

Landscapes are authored in YAML. Schemas (validation rules) are in JSON Schema format.

YAML because infrastructure landscapes must be readable and writable by platform engineers, SREs, security teams, and architects — not just developers. Comments, block scalars, and minimal syntax noise matter.

JSON Schema because validation tooling (ajv, IDE plugins, CI validators) expects it.

3.2 Git-Native Governance (Architecture as Code)

Infrastructure architecture in PRISM/I is architecture as code: the landscape lives in git, not a CMDB or a diagramming tool.

PRISM/I landscapes live in git. No separate CMDB export step required.

3.3 Ownership Model

Every artifact in a PRISM/I landscape declares an owner.

Ownership determines who is responsible for the artifact's availability, security posture, and cost. It is not the same as who uses an artifact.

3.4 Temporal Axis

Every PRISM/I landscape is timestamped and positioned on a temporal axis.

A landscape in transition state documents both what exists now and what it is becoming. This is how PRISM/I captures migrations in flight — cloud migrations, platform consolidations, region expansions — without requiring a separate "future state" document.

4. Dimensions — Artifact Types

4.1 Who

4.2 Where

4.3 Runtime

4.4 State

4.5 Control

4.6 Operations

Operations artifacts carry an optional maturity field (initial → developing → defined → managed → optimizing) rating the operational discipline around that artifact — e.g. how consistently a pipeline enforces gates, or how complete monitoring coverage is — independent of its status.

5. File Structure

A PRISM/I landscape is a directory with one YAML file per dimension.

<org-name>/
  .prism-i/
    config.yaml           # landscape metadata
  who/
    landscape.yaml
  where/
    landscape.yaml
  runtime/
    landscape.yaml
  state/
    landscape.yaml
  control/
    landscape.yaml
  operations/
    landscape.yaml

.prism-i/config.yaml

prism_i_version: "1.0"
organization: "ACME, INC"
domain: insurance
scope: enterprise
temporal_state: baseline     # baseline | transition | target
as_of: "2025-01-01"
active_dimensions:
  - who
  - where
  - runtime
  - state
  - control
  - operations

Dimension landscape file structure

# who/landscape.yaml
dimension: who
as_of: "2025-01-01"
temporal_state: baseline

teams:
  - id: team-platform
    name: "Platform Engineering"
    ownership: self
    type: team
    ...

providers:
  - id: prov-aws
    name: "Amazon Web Services"
    ownership: external
    type: provider
    ...

# where/landscape.yaml
dimension: where
as_of: "2025-01-01"
temporal_state: baseline

accounts:
  - id: acct-aws-prod
    name: "AWS Production Account"
    ownership: self
    type: account
    provider: aws
    ...

regions:
  - id: reg-us-east-1
    name: "US East (N. Virginia)"
    type: region
    provider: prov-aws
    ...

Each dimension file uses its artifact type as the top-level key (plural). Artifacts within each section follow the same pattern: id, name, type, ownership, plus dimension-specific fields.

6. Artifact Fields

Required fields (all artifact types)

Common optional fields

Cross-referencing PRISM EA

A PRISM/I artifact can reference a PRISM EA artifact by its ID using the links field:

- id: svc-claims-api
  name: "Claims API"
  type: service
  ownership: self
  links:
    prism_ea_system: sys-claims-portal   # ID in PRISM EA Reality/systems

This is a soft reference — no schema enforcement across frameworks. PRISM/I does not import PRISM EA's schemas.

7. Temporal Representation

Infrastructure landscapes change constantly. PRISM/I captures change at the artifact level, not just the landscape level.

# runtime/landscape.yaml
temporal_state: transition    # landscape is mid-migration

services:
  - id: svc-billing-zos
    name: "Legacy Billing z/OS"
    type: vm
    ownership: self
    status: decommissioning
    temporal_state: baseline   # this artifact is the old state

  - id: svc-billing-k8s
    name: "Billing Service (Kubernetes)"
    type: service
    ownership: self
    status: active
    temporal_state: target     # this artifact is the target state

A landscape in transition state shows baseline and target artifacts side by side. The diff between them is the migration.

8. Validation

PRISM/I landscapes validate against JSON Schemas in schemas/.

9. What PRISM/I Does Not Cover

• Application architecture — service-to-service dependencies, API contracts, domain models. These belong in PRISM EA (Signal layer) or architecture decision records.
• Cost management — cloud billing, reserved instance tracking, chargeback. PRISM/I captures artifact ownership (which enables cost attribution) but is not a cost tool.
• Runbook content — PRISM/I records that a runbook exists as an artifact. The runbook itself lives in your wiki or docs system.
• Real-time state — PRISM/I is a landscape description, not a live inventory. It describes what should be true as of as_of. For live state, use your cloud provider's asset inventory or a CMDB.

Paper

Palakurthi, V.G. (2026). PRISM: Enterprise architecture frameworks for the source-first era.

• Site: https://prism-framework.org/
• PDF: https://prism-framework.org/PRISM_Framework_V1.0.pdf
• SSRN: https://ssrn.com/abstract=7037719
• Zenodo (DOI): https://doi.org/10.5281/zenodo.21325668