Skip to main content

Meta model

The Caplo meta model is the set of reusable element types, relation types, and configurable properties available in your workspace.

You do not need to enable everything on day one. Caplo works best when you start with a small set of types that support the questions you actually want to answer.

Enabled element types​

Caplo entity types are based on ArchiMate, with a few practical Caplo-specific additions such as vendors.

Use Settings > Diagram elements to choose which element types are available in the diagram toolbar and related creation flows. This keeps modeling focused and avoids showing types your team does not use.

Typical starting sets include:

  • Application landscape: Application, Application service, Interface, Data object
  • Business architecture: Capability, Process, Business actor, Business service
  • Transformation planning: Goal, Outcome, Work package
  • Practical extensions: Vendor when supplier context matters

If you need a visual mapping between Caplo and ArchiMate, see Caplo vs. ArchiMate.

Entity types​

Every entity in the Repository has one type. That type controls:

  • How the entity is labeled in the toolbar and Repository
  • Which properties can be shown or edited
  • Which relations make sense during modeling and analysis

Choose the type that best matches the real-world thing you want to reuse. If your team is unsure between two close types, pick the one that helps reporting and diagram reuse most clearly.

Relation types​

Common reusable relation types in Caplo include:

  • Association for a general connection
  • Parent-child for hierarchy
  • Realizes for "this implements or supports that"
  • Accessed by for data or object access
  • Triggers for process or event flow
  • Flows for movement of data, information, or work

Caplo can infer some of these relations for you while modeling on a diagram. When the connection is only explanatory, keep it diagram-only instead of turning it into reusable repository structure.

Hierarchy in Caplo​

Caplo uses Parent-child as its explicit reusable hierarchy relation, but the directional model is broader than that.

Most reusable relation types in Caplo follow one consistent rule: the stored direction goes from the lower, more detailed, or supporting side to the higher, more abstract, or consuming side.

Examples:

  • Child -> Parent
  • Application -> Capability for Realizes
  • Data object -> Application for Accessed by
  • Source application -> Target application for Flows
  • Triggering process -> Triggered process for Triggers

This directional convention matters across the product:

  • The Repository stores the canonical relation direction this way.
  • Same-type nesting in diagrams creates or reuses Parent-child.
  • Some different-type nesting combinations infer another reusable directional relation instead.
  • Graph exploration and reports traverse relations directionally, so top-down and bottom-up produce different results.

If you are only trying to group shapes visually, use a diagram-only grouping approach rather than implying reusable structure.

Association is the least-specific relation type. Use it for a general connection, not when the directional meaning is important.

Entity and relation properties​

Caplo calls configurable metadata properties properties in the product UI.

Use:

  • Settings > Entity properties to configure metadata for entity types
  • Settings > Relation properties to configure metadata for relation types

Good properties are the properties that help your team filter, compare, color, group, or report on the model. Examples include owner, lifecycle, criticality, cost, risk, interface metadata, or review status.

Properties vs. relations

Use a property when you want metadata on one item. Use a relation when you need to explain how two items connect.

Keep it small at first​

If your workspace is new, start with a narrow meta model. It is better to have a small, well-maintained set of element types and properties than a theoretically complete model that nobody uses consistently.