Workflows & Governance

Preamble

Enterprise architectures are a combination of culture, organization, and systems with a life of their own. It ensues that EA changes cannot be carried out through autonomous projects as they must ensure the continuity, integrity, and consistency of supported activities. On that account phased processes with neatly defined inception and completion are of limited use for large, diversified, and structured organizations. Hence the benefits of setting apart changes pertaining to EA engineering from projects carried out at the system level.

Scope & Purpose

EA engineering should first be defined by scope:

• System level, focused on the consistency and continuity of the representations managed by supporting systems
• Enterprise level, focused on the role of systems in support of business models

and purpose:

• Business value, for requirements rooted in the specifics of business processes as defined directly or through use cases
• Architecture assets, for requirements set across business processes, through models or system cases

Interfaces can then be defined accordingly:

• Business cases (BC), between enterprises and environments
• Use cases (UC), between enterprises and systems, with Agile cases (AC) for stand-alone projects without organizational or technical dependencies (ensuring shared ownership continuous deliveries)
• Function cases (FC), between systems
• Technical cases (TC), within systems

Indicative remits can be added but the specifics are best left to enterprises’ organization.

EA Engineering Workflow

EA engineering workflows must be anchored to model-based backbones; with the Pagoda blueprint such backbones are built on descriptive (DM), prescriptive (PM), and technical (TM) models.

Crossing scope and models determine integration junctures:

• Organizational integration, for the dynamic alignment of descriptive models with changes in business environments
• Functional integration, between enterprise organization and system architecture’s capabilities
• Technical integration, between functional and technical architectures
• Operational integration, for the dynamic alignment of technical models with changes in physical environments

EA workflows combining the Pagoda blueprint with ontologies can ensure the consistency of architectural changes along time and across business, organizational, and technical concerns.

Engineering Threads & the Pagoda Workshops

Engineering Threads

As far as enterprise architectures are concerned, artifacts can be organized around three basic engineering threads:

• Anchors, which attach business entities (surrogates) to their counterpart identified in environments
• Objects, for the representation of business entities (anchors or otherwise) identified at the enterprise or system level
• Aspects, for the semantics and formats of associated features, the former defined at the enterprise level, the latter at the system level

These threads can be associated with broadly defined responsibilities:

• Enterprise architects and business analysts identify anchors and regular business objects depending on the business environment, objectives, and business entities already managed; apart from identity and intrinsic (or structural) properties, no assumption should be made regarding modeling constructs (a).
• Business analysts and systems architects flesh out anchors and associated business objects with aspects using logical connectors, whenever possible (b).
• Systems architects and software engineers proceed with the translation of descriptive models into prescriptive ones, taking into account the structure of descriptive anchors. The detachment of nonstructural aspects and the distinction between logical connectors and semantic ones give them enough latitude for design (c).

