7lens Data Model

Canonical copy

Copied from the 7lens app repository, docs/datamodel/7lens-data-model.md at 012d434, on 2026-11-11. The app repository is the source of truth. Do not edit this page here; change the source and re-run npm run sync:reference.

This is a strategic source document: the canonical semantic model and terminology.

The 7lens Data Model

The core 7lens data model is the Ontology: four axes. Shared representation covers time, naming, people, provenance, lifecycle, quantities, money, declarations, and preferences.

• Groups define how the enterprise classifies and organizes elements.
• Organization defines who the enterprise is and where it operates.
• Technology defines the technology capabilities the enterprise provides and how they are organized.
• Business defines the business areas and applications that support them.

Beyond the Ontology, 7lens adds Data Model Extensions (Inventory, Contracts, Processes) that extend the core without being axes of it. They are described at the end of this document.

Organization

Organization defines the enterprise and its geographic and legal structure.

• Organization — the enterprise itself. There is one global Organization.
• Region — a major geographic area within the Organization.
• Sub-region — an optional geographic level used by large enterprises.
• Country — a country (identified by its ISO 3166-1 alpha-2 code) that belongs to exactly one Sub-region or, when Sub-regions are not used, directly to one Region.
• Legal Entity — a legal entity operating within a Country.

Each Organization node has accountable_person, labelled Owner. It records accountability for the accuracy of that node’s facts.

Regions and Sub-regions follow the UN M49 standard geographic scheme; Countries use ISO 3166-1 alpha-2 codes. Commercial groupings such as EMEA or APAC are overlays, not these base geographic levels.

Structure:

Organization → Region → Sub-region (optional) → Country → Legal Entity

Groups

The Groups axis records how the enterprise classifies things and which external frameworks and tool integrations it enables. Configuration exposes that axis as three containers: Groups, Frameworks, and Integrations. Structural detail for the tree, ownership, rules, and containers lives in Groups.

Groups (the classification container) are customer-defined global strategic classification dimensions used to organize and classify entities across the 7lens model and establish strategic ownership and access boundaries.

A Group defines:

• the strategic classification dimension
• a human-readable name and a lowercase programmatic key
• its allowed values, and the owner of each Group value
• which entity types the Group applies to, and per type: whether a value is required, whether one or many values are allowed, and whether children inherit and may override
• direct values, container subgroups (each holding values), or both

Groups:

• are global classifications, not part of the organizational hierarchy
• can apply across Organization, Business and Technology
• apply to higher-level concepts: Organization, Region, Sub-region, Country, Legal Entity, Technology Stack, Service, Offering, Platform, Business Domain, Application
• provide a consistent way to classify higher-level concepts across the 7lens model
• can be used to establish role and access boundaries across 7lens, through the owner of each value
• allow each enterprise to define how its landscape is strategically organized
• can be inherited down the parent chain and can be explicitly overridden by a child
• hold direct values, container subgroups, or both — a subgroup is a container of values, not a nested Group

A Group is validated whenever it applies. A missing required pick is an error on a new write and a warning on existing data. A missing optional pick is a warning. A value inherited from a parent does not satisfy required. The record is not saved on a new write while a required pick is missing.

Frameworks enable published standards, architecture models, and compliance regimes (for example TOGAF, TBM, ISO 27001, GDPR, DORA). Selection records intent, not certification.

Integrations enable published tool / platform taxonomies for mapping (for example ServiceNow CSDM). An Integration id is a catalogue taxonomy entry, not an Asset instance id, Deployment id, or tenant id.

DOs

• Put customer strategic classification under Groups.
• Put published standards and compliance regimes under Frameworks.
• Put published tool / platform mapping taxonomies under Integrations.
• Keep classification picks on the classified entity (group_values).

DONTs

• Do not invent a “Technology Groups” container, or use a custom Group to stand in for Technology Stack / Service / Offering / Platform membership.
• Do not model Data Sensitivity, Environment, or Lifecycle as Groups.
• Do not encode catalogue Frameworks or Integrations as ordinary custom Group values.
• Do not place OSM under Frameworks. OSM seeds the Technology catalog; it is not a Framework selection.

Groups allow each enterprise to classify its landscape according to how that enterprise operates.

Technology

Technology defines the technology capabilities that exist within the enterprise and how they are organized.

The Technology catalog (what capabilities exist) is kept separate from capability health and posture (their operational state over time).

Technology hierarchy

Stack → Service → Offering / Asset Type

• Stack — groups Services into technology domains. Stacks are recursive, so a Stack can contain other Stacks. A Stack is an operational competency domain (for example Compute, Databases, Networking, Storage), not a catalogue of end-user products.
• Service — groups Offerings and Asset Types that provide a technology capability.
• Offering — a specific functionality or capability exposed by a Service.
• Asset Type — the recognition key for Assets of that Service. It sits alongside Offerings, not under an Offering.

Business applications never live under Technology. The Technology hierarchy is Stack → Service → Offering / Asset Type (plus the cross-cutting Platform and ICT Provider). Anything the enterprise operates that supplies a Service and that business users work in (for example ERP, CRM, HR, or ITSM) is a Platform. The business uses built on it are Business Applications, which reference Technology through consumes[].service. An Application and a Platform have no direct link. An Asset belongs to a Deployment, and that Deployment belongs to an Application or a Platform, not both. Neither is modelled as a Technology Stack, Service, or Offering.

Platform

Platform is something the enterprise operates that supplies a set of Services and/or Offerings and that business users work in. It may be built in-house (for example an internal developer platform, automation platform, or AI agent platform) or be a SaaS / third-party product the enterprise operates (for example SAP SuccessFactors, Microsoft Teams, or ServiceNow ITSM).

A Platform is cross-cutting and is not another level of the Stack → Service → Offering / Asset Type hierarchy. It is not a cloud or SaaS vendor — those remain ICT Providers — and it is not a Business Application. Business-facing SaaS that the enterprise operates and that business users work in (for example ERP or a supplier portal) is a Platform. The business uses built on it are Business Applications, including when the product is a single-purpose SaaS.

ICT Provider

ICT Provider is a third-party provider of technology (for example a cloud or SaaS vendor) that a Service or Offering relies on.

ICT Providers are cross-cutting and are not another level of the Stack → Service → Offering / Asset Type hierarchy. They support provider-risk and third-party concerns such as substitutability and regulatory exposure.

Framework Mappings

Framework Mappings relate 7lens concepts to external frameworks (for example TBM, TOGAF, ISO, NIST, GDPR, DORA).

Framework Mappings are global. When 7lens is used as a platform, they are enabled on the Groups axis under the Frameworks and Integrations containers (not as ordinary Group values), and Technology and Business inherit those definitions. OSM is the Technology catalog seed; it is never selected under Config Frameworks. When 7lens is used with OSM only, Technology-side mapping stays in the Technology definition.

Business

Business defines how the enterprise organizes its business landscape and the applications that support it.

Business hierarchy

Domain → Application

• Domain — groups Applications according to a business-related classification defined by the enterprise. Domains are recursive, so a Domain can contain other Domains. Domain is always mapped to a Legal Entity, in the Organization.
• Application — a business application that provides functionality to business users, customers, or other business consumers. An Application consumes the Technology Services it relies on. An Application stores no link to a Platform.

An Application has no Organization owner of its own; its Organization ownership flows through its Domain’s Legal Entity.

A Domain could represent a business capability, a business area, a value stream, a product or service area, a customer journey or another meaningful business classification.

Relationships across the model

The four parts connect into a single model:

• A Domain is mapped to a Legal Entity (Organization).
• An Application belongs to a Domain, and consumes Technology Services.
• A Platform offers a set of Services and/or Offerings. It may be in-house or a SaaS / third-party product the enterprise operates; it is not an ICT Provider and not a Business Application.
• A Group classifies entities across Organization, Technology and Business. A Group may hold direct values, container subgroups (each holding values), or both. Classification picks are stored on the classified entity (group_values), not in assignments.

Beyond the core model: Data Model Extensions

The four parts above — Groups, Organization, Technology, Business — are the Ontology: the core 7lens data model. The following are Data Model Extensions: they extend the core Ontology to add value. They are not separate data models, and they are not axes of the Ontology.

Inventory

Inventory consolidates the enterprise’s complete asset inventory. An Asset is any real thing the enterprise needs to track — a service, infrastructure, a license, or anything else that belongs in the inventory.

An Asset belongs to one or more Applications and/or Platforms. It may also belong to a Domain. An Asset that belongs to a Platform does not inherit ownership through a Business Domain. An Asset may be produced by a Platform, or not; both are valid. Producing every Asset through a Platform is the recommended target, for automation, standardization and security.

An Asset maps to Technology through its Asset Type and one Offering of that same Service. Stack and Service derive from the Asset Type. The Provider derives from the Offering.

An Asset that belongs to neither the Business axis nor a Platform is handled as an exception to this model.

Contracts

The Contracts extension normalizes the enterprise’s commercial contracts — the agreements with vendors and providers for software, hardware, and services — against the owned configuration. By tying each contract to what it actually covers, it makes real spend visible and optimizable. (Base definition; detailed extension is future work.)

Processes

The Processes extension turns the deterministic process out of operators’ heads into a machine-readable, deterministic process that can be automated and monitored — improving efficiency, time to market, and MTTR. (Base definition; detailed extension is future work.)