Caminao & DoDAF


Compared to DoDAF, Caminao’s ambition is to promote a simple but critical shift in modeling paradigm combined with a compact set of consolidated concepts that could be used as a foundation for any specific methodology.

Requirements (Irina Nakhova)

Beside intrinsic benefits for quality, traceability, and costs across the whole of systems architectures and engineering, it is to iron out idiosyncrasies between methodologies and facilitate their interoperability.

Modeling Paradigm

The Caminao paradigm takes from the Stanford’s Symbolic Systems Program (SSP) and defines computer systems as container designed to manage symbolic representations. The objective of systems modeling is therefore to define the surrogates meant to stand for the objects and behaviors of concerns, together with the processes ensuring the continuity and consistency of changes within and without the systems considered.

That can be formalized with the distinction between extensional (descriptive) and intensional (prescriptive) models.

That simple paradigm is of critical importance for systems modeling: if overlooked, there is no way to specify the nature and timing of information flows governing systems states.


Given its focus on data and information (and overlooking processes), the DoDAF meta-model can only be aligned on a part of Caminao’s scope:

  • Conceptual (enterprise): describe business contexts and concerns on one hand, enterprise organization and objectives on the other hand.
  • Logical (functional): describe the functions supported by systems independently of platforms and technologies.
  • Physical (aka platform): describe the technical implementation of systems functionalities.

Nonetheless, setting apart controversies about terms, that understanding is widely accepted and prove very effective when responsibilities of problems and solutions are to be defined and managed.


Together with its shift in modeling paradigm and standard meta-model, the third pillar of Caminao is a core of well-known concepts with principled and unambiguous semantics (see Annex 1).

Using a reasoned and consistent set of symbols to identify these concepts is an essential part of  the Caminao approach as it simultaneously demonstrates:

  • Its semantic capabilities: the whole range of architecture concerns can be unambiguously expressed through the combination of few iconic constructs.
  • Its versatility: other methodologies like DoDAF can slip into the clothes, play with the attire, and clear up their practice while avoiding the cumbersome management of confusing lexicons and changing translation rules.

Mapping descriptions of data and information should be straightforward as the differences between Caminao and DoDAF meta-models are limited to lexical variants. That’s not the cases for activities because discrepancies are rooted in MoDAF Meta-Model (DM2) paradigm.

MoDAF’s DM2 is founded upon the International Defense Enterprise Architecture Specification (IDEAS), which epitomizes by name and deed the hazards of unbounded abstractions, namely conceptual models lost in generalities unrelated to purposes.

As a consequence of DM2 single sided paradigm (contexts are overlooked), concepts associated with external changes and actual phenomena (i.e time, events and processes) are not deemed to appear at conceptual level, which can only hamper the description of systems external behaviors, in particular the concepts of actors and events.

Regarding the former, the problem can be easily be fixed by refining the notion of performer with reasoned distinctions between:

  • Agents and roles (aka UML’s actors).
  • Individual performers and collective ones: the latter cannot interact with systems.
  • Devices, systems, and persons: the differences are to determine symbolic communication capabilities and social identities.

As for time, events, and processes, since they don’t appear explicitly in MoDAF DM2, Caminao’s concepts could help to fill the void.


Capabilities play a central role for Caminao as well as DoDAF, both as an internal backbone and an external reference to Zachman Framework.

Whereas Caminao is focused on the conceptual/enterprise level, its objective is to bring contexts, enterprises, and systems under a conceptual canopy, namely:

  • How to define the footprint of contexts, objectives and organizations as systems surrogates.
  • How to map these conceptual descriptions to the functional architectures supporting business processes.

Caminao use capabilities to achieve both objectives.

Concepts, functional footprint, and architecture capabilities

At enterprise level systems are part and parcel of business environments, which entails a common semantics for overlapping concepts. Like DoDAF, Caminao is using Zachman’s architecture capabilities to consolidate the conceptual description of business footprint in systems architecture.

But such alignment of business and architectures concepts should be limited to capabilities as there is no reason to assume that the description of platforms components should tally the one of the objects and processes they implement. Hence the benefit of a level of indirection organized around functional archetypes marking the limit of Caminao scope (see Annex 3).


As already noted, DM2 takes a conceptual view of activities, overlooking the way they are executed; that conceptual fault can be mended with Caminao’s processes defined as the actual execution of activities.

Restoring the balance between symbolic (activities) and operational (processes) descriptions puts a new light on the relationship between processes and supporting architectures, and consequently on the nature of capabilities with regard to business, engineering, and operational processes.

Capabilities with regard to business, engineering, and operational processes.

That differentiated approach is all the more necessary given networked business environments, the merging of actual and digital business flows, and the integration of business and software engineering processes.

Models & Viewpoints

Models and views are best understood as documents with or without attached rights (e.g CRUD). DoDAF define more than 50 of them, most with significant overlaps, some even multiple. EDM systems will certainly help to navigate through the maze but their added value is to remain hamstrung by the level of descriptions, in particular for the connections documented manually.

