[ ^ ^ OsEATools | ^ MetaModel | Overview | Base-principles and requirements | Model-objects | Entities | Relations | Models | Categories ] ( see also: examples, ArchiMate, TOGAF )

---

Metamodel: Categories

A category represents an arbitrary, abstract grouping of entity-types / entities, relation-types / relations and/or model-types / models.

A category-type is a template (‘class’) for a specific type of category.

Within the metamodel, ‘category’ and category-type’ are essentially the same, since all categories are defined as subclasses which may themselves be subclassed into sub-categories.

Category subclasses may be incorporated into the subclass ‘stack’ for any entity-type, relation-type or model-type.

Categories do not in themselves have any active semantic role: they exist solely as a convenience, to support any appropriate classification schema.

The two key features of a category are its label, which can be used as a filter to select subsets of entities, relations or models and/or the respective types; and an optional ‘linkable’ interface for connection of relation-types, which allows a relation-type to connect to an entire category of object-types rather than solely at the level of individual atomic object-type (as is usually the case in existing enterprise-architecture toolsets).

One key categorization schema for architecture entity-types would be the following variant on the Zachman frame:

• ‘row’ category:
  • row 0: ‘Universals‘ – in principle, should never change: core constants to which everything should align – identifies the overall region of interest and the key points of connection shared with enterprise partners and other stakeholders; added for compatibility with ISO-9000 etc
  • row 1: ‘Scope‘ (Zachman: ‘Planner’) – adds possibility of change: core entities in each category, in list form, without relationships - the key ‘items of interest’ for the enterprise
  • row 2: ‘Business‘ (Zachman: ‘Owner’) – adds relationships and dependencies between entities: core entities described in summary-form for business-metrics, including relationships between entities both of the same type (’primitives’) and of different types (’composites’)
  • row 3: ‘System‘ (Zachman: ‘Designer’) – adds attributes to abstract ‘logical’ entities: entities expanded out into implementation-independent designs - includes descriptive attributes
  • row 4: ‘Develop‘ (Zachman: ‘Builder’) – adds details for real-world ‘physical’ design: entities and attributes expanded out into implementation-dependent designs, including additional patterns such as cross-reference tables for ‘many-to-many’ data-relationships
  • row 5: ‘Deploy‘ (Zachman: ‘Sub-contractor’ or ‘Out of Scope’) – adds details of intended future deployment: implementation of designs into actual software, actual business-processes, work-instructions, hardware, networks etc
  • row 6: ‘Operations‘ (Zachman: implied but not described) – adds details of actual usage: specific instances of entities, processes etc, as created, modified, and acted on in real-time operations
• ‘column’ category:
  • What: assets (resources available to the enterprise) of any kind – physical objects, data, links to people, brands, morale, finances, etc
  • Where: locations – in physical space (geography etc), virtual space (IP nodes, http addresses etc), relational space (social networks etc), time and suchlike
  • How: functions - activities to create change, distinct from the agent (machine, software, person etc) that carries out that activity
  • Who: capabilities clustered as roles or ‘actors’ – may be human, machine, software application, etc, and individual or collective
  • When: events and relationships between those events – may be in time, or physical, virtual, human, business-rule trigger or other event
  • Why: decisions, reasons, constraints and other tests which trigger or validate the condition for the ‘reason’ and the like, as in strategy, policy, business-requirements, business-rules, regulations etc.
• ‘type-segment’ category (used for assets, functions, locations, capabilities and events):
  • physical: alienable; tangible objects (‘asset’), mechanical processes and functions, physical or temporal locations, physical events; also align to rule-based skills (‘capability’) and decisions
  • virtual: non-alienable; intangible objects such as data (‘asset’), software processes and functions, logical locations, data-driven events; also align to analytic skills (‘capability’) and decisions
  • relational: ‘two-way’ personal connection: links to people (as indirect ‘asset’), manual processes and functions, social/relational locations, human events; also align to heuristic skills (‘capability’) and decisions
  • aspirational: ‘one-way’ personal connection: principles and values, brands and belonging, morale and self-belief (‘asset’), value-webs and dependencies (‘location’), business-rules (‘event’); also align with principle-based skills (‘capability’) and decisions
  • abstract: additional uncategorised segments such as financial (‘asset’, ‘function’), energy (‘asset’), time (as ‘event’-trigger) etc
• ‘skill-segment’ category (used for capabilities – i.e. competency – and decisions):
  • rule-based: no real skill required, can be implemented via training, or built-in within software or machine function
  • analytic: requires analytic competence and usually some practical experience; may be built into software, but at significant cost
  • heuristic: requires genuine skill and practical experience for context-specific interpretation; autonomous software systems possibly but at high cost and high complexity; IT is usually more effective in a decision-support rather than decision-making role
  • principle-based: requires high degree of skill and ability to cope with inherent uncertainty; not yet feasible to build any IT-based system with this type of capability

In Zachman terms, an architectural ‘primitive’ is an entity-type that has membership of only one sub-category within each of the above classification schemas (i.e. one cell in the set of intersecting row/column/type-segment categories); an architectural ‘composite’ has membership of more than one sub-category in the ‘column’ and/or ‘segment’ categories, but only one sub-category in the ‘row’ category (e.g. a service is a composite of ‘function’ and ‘capability’); whilst an architectural ‘pattern’ may also be a member of more than one ‘row’.

Note that not all architecture entities are covered directly by that schema: for example, real people are intentionally not included (though ‘relational asset’ links to real people are included), and ‘process’ is technically a complex dynamic composite of services (each itself a composite of ‘function’ and ‘capability’, linked in turn to ‘asset’ etc) which itself forms a service.

(Use of a Zachman-like frame should not constrain modeling only to such items as will fit easily into the frame. Nor should model-types necessarily be restricted to single cells within the frame, or categorization of cells determined by the available model-types – both of which arbitrary constraints still occur in many current architecture-toolsets.)

Category-classes may also be included in the ‘stacks’ for relation-types and model-types. For example:

• for relation-types:
  • relation is used in BPMN models
  • relation may / may not traverse framework ‘row’ boundary (e.g. «realizes» or «extends» may cross row-boundary, but «aggregates» cannot)
  • relation uses modal-logic (deontic logic, alethic logic etc)
• for model-types:
  • model is a function/process-model (BPMN, UML ‘Activity’, IDEF0), a data-related model (ERD, UML ‘Class’, IDEF1X) (indicates relation/entity-types that may be included)
  • model is a UML model (indicates family of model-types)
  • model requires strict conformance (model-type must verify and/or enforce semantic correctness of all relations)

It will be useful if the community can build a range of standard categorizations, to optimize the potential for model-interchange between practitioners. But the first requirement is to agree on the structure of the core-metamodel – i.e. the fundamental definitions of the ‘common base-type’ and thence base entity-type, relation-type, model-type and category-type, the implementation of the subclass ‘stack’ for each, and the overall representation in an appropriate file-exchange format – to guarantee at least some level of interchange and interoperability between toolset-users and toolsets.

---

[ OsEATools | MetaModel | Overview | Base-principles and requirements | Model-objects | Entities | Relations | Models | Categories ] ( see also: examples, ArchiMate, TOGAF )