ArchiMate & The Pagoda Blueprint

Blueprints & Languages (Hans Vredeman de Vries)

Preamble

ArchiMate is The Open Group‘s modeling language for enterprise architecture (EA). Endorsed by different tool vendors and consulting firms, it is meant to support enterprise architects in describing, analyzing and visualizing the relationships across architecture dimensions in an unambiguous way, emulating well-established disciplines like civil engineering or building and construction.

Yet, compared to the brick and mortar ones, enterprise architectures are a mix of organization and symbolic and physical components, supposed to change with shifting digital environments. It ensues that the distinction between tools and methods is not as straightforward for enterprise architecture as it is for the physical ones. As a corollary, one cannot expect ArchiMate to come with a built-in neutrality: that’s something that must be thoroughly thought-out beforehand by modellers. The issue can be best dealt with through ArchiMate layers.

ArchiMate Architecture Layers

ArchiMate is more than a modeling language as it comes with an architecture framework made of three core layers and three additional ones.

While the core layers can be aligned with a broadly agreed understanding, that’s not the case when they are combined with the additional ones.

Core Layers

Notwithstanding lexical variations, ArchiMate core layers can be aligned with broadly accepted concepts, as exemplified by the Zachman framework; that makes ArchiMate basic framework an easy match with the Pagoda blueprint:

Archimate Business layer describe enterprises’ structure and behavior in relation with their statutory and business environment. That corresponds to the Pagoda upper level (enterprise organization and architecture capabilities).
Archimate Application layer describe the services provided by information systems. That corresponds to the Pagoda middle level (system functional architecture and capabilities).
Archimate Technology layer describe the infrastructure supporting systems functions and services. That corresponds to the Pagoda lower level (system technical architecture and platform capabilities).

Unfortunately, the architectural consistency of these semantics is being undermined by the extensions.

Additional Layers

In an attempt to take into account broader EA issues, ArchiMate 3.0 has introduced new lines for the modeling of strategies, physical operations, and deployments.

The problem is that the semantics of these extensions are often at odds with architecture layers semantics, therefore subverting the conceptual integrity of the core original layers.

As understood by ArchiMate 3.0, the strategy line encompasses the modeling of environments, business processes, organization, and resources. These concerns cut across the core capability layers in a way that should be expected for views but not for architecture layers.

More significantly, the introduction of a physical layer induces changes in the semantics of the technology layer, changes which then bounce further into the semantics of the application one:

First, the technology layer must be redefined in functional terms independently of physical implementations
Then, the application layer should also be redefined as to take into account the new distinction introduced between functional architecture (disembodied technology), and software (symbolic) and hardware (physical) components.

Beyond the effect on the framework conceptual consistency, the main consequence of the extensions is to introduce implicit architectural biases, and thus impairing the neutrality of the language.

Framework Ecumenism & Language Neutrality

As before with UML, The Open Group has taken a wrong turn with ArchiMate 3.0, turning an articulate if sketchy modeling language into a medley of architecture and system specifications. And both turns have been taken for the same reason: adopting the rationale of tools providers instead of considering the needs of final users.

Frameworks: Layers vs Views

The extension of the original framework introduces a confusion between architecture layers and views: contrary to views, which are driven by users perspectives independently of targeted infrastructures, layers reflect definitive assumptions about architectures’ shared assets and mechanisms.

The turn taken by ArchiMate 3 towards views appears clearly with editing tools which freely mix heterogeneous artifacts across architecture layers. Such flexibility brings clear benefits for tools providers who can thus focus on technical interoperability; but it also passes the buck of semantic interoperability to final users, namely EA modellers; they can do that through architecture frameworks or language semantics.

Enterprise architecture frameworks are meant to ensure a dynamic alignment between changeable business opportunities and sustainable systems capabilities. On that account architecture layers come first and a confusion between layers and views can critically hinders the task of enterprise architects. Enterprise architects should therefore put the focus on ArchiMate core layers, and then carry on with the neutrality of language semantics.

Languages: specificity vs ecumenism

As far as EA is concerned, modeling languages are meant to describe business objects and processes on the one hand, organization and systems on the other hand. To that effect four levels of description can be used:

Lexicons, for the meaning of terms
Syntactic rules, for the configuration of terms independently of their meaning
Semantics, for the meaning of terms configurations
Pragmatics, for the the meaning of configurations used in contexts

Assuming that the neutrality of a language is defined by its capacity to be combined with others, it would be more easily achieved through a clear-cut separation of levels: domain-specific for lexicons, semantics, and pragmatics; ecumenical for syntax. In practice that can be difficult because individual meanings (lexicons) are often affected by configurations (semantics) and usage (pragmatics). Hence the benefits for language neutrality of relying on compact and unambiguous lexicons; and conversely the negative impact of extensions on the interoperability of modeling languages.

ArchiMate for Pagoda Blueprints

Crediting the Pagoda framework and ArchiMate for intended ecumenism, one would expect some natural alignment between the former’s blueprints and the tools implementing the latter. As suggested above, that can be done at the architecture (framework) or semantic (language) level.

Architectural Alignment

Forcing conceptual alignments and trying to coerce requirements semantics into specific boxes is arguably a doomed policy, especially for architectures meant to be shared across domains while continuously adapted to changing environments. Hence the benefits of matching ArchiMate core concepts with enterprise architecture capabilities as defined by the Pagoda blueprint:

Matching ArchiMate Core Concepts to Enterprise Architecture Capabilities

Taking advantage of the commonly agreed semantics typified by design patterns, these architectural concepts can then be translated into system engineering artifacts. But to go further and encompass business models and domains, enterprise architects need more than systems modeling languages.

Semantics Alignment

As noted before, the neutrality, and consequently the interoperability, of a modeling language depends on a clear distinction between linguistic levels: lexicon, syntax, semantics, and pragmatics.

But managing these distinctions, already difficult for the modeling of systems, becomes too much of a challenge at the enterprise level given the semantic overlaps of business domain, organization, and systems. To manage the whole of EA semantic dimensions without compromising their neutrality, modeling languages must be propped up by thesauruses or ontologies.

Thesauruses and ontologies operate at different levels:

Thesauruses deal with two semantic dimensions: the meaning of individual words and the ways these meanings can be combined
Ontologies add a third dimension: the contexts of use and their impact on semantics

In principle, thesauruses can cope with the lexical and semantic levels of descriptions, and ensure the consistency of domains semantics and consequently the conceptual interoperability of modeling languages.

In practice, the protean nature of business semantics are bound to induce exponential complexity for large organizations handling overlapping domains in shifting environments.

Ontological Alignment

Since thesaurus and ontologies can use the same kind of formalism, typically Resource Description Framework (RDF), they often overlap. That’s the case when EA ontologies are represented by semantic networks or conceptual graphs without taking into account the specificity of architectural concepts.

But full ontologies can go further if they use pragmatic levels to deal with contexts and purposes of descriptions. For EA that would enable the integration of built-in architectural concepts. Taking the Caminao kernel as an exemple of EA-driven ontology:

Kernel categories represent sets of objects (actual or symbolic) or phenomena (events or behaviors) identified in environments or systems. They come with standardized semantics which can be refined to target more specific contexts or concerns.
Aspects describe elementary or structured features (attributes, associations, or operations) with standardized semantics; they can be refined depending on the objects or phenomena concerned.
Connectors are syntactic constructs with built-in semantics.

Combined with an EA ontology, ArchiMate could thus ensure semantic interoperability with modeling languages as well as methodological neutrality with regard to architectural options.

ArchiMate & The Pagoda Blueprint

Preamble