Enterprise Vocabularies and Reference Content
An Enterprise Vocabulary is a structured specification of the business concepts relevant to an organisation or project. It defines their meaning, attributes, relationships and applicable constraints, with lifecycle definitions where needed.
The word “vocabulary” has a particular scope in MONJO. It includes the definitions required to model business information consistently, beyond the labels used to name that information.
From reference concepts to local meaning
MONJO's reference content supplies reusable business concepts and classifications. An organisation selects relevant concepts and elaborates them to express its own needs.
For CycleXplore, a reference concept such as Customer offers a starting point. CycleXplore must still decide the boundary of that concept in its rental business, which information it needs, and how customers relate to rental orders.
| Aspect | Reference content | Enterprise Vocabulary |
|---|---|---|
| Scope | Reusable business concepts across contexts | Concepts relevant to the organisation or project |
| Meaning | Shared baseline definitions and relationships | Selected definitions elaborated for a stated context |
| Detail | Reusable reference information | The attributes, constraints and relationships needed locally |
| Terminology | Reference names and identifiers | Suitable local labels, with clear mappings to reference meaning |
| Extension | A baseline for reuse | Additional local types and relationships where required |
A vocabulary can therefore be understood as a selection, specialisation and extension of reference content, expressed according to the Monjo Object Model. Calling it a strict subset would overlook the additional detail and new concepts that an organisation may legitimately introduce.
Foundational classes are available for selection
Classes such as Participant and Engagement organise broad families of business concepts. A particular vocabulary draws on the branches relevant to its scope. Users do not need to activate the entire reference classification to model one capability.
Where a selected subtype has ancestors, the ancestral definitions are retained automatically. For example, selecting Customer retains the applicable Trading Partner and Participant ancestry. Users do not have to separately compose those ancestors, populate them independently, or open a workbook for each one. The system maintains the ancestral context automatically.
Selecting a subtype thus brings its inherited context with it. Selectivity concerns the business concepts the organisation needs; it does not discard the meaning on which those concepts depend.
Start with a useful scope
A vocabulary may cover a whole organisation, a project or a focused capability. Starting with a bounded need makes it easier to review definitions against real work.
For an initial CycleXplore rental-management scope, the team might need Customer, Bicycle and Rental Order definitions, together with the relationships that connect them. Its first scope need not include every concept associated with finance, staffing, marketing or governance.
The Discovery Framework helps identify the required capabilities and data assets, then derive the definitions needed to support them. This creates a reason for including each element and a way to recognise missing requirements.
What an enterprise definition needs to explain
A useful definition answers more than “What shall we call it?”
| Question | CycleXplore example |
|---|---|
| What does it mean? | What business commitment does a Rental Order represent? |
| What is its scope? | Are preliminary rental inquiries included or modeled separately? |
| How is it identified? | Which identifier distinguishes one order from another? |
| Which information belongs to it? | Rental period, collection details and other required attributes |
| How does it relate? | The customer placing it and the bicycles associated with it |
| Which conditions apply? | Required relationships, valid values and relevant business constraints |
| How can it change? | Applicable classifications, states and permitted transitions |
| Who is responsible for its meaning? | The business owner or steward who reviews the definition |
These questions guide composition. They are not a replacement for the construct-specific specifications and templates used for detailed modeling.
Extend the vocabulary when needed
Organisations may add object types and relationship types beyond the reference baseline. An extension is MONJO-conformant when it follows the applicable semantics, rules and constraints of the Object Model.
For instance, CycleXplore may need a concept specific to its rental service that is absent from the selected reference content. It can define that concept using an appropriate MONJO construct and describe its relationships to existing types.
A local extension should make its meaning explicit and preserve the meaning of reference concepts it reuses. A preferred local label can aid communication, but changing a label does not justify silently changing the concept behind it.
Local vocabulary development and contribution to the shared MONJO reference content are separate activities. A useful organisation-specific concept need not become part of the shared baseline before it can serve that organisation.
Check conformance and business adequacy
Two important reviews ask different questions:
- Does the vocabulary use MONJO's constructs correctly? This concerns model conformance.
- Does it describe the organisation accurately and sufficiently? This concerns business adequacy.
Actual records also need to conform to the definitions, and a chosen runtime needs to support the constructs used. A valid model, correct business requirements, conforming data and compatible software are related requirements, each deserving attention.
Specifications establish the modeling rules. Templates, guides, rubrics, examples and validation resources support their consistent application. AI-assisted composition can use those same resources to propose definitions and identify gaps; business owners remain responsible for resolving business meaning.
Definitions and records evolve differently
Adding a new rental order adds instance data. Changing what Rental Order means changes the vocabulary.
Definition changes may affect existing records, reports, integrations and application behavior. They should be reviewed for their impact, including whether existing data needs transformation or additional information. A system's ability to change metadata does not remove the need to manage the consequences.
Vocabularies and scoped semantic views
An Enterprise Vocabulary can support several views. A rental-management view may emphasise customers, rental orders and bicycles. A performance view may use some of the same concepts with measures and reporting relationships.
These views provide context without requiring independent, conflicting definitions of the same concept. Their diagrams and specifications should remain connected to the shared vocabulary.