Featured

Modeling Symbolic Representations

System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.

Modeling is synchronic: contexts must be mapped to representations (Velazquez, “Las Meninas”).

Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.

This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:

All examples are taken from ancient civilizations in order to put the focus on generic problems of symbolic architectures, disregarding technologies.

Symbolic representation: a primer

Original illustrations by Albert (http://www.albertdessinateur.com/) allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.

Requirements in Digital Environments

Symbolic environment (National Gallery, Canberra, Australia).

Preamble

Beyond varying names, requirements have often been classified into four basic categories:

  1. Process requirements deal with organization and business processes independently of the part played by supporting systems.
  2. Application requirements deal with the part played by supporting systems in the realization of processes requirements..
  3. Quality of Service requirements deal with users experience independently of symbolic contents.
  4. Technical requirements deal with the implementation of systems functions independently of users experience.
A customary requirements taxonomy

Yet, regardless of the soundness of these categories, their effectiveness varies with contexts, and contexts have been drastically disrupted with enterprises immersion in digital environments.

Digital Disruption

With the generalization of digital environments and the ensuing intermingling of business processes and IT two established distinctions are losing their grip, first between processes and applications, and then between users and systems.

Before and after digital disruption

For processes, the blurring is to concern non deterministic operations (heuristics, non modal logic, learning, …) that used to be the prerogative of humans but are now commonly carried out by artificial brains set in applications (a), user interface (d), or elsewhere (b). As a corollary, user interfaces are losing their homogeneity, as single systems with established codes of conduct are being replaced by an undefined number of unidentified agents (c, d).

Lest they drive enterprises into dead ends requirements have to map their systems according to the new digital territories. Not surprisingly, that can be best achieved using the symbolic/non symbolic distinction.

Requirements associated with symbolic contents.. Given that symbolic expressions can be reformulated, the granularity of these requirements can always be adjusted as to fall into single domains and therefore under the authority of clearly identified owners or stakeholders.

Requirements not dealing with symbolic contents. Since they cannot be uniquely tied to symbolic flows between systems and business contexts, nothing can be assumed regarding the identity of stakeholders. Yet, as they target systems features and behaviors, they can still be associated with architecture levels: enterprise, functional, technical.

Functional Requirements

As commonly understood, functional requirements cover business concerns and the part supported by systems; as such they can be aligned with enterprise architecture capabilities, symbolic (roles, business entities, business logic), and non symbolic (physical objects and locations, time-frames, events, processes execution).

In order to deal with the blurring induced by digital flows, requirements should ensure the transparency and traceability of interactions:

  • Transparency: users should be continuously aware of the kind of agent in charge behind the screen.
  • Traceability: users should be able to ask for explanations about every outcome.

As noted above, such requirements cannot be circumscribed to users interfaces or even applications as they involve the whole of the knowledge architecture . To that end functional requirements should be organized in relation to enterprise architecture capabilities, and include the necessary extensions for knowledge architecture:

  • When agents/roles assignments remain open requirements should include communication (natural, symbolic, or digital) and cognitive capabilities.
  • Assuming that requirements are not limited to modeled information, the distinction between data, information, and knowledge should be explicit.
  • Likewise for non deterministic reasoning used in business logic.
Functional requirements and Capabilities

Requirements concerning the digital capabilities of entry-points and time-frames of processes execution are to be added in order to associate functional and quality of service requirements.

Non Functional Requirements

Non functional requirements (NFRs) are meant to encompass whatever remain which cannot be tied to symbolic representations.

As should be expected for leftover categories, non functional requirements are by nature a mixed bag of overlapping items straddling the line between systems and applications depending on whether they directly affect users experience (quality of service), or are of the sole concern of architects and engineers (technical requirements).

The heterogeneity of non functional requirements is compounded by the mirror impact of the digital transformation on functional ones when business requirements (e.g high-frequency trading) combine performances with “intelligent” computing (e.g. machine learning capabilities).

Quality of Service and Capabilities

Yet, that is not to say that the distinction is arbitrary; in fact it conveys an implicit policy regarding architecture capabilities: defining elapse time as functional means that high-frequency traders will be supported by their own communication network and workstations, otherwise they will be dependent upon the company technical architecture, managed by a separate organizational unit, governed by its own concerns and policies.

On that account the digital transformation may help to clarify the issue of non functional requirements because all requirements, functional or otherwise can now be framed uniformly and therefore discriminate more easily.

FURTHER READING

Agile Architectures & Digital Backbones

Agility is the ability to react quickly and effectively to changes in environments. Taking cue from people, agility is conditioned by the resilience and plasticity of a backbone and the accuracy and reactivity of sensory motor connections.

Information layer (George Drivas)

On that account, the digital transformation of enterprise architectures calls into question the relevance of a flat information layer, and more generally of the traditional distinction between business and IT systems.

VALUE CHAINS & Digital Flows

To begin with connections, the generalization of digital flows is to affect the meaning of value chains, a concept introduced by Porter in 1985 as a way to chart the sequences of activities contributing to the delivery of a valuable product or service to market.

From a digital point of view value chains can be likened to nerves carrying signals between operations and organization; from a business point of view they are meant to track down the path of added value across contributing resources and assets.

But digital transformation and the ensuing pervasiveness of software components in business processes blur the boundaries between primary and supporting activities, calling for a redefinition of the relationships between business processes and supporting systems.

In return, the generalization of homogeneous digital flows within and without enterprises could also support the exchange of combined actual and symbolic contents between business environment and operations; hence the benefits of redefining supporting activities in terms of generic capabilities binding systems to enterprises organization:

  • Who could use the systems: interfaces, security, confidentiality, numbers, latency, synchronization, …
  • What kind of objects could be managed: storage, volumes, encryption, …
  • How activities could be supported: representation, and management of business logic.
  • When processes could be executed: events, control, orchestration, choreography…
  • Where processes could be executed : locations, assets, communication channels.
Redefining supporting activities in terms of enterprise architecture capabilities

The immediate benefit of that shift is to bring transparency to the overlaps between business processes and supporting systems. Concomitantly, it paves the way to a tighter integration of enterprise systems and knowledge architectures.

Information Layer vs Digital Backbone

Using digital flows to anchor business processes to architecture capabilities makes redundant the indiscriminate information layer often introduced between business and applications ones. Instead, a digital backbone can be set across the whole of enterprise architectures, with conceptual, logical, and digital data descriptions aligned respectively with computation independent, platform independent, and platform specific models.

A digital backbone instead of an information: layer

The alignment of architecture layers with differentiated information processing capabilities is to become a critical asset for enterprises immersed in digital environment. To deal with changes and competitors enterprises have to combine long-term objectives relative to their business environment with direct observations from the digital one. That cannot be achieved without a distinctive management of data, information, and knowledge:

  • At digital level data inputs from environments are to be sorted out as observations or managed information, the former to be fed into analytic models, recorded, or deleted, the latter used to update business surrogates in line with systems models.
  • At business level knowledge is managed with thesauruses and semantic graphs; it is at the source of business models and objectives as well as organization, and consequently of the architecture of information systems; knowledge is also updated through analytic tools.

Enterprise architects could then manage changes with regard to business intelligence (business models and observed and managed data) and existing systems, with ontologies securing the semantic interoperability of the different representations.

Combined with the Pagoda architecture blueprint for resilience and plasticity, the digital backbone would provide the spinal chord ensuring enterprise homeostasis.

FURTHER READING

EA: A Common Modeling Roof

To become a discipline enterprise architecture has to contrive some shared modeling paradigm; that can be done from established ones like layers, MVC (Model-View-Controller), MDA (Model Driven Architecture), or the 4+1 views.

A Portable & Inter-operable Roof (Jonas Bendiksen)

Architecture Layers

To begin with, the basic layers of process, data, application, and technology layers can be rearranged as to make data orthogonal to other layers.

Then, Model Driven architecture (MDA) can be used as representative of model based systems engineering (MBSE) approaches:

  • Computation independent models (CIMs) describe organization and business processes independently of the role played by supporting systems.
  • Platform independent models (PIMs) describe the functionalities supported by systems independently of their implementation.
  • Platform specific models (PSMs) describe systems components depending on implementation platforms.

It can also be easily aligned with Zachman framework.

With regard to data bases modeling, there is a large consensus for the conceptual, logical, and physical distinction:

  • Conceptual models describe enterprises organization and business independently of supporting systems.
  • Logical models describe the symbolic objects managed by supporting systems as surrogates of business objects and activities.
  • Physical (nowadays digital) models describe the actual implementation of symbolic surrogates as binary objects.

As for systems functional modeling, the Model-View-Controller (MVC) is arguably the leading pattern whatever the guises:

  • Model: shared and a life-cycle independent of business processes. The continuity and consistency of business objects representation must be guaranteed independently of the applications using them.
  • View: what is not shared with a life-cycle set by user session. The continuity and consistency of representations is managed locally (interactions with external agents or devices independently of targeted applications.
  • Controller: shared with a life-cycle set by a business process. The continuity and consistency of representations is managed independently of the persistency of business objects and interactions with external agents or devices.

Services can be introduced to represent functions to be shared with no life-cycle.

Architecture engineering

Finally, the relationships between architecture blueprints and systems engineering can be derived from Philippe Kruchten’s “4+1”: View Model of Software Architecture”:

  • Logical view: design of software artifacts.
  • Process view: execution of activities.
  • Deployment (aka physical) view: mapping of software components across physical environments (platforms).
  • Development (aka implementation) view:  organization of software artifacts in development environments.

A fifth view being added for use cases describing interactions between systems and environments.

At first, views at enterprise architecture level appear to be congruent with these ones, e.g: logical for data, process for applications, physical for technology. But labels may be misguiding when applied indifferently to software architecture (views) and enterprise architecture (layers): contrary to views, which are solely defined by concerns independently of targeted structures, layers reflect definitive assumptions about architectures. That confusion between views and layers, illustrated by a miscellany of tabular and pyramidal representations, would be of little consequence were the modeling of changes not a critical issue; not so for enterprise architecture.

As it happens the confusion can be worked out if views are redefined solely and comprehensibly in terms of engineering:

  • Domains modeling: conceptual, logical, and physical.
  • Applications development: business logic, systems functions, programs.
  • Systems deployment: locations, processes, configurations.
  • Enterprise organisation and operations.

That make views congruent with engineering workshops, enabling a seamless integration of enterprise architecture blueprints with evolutionary processes.

FURTHER READING

System vs Enterprise Transformation

Preamble

Compared to brick and mortar ones, enterprise architectures come with two critical extensions, one for their ability to change, the other for the intertwine of material and symbolic components.

Problems & Solution Spaces (Inci Eviner)

On that account the standard systems modeling paradigm is to fall short when enterprise changes are to be carried out in digital environments.

Problems & Solutions

Whatever the target (from concrete edifices to abstract polities), models come first in architect’s toolbox. Applied to enterprise architectures, models have to fathom different kinds of elements: physical (hardware), logical (software), human (organization), or conceptual (business).

From that point, what characterizes enterprise architectures is the mingling of physical and symbolic components, and their intrinsic evolutionary nature; problems and solutions have to be refined accordingly.

With regard to time and the ability to change, problems and solutions are defined by specific and changing contexts on one hand, shared and stable capabilities on the other hand. As for symbolic components, a level of indirection should be introduced between enterprise and physical spaces:

  • At enterprise level problems are defined by business environment and objectives (aka business model), and solved by organization and activities, to be translated into processes.
  • At system level problems are defined by processes requirements, and solved by objects representation and systems functions.
  • At platform level problems are defined by functional and operational requirements, and solved by applications design and configurations.

Such layered and crossed spaces are to induce two categories of feedback:

  • Between problems and solutions spaces, represented respectively by descriptive and prescriptive models.
  • Between layers and corresponding stakeholders, according to contexts, concerns, and time-frames.

Whereas facilitating that two-pronged approach is to be a primary objective of enterprise architects, the standard modeling paradigm (epitomized by languages like UML or SysML) is floundering up and down: up as it overlooks environments and organizational concerns, down by being overloaded with software concerns.

How to Sort Means (Systems) from Ends (Business)

Extending the system architecture paradigm to enterprise is the cornerstone of enterprise architecture as it provide a principled and integrated governance framework:

  • Business strategic planning: integration of intensional and extensional representations respectively for organisation and systems and business and physical environments.
  • System architecture: integration of portfolio management and projects planning and development combining model based and agile solutions .
  • Business intelligence: integration of strategic operational decision-making.

Bringing representations of environments, organization, and systems under a common conceptual roof is critical because planing and managing changes constitute the alpha and omega of enterprise architecture; and changes in diversified and complex organizations cannot be managed without maps.

The Matter of Change

Compared to systems architectures, change is an intrinsic aspect of enterprises architectures; hence the need for a modeling paradigm to ensure a seamless integration of blueprints and evolutionary processes.

Taking example from urbanism, the objective would be to characterize the changes with regard to scope and dependencies across maps and territories. On that account, the primary distinction should be between changes confined to either territories or maps, and changes affecting both.

Confined changes are meant to occur under the architectural floor, i.e without affecting the mapping of territories:

  • Territories: local changes at enterprise (e.g organisation) or systems (e.g operations) levels not requiring updates of architecture models.
  • Maps: local changes of domains or activities not affecting enterprise or systems elements at architecture level (e.g new features or business rules).

Conversely, changes above architectural floor whether originated in territories or maps are meant to modify the mapping relationship:

  • Changes in business domains (maps) induced by changes in enterprise environments (e.g regulations).
  • Changes in operations (systems) induced by changes in activities (e.g new channels).

That double helix of organizational, physical, and software components on one hand, models and symbolic artifacts on the other hand, is the key to agile architectures and digital transformation.

FURTHER READING

How to Set Off EA Decision-making

Assuming a clear presentation of enterprise architecture, going further to persuade decision-makers to engage with EA implies a shift in the course of the presentation:

  1. Convincing arguments are logical, not visuals.
  2. Expectations are to be met with commitments.
  3. Decisions are best triggered by present and concrete opportunities.
Carpe Diem (Bruno Barbey)

Decision-making is driven by rules

Boxes and arrows may help to understand issues and support decision-making processes, but decisions are more easily triggered by rules than visuals. As far as enterprise architecture is concerned, the rule of the game is the necessary collaboration across enterprise business and systems units.

Expectations Must come with commitments

Visuals presentations help with reasoning and expectations, but decisions are made when problems (expectations) and solutions (commitments) spaces can be aligned. That should be a primary argument for enterprise architecture :

  • At enterprise level problems are defined by business environment and objectives (aka business model), and solved by organization and activities, to be translated into processes.
  • At system level problems are defined by processes requirements, and solved by objects representation and systems functions.
  • At platform level problems are defined by functional and operational requirements, and solved by applications design and configurations.

decisions are best triggered by present and concrete opportunities

Enterprise architecture is a continuous endeavor that can only be carried out through collaboration. As a corollary, decisions are to be made on a piecemeal basis on business driven projects involving architectural decisions, e.g. when business logic has to be factored out and business processes cut to an architecture backbone.

Assuming a common understanding of data models (conceptual, logical, physical), such business process backbones could support pragmatic, gradual, and integrated approaches to enterprise architecture.

FURTHER READING

How to present EA to Decision-makers

Preamble

To be brief and to the point a presentation of enterprise architecture at decision-makers is to follow three principles:

  1. Architecture is visual issue
  2. Schemas should contain between 8 and 12 unrelated concepts.
  3. Semantics should be non ambiguous and specific to the issue. 
(Bridget Riley)

To that end, the focus should present architecture as an activity and its outcome. Applied to enterprise, architecture has to deal with more than actual edifices and contexts, and encompasses business environments and objectives on one side, organization, processes, and assets on the other side. Moreover, enterprise architecture is a continuous and dynamic endeavor because change and exchanges are part and parcel of enterprises life-cycle:

  • At enterprise level, architectures are needed to map organizations and systems to changing environments.
  • At system level, architectures are needed to map changing organizations and processes to supporting systems.

Enterprise architecture can therefore be defined in terms of the maps and territories (outcome), and the management of changes across and between (activity).

Mapping Territories

Compared to its bricks and mortar counterpart, enterprises architecture is a work in progress to be carried out all along enterprises life-cycle; hence the need of maps to figure out their environments, organization, assets, and processes:

  • At enterprise level maps are meant to describe business environments on one hand, concepts, objectives, organization and processes on the other hand.
  • At operational level maps are to describe physical and digital environments on one hand, interfaces and platforms on the other hand.

Then, a third level is introduced in between to describe systems and ensure transparency and consistency with regard to territories.

Enterprise Maps & Territories

For all intents and purposes that ternary view of enterprise architectures holds true independently of labels (layers, levels, tiers, etc), or perspective (business, data, applications, technologies, etc). That genericity appears clearly when maps are aligned with traditional models hierarchy: conceptual, logical and functional, and physical.

managing changes

Taking a leaf from Stafford Beer’s view of enterprises as viable systems, their sustainability depends on a continuous and timely adaptation to their environment; that cannot be achieved without a dynamic alignment of maps and territories; hence the need for enterprise architectures to provide for:

  • Continuous and consistent attachments between identified elements in maps and territories.
  • Transparency and traceability of changes across maps and territories.

Regarding continuity, ill-famed Waterfall epitomizes the detached conception of systems engineering and its implicit assumption that requirements are enough to ensure the alignment of systems with their business environments. To be sure, the plights of Waterfall have already marked a significant rip in the detached paradigm, a rift partially patched by agile development models. But while agile, and more generally iterative schemes, are at their best for business driven application with well defined scope and ownership, they fall short for architecture oriented ones with overlapping footprint and distributed stakeholders; that’s when maps are required.

Regarding transparency, enterprise architecture misconceptions come from mirroring its physical cousin, using geometrical patterns without being specific about their constitutive elements, and consequently the dynamics of interactions.

As it happens, both flaws can be mended by generalizing to systems the well accepted view model of software architecture:

  • Logical view: design of software artifacts.
  • Process view: captures the concurrency and synchronization aspects.
  • Physical view: describes the mapping(s) of software artifacts onto hardware.
  • Development view: describes the static organization of software artifacts in development environments.

One that basis changes in systems architectures would be managed in four workshops, two focused on territories (enterprise and operations) and two on maps (domains and applications).

Mapping changes to Enterprise Architectures

Defining engineering workflows in terms of maps and territories is to provide the foundations of model based systems engineering.

FURTHER READING

Declarative Frameworks & Emerging Architectures

Preamble

Ingrained habits die hard, especially mental ones as they are not weighted down by a mortal envelope. Fear is arguably a primary factor of persistence, if only because being able to repeat something proves that nothing bad has happened before.

Live, Die, Repeat (Philippe de Champaigne)

Procedures epitomize that human leaning as ordered sequences of predefined activities give confidence in proportion to generality. Compounding the deterministic delusion, procedures seem to suspend time, arguably a primary factor of human anxiety.

Procedures are Dead-ends

From hourglasses to T.S. Elliot’s handful, sand materializes human double bind with time, between will of measurement and fear of ephemerality.

Procedures seem to provide a way out of the dilemma by replacing time with prefabricated frames designed to ensure that things can only happen when required. But with extensive and ubiquitous digital technologies dissolving traditional boundaries, enterprises become directly exposed to competitive environments in continuous mutation; that makes deterministic schemes out of kilter:

  • There is no reason to assume the permanence of initial time-frames for the duration of planned procedures.
  • The blending of organizations with supporting systems means that architectural changes cannot be carried out top-down lest the whole be paralyzed by the management overheads induced by cross expectations and commitments.
  • Unfettered digital exchanges between enterprises and their environment, combined with ubiquitous smart bots in business processes, are to require a fine grained management of changes across artefacts.

These shifts call for a complete upturn of paradigm: event driven instead of scheduled, bottom-up instead of top-down, model based instead of activity driven.

Declarative frameworks: Non Deterministic, Model Based, Agile

The procedural/declarative distinction has its origin in the imperative/declarative programming one, the principle being to specify necessary and sufficient conditions instead of defining the sequence of operations, letting programs pick the best options depending on circumstances.

Applying the principle to enterprise architecture can help to get out of a basic conundrum, namely how to manage changes across supporting systems without putting a halt to enterprise activities.

Obviously, the preferred option is to circumscribe changes to well identified business needs, and carry on with the agile development model. But that’s not always possible as cross dependencies (business, organizational, or technical) may induce phasing constraints between engineering tasks.

As notoriously illustrated by Waterfall, procedural (if not bureaucratic) schemes have for long be seen as the only way to deal with phasing constraints; that’s not a necessity: with constraints and conditions defined on artifacts, developments can be governed by their status instead of having to be hard-wired into procedures. That’s precisely what model based development is meant to do.

And since iterative development models are by nature declarative, agile and model-based development schemes may be natural bedfellows.

Epigenetics & Emerging architectures

Given their their immersion in digital environments and the primacy of business intelligence, enterprises can be seen as living organisms using information to keep an edge in competitive environments. On that account homeostasis become a critical factor, to be supported by osmosis, architecture versatility and plasticity, and traditional strategic planning.

Set on a broader perspective, the merging of systems and knowledge architectures on one hand, the pervasive surge of machine learning technologies on the other hand, introduce a new dimension in the exchange of information between enterprises and their environment, making room for emerging architectures.

Using epigenetics as a metaphor of the mechanisms at hand, enterprises would be seen as organisms, systems as organs and cells, and models (including source) as genome coded with the DNA.

According to classical genetics, phenotypes (actual forms and capabilities of organisms) inherit through the copy of genotypes and changes between generations can only be carried out through changes in genotypes. Applied to systems, it would entail that changes would only happen intentionally, after being designed and programmed into the systems supporting enterprise organization and processes.

Enterprises epigenetics and emerging architectures

The Extended Evolutionary Synthesis considers the impact of non coded (aka epigenetic) factors  on the transmission of the genotype between generations. Applying the same principles to systems would introduce new mechanisms:

  • Enterprise organization and their use of supporting systems could be adjusted to changes in environments prior to changes in coded applications.
  • Enterprise architects could use data mining and deep-learning technologies to understand those changes and assess their impact on strategies.
  • Abstractions would be used to consolidate emerging designs with existing architectures.
  • Models would be transformed accordingly.

While applying the epigenetics metaphor to enterprise mutations has obvious limitations, it nonetheless puts a compelling light on two necessary conditions for emerging structures:

  • Non-deterministic mechanisms governing the way changes are activated.
  • A decrypting mechanism between implicit or latent contents (data from digital environments) to explicit ones (information systems).

The first condition is to be met with agile and model based engineering, the second one with deep-learning.

FURTHER READING