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.

Squared Outline: Activity

As far as modeling is concerned a distinction has to be maintained between the symbolic description of activities and the processes describing their actual execution.

Given that distinction, the objective is to align action semantics with the constraints of their execution:

  1. Action on symbolic representations without coupling with the context (no change).
  2. Action on symbolic representations with coupling with context (change in expectations).
  3. Interaction with actual context without direct coupling (change in process status).
  4. Interaction with actual context with direct coupling  (change in objects).

That taxonomy can then be applied to map use cases semantics to architecture capabilities.

Squared Outline: Time-frames

Time-frames are defined by root events and therefore best defined along the same guideline, namely their scope and the nature of coupling. 

Along that understanding, time-frames can be defined with regard to context (symbolic or actual) and coupling (asynchronous or synchronous):

  1. Symbolic, no coupling: time-frames set by internal events, involving a single actor.
  2. Symbolic, coupling: time-frames set by external events, involving a single actor.
  3. Actual, asynchronous: time-frames set by external events, involving different actors without real-time constraint.
  4. Actual, synchronous: time-frames set by external events, involving different actors with real-time constraint.

That taxonomy could be used to align time-frames with processes‘ execution mode.

2019: Hit The Caminao Ground Running

Hitting the ground running with Caminao is meant to be easy as it relies on
a well-founded modeling paradigm (Stanford Symbolic Systems Program) and a solid and well established reference framework (Zachman’s).

Moving On (Moises Levy)

Secured by these foundations, teams could carry on with agile and MBSE development models, helped, if and when necessary, by a comprehensive and consistent documentation freely available online.

Symbolic Systems Paradigm

The Stanford Symbolic System Program (SSP) is built on clear and incontrovertible evidence: the purpose of computer systems is to manage the symbolic counterparts (aka surrogates) of business objects and activities. Based on that understanding, enterprise architectures can be wholly and consistently defined by maps (the models) and territories (relevant business objects and activities and their symbolic counterparts in systems).

A formal as well as pragmatic understanding of Enterprises and Systems

That paradigm is at the same time straightforward and aligned with the formal distinction between extensional and intensional representations, the former for requirements analysis (descriptive models), the latter for systems design (prescriptive models).

Zachman’s Framework

Given its clarity of purpose and concepts, the Zachman Framework is arguably a reference of choice; its core is defined by six columns and five lines, each of them associated with well known concepts:

A clear and compact set of unambiguous concepts encompassing the whole of enterprise architecture.

Yet, the table arrangement comes with some discrepancies:

  • Lines mix architectures artifacts (2-4) with contexts (1) and instances (5).
  • Columns mix capabilities (1-5) with objectives (6).

While keeping the semantics intact, Caminao rearranges the artifacts lines into pentagons:

Changing the format opens the door to enterprise architecture capabilities

That simple transformation significantly improves the transparency of enterprise architectures while bringing a new light on dependencies set across layers and capabilities. As it happens, and not by chance, it neatly fits with the Pagoda architecture blueprint.

Digital Transformation & The Pagoda Blueprint

The generalization of digitical environments vindicates the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns. On that account, consequences go well beyond a shallow transformation of business processes and call for an in-depth transformation of enterprise architectures that should put the focus on their capacity to refine business data flows into information assets supporting knowledge management and decision-making:

  • Ubiquitous, massive, and unrelentig digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms and the information (previously data) models ensuring the continuity and consistency of systems.  
  • Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
  • A comprehensive and business driven integration of organization and knowldege could then support strategic and operational decision-making at enterprise level.

Such an information backbone set across architecture layers tallies with the Pagoda architecture blueprint well known for its resilience and adaptability in unsettled environments.

The Pagoda blueprint can be much more than a metaphor for Enterprise Arcuitecture

That blueprint can be much more than metaphoric: applied to enterprise architectures it would greatly enhance the traceability of transformations induced by digital environments.

Proceed With Agile & MBSE

Once set on track with a reliable paradigm and a clear reference framework, teams can carry on with their choice of development models:

  • Agile schemes for business driven applications for which conditions of shared ownership and continuous delivery can be met.
  • Phased schemes for architecture developments set across business processes. 

Whatever the development methods, the modeling paradigm will put enterprise architecture and projects management on a principled basis, and the framework will significantly enhance their integration.

FURTHER READING

 

Squared Outline: Events

In line with the Symbolic Systems paradigm, events are best understood in terms of interactions between systems (or enterprises) and the environment they represent (or live off).


Events with regard to nature and coupling

On that account events are to be associated with four kinds of notifications:

  1. Actual (aka non symbolic) changes in the state of objects.
  2. Actual (aka non symbolic) changes in the state of activities.
  3. Changes in the state of expectations (e.g requests/acknowledgments).
  4. Neutral changes in symbolic representations (e.g messages).

That classification is of particular importance for the definition of time which, taking a leaf from Einstein, is the only reason so that events don’t happen at once.

FURTHER READINGS

Squared Outline: Artificial Brains

Artificial intelligence is generally defined in relation with the human ability to figure out situations and solve problems. The term may also put the focus on an hypothetical disembodied artificial brain.

A Human Perspective on Artificial Brains

Taking the brain perspective makes for easier outlining:

  1. Artificial brains can build and process symbolic and non symbolic representations, respectively with semantic and neural networks.
  2. Artificial brains can solve problems applying logic and abstraction or 
    data analytics, respectively to symbolic and non symbolic representations.
  3. Like human ones, artificial brains combine sensory-motor capabilities with purely cognitive ones.
  4. Like human ones, and apart from sensory-motor capabilities, artificial brains support a degree of cognitive plasticity and versatility between symbolic and non symbolic representation and processing.

These generic capabilities are at the root of the wide-ranging and dramatic advances of machine learning.

FURTHER READING

Squared Outline: Ontologies

The upsurge in the scope and performances of artificial brains sometimes brings a new light on human cognition. Semantic layers and knowledge graphs offer a good example of a return to classics, in that case with Greek philosophers’ ontologies.

According to their philosophical origins, ontologies are systematic accounts of existence for whatever can make sense in an universe of discourse. From that starting point four basic observations can be made:

  1. Ontologies are structured set of names denoting symbolic (aka cognitive) representations.
  2. These representations can stand for whatever may be taken into consideration: terms (nothing is represented), ideas (sets of terms), instances of objects or phenomena, categories (sets of instances), documents.
  3. Ontologies are solely dedicated to the validity and internal consistency of the representations.
  4. Ontologies are not contingent on truth (epistemic) status, i.e external consistency. As a corollary,  they are not meant to support emprical purposes.

That makes models a refinement of ontologies as they are meant to be externally consistent and serve a purpose.

FURTHER READING

EXTERNAL LINKS

Frameworks: How to Avoid Quagmires

Preamble

Deciding upon a framework is a choice that bears upon a wide range of enterprise activities and may induce profound transformations in organization and systems. It ensues that the outcome is practically settled at the outset: once on a wrong path the only option is often to cut the losses as soon as possible.

gianni-motti
When the first step settles the issue for the whole journey (Gianni Motti)

As it happens, there is no reason to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.

Taking five, simple litmus tests can be used to avert overhasty moves into quagmires. Compared to a comprehensive assessment, the objective would only be to establish a shortlist of frameworks worth of a further assessment. For that purpose forms (but not substance) are to be considered for the consistency of definitions, the specificity of value propositions, and the reliability of roadmaps.

Consistency of Definitions

Frameworks come with glossaries covering generic, specific, and standard terms in various proportions; the soundness of these glossaries can be assessed independently of their meanings.

For that purpose simple metrics can be applied to a sample of definitions of core concepts, (e.g: agent, role, actor, event, object, activity, process, device, system, architecture, enterprise):

  • Self-contained: terms directly and fully defined, i.e without referring to other glossary terms (c,a,m).
  • Number of references used.
  • Circular references: terms including at least one path to itself (d,e,f)
  • Average length of non-circular references
  • Overlaps (i and j)
  • Conflicts (w by (x><e)

GloGraph
Basic definitions graph (x contradict e)

Even computed on small samples (10 to 50), these metrics should be enough to provide a sound yardstick.

Value Proposition Specifics

Pledges about meeting stakeholder needs, holistic undertaking, or enhanced agility are part and parcel of every pitch; but as declarations of intent they give little information about frameworks.

To be given consideration a framework should also be specific about its value proposition, in particular with regard to its description of enterprise architecture and systems engineering processes.

Assuming that the specificity of a value proposition equals the likelihood of a contrary stance (no framework would purport ignoring business needs or being non agile), general commitments must be supported by schemes meant to make a difference.

Roadmap Reliability

Given what is at stake, adopting a framework should only be considered if it can significantly reduce uncertainty. On that account road-maps built from pre-defined activities are deceptive as they rely on the implicit assumption that things will always be as they are meant to be. So, taking for granted that positive outcomes can never be guaranteed independently of circumstances, a framework reliability is to be assessed through its governance apparatus.

Along that reasoning, key stages, steps, or activities defined by a roadmap should be framed into a clear decision-making processes, e.g the observation, orientation, decision, action (OODA) loop.

A framework reliability could then be judged by its ability to support enterprise architects in assessing situations and picking a course of action.

Further Reading