Skip to main content

Meta-Model

Matthieu Bonnard avatar
Written by Matthieu Bonnard
Updated over a week ago

Introduction

An enterprise architecture meta-model is an abstract framework that defines the structure, relationships and constraints of the various artefacts that make up your architecture. It provides a standardised language to describe and analyse components of the architecture to ensure consistency and to facilitate communication among stakeholders.

A well-designed meta-model offers a structured framework to define, organise and interpret the different elements and relationships of the architecture.

Kabeen offers a specific meta-model for mapping information systems and their interactions. This meta-model draws from enterprise architecture practices, particularly the business, data, applications and technology layers. The sections below detail the main entities handled in the Kabeen platform and their attributes.

Main Layers of the Kabeen Meta-Model

The Kabeen meta-model is organised similarly to the layers of an enterprise architecture meta-model:

  1. Business and organisation layers: represent the organisational structure and the teams using applications.

  2. Applications layer: describes the software solutions, their functional characteristics and lifecycle.

  3. Data layer: lists the data objects and their attributes (confidentiality, criticality, master role, etc.).

  4. Infrastructure layer: groups the servers, networks used to run the applications.

    These layers are connected via typical dependencies: business processes consume data, applications support business processes, applications access data, and applications run on infrastructure.

Entities and Attributes

Organisational Units

Organisational units represent the hierarchical structure of the company and allow grouping of applications and users by team. A unit may be a group of teams or a department. It can contain sub-groups.

  • Field: Name — the name of the group or unit.

  • Field: Parent Group — allows representation of the hierarchy.

  • Field: Owner — the business owner responsible for quality and updating the application information

Applications

Applications describe the software (SaaS or on-premises) used by teams. They have several tabs covering different aspects (overview, operations, finance, usage, architecture, data).

General attributes include:

  • Name — name of the application.

  • Publisher — the software vendor.

  • Category — functional domain (commerce, HR, marketing, etc.).

  • Criticality — impact of the application (low, medium, high).

  • Type — solution type (SaaS, internal development, hosted).

  • Status — lifecycle status (deployed, phasing-in, phasing-out).

  • Start date (month/year) in production.

  • Owner — person(s) responsible for quality and updating info (up to 5).

  • Description — functional description (e.g., CRM & loyalty, quote & contract management).

  • Functional capabilities — list of functional capabilities covered.

  • Authentication — type (local, SSO…), primary factor (password, smart-card) and secondary factor (MFA).

  • Technologies — list of technologies and their version used to develop the application (e.g., JavaScript ES6, Python 3.0, framework).

  • Schemes & documents — list of associated documents (user manuals, videos, procedures) with title, type and date of addition.

  • Metrics:

    • Health status — overall health indicator (Good, Medium, Poor).

    • Number of users — number of active users in last 30 days.

    • Annual cost — total estimated cost for current year.

Data Objects

Data objects represent sets of data handled by applications (commercial documents, quotes, contacts…). A data catalogue allows identification of information types and their sensitivity levels.

Fields include:

  • Name — name of data object.

  • Domain — functional domain (commerce, HR, finance…).

  • Confidentiality — level of confidentiality (internal, public, restricted, secret, top secret).

  • Criticality — importance of the data (low, medium, high).

  • Particularity — special classification (e.g., personal data).

  • Role — with respect to an application (Master, Reference, Read-only).

  • Owner — person ensuring data quality and update.

  • Description — description of the data contents (e.g., commercial proposals).

Data Flows

Data flows describe the exchanges of data between source and target.

Fields include:

  • Source — originating application of the data.

  • Data objects — list of data objects transmitted.

  • Target — receiving application of the data.

  • Description — description of the data flow.

  • Protocol — protocol used for data exchange.

  • Format — data format during exchange.

  • Frequency — exchange frequency.

  • Port — network port used for data exchange (e.g., TCP 443).

  • Documents — list of associated documents (schema, architecture) to the flow (up to 5).

Infrastructures & Technologies

Servers

Servers represent physical or virtual machines hosting applications. Fields:

  • Name — server name (e.g., CNS-SRV-ODOO-WEB01).

  • Role type — main role: application, directory, database, security, etc.

  • Criticality — level of criticality linked to applications on the server.

  • IP address — assigned IP to the server.

  • Location — physical site, data centre, cloud provider.

  • Operating system — installed OS (Windows, Linux…).

  • Manufacturer — virtualisation platform or vendor (VMware, Hyper-V…).

  • Hosted applications — list of applications deployed with number of users.

Networks

Networks group sub-networks (DMZ, LAN, data centre…) and describe addressing and connected devices. Fields:

  • Name — network name (e.g., CNS-OVH-SRV).

  • Role — network type (DMZ, local network, data centre network).

  • Address (CIDR) — e.g., 10.200.0.0/16.

  • VLAN ID — optional VLAN identifier.

  • Firewall — indicates whether a firewall is active on this network.

  • Attached servers — list of servers belonging to this network with their IPs.

Conclusion

The structuring of information in Kabeen through a coherent meta-model draws from enterprise architecture best practices. By providing well-defined entities and explicit relationships, the platform enables systematic documentation and analysis of your information system. This approach offers a common language for all stakeholders, supports decision-making and ensures alignment between business objectives and technological solutions.

Did this answer your question?