So the transparency, traceability, and reliability of DoDAF models and views could be significantly improved by the use of Caminao tagged artifacts. That could also provide a reasoned basis for the design of composite ones.

P.S. Caminao and OMG’s Unified Architecture Framework (UAF)

The intent of OMG / Unified Architecture Framework Profile (UAFP) is to “provide a Domain Meta-model usable by non UML/SysML tool vendors who may wish to implement the UAF within their own tool and metalanguage.”

But targeting the metalanguages of tools providers implies climbing up the abstraction scale way above the practical concerns of end users, namely the modeling of systems architectures.

Caminao by contrast is built on a clear modeling paradigm focused on the semantics of systems architectures. So whereas UAF has to consider a wide range of lexical and syntactic constructs, Caminao limits itself with the small subset used at architecture level.

That puts UAF and Caminao along orthogonal perspectives, and as a corollary, looking at opposite audiences: tools providers for the former, end users for the latter.

Annex 1: Caminao Concepts

descr110Physical container

Containers introduced to manage actual objects and processes within address spaces or time frames.

descrPackSymbolic container

Containers introduced to manage descriptions (as opposed to instances) under a single authority. For example, organizational units will usually be simultaneously associated to different physical (locations) and symbolic (business objects and processes) containers.


Physical realizations of symbolic containers introduced to manage instances (aka surrogates) of digital objects.

Physical entity

Actual objects (passive or active) with stable (but not necessarily persistent) physical identity. Identities, life-cycle and behaviors are set by the businesses under consideration. Documents, systems, or locations can also be defined as physical entities.

Symbolic object / Information

Representation of identified instances of objects (physical or symbolic), events, or activities. Not to be confused with symbolic physical objects (e.g documents) or digital hybrids (e.g digital signatures). Power-types (²) are used to partition objects.


Information of request identified by a communication; may or may not be kept temporarily or persistently, but never modified.

Person & Organization

Active physical entity with social identity and full communication capability; structured collection of persons.

descr30Role (aka Actor)

Part played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents (physical identity) or associations (static).


Change in the state of business objects, processes, or expectations. Since the execution of  activities is defined by time-frames, they appear as events when start and completion cannot be distinguished.


Functional description of operations and flows (data and control) defined independently of the part played by supporting systems. Equivalent to UML and BPM terms. Activity power-types (², aka branches, aka extension points) are used to partition execution paths.

Execution state (aka mode)

Operational description of activities with regard to processes’ control and execution.

Refined categories can then be defined by crossing primary ones.

Annex 2: DoDAF Conceptual Data Model

Taking into account the extensions mentioned above for time, events, and processes, the alignment doesn’t much further than terminologies.

  1. Activity: Symbolic description. Not to be confused with actual execution of activities, aka Processes
  2. Resource: Left out.
    • Materiel (aka device): active physical object, no social identity, no symbolic communication ability
    • Information: (symbolic description) of state of a something of interest that is materialized — in any medium or form — and communicated or received.
      • Data: (aka transient symbolic description) Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
      • Architectural Description: Container for symbolic (functional) or physical (technical) description.
    • Performer: to be redefined by.
      • Organization: redefined as a symbolic social construct.
      • System: redefined as a functional construct dedicated to the management of symbolic representations.
      • Person Type: roles (aka actor) to be performed by agents (devices, systems, persons).
      • Service: activity described by a request and outcome independently of space and time.
  3. Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities. Regrouped under Zachman taxonomy: who, what, how, where, when.
  4. Condition: The state of an environment or situation.
  5. Desired Effect: Condition.
  6. Measure: Quantifiable attribute
  7. Measure Type: A category of Measures.
  8. Location: A point or extent in space that may be referred to physically or logically.
  9. Guidance: (Left out) An authoritative statement intended to lead or steer the execution of actions.
    • Rule: Condition governing changes in the state of objects, behaviors, or expectations.
      • Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
      • Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
  10. Project: A process mixing past, present, and future states.
  11. Vision: A symbolic container for the descriptions of future states.
  12. Skill: The ability to perform or support.

A special mention must be added for power-types which play a significant role in Caminao while being formally defined by DM2.

Annex 3: Functional Archetypes

Whereas Caminao doesn’t deal with systems design, one of its main objective is to ensure seamless traceability between conceptual and functional descriptions. That can be achieved by using reasoned functional archetypes:

Boundary : local with transient life-cycle.


RT Boundary: analog, local with transient life-cycle.


Passive Control: shared with transient life-cycle.


Active Control: generate events, shared with transient life-cycle.


Entity: shared, with persistent life-cycle.


Service: shared, without (instant) life-cycle.


Message: life-cycle bound to network, no change


Request: life-cycle bound to network, change in state of object, process, or expectation.


Further Reading

Enterprise Architecture

External Links


%d bloggers like this: