We have a meta model the encompasses three business modeling disciplines; information modeling, capability modeling and process modeling. We use this model in our modeling tool, "Nexus Bridge", where we have a version controlled model repository.
All illustrations in this article can be found in a Lucid chart document.
- Abstract entities are grey
- Central entities are blue
- Contract entities are green
- Realization entities are yellow
- Entities that are not implemented yet in Nexus Bridge have dashed lines
- Entity names that are in bold signifies the root entity for a group of entities, i.e. the root owner of all other entities in that group
- A relationship that ends in a diamond (filled or unfilled) signifies that the reference is permanent
- A filled diamond signifies that the entity on the diamond side is the "owner" of the entity on the other side
- Relations with an empty arrow head (triangle) signifies inheritence
- When we mark an entity with
<<X>>, that means that the entity inherits fromX. - In some illustrations we have chosen to include all inherited attributes. To distinguish the inherited attributes from the "real" attributes, the inherited are in italic and the "real" are in bold.
- An hourglass indicates that an item is temporal, e.g. the entity "contect".
Here is an illustration with a selection of the most significant entities in our entity model.
Abstract core entities
We have two abstract core entities that we base our entities on.
Model object
All our entities inherits from model object. This means that all our meta model entities have the following attributes:
- id to uniquely identify an instance
- description; a written description about the entity
- lock state, one of "unlocked", "partially locked" and "locked"
Example: The entity CentralEnumeration is the owner of the entity CentralEnumerationValue, which means that an enumeration can have a list of enumeration values.
For lock state to have a meaning, there has to be one entity that has the ability to lock all entities under it. Such entities are recognized by having two specific attributes, major version and minor version. The initial values are "1" and "0", i.e. version "1.0". We will call those entities top entities for now.
The top entity can be locked, which means that it and all its descendants get lock state "locked. The locked entities can no longer be updated, but it is still possible to add new descendents. When a new descendent is added it will be marked as "unlocked" and all its ancestors will be marked as "partially locked" and the minor version will be increased with 1. The new, unlocked entities can be modified until the top entity, which now is marked as "partially locked" is locked again.
A locked top entity can have its major version bumped, i.e. increased with 1. When that happens it and all its descendent entities are marked as "unlocked".
Examples of such top objects in our model: Event and Contract
Named object
The absolute majority of the meta model entities inherits from named object. These entities have a name that must be unique within their owner entity.
Example: In the example above, the enumeration values must each have a name that is unique within their enumeration.
Abstract value entities
There are a number of abstract entities that are related to values. We introduce the abstract entity value bearer and two abstract entities that inherits from value bearer; parameter and attribute. We will also introduce two abstract entities that are referenced by the value bearer; enumeration and attribute collection. As we introduce enumeration, it is natural to also introduce enumeration value.
Value bearer
Entities that represents a value, such as attributes and parameters inherits from value bearer. A value bearer has the following attributes
- logic type, the type for the value, e.g. "integer" or "entity reference"
- collection type, is this a collection of values and what type of collection in that case, e.g. "none" or "ordered list"
- temporal, true if the value is temporal
If the logic type is "entity reference" or "attribute collection", then the value bearer entity has a reference to an attribute collection entity. If the logic type is "enumeration", is has a reference to an enumeration entity.
A value bearer is considered temporal if the value is associated with a specific time span, limited by a start time and an end time. For an implementation this could mean that we save a ValidFromTime and a ValidToTime with the value and that we will provide a way to get the value that was valid for a specific time.
An example of a temporal value bearer would be the marital status for a person, but only if we need to keep track of historical values.
Attribute collection
An attribute collection is a collection of attribute, that is the base for both entity and event.
Attributes have sort order that decides the order of he attributes.
Function parameters
A function has a collection of parameter, e.g. ContractEntityMethod and FunctionInParameter.
Function parameters have sort order that decides the position for each parameter.
Enumerations
An enumeration is a collection of enumeration value, e.g. CentralEnumeration and CentralEnumerationValue.
Enumeration values have sort order that decides the sort order for the values.
An example of an enumeration could be "Car body style" that could have the values "Sedan", "Coupe", "Cabriolet", etc.
Entity and relationship
Entity
An entity is a collection of entity attribute.
Entity has the following attributes:
- abstract; true if the entity is abstract
- plural name; the plural form of the name of the entity
An entity can inherit from another entity.
When an entity inherits from another entity, that means that it will be considered to also have all the attributes that the inherited entity has.
Entity attribute has the following attributes:
- primary key; true if the attribute is the primary key for the entity
Relationship
A relationship has two nodes; from node and to node.
Each node has the following attributes:
- name, the name of the relationship seen from the node
- cardinality, one of "0..1", "1", "0..n" and "1..n"
- permanent, true if the node has cardinality "1" and can't be moved to another entity
Inspiration - connections between similar entities
We have introduced a relationship between two entities that we call inspiration .
The relation goes from an inspired entity, which is inspired by an inspiration entity. This requires that they are similar in structure and that the inspired entity copies much of its content from the inspiration entity.
Examples: ContractObject is inspired by CentralObject and ContractObjectAttributeis inspired by CentralObjectAttribute.
All attributes in an inspired entity is initially copied from the inspiration entity. The inspired entity has an attribute, copy when unlocked, which controls if the inspired entity continues to copy the inspiration attributes as long as the inspired object is unlocked.
An inspired entity might want to have complete control over some of the attributes, i.e. modification should not be overwritten by the inspiration entity. An inspired entity has an attribute, deviations, which specifies which attributes that the entity has intentionally modified.
Central entities
The entity central is where we define our total information model, see wikipedia. It consists of enumerations, objects, entities (with their events) and relationships.
Central enumeration
The entities central enumeration and central enumeration value are just the central versions of enumeration and enumeration value.
When a central object or a central entity has an attribute that requires an enumeration, this is where we define that enumeration.
Central object
The entities central object and central object attribute represents attribute collections that are not entities, i.e. a group of attributes with no primary key that is used in central entities and other central objects.
Example: The entity Person can have an attribute with "Legal address". That attribute has the logic type "Attribute collection" and refers to the object named "Address", which inte turn have attributes like "Street", "Zip code", etc.
Central entity and relationship
The entities central entity, central entity attribute and central relationship are just the central versions of entity, entity attribute and relationship.
A central entity can inherit attributes from another central entity.
Event
The entities event and event attribute represent business events.
An event have the following attributes:
- major version, e.g. "1"; increased with 1 every time a breaking change is introduced
- *minor version", e.g. "0"; increased with 1 every time a non-breaking change is introduced
This entity is a so called top entity for lock status, i.e. this is where you control the lock status for all descendent objects.
Contract entities
The entity contract is where we define an API. It consists of enumerations, objects, functions, entities (with their methods) and relationships. The contract entities can be inspired by the central entities, see the inspiration chapter.
A contract has the following attributes:
- major version, e.g. "1"; increased with 1 every time a breaking change is introduced
- *minor version", e.g. "0"; increased with 1 every time a non-breaking change is introduced
- type; one of the following values: "business capability", "technical capability", "service offering" and "system"
We classify the contracts into four types:
- business capability; a business building block with a very stable API, e.g. "invoicing", "warehouse management"
- technical capability; a technical building block with a very stable API, e.g. "authentication", "publish-subscribe"
- service offering, An API that is either temporary, volatile or someone else has power over the requirements. Example: A new service that we want to expose to our customers to increase our competitiveness, a service that a business customer requires from us
- system; a service that a system must implement, e.g. a GDPR API with methods for anonymization and removal of personal information.
All contract entities that has a central counterpart can be inspired by that entity.
Entities in a contract of type "business capability" can only deviate for the attribute friendly name, but the entities in the other contract types can deviate on all attributes.
Contract enumeration
The entities contract enumeration and contract enumeration value are just the contract versions of enumeration and enumeration value.
When a contract object or a contract entity has an attribute that requires an enumeration, this is where we define that enumeration.
This entity is a so called top entity for lock status, i.e. this is where you control the lock status for all descendent objects.
Contract object
The entities contract object and contract object attribute represents attribute collections that are not entities, i.e. a group of attributes with no primary key that is used in contract entities and other contract objects.
Example: The entity Person can have an attribute with "Legal address". That attribute has the logic type "Attribute collection" and refers to the object named "Address", which inte turn have attributes like "Street", "Zip code", etc.
Contract entity
The entities contract entity and contract entity attribute are the contract versions of entity and entity attribute.
A contract entity can inherit attributes from another contract entity.
Entity methods and contract functions
A contract has a number of functions. If they are connected to an entity, we call them contract entity method and if they are not we call them capability function.
A function has a collection of function in parameter and a collection of function return value.
Realization entities
The entity realization is where we define how we implement the contracts; how do we group the contracts in deployable entities, which source systems do we use to assist us in implementing the contracts, etc.. It consists of contract implementation containers, contract implementations, source systems and event subscriptions.
