Caminao & The Zachman Framework

 Preamble

While the Zachman’s framework has a well established (and unparalleled) conceptual standing, its actual imprint on enterprise architects’ practices remains limited. That apparent deficiency could be explained by the limits of its tabulated representation, and disposed of by morphing lines and columns into embedded pentagons.

Architectures Cannot Be Folded Into Tables

Putting aside customary misgivings about principled modeling schemes, two main factors may have hampered the use of the Zachman’s framework:

• Overreach: the universality and potential benefits of its core concepts may have been blurred by a number of additional constructs with specific semantics or limited applicability.
• Format: the tabulated representation with columns and lines prevents a clear description and understanding of the cross relationships between architectures capabilities.

The Caminao framework may help to overcome these obstacles by focusing on Zachman’s core concepts and replacing columns and lines with embedded pentagons.

Unfolding Architectures Maps

Its clarity of purpose is arguably a strong point of the Zachman framework as it can be defined by six columns and five lines. But the arrangement comes with some discrepancies as it mixes architectures artifacts (lines 2-4 and columns 1-5) with contexts, instances, and purposes.

Contrary to the first five columns, each characterizing a capability, the last one is about the objectives to be achieved by the architecture as a whole; hence the need of setting it apart of the primary capabilities which can then be represented by a pentagon.

Regarding the lines, the distinction between scope contexts and business concepts is less contingent on architecture than on business strategy. Moreover, there is a conceptual difference between what can be defined by enterprise architecture and what is defined by the environment (more on that below).

Likewise, platforms and tools technologies are better understood as a homogeneous layer, at least from an enterprise architecture perspective.

Finally, if the bottom line for operational instances falls outside the description of architecture artifacts, it is to support the definition of acceptance tests.

Transparency & Traceability

The primary objective of an EA framework is to provide a comprehensive and consistent cross description of the whole of systems architectures; yet, the benefits of Zachman’s clarity of concepts may be frustrated by the specific formalisms of diagrams used at the junctions between columns and lines.

A geometric representation of clear-cut capabilities and homogeneous layers could do away with proxy diagrams, unveiling a backbone of architecture artifacts unfettered by a medley of modeling notations.

That representation would open the door to built-in transparency and traceability mechanisms across horizontal (capabilities), vertical (layers), and transverse (capabilities and layers) perspectives.

Instead of a cumbersome and ambiguous accumulation of manually defined connectors (‘verify’,’satisfy’, ‘refine’, ‘sub’, ‘trace’, ‘derive’, …), the semantics of most of the dependencies could be unambiguously induced from context.

“Why” & the Business Value Chain

The generalization of digital environments renders obsolete the traditional distinctions between enterprises and their business context, which means that software engineering must be integrated with the design of business processes. That implies a change of perspective for the Zachman’s sixth  (“Why” ) column, with the vertical (architecture) perspective replaced by a horizontal (business value) one,  the “Why” column becoming a line set across enterprise architecture capabilities.  With a pentagonal representation, that line would appear as circling the outer range.

Taking advantage of the built-in traceability mechanisms mentioned above, business processes could be rooted in value chains and designed alongside supporting applications.

Services Oriented Architectures

The integration of business and engineering processes is not necessarily a one-to-one affair as key business functions are meant to be shared across business processes. That objective is best achieved with service oriented architectures (SOA) and a clear distinction between enterprise (for specific business processes) and functional architectures (for shared business functions).

Contrary to the silo perspective of a tabulated representation, using pentagons would help to align functional capabilities with services.

Model Based Systems Engineering

Whatever the assorted labels (based/driven, system/software, development/engineering,…), the basic tenet of model based system engineering (MBSE) is to define engineering processes in terms of artifacts (models or code) transformations.

Given its formal and comprehensive description of systems artifacts, the Zachman’s framework should have provided a sound basis for MBSE. That it didn’t happen is all the more intriguing that MBSE implementations have been mostly limited to the last step of engineering, i.e model-to-code transformations, and could have benefited from a broader methodological basis.

To begin with, given that enterprise level modeling remains a matter of customary practices, there isn’t much contents upstream to feed MBSE with, whatever the representations.

Nonetheless, assuming some enterprise architecture models, tabulated representations will suggest (if not enforce) injective transformations along columns; that may be fine for standalone applications but certainly not for architectures which are supposed to articulate shared assets with specific processes.

That hindrance is eliminated when columns and lines are replaced by pentagons.

That simple transformation significantly improves the transparency of enterprise architectures while bringing a new light on dependencies set across layers and capabilities. As it happens, and not by chance, it neatly fits with the Pagoda architecture blueprint and pave the way to enterprises digital transformation.

THE PAGODA BLUEPRINT & Enterprises Digital Transformation

The generalization of digitical environments bears out the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns. On that account, consequences go well beyond a shallow transformation of business processes and call for an in-depth transformation of enterprise architectures that should put the focus on their capacity to refine business data flows into information assets supporting knowledge management and decision-making:

• Ubiquitous, massive, and unrelentig digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms and the information (previously data) models ensuring the continuity and consistency of systems.
• Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
• A comprehensive and business driven integration of organization and knowldege could then support strategic and operational decision-making at enterprise level.

Such an information backbone set across architecture layers tallies with the Pagoda architecture blueprint well known for its resilience and adaptability in unsettled environments:

That blueprint can be much more than metaphoric: applied to enterprise architectures it would greatly enhance the traceability of transformations induced by digital environments.

Instances, Tests, & Quality

Like the sixth “Why” column, the bottom line for operational instances is not about architectures. But when set on the outer range of pentagons operational instances would point to their role as a basis for “Why” associated tests cases.

Depending on layers these instances could be used for unit, integration, or acceptance tests, either specifically or across capabilities. They could also be used to test the quality of service (QoS).

Metrics

Systems engineering measurements have to take into account three different dimensions:

1. Size and complexity of the problem at hand independently of supporting systems (business requirements).
2. What is expected from supporting systems with regard to business requirements (functional requirements) and quality of service.
3. Constraints on implementation (technical requirements).

On that account, and beside a direct alignment with architecture layers, capabilities can serve as a basis for the computation of Function Points:

• Who: users, user’s entry points, users’ interfaces.
• What: conceptual, logical, and physical models.
• How: business logic, use cases, transactions.
• Where: locations, systems locations, resources configurations
• When: business events, events synchronization, communication architecture

Assessing requirements with regard to capabilities could significantly improve costs/benefits analysis and decision-making.

Scope Contexts & Ontologies

As already noted, Zachman’s lines for scope contexts and business concepts straddle the boundaries between enterprise architectures and business environments which, in any case, are crumbling under digital business flows. Confronted to the merging of systems and environments, enterprise architects have to bring together:

• Comprehensive and consistent descriptions of managed organizations, processes, and systems.
• Partial and conjectural descriptions of external business environments.

Even if models could be used for all kinds of descriptions, they would arguably differ in nature, hence the benefits of stereotyped ontologies encompassing the whole range of descriptions:

• Thesaurus: ontologies covering terms and concepts.
• Document Management: ontologies covering documents with regard to topics.
• Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
• Engineering: ontologies pertaining to the symbolic representation of products and services.

Zachman’s line for scope contexts could then be reinstalled as ontologies, with profiles defined with regard to the nature of the contexts:

• Institutional: Regulatory authority, steady, changes subject to established procedures.
• Professional: Agreed upon between parties, steady, changes subject to established procedures.
• Corporate: Defined by enterprises, changes subject to internal decision-making.
• Social: Defined by usage, volatile, continuous and informal changes.
• Personal: Customary, defined by named individuals (e.g research paper).

Using profiled ontologies to describe scope contexts will help to align knowledge management with EA governance by setting apart ontologies defined externally (e.g regulations), from the ones set through decision-making, strategic (e.g plate-form) or tactical (e.g partnerships).

Further Reading

• Feasibility & Capabilities
• Data Mining & Requirements Analysis
• Focus: Rules & Architecture
• Requirements and Architecture Capabilities
• Tests in Driving seats
• From Processes to Services
• Open Ontologies: From Silos to Architectures
• Ontologies as Productive Assets
• Ontologies & Enterprise Architecture
• Caminao & DoDAF
• Ontologies & Models
• Enterprise Governance & Knowledge
• EA: Work Units & Workflows

External Links

• A Historical Look at Enterprise Architecture with John Zachman
• Sowa John F., John A. Zachman, “Extending and formalizing the framework for information systems architecture”
• Dürer’s Conjuncture (The Guardian)
• The Zachman Framework Evolution
• The Zachman Framework Glossary