EA workflows should then be organized as to ensure the threads’ consistency along inceptions (#) and transformations (+):

• Organizational integration, to ensure the continuity and consistency of business anchors, aspects’ semantics, and business logic (a)
• Functional engineering, pivoting on functional or use cases as black-boxes with regard to descriptive models, and as white-boxes with regard to prescriptive ones (b)
• Technical engineering and Quality of Service, pivoting on system cases as black-boxes with regard to prescriptive models, and as white-boxes with regard to technical ones (c)
• Operational integration, to ensure that technical models and configurations can support the execution of business processes with the expected quality of service (d)

Despite the apparent (and misguiding) sequence, any hint to a waterfall scheme should be be ignored: the engineering of enterprise architectures cannot be neatly fragmented into domains and organization on the one hand, systems on the other hand; it must instead be carried out through iterations and increments. That can be achieved with the Pagoda workshops.

The Pagoda Workshops

Borrowing from production areas in job shop manufacturing processes, EA workflows can be organized along four basic workshops, depending on the nature of transformations:

• Enterprise, for business objectives and organization (descriptive models)
• Domains, for the symbolic representation of business objects and processes (prescriptive models)
• Applications, for the implementation of processes by supporting systems (technical models)
• Systems, for operational resources deployments (configurations)

Between requirements (business environment) and deliveries (physical environment), the Pagoda workflows can thus be defined by paths between workshops and pivots: uses cases, function cases, and system cases.

EA Engineering Pivots

The aim of the Pagoda workflows is to ensure the consistency and continuity of the representations managed by systems. Given the intrinsic cross-dependencies of architectural changes, the priority is to identify pivots, with regard to intensional and extensional perspectives, the former focused on the integration of organizations and systems architectures, the latter on systemic changes in enterprise and environments.

Organizational Pivot

The role of the organizational pivot is to ensure the alignment of organization and supporting systems with regard to structures (anchors and associated objects), processes, and aspects:

• The alignment of activities and structures is achieved using architecture capabilities and organization as a bridge between business processes and descriptive models
• The alignment of aspects’ semantics (meanings) across activities and structures is achieved through thesauruses

Ontologies provide the glue between models, for organization and systems, and thesauruses, for the semantics of business domains.

Functional Pivot

The role of the functional pivot is to ensure the consistency of symbolic representations. It is set by use cases and models:

• Use cases, for the consistency of users expectations with regard to the structure and semantics of business objects as represented by descriptive models
• Models, for the mapping of business objects and processes (descriptive models) into the active and passive system components supporting architecture capabilities for boundaries, control, persistency, and services (prescriptive models)

Ontologies are used to ensure the semantic consistency of business logic across business domains before and after its implementation through shared business functions or services.

Technical Pivot

The The role of the technical pivot is to ensure the consistency of implementations. It put the focus on a black-box view of use and function cases and the mapping of (specific) business processes to (shared) business functions:

• Realization of business-driven use cases by architecture-based system cases
• Feasibility of system cases with regard to platform capabilities as represented by technical models

Contrary to the functional one, the technical integration is homeomorph as it doesn’t entail a structural transformation of functional capabilities into technical ones.

Operational Pivot

The role of the operational pivot is to ensure the alignment of the technical architecture with enterprises physical environment:

• Operations: alignment of platform capabilities with operational constraints (locations and communication, volumes, security, …)
• Quality of service: resources and configurations for the technical architecture considered

The operational pivot should be combined with the organizational one, taking advantage of process mining to enhance feedbacks.

Extensional Perspective: Agility & Sustainability

While the aim of intensional (or engineering) perspective is to secure the integrity of the enterprise architecture, the extensional one puts the focus on its sustainability with regard to potential systemic disruptions from business and/or physical environments. With the Pagoda blueprint, that capacity can be analysed in terms of versatility and plasticity:

Versatility is the ability to adjust processes to shifting environments without inducing systemic changes in architectures. With the Pagoda blueprint it means improving the relevance of descriptive models without increasing the complexity of prescriptive ones. Versatility can thus be maintained when changes can be carried out without affecting architecture anchors, typically:

• Business model: adding new anchors, objects, and aspects without affecting existing ones
• Domain: changes in the structure and semantics of business objects
• Process: changes in aspects’ semantics
• Application: changes in business logic

Plasticity (or flexibility) is the ability to improve architectures without impairing the effectiveness of supported processes. With the Pagoda blueprint it means reducing the complexity of prescriptive models without introducing discrepancies with descriptive ones. That can be achieved through the improvement of architectures capabilities, from components refactoring to system modernization.

That taxonomy of issues can be used to defined EA engineering templates.

EA Engineering Templates

Workshops Layout & Development Models

Overview

Starting with a nondescript situation, a comprehensive EA engineering workflow would encompass the four Pagoda workshops:

• Enterprise workshop: where enterprise architects (EA), system architects (SA) and business analysts (BA) identify business objects and anchors (#) as well as their semantics (descriptive models, aka computation independent models)
• Domains workshop: where business analysts and system architects define the corresponding representations to be managed by systems (prescriptive models, aka platform independent models)
• Application workshop: where business analysts and software engineers (SE) define and develop the corresponding implementations by systems (technical models, aka platform specific models)
• System workshop: where software engineers and process managers (PM) define and manage deployed configurations.

Targeted engineering processes can then be organized according to scope and development models.

Development Models

Crossing scope with development models, four basic profiles can be identified for stand-alone applications free of cross dependencies (a), and Model-based for developments inducing architectural dependencies (b,c,d):

• Application, for self-contained projects developed directly through the application workshop without using intermediate models (a)
• Process, for business applications with overlapping footprint developed from use cases through the application workshop (b)
• Domain, for developments affecting business domains without changes in anchors (c)
• Services, for developments affecting business anchors, domains, and functions (d)

As a complement to scope-based templates, capabilities-based ones can be introduced to deal with legacy projects, from refactoring to modernization.

Projects as Dynamic Trees

Given that EA engineering is meant be carried out continuously, workflows are supposed to bring together projects set along different profiles. That can be achieved with projects managed as dynamic trees, with requirements from processes (or services) as roots, function, use, and system cases as subtrees, and deliverables as leaves. That will enable projects to be explored and developed dynamically depending on the status of nodes:

1. Roots are used to set contexts, business processes, and anchors in descriptive models, before being realized through use cases (downward arrows). They could also be used for the development of services.
2. Use and function cases are first seen as black boxes anchored to prescriptive models before being realized by other use, function, or system cases (downward arrows).
3. System cases are anchored to technical models, and realized by other system cases or implemented as components.
4. Finally, cases’ outcomes are integrated, tested and delivered (upward arrows).

Projects can thus be developed dynamically according to functional and engineering dependencies and the status of work units. For instance:

• A workflow combining three projects, two for use cases (P1, P3), and one for a function case (P2),
• Two functional dependencies, one between system cases (d1), the other between use and function cases (d3)

The first cycle will deal with the left subtree of P1, and the whole of P2, and the second cycle will complete the development and integration of P1 and P3, and introduce an agile project P4 as a tributary to the system case implementing P3.

It must be noted that the mapping between work units and models can be fine-grained and reset dynamically depending on operations (e.g., create, read, update, delete), scope (descriptive, prescriptive, technical), targets (anchor, object, aspect), and status (e.g., planned, current, suspended).

Basic Engineering Workflows

Typical EA workflows can be identified by the workshops concerned and the nature of intermediate documents.

Applications

Objective

Stand-alone business-driven requirements

Specifics

• Source: identified actors within the enterprise
• No intermediates: continuous and direct collaboration between users representatives and software engineers for the duration of the project
• Management: given objective and resources decisions can be made by the project team without external interventions
• Deliveries: contents and schedules can be set by the project team on a continuous basis independently of external constraints

Development model (typically Agile)

A set of activities is carried out iteratively by the project team taking collective responsibility until completion conditions are met.

Use cases

Objective

Business-driven requirements

Specifics

• Source: identified actors within the enterprise
• Intermediates: use and system cases
• Management: organizational, functional, or technical dependencies between use cases, realized, under development, or planned
• Deliveries: defined contents and schedules

Development model

Phased work units identified by use cases.

Functions

Objective

Services or business functions shared across business processes.

Specifics

• Source: organizational units
• Intermediates: function and use cases
• Management: shared
• Deliveries: phased and planned

Development model

Phased and coordinated work units tasked with differentiated activities under differentiated responsibilities.

Modernization Workflows

As noted before, enterprise architecture is a work in progress, and for enterprises immersed in digital environments, change becomes a routine carried out back and forth along the arrow of time: backward by restoring past requirements from opaque legacy code, and forward by developing new capabilities.

Assuming that modernization can be carried out simultaneously in both directions, all developments, legacy or otherwise, should be managed within the same framework combining:

• The wrapping of legacy components into encasings adapted to the new environment, thus enabling the legacy components to be run unmodified
• The refactoring or replacement of legacy components reproducing their functions in the targeted environment
• The development of new applications

Modernization policies can thus be summarily described through four basic patterns:

• Wrapping legacy applications in support of new use cases without affecting function cases or models. Architecture changes are limited to technical models (a).
• Refactoring legacy applications and wrapping functions in support of new use and functions cases. Changes affect technical and prescriptive models (b).
• Refactoring applications and functions but wrapping databases in support of new functional architecture. Changes affect technical and prescriptive models (c).
• Refactoring the whole of functional architecture. Changes affect all EA modeling levels (d).

Modernization can thus be carried out continuously through a dynamic management of workflows combining legacy projects and new developments.

EA Workflows & Governance

The immersion of enterprises into digital environments and the fusing of IT and business value chains put the focus on enterprise architectures’ agility, resilience, and sustainability, and thus on the ways changes can be monitored and dealt with by engineering workflows.

Systemic Changes & Decision-making

Compared to the system (or intensional) perspective considered above, the enterprise one is systemic (or extensional), with changes rooted in environments, directly or through changes in policies affecting business models and/or systems architecture, and their counterpart in organization (business processes and functions) and platforms.

But with digital environments ironing out traditional categories and time frames, the difficulty is to set apart systemic changes from run-of-the-mill ones. To keep track of shifting markets enterprises must gear their decision-making and engineering processes through a loop combining observation, orientation, decision, and action (OODA):

1. Observation: changes in business and digital environments are monitored (and their reliability assessed) at the digital (data mining) or business (business intelligence) level.
2. Orientation: models and Knowledge graphs are used to assess changes with regard to enterprise objectives, organization, and systems.
3. Decision: policies are defined or updated, and commitments are made regarding organization, systems, or platforms.
4. Action: commitments are implemented in terms of processes, functions, or applications.

Decision-making can thus be associated to workshops depending on pivots and the nature of footprints: organizational, technical, and functional:

• Business domains and processes: to align changes in business and information models (a)
• Technical architecture: to align changes in digital environment and platforms (b)
• Functional architecture: to ensure the consistency of changes between domains and applications (c)

That integration of decision-making and engineering processes opens the door to a knowledge-driven EA governance.

Workflows Governance

Enterprise decision-making cannot be reduced to static decision-trees and must integrate collaboration, uncertainties, and time; all the more so considering how digital environments impart information to decision-making processes:

• Data: obtained from environments, through observations (e.g. data mining) or action (e.g.process mining).
• Information: structured data with relevant semantics as managed by systems. Used for orientation.
• Knowledge: information put to use in line with business objectives. Used for decisions.

Wheels of decision-making can thus combine inputs (Data/Information/Knowledge) and drive (Observation/Orientation/Decision/Action):

• Observations are carried out through enterprise and system workshops, the former from environments, the latter from operations. The aim is to process data into predictive, descriptive, and technical models
• Orientation is carried out through enterprise and domains workshops, the former with regard to business objectives, the latter with regard to models
• Decisions are carried out in all workshops: enterprise (business and function cases), domains (objects structures and semantics), applications (use and system cases), and systems (resources and deployments)

That duality is the key to knowledge-based governance.

Governance & Knowledge

The digital revolution introduces a double challenge for enterprise governance:

• It irons out usual milestones of tactical and strategic time frames
• It render obsolete many of the fences between business environment, organization, and systems

To make up for the disruption of traditional decision-making references, enterprises governance must rely on reliable traceability and accountability of their decision-making processes:

• Traceability considers the objective factors and reasoning behind decisions made by systems as well as people and organizational units
• Accountability considers the part played by judgments made by individuals or collective entities

While identifying responsibilities is obviously a governance prerequisite, it turns out to be a challenging endeavour when decision-making processes are supported by systems with Artificial intelligence and Machine learning capabilities. Hence the benefits of built-in mechanisms capable of untangling the threads of reason and judgment running across systems and organization.

That can be achieved with a two-pronged approach, matching the nature of issues:

• Uncertainties regarding observations (Observation)
• Reliability of causal chains (Orientation)
• Risks induced by time lags between commitments and actual execution (Decision)
• Efficiency of execution (Action)

with the way they are worked out: observation (data), reasoning (information), judgment (knowledge).

Finally, that understanding of EA governance can be used to characterize operational, tactical, and strategic decisions:

• Operational, when observed data can be directly mapped to information and put to use as knowledge, thus allowing for routine decision-making .
• Tactical, when partial or imperfect information can be improved with additional data until causal chains are secured. Risks are managed through traceability, and the timing of decisions depends on a cost/benefit assessment of improved traceability.
• Strategic, when unreliable or insufficient relevant facts and doubtful causal chains prevent cost/benefit assessments within the targeted time frame. Whenever such decisions must be taken and changes committed to, risk-management schemes are introduced to cover for ill-fated turns of events.

While operational and tactical decision-making are supposed to be the preserve of systems and business units, the digital transformation is amalgamating the stakes and spreading the hazards — as illustrated by the range of potential consequences of a data breach, from regulatory sanctions for noncompliance to damage to customers’ trust.

Further Reading

• Caminao Framework Overview
• The Pagoda Playbook
• Knowledge Management Booklet
• Knowledgeable Organizations
• How to Pick Development Models
• Products, Projects, Processes
• Projects Have to Liaise
• Phased Yet Lean Processes
• EA Workflows
• EA: Maps & Territories
• EA: Legacy & Latency
• Models Transformation & Agile Development
• Modernization & The Archaeology of Software