DoDAF’s primary objective is to support decision-making regarding key architecture options; for that purpose one need to bring under a single conceptual roof the whole of information associated to enterprise architecture together with all the regulatory and domain specific knowledge pertaining to business and technology environments.
Users, systems, & environments (Irina Nakhova)
That can be achieved through the Caminao’s shift in modeling paradigm combined with a compact set of consolidated concepts whose unambiguous semantics could be aligned with any specific methodology. Beside intrinsic benefits for quality, traceability, and costs, it is to iron out idiosyncrasies between methodologies (for engineering) and ontologies (for environments).
Modeling Paradigm
Caminao paradigm shift is based on a straightforward understanding of computer systems as containers designed to manage symbolic representations (Stanford’s Symbolic Systems Program (SSP)). 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.
Modeling paradigm: a straightforward understanding of computer systems
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), DoDAF-DM2 meta-model (see Annex 2) can only be partially aligned with 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, and setting apart controversies about terms, that understanding is widely accepted and very effective when responsibilities of problems and solutions are to be defined and managed.
Concepts
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 DoDAF Meta-model (DM2) paradigm.
DoDAF’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 circumstances and 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 DoDAF DM2, Caminao’s concepts could help to fill the void.
Capabilities
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 an EA 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.
The role of functional architectures is to map conceptual models to systems 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 (EA: Maps & Territories).
But such alignment of business and architectures concepts should not 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).
Processes & Workflows
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 can be defined across architecture layers 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. With fences crumbling between enterprise systems and business context, phased processes risk to shackle organizational units into a web of hopeless reciprocal commitments. That can only be avoided with workflows carrying out architecture changes on a continuous and consistent basis (EA: Work units & Workflows).
Models, Viewpoints, Ontologies
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.
To begin with, transparency, traceability, and reliability of views could be significantly improved by anchoring models to capabilities (EA: Maps & Territories) at enterprise, systems, and platform level, providing a reasoned basis for the design of composite models and views.
But if DoDAF is to support strategic decision-making across government agencies and industry contractors, views must bring a wide range of semantics under a common conceptual roof; that cannot be achieved without a principled taxonomy of ontologies: depending on the basis of their semantics:
Institutional: mandatory semantics sanctioned by authority
Professional: agreed semantics shared between parties.
Corporate: enterprise defined semantics.
Social: customary semantics observed without specific source or boundary.
Personal: customary semantics used within identified groups of individuals.
Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).
Crossing capabilities (Who,What,How, Where, When) and architectures (enterprise, systems, platforms) with archetypes of ontologies will help to link enterprise architecture workflows with knowledge of business and technical environments; the benefits of a seamless integration between systems engineering and knowledge management can be easily demonstrated for procurement:
Business requirements borrow semantics of from USCIS and FOIA and stereotypes from DoDAF
Functional requirements are submitted to industry providers together with current platforms.
Proposals are compared, modified, and possibly combined.
Procurement with regard to capabilities, architecture layer, and ontologies
Given the shared conceptual backbone, formal syntax for associations and abstractions can be used to define and manage different levels of granularity (model, capability, component, etc) across semantic levels.
Compared to the OMG’s Unified Architecture Framework Profile (UAFP), the distinction between semantics and syntax brings the best of two sides: On users’ side ontological views greatly enhance transparency and modularity for the different users’ categories (business analysts, enterprise architects, knowledge engineers, etc), on technical side (for tools providers) they can be easily translated into meta-models.
Such a framework would bring business and systems descriptions under a shared conceptual canopy (EA: Maps & Territories), and ensure that changes can be managed on a continuous and consistent basis (EA: Work units & Workflows).
Ontologies vs Meta-models: A Proof of Concept
Frameworks are meant to promote consensus and establish clear and well circumscribed common ground; but the whopping range of OMG’s profiles and frameworks doesn’t argue in favor of meta-models. The downsides of that policy are epitomized by the intents enumerated upfront by the OMG / Unified Architecture Framework Profile (UAFP) as they read more like a holiday-maker shopping list than focused and fine-tuned requirements.
Ontologies by contrast are built according to the semantics of domains and concerns. So whereas meta-models have to mix lexical, syntactic, and semantic constructs, ontologies can be built on well delineated layers.
An ontological kernel has been developed as a Proof of Concept of the benefits of ontologies for enterprise architecture, the purpose being to extend the Caminao enterprise architecture paradigm to contexts and environments. That kernel has been built on two principles:
A clear-cut distinction between truth-preserving representation and domain specific semantics.
Profiled ontologies designed according to the nature of contents (concepts, documents, or artifacts), layers (environment, enterprise, systems, platforms), and contexts (institutional, professional, corporate, social.
That provides for a seamless integration of information processing, from data mining to knowledge management and decision making:
Data is first captured through aspects.
Categories are used to process data into information on one hand, design production systems on the other hand.
Concepts serve as bridges to knowledgeable information.
Its Protégé/OWL 2 implementation ensures portability and interoperability. A beta version is available for comments on the Stanford/Protégé portal with the link: Caminao Ontological Kernel (CaKe).
Annex 1: Caminao Concepts
Physical container
Containers introduced to manage actual objects and processes within address spaces or time frames.
Symbolic 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.
System
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.
Message
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.
Role (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).
Event
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.
Activity
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, alignment has to be considered at two levels.
With regard to knowledge architecture:
A distinction should be introduced between activities as logical descriptions (business logic), and processes as the actual execution of activities. Capabilities could then be more effectively defined with regard to processes.
The concept of Agent should be introduced instead of Performer in order todeal more effectively with roles and organizational units.
Conditions could be understood as a special case of rules.
The concept of guidance could be defined with regard to contexts and governance.
Regarding terminologies:
Activity: Symbolic description. Not to be confused with actual execution of activities, aka Processes
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.
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.
Condition: The state of an environment or situation.
Desired Effect: Condition.
Measure: Quantifiable attribute
Measure Type: A category of Measures.
Location: A point or extent in space that may be referred to physically or logically.
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.
Project: A process mixing past, present, and future states.
Vision: A symbolic container for the descriptions of future states.
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.
