The Pagoda Playbook

 Enterprise Architecture Fundamentals 

Preamble

Enterprise architecture (EA) practitioners are often frustrated by the gap between their experience and existing frameworks and, as a corollary, by the uncertain benefits, substantial overheads, and steep learning curves of a principled approach to EA. The Pagoda Blueprint can be a game changer, and the playbook should help with that.

Objective

The primary objective of the Pagoda playbook is to support the ecumenism and autonomy of EA practices by establishing clear and reliable directions, milestones, and yardsticks that would ensure:

  • Hitting the ground running on familiar tracks with minimal preliminaries
  • A clear understanding of both operational and strategic issues, backed by pragmatic indicators to monitor achievements
  • A smooth learning curve supported by self-improvement and experience feedback

To that end the approach is driven by two key principles:

  • Seamless integration of assets, tools, methods, and know-how
  • Incremental development of enterprises’ architecture and organizational maturity

Overview

The Pagoda playbook is set along revisited CMMI (Capacity maturity model integration) levels:

  1. Initialization: existing assets, resources, and practices (systems, tools, organizational units, …) are progressively inventoried and matched with core Pagoda blueprint elements (components, models, use cases, …).
  2. Management: inventoried elements are organized with regard to commonly accepted engineering categories, e.g., Zachman’s or ArchiMate’s
  3. Normalization: projects are progressively defined (or refactored) in terms of core Pagoda blueprint categories for use cases and models, and development models, Agile or phased
  4. Assessment: phased projects are refactored and assessed in terms of Model-based engineering processes.
  5. Optimization: engineering processes, Agile or phased, are mapped to business ones, paving the way to EA maturity assessment.

These moves are carried out iteratively within and across Pagoda layers in order to extend the maturity footprint in terms of artifacts, projects, and processes:

  • Horizontal iterations are focused on incremental integration within architecture layers (levels 1,2,3)
  • Vertical iterations are focused on model-based integration of engineering processes (levels 4,5)
Iterative and incremental implementation of the Pagoda framework

The status of each maturity level can be continuously monitored through the ratio of corresponding realizations.

Monitoring the spiralling out EA Maturity Footprint

That iterative and incremental approach to enterprise architecture gives a new and more concrete significance to the assessment of CMMI levels, taking into account the integration of engineering and business processes in relation with enterprise architecture capabilities.

Engineering Processes as glue between Business Processes and Architecture Capabilities

Playbook Levels

1. Initialialization

The aim of the first level is to build incrementally a reasoned (pagoda-like) directory of all items pertaining to enterprise architecture: domains, organization, systems, platforms, and projects. Once inventoried, these elements are mapped to entries in the Pagoda blueprint: requirements, models, use cases, final outcomes.

Organization of a reasoned (Pagoda like) directory of EA

To ensure the continuity with existing organizations and methods roles should remain loosely defined in terms of commonly accepted responsibilities: enterprise architects (EA), business analysts (BA), system architects (SA), software engineers (SE), and project managers (PM).

Like all playbook’s levels, initialialization is meant to be carried out iteratively, in parallel with other levels, progresses being measured by the ratio of elements mapped to core Pagoda entries.

2. Projects Management

The aim of the second level is to align elements defined at the first level (requirements, use cases, models) with established systems architecture artifacts like the ones defined by the Zachman framework or ArchiMate.

Using ArchiMate as a reference

Iterations at the Playbook second level are framed by the advances achieved at the first level; the aim is to divide projects between agile and phased development models, the former for business oriented requirements that can be managed on their own, the latter for developments impacting shared architecture capabilities. The status of the second level can be thus measured by the ratio of sorted projects.

3. Projects Normalization

The third level provides the nexus of actionable EA through the generalization of Model-based systems engineering (MBSE).

To that end phased projects (identified at the second level) are organized as dynamic trees rooted in business processes, with use and function cases as subtrees and system cases as leaves.

How to build MBSE projects

With tasks defined by use cases and work units by changes in models, tree traversal algorithms can be used to monitor achievements and manage projects.

Liaisons are added for Agile projects contingent on the outcomes of phased ones, but phased projects depending on Agile ones must be barred due to Agile’s continuous delivery constraint.

The status of the third level can be measured by the ratio of phased projects designed on that basis.

4. Processes Assessment

The aim of the fourth level is to set engineering processes assessment on a sound and unbiased basis; to that end a double distinction is necessary:

  • Between agile and phased development models, brought about at the second level
  • Between projects and processes, to be carried out at this level

Processes are archetypes of projects organized as sequences of differentiated activities. On that account typical Agile projects can be seen as reduced to a repeated single, if multifaceted, activity. It ensues that such projects, built to meet specific objectives and to be developed independently, can be directly assessed in terms of size, complexity, time and resources, without further reference to processes. Not so for phased projects whose differentiated tasks reflect the complexity of scope and dependencies set across architecture capabilities; hence the benefits of processes.

The objective of the fourth level is thus to match Model-based projects to archetypes of engineering processes defined in terms of:

  • Business, use, function, and system cases for objectives
  • Descriptive, prescriptive, and technical models for intermediate outcomes
  • Applications, functions, and databases, for final outcomes
  • Organizational, functional, and technical patterns
Architectural changes induced by Model-based systems engineering processes

With work units directly associated to changes in models, standardized metrics of models complexity could be used to assess engineering processes.

While the measurement of models’ intrinsic complexity is clearly a challenging endeavour, assessing changes may be more achievable, for instance by applying standardized function points uniformly across models. That would enable a pragmatic assessment of changes in architecture versatility and plasticity:

Versatility (V) is the ability to adjust processes to shifting environments without inducing significant changes to architectures. With regard to EA, it means improving the relevance of descriptive models without increasing the complexity of prescriptive ones.

Plasticity (or flexibility) (P) is the ability to improve architectures without impairing the effectiveness of supported processes. With regard to EA, it means reducing the complexity of prescriptive models without introducing discrepancies with descriptive ones.

The status of the fourth level could thus be measured by the ratio of projects amenable to such assessment.

5. Processes Optimisation

The fifth and final maturity level extends assessment to the whole of engineering and business processes.

With the benefits of model-based engineering processes defined through use, function, and system cases (fourth level), the objective is to organize business processes in terms of architecture functions and services, and then attach cases, and consequently engineering processes, to business processes in a way that could mirror the supporting architecture; Agile developments being used when architecture capabilities are not affected.

Crossing Engineering and Business Processes

The fifth level would ensure a constant mapping of goals (business processes), resources (supporting functions and services), and tasks (engineering processes):

  • Business objectives that can be met rapidly without affecting shared functions or services (=) are circumscribed, and assigned to Agile projects
  • Business objectives cutting across EA capabilities are sorted in relation with their footprint and organized into trees or subtrees of use cases, along decreasing neutrality, with leaves assigned to system cases or Agile projects

The maturity at the fifth level will be measured by the ratio of business processes that can be fully ascribed in terms of Agile and/or phased realizations.

The maturity of the enterprise architecture itself will be measured by the ratio of business processes that can be fully ascribed in terms of function cases.

Environments

Enterprise architecture is a continuous endeavour which has no beginning or end: when enterprises start to think about EA they already have one which, in contrast to systems, cannot be simply deposed and replaced. It ensues that the best playbooks are the ones that can be engaged progressively without entailing significant breaks in enterprises activities, or investment in supporting environment. Regarding the latter, three basic issues should be considered: frameworks, engineering, and knowledge.

Framework

Deciding upon a framework is a choice that bears upon a wide range of issues and may induce profound transformations in organization and systems. Given the stakes, decisions taken upfront would come with many hazards and few safeguards: once in the middle of an architectural quagmire returns could be taxing, if not hopeless. Yet, as demonstrated by the Pagoda playbook, there is no need to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.

Engineering

A major pitfall of introducing EA is the confusion between engineering environments on the one hand, methodologies on the other hand.

EA being by nature destined for large and complex organizations, one can assume a plurality of engineering environments, which thus calls for some ecumenism by EA practitioners. Difficulties arise when methods are blended with development tools, seriously hampering their neutrality, in particular for modeling tools, as illustrated by the use of ArchiMate.

Engagement in the Pagoda playbook should thus aim at a neutral employ of existing engineering environments independently of methods.

Knowledge

The Pagoda playbook can be aligned with a knowledge engineering framework organized in terms of:

  • Data (facts), from direct observations or as a product of data factories, can be neatly separated from information managed by systems — a necessary condition for compliance with privacy regulations.
  • Information (categories), for the subset of data that fits within the categories pertaining to business objectives (e.g., customers, accounts), can be continuously and consistently managed as systems surrogates.
  • Knowledge (concepts), for individual or collective skills and expertise, can be explicitly represented in conceptual models, Knowledge graphs or ontologies. 
Knowledge-based System Engineering

Cross interfaces provide shallow access to all resources according to names (thesauruses), structure (XML), and purpose (RDF):

  • Thesauruses ensure access to the semantics attached to names
  • Resources Description Framework (RDF) are the Swiss Army Knife of graph-based representation of symbolic contents
  • Extensible Markup Language (XML) is the Swiss Army Knife for the representation of documents structure, ensuring the storing, transmitting, and reconstructing of arbitrary contents independently of their meaning

These interfaces give access to symbolic artifacts independently of purposes and semantics.

Dedicated interfaces allow deep access to symbolic artifacts according to purpose and semantics:

  • Data files: JSON
  • Data/Facts: SQL (datasets), statistical series (SAS, MATLAB, SPS), references (NIEM), Object-oriented analysis (ORM, NIAM)
  • Information/Categories: general (UML) and specialised (Archimate, SysML, BPMN) modeling languages and methods (OOD)
  • Knowledge and concepts: ontology (OWL) and logic (Prolog) languages

The primary objective of the engagement in the Pagoda playbook is thus to integrate the different sources of knowledge. Then, tools like knowledge graphs and ontologies should be used to set up a self-reinforcing knowledge architecture weaving together observations (environments), reasoning (systems), and judgments (organization).

Further Reading

%d bloggers like this: