Preamble
Objectives
The aim of the Case study series is to illustrate the principles developed in the book Enterprise Architecture Fundamentals through their OWL 2 implementation with the Caminao ontological kernel.
On a general perspective, the workshops will deal with three main issues:
- Scope: how to bring under a common conceptual and pragmatic roof business, organizational, and systems engineering considerations
- Representations: how to ensure a formal, integrated, and ecumenical description of all the aspects concerned
- Interoperability: how an open-source EA ontology can enable a seamless integration with engineering platforms
With regard to the specificity of enterprise architecture, the light will be put on:
- Drawing the line between enterprise and system architectural concerns
- Using representative topics to expound modeling alternatives
- Linking modeling alternatives to standard design patterns
These issues will be considered with regard to the activities and development of a restaurant, with episodes loosely set across EA workshops:
- Enterprise workshop: organization, business domains and processes, supporting- systems interfaces, locations, and communication channels
- Domains workshop: symbolic representation of business objects and rules
- Applications workshop: development of systems functions business applications
- Systems workshop: operations and deployments
The case study will be carried out as an open workshop using the OWL 2 / Protégé implementation of the Caminao kernel. Preliminary versions of the kernel itself (Cake 2.0) and the case study (A Diner in bOwls) can be consulted on the Protégé portal.
This opening episode is focused on inventories and meant to serve as a pilot for the whole series.
Outline
As far as information systems are concerned, EA requirements should first decide what is to be represented (aka surrogates), and why; and then determine which subset is already represented by supporting systems.
Inventories provide a smooth learning curve to modeling issues, starting with the representation of physical items and the necessary distinction between what can be known from the environment, and what must be managed by the enterprise.
Models: Products & References
Models are symbolic representations of environments and managed objects and activities with regard to given objectives. The primary objective is therefore to draw a line between relevant categories and irrelevant ones. That task can be illustrated with inventories in a restaurant pantry.
In theory there are two basic modeling approaches: (a) the modeling of conceptual hierarchies with inventories defined as features or, (b) the modeling of inventories with references to externally defined conceptual hierarchies. In practice the first (conceptual) approach would tie the enterprise information architecture to an external reference system, or compel the enterprise to define and maintain its own conceptual model in line with the ones set in the environment.
Categories
To begin with, management will want to know the contents of the diner’s pantry without being too specific about the details of inventories. To that end an enterprise architecture pattern (≈) is introduced to deal with management issues independently of the nature and use of the elements considered. Typically, such a pattern for products references should include name, code, what pertains to shelf life, and the quantities at hand.
The aim of enterprise ontologies is not to describe the world but to manage what enterprises must know about it.
Types & Instances
Taking into account the kinds of food, actual inventory items can be managed, and therefore represented, at different levels, depending on accounting rules:
- Fungible items, like oil or butter
- Batches of unidentified items, like eggs, cheeses, or poultry.
- Items identified individually as to ensure traceability, for example pieces of beef (regulatory context) or pricey bottles of wine (accountability).
Include connectors are used when homogeneous identification mechanism is not necessary (composition) or cannot be established.
Inventory items can be managed wholesale and locally (e.g., cheeses or average wines) at the enterprise level, or specifically (e.g., specific wines, cheeses, or poultry), with references to external information (e.g., nutrients).
Compared to unidentified items, the representation of identified ones raises the issue of the identity principle, and more specifically of identities set externally.
Taking quarter beefs for exemple, three options can be considered:
- Unidentified items: collections (QuarterBeefs) representing homogeneous sets of specific yet unidentified quarter beefs (e.g., sirloin, rib)
- Locally identified items: specific quarter beefs identified at the enterprise level managed individually (e.g., qBeef:Round214564, qBeef:Round214565) or through collections
- Externally identified items: quarter beefs identified in line with external regulations, ensuring their traceability (mapTerrit_) to providers (e.g., qBeef:Rib025)
It must be noted that these options can be combined, e.g., bottles of wines Grand Cru could be also identified externally by vineries.
That elementary analysis of inventories representation put light on the different modeling options that must be considered upfront regarding individuals and their identification. The role of enterprise architects is to define templates that will ensure the consistency of choices across models and along time.
Templates & Meta-models
Meta-models are models of models: instead of representing relevant individuals in environment, they represent relevant categories in models. For enterprise architects relevance should be primarily about identification mechanisms:
- System or process: identities are used to manage representations; for instance batches of poultry with regard to expiry dates.
- Enterprise or organization: identities are used to manage business objects; for instance pricey bottles of wine.
- Environment: identities are used to align business objects with their external counterpart; for instance quarter beefs.
These distinctions are more easily managed through templates & meta-models:
Templates are generic types introduced to manage inherited aspects independently of context of use. Profiles are for descriptive models, patterns for prescriptive ones
Associations between models and meta-models are achieved using:
- mapTerrit_ connectors, between enterprise and external objects representations, e.g., inventory items (symbolic objects) for quarter Beefs would be mapped to their physical counterpart identified through the supply chain
- realization_ connectors, between enterprise actual or symbolic objects or artifacts
Assuming that compliance with food regulations are managed through a dedicated pattern (FoodRegulationCompliance≈), a profile is used for the domain (FoodRegulationsCompliance≈), mapped to the US Food Safety Regulations external regulations.
In order to ease the reading of diagrams a postfix “≈”is added to the name of templates.
See more about Domains.
Variants: Partitions & Powertypes
Models are meant to deal with complexity, namely the representation of variants. But variants, and therefore complexity, is not intrinsic but is determined by concerns or purposes: as far as bottle style is concerned, the complexity of wines could be reduced to two variants for sloping and high shoulders; no doubt that sommeliers would scale their complexity on a different order of magnitude. The first step is therefore to list relevant partitions with regard to their nature, values, and associated features:
First, the nature of partitions:
- Structural partitions are set once and for all; e.g., wines’ grape or poultry type.
- Phased partitions are nonstructural, with changes subject to events and sequencing constraints; e.g., the shelf-life of food products.
- Functional partitions reflect the roles of targeted objects; e.g., how food products are employed in diet or gourmet dishes.
- Analytical partitions are nonstructural ones defined on the value of individual features (data) independently of states and roles; e.g., wines’ customers’ segments.
In line with the ecumenism and adaptability objectives, variants can be represented differently at the ontological level depending on what is known about their nature, and/or their representation at the modeling level; three basic connectors can be used:
- sortedBy_ connectors, between types and partitions
- subsets_ connectors, between structural variants
- extendedBy_ connectors, between functional variants
Partitions can serve a basis for the analysis of variants, starting with powertypes with instances representing the options, e.g., wine regions and grapes:
Finally, the discriminant features valued uniformly within entries.
See more about Powertypes.