Hitting the ground running with Caminao is meant to be easy as it relies on
a well-founded modeling paradigm (Stanford Symbolic Systems Program) and a solid and well established reference framework (Zachman’s).
Secured by these foundations, teams could carry on with agile and MBSE development models, helped, if and when necessary, by a comprehensive and consistent documentation freely available online.
Symbolic Systems Paradigm
The Stanford Symbolic System Program (SSP) is built on clear and incontrovertible evidence: the purpose of computer systems is to manage the symbolic counterparts (aka surrogates) of business objects and activities. Based on that understanding, enterprise architectures can be wholly and consistently defined by maps (the models) and territories (relevant business objects and activities and their symbolic counterparts in systems).
That paradigm is at the same time straightforward and aligned with the formal distinction between extensional and intensional representations, the former for requirements analysis (descriptive models), the latter for systems design (prescriptive models).
Given its clarity of purpose and concepts, the Zachman Framework is arguably a reference of choice; its core is defined by six columns and five lines, each of them associated with well known concepts:
Yet, the table arrangement comes with some discrepancies:
- Lines mix architectures artifacts (2-4) with contexts (1) and instances (5).
- Columns mix capabilities (1-5) with objectives (6).
While keeping the semantics intact, Caminao rearranges the artifacts lines into 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.
Digital Transformation & The Pagoda Blueprint
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.
Proceed With Agile & MBSE
Once set on track with a reliable paradigm and a clear reference framework, teams can carry on with their choice of development models:
- Agile schemes for business driven applications for which conditions of shared ownership and continuous delivery can be met.
- Phased schemes for architecture developments set across business processes.
Whatever the development methods, the modeling paradigm will put enterprise architecture and projects management on a principled basis, and the framework will significantly enhance their integration.
- What to Expect from a Framework
- Frameworks: How to Avoid Quagmires
- Thread: Enterprise Architecture
- Enterprise Architectures & Separation of Concerns
- Where to Begin with EA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows
- EA: Legacy & Latency
- Ontologies & Enterprise Architecture
- EA Frameworks: Non Negotiable Features
- Enterprise Governance & Knowledge
- Squaring EA Governance
- EA Documentation: Taking Words for Systems
- Governance, Regulations & Risks