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.

Facts, Categories, Concepts

The whole of enterprises’ endeavors and behaviors cannot be coerced into models lest they inhibit their ability to navigate ill defined and shifting business environments. Enterprises immersion in digital environments is making limits all the more explicit:

  • On the environment side, facts, once like manna from heaven ready to be picked and interpreted, have turned into data floods swamping all recognizable models imprints
  • On the symbolic side, concepts, once steadily supported by explicit models and logic, are now emerging like new species from the Big Data primordial soup.

Typically, business analysts are taking the lead on both fronts toting learning machines and waving knowledge graphs. In between system architects have to deal with a two-pronged encroachment on information models.

  • On the one hand they have to build a Chinese wall between private data and managed information to comply with regulations
  • On the other hand they have to feed decision-making processes with accurate and up-to-date observations, and adjust information systems with relevant and actionable concepts.

That brings a new light on the so-called conceptual, logical, and physical “data” models as key components of enterprise architecture:

  • Physical data models are meant to be directly lined up with operations and digital environments
  • Logical models represent the categories managed by information systems and must be up to par with systems functional architecture
  • Conceptual models are meant to represent enterprise knowledge of business domains and objectives, as well as its embodiment in organisation and people.

Logical models (information) appear therefore as an architecture hub linking business facts (data) and concepts (knowledge), ensuring exchanges between environments and representations e.g.:

  • Knowledge analysing data looking for new business categories (a)
  • Knowledge using business categories to build new data sets (b)
  • Data being crossed with business categories to improve knowledge (c)

Taking advantage of the digital transformation, such exchanges can be turned into osmosis between systems and information architectures.

FURTHER READING

Actionable Enterprise Architectures

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 actionable representations of environments, organization, assets, and processes.

As any artifact, actual or symbolic, models must serve some purposes which for systems architectures can be of two kind, descriptive (e.g analysis) or prescriptive (e.g design). Although that distinction often remains implicit at the systems level, it becomes critical at the enterprises level, when business objectives and organization take center stage. Compared to systems modeling, that would induce two key differences:

  • Architecture blueprints: enterprise architecture modeling has to be supported by a built-in distinction between business objectives and systems capabilities.
  • Engineering Processes: the modeling paradigm must ensure the integration of architecture blueprints and architecture changes.

A Taxonomy

Blueprints (models in systems parlance) can be characterized by a combination of targets and purposes:

  • Descriptive models cover all relevant aspects of environments and the ways to deal with them.
  • Prescriptive models aim at managed elements (organization, processes, products, or systems), and how they can be defined, designed, or built.
  • Predictive models add a virtual dimension to actual descriptive and prescriptive ones.

From a formal point of view these distinctions can be expressed in terms of modal logic:

Descriptive representations are meant to provide serviceable models of the business environment; such models are said to be extensional as their objective is to classify observations of objects and phenomena (or extensions) into categories. Actual descriptive (or analysis) models are used to organize the relevant features of domains; virtual ones (or analytic models) are used to extrapolate from actual observations.

Prescriptive representations go the other way as their purpose is to define presumptive artifacts or activities; they are said to be intensional as they denote sets of features meant to be supported by individuals instead of set of individuals. Actual prescriptive (or design) models deal with artifacts to be built, virtual ones with intended objectives or behaviors .

Digital Immersion & Emerging Architectures

Such a formal understanding of models has practical consequences for enterprise architecture as it provides a principled and integrated governance framework:

  • Strategic planning: integration of prescriptive representations between organization and systems, and of descriptive ones between expectations (business environment) and observations actual environment).
  • Systems engineering: integration of portfolio management and projects planning and development combining model based and agile solutions .
  • Business intelligence: integration of strategic and operational decision-making.

That alignment of systems and knowledge architectures is to be critical for enterprise governance, especially with regard to managing changes in digital environments.

FURTHER READING

EA in the Loops

Enterprise Architects are to jump across loops (Bruce Beasley)

When push comes to shove, deciding on a development process is to decide between instant or delayed returns, namely focusing on users needs with agile development, or taking extended features into consideration and weighting the benefits of reuse against additional costs, e.g.:

  • Designs to be reused as patterns.
  • Profiling configurations.
  • Structuring business process models so that they could be designed as business functions.
  • Formatting business logic for automated code generation.

The intricacies of stakes and decision-making processes can be set forth by applying the Observation-Orientation-Decision-Action (OODA) loop to the four views of changes: enterprise, business domains, business applications, systems:

At enterprise level the loops are triggered by changes in business environments pertaining to business model and objectives. They are supposed to affect different business domains.

  1. Observations: Business opportunities
  2. Orientation: Assessment of business opportunities with regard to business objectives.
  3. Decision: Committing resources to changes in organization and processes
  4. Action: Achieving changes in organization and processes

Changes initiated from business domains can be derived from enterprise level or the result of more specific objectives. They are supposed to affect different applications.

  1. Observations: Business analysis
  2. Orientation: Functional feasibility and assessment of transformation benefits.
  3. Decision: Committing changes in functional architecture.
  4. Action: Development, integration, tests

Changes at application level are initiated by organizational units, business or otherwise. They are supposed to be self-contained.

  1. Observations: Users requirements
  2. Orientation: Engineering feasibility and assessment of development options.
  3. Decision: Choice of a development model.
  4. Action: Development, integration, tests

Changes at system level are initiated by organizational units, including business ones (quality of service). They are supposed to affect different applications.

  1. Observations: Process mining and operational requirements
  2. Orientation: Operational feasibility and assessment of configurations.
  3. Decision: Development model.
  4. Action: Deployment and acceptance.

Given that sizeable companies with differentiated organization and business have to manage these different threads continuously and consistently, old fashioned imperative processes can only lead to paralysis. Hence the need of a declarative approach to EA workflows.

FURTHER READING

About Scales & Times

As far as enterprise architecture is concerned, the issue of scale is fogged by two confusions: one between processes and structures, the other between space and time. That square is at the core of the discipline.

Scaling Time (Tycho Brahe)

The Matter of Time

Even before the digital unfolding of environments, everybody was to agree that business is all about timing; and yet, that critical dimension remains a side issue of most enterprise architecture frameworks, which consequently fail to deal with enterprises ability to change and adapt in competitive environments.

With regard to time, the business perspective is said to be synchronic because it must continuously tally with environments constraints, opportunities, and risks.

By contrast, the engineering perspective is said to be diachronic because once fastened to requirements, developments are supposed to proceed according their own time-span.

Mixing Timescales

For enterprise architects, pairing up business and engineering momentum may look like a Fourier transform that would decompose enterprise architecture into piecemeal capabilities to be adjusted to the flow of business circumstances. But assets being by nature discrete, changes are not easily ironed out and some mechanism is necessary to align business and engineering time-frames, the former set at enterprise level and used to align enterprise architecture capabilities with business objectives, the latter set at system level and used to manage developments.

Agile methodologies solve the problem by assuming continuous deliveries disconnected from external schedules and by folding projects into detached time warps. Along with debatable scaling attempts, definitively non agile procedures are used to carry on with agile projects at system level.

As it happens, the iterative model can be upgraded to architecture level, enabling the linking of business driven changes to systems based ones without breaking agile principles:

  • Projects’ scope, objectives, and invariants are set with regard to enterprise architecture capabilities.
  • Iterations combine requirements analysis, development, and acceptance.
  • Increments and deliverables are defined dynamically contingent on scope and invariants.
  • Exit conditions (aka deliveries) are defined with regard to quality of services and technical requirements.

So-called architecture backlogs could thus be added to coordinate self-contained developments, standalone applications as well as system business functions, e.g. (invariants are in grey):

But the coordination issue remains between architecture backlogs, and adding procedures or committees shouldn’t be an option as it would seriously curb enterprise agility. By contrast, model based solutions are to ensure a constant and consistent adaptation of enterprise architectures to their environment.

FURTHER READINGS

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