Modeling Symbolic Representations

March 16, 2010

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 ( allow for concrete understanding of requirements, avoiding the biases associated with contrived textual descriptions.


2018: Clones vs Octopuses

December 4, 2017

In the footsteps of robots replacing workmen, deep learning bots look to boot out knowledge workers overwhelmed by muddy data.

Cloning Knowledge (Tadeusz Cantor, from “The Dead Class”)

Faced with that , should humans try to learn deeper and faster than clones, or should they learn from octopuses and their smart hands.

Machine Learning & The Economics of Clones

As illustrated by scan-reading AI machines, the spreading of learning AI technology in every nook and cranny introduces something like an exponential multiplier: compared to the power-loom of the Industrial Revolution which substituted machines for workers, deep learning is substituting replicators for machines; and contrary to power looms, there is no physical limitation on the number of smart clones that can be deployed. So, however fast and deep humans can learn, clones are much too prolific: it’s a no-win situation. To get out of that conundrum humans have to put their hand on a competitive edge, e.g some kind of knowledge that cannot be cloned.

Knowledge & Competition

Appraising humans learning sway over machines, one can take from Spinoza’s categories of knowledge with regard to sources:

  1. Senses (views, sounds, smells, touches) or beliefs (as nurtured by the supposed common “sense”). Artificial sensors can compete with human ones, and smart machines are much better if prejudiced beliefs are put into the equation.
  2. Reasoning, i.e the mental processing of symbolic representations. As demonstrated by AlphaGo, machines are bound to fast extend their competitive edge.
  3. Philosophy which is by essence meant to bring together perceptions, intuitions, and symbolic representations. That’s where human intelligence could beat its artificial cousin which is clueless when purposes are needed.

That assessment is bore out by evolution: the absolute dominance established by humans over other animal species comes from their use of knowledge, which can be summarized as:

  1. Use of symbolic representations.
  2. Ability to formulate and exchange representations of contexts, concerns, and policies.
  3. Ability to agree on stakes and cooperate on policies.

On that basis, the third dimension, i.e the use of symbolic knowledge to cooperate on non-zero-sum endeavors, can be used to draw the demarcation line between human and artificial intelligence:

  • Paths and paces of pursuits as part and parcel of the knowledge itself. The fact that both are mostly obviated by search engines gives humans some edge.
  • Operational knowledge is best understood as information put to use, and must include concerns and decision-making. But smart bots’ ubiquity and capabilities often sap information traceability and decisions transparency, which makes room for humans to prevail.

So humans can find a clear competitive edge in this knowledge dimension because it relies on a combination of experience and thinking and is therefore hard to clone. Organizations should make sure that’s where smart systems take back and humans take up.

Organization & Innovation

Innovation being at the root of competitive edge, understanding the role played by smart systems is a key success factor; that is to be defined by organization.

As epitomized by Henry Ford, industrial-era thinking associated innovation with top-down management and the specialization of execution:

  • At execution level manual tasks were to be fragmented and specialized.
  • At management level analysis and decision-making were to be centralized and abstracted.

That organizational paradigm puts a double restraint on innovation:

  • On execution side the fragmentation of manual tasks prevents workers from effectively assessing and improving their performances.
  • On management side knowledge is kept in conceptual boxes and bereft of feedback from actual uses.

That railing between smart brains and dumb hands may have worked well enough for manufacturing processes limited to material flows and subject to circumscribed and predictable technological changes. It didn’t last.

First, as such hierarchies necessarily grow with processes complexity, overheads and rigidity force repeated pruning. Then, flat hierarchies are of limited use when information flows are to be combined with material ones, so enterprises have to start with matrix organization. Finally, with the seamless integration of digital and material flows, perpetuating the traditional line between management and execution is bound to hamstring innovation:

  • Smart tools may be able to perform a wide range of physical tasks without human supervision, but the core of innovation core as well as its front lines are where human and machines collaborate in processing a mix of material and information flows, both learning from the experience.
  • Hierarchies and centralized decision-making are being cut out from feeders when set in networked business environments colonized by smart bots on both sides of corporate boundaries.

Not surprisingly, these innovation trends seem to tally with the social dimension of knowledge.

Learning from the Octopus

The AI revolution has already broken all historical records of footprint (everything is affected) and speed (a matter of years). Given the length of human education cycles, appraising the consequences comes with some urgency, beginning with the disposal of two entrenched beliefs:

At individual level the new paradigm could be compared to the nervous system of octopuses: each arm gets its brain and neurons, and so its own touch of knowledge and taste of decision-making.

On a broader (i.e enterprise) perspective, knowledge should be supported by two organizational layers, one direct and innovation-driven between trusted co-workers, the other networked and knowledge-driven between remote workers, trusted or otherwise.

Further Reading

External Links

Flawed Code vs Model in the Loop

November 27, 2017


Repeated announces of looming software apocalypse may take some edge off vigilance, but repeated systems failures should be taken seriously, if only because they  appear to be rooted in a wide array of causes, from wrongly valued single parameters (e.g 911 threshold or Apple’s free pass for “root” users) to architecture obsolescence (e.g reservation systems.)

Spreading hazardous digits (Mona Hatoum)

Yet, if alarms are not to be ignored, prognoses should go beyond syndromes and remedies beyond sticking plaster: contrary to what is suggested by The Atlantic’s article, systems are much more than piles of code, and programming is probably where quality has been taken the most seriously.

Programs vs Systems

Whatever programmers’ creativity and expertise, they cannot tackle complexity across space, time, and languages: today’s systems are made of distributed interacting components, specified and coded in different languages, and deployed and modified across overlapping time-frames. Even without taking into account continuous improvements in quality, apocalypse is not to loom in the particulars of code but on their ways in the world.

Solutions should therefore be looked for at system level, and that conclusion can only be bolstered by the ubiquity of digitized business flows.

Systems are the New Babel

As illustrated by the windfalls benefiting Cobol old timers, language is arguably a critical factor, for the maintenance of legacy programs as well as for communication between stakeholders, users, and engineers.

So if problems can be traced back to languages, it’s where solutions are to be found: from programming languages (for code) to natural ones (for systems requirements), everything can be specified as symbolic representations, i.e models.

Model in the Loop

Models are generally understood as abstractions, and often avoided for that very reason. That shortsighted mind-set is made up for by concrete employs of abstractions, as illustrated by the Automotive industry and the way it embeds models in engineering processes.

Summarily, the Automotive’s Model in Loop (MiL) can be explained through three basic ideas:

  • Systems are to be understood as the combination of physical and software artifacts.
  • Insofar as both can be implemented as digits, they can be uniformly described as models.
  • As a consequence, analysis, design and engineering can be carried out through the iterative building, simulating, testing, and adjusting various combinations of hardware and software.

By bringing together physical components and code into a seamless digitized whole, MiL brings down the conceptual gap between actual elements and symbolic representations, aka models. And that leap could be generalized to a much wider range of systems.

Models are the New Code

Programming habits and the constraints imposed by the maintenance of legacy systems have perpetuated the traditional understanding of systems as a building-up of programs; hence the focus put on the quality of code. But when large, distributed, and perennial systems are concerned, that bottom-up mind-set falls short and brings about:

  • An exponential increase of complexity at system level.
  • Opacity and discontinued traceability at application level between current use and legacy code.

Both flaws could be corrected by combining top-down modeling and bottom-up engineering. That could be achieved with iterative processes carried out from both directions.

Model in the Loop meets Enterprise Architecture

From a formal perspective models are of two sorts: extensional ones operate bottom-up and associate sets of individuals with categories, intensional ones operate top-down and specify the features meant to be shared by all instances of a type. based on that understanding, the former can be used to simulate the behaviors of targeted individuals depending on categories, and the latter to prescribe how to create instances of types meant to implement categories.

As it happens, Model-in-loop combines the two schemes at component level:

  • Any combination of manual and automated solution can be used as a starting point for analysis and simulation (a).
  • Given the outcomes of simulation and tests, the architecture is revisited (b) and corresponding artifacts (software and hardware) are designed (c).
  • The new combination of artifacts are developed and integrated, ready for analysis and simulation (d).

Model in the Loop

Assuming that MiL bottom-up approach could be tallied with top-down systems engineering processes, it would enable a seamless and continuous integration of changes in software components and systems architectures.

Further Reading

External Links

Focus: Business Analyst Booklet

November 6, 2017


Business analysts stand between unbounded and moving business landscapes on one hand, distinctive and steady enterprise organization and culture on the other hand.

How to align enterprise resources and business opportunities (Patrick Zachmann)

Assuming that BAs’ primary concern is to keep ahead of the competition, framing business undertakings into universal guidelines could be counterproductive. By contrast, harnessing together versatile business processes and reliable systems architectures will clearly enhance business agility; hence the benefits of lining up enterprise architects’ and business analysts’ conceptual toolboxes:

  1. Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
  2. Models: how the concepts are used to consolidate business requirements and convey them to enterprise architects and software engineers.
  3. Processes: how to harness organization and business objectives and align applications with business value.
  4. Architectures: how to contrive along time the continuity and consistency of business concepts and objectives, and their congruence with systems capabilities.
  5. Governance: assessment of business value and risks.

On that basis, the objective here is not to detail BAs’ tasks or methods but to focus on core issues to be addressed by business analysts.


Whereas systems architecture is not their primary concern, business analysts should nonetheless share the same modeling paradigm:

  • Analysis models for business environments and objectives.
  • Design models for the architecture of systems and the specification of components.

Business objects and processes must be consistently identified (#) across business and system realms.

It is worth to remind that the distinction between descriptive (aka analysis) and prescriptive (aka design) models is not arbitrary but based on logic principles: the former are extensional as they classify actual instances of business objects and activities; in contrast, the latter are intensional as they define the features and behaviors of required system artifacts.

The distinction also brings organizational benefits as it tallies with BAs’ responsibility regarding the consistency and continuity of identities and semantics of actual objects and processes (business extensions) and their symbolic counterparts (system intensions):

Relevant categories at architecture level can be neatly and unambiguously defined.

  • Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
  • Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
  • Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
  • Events are changes in the state of business objects, processes, or expectations.
  • Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.

While business analysts should only be tasked with the continuous and consistent mapping of business individuals to their system surrogates, and not with their implementations, that cannot be achieved without a full and unambiguous specification of the variants and abstractions for the business objects and processes to be represented.

Languages & Models

Being in charge of requirements, business analysts can be seen as the gate-keepers of the whole engineering process. To begin with, and depending on the nature of domains, BAs can capture requirements using formal (e.g for scientific domains), specific, or natural languages. Then, requirements analysis can be carried out:

  • Iteratively in unison with development and in collaboration with software engineers (agile approach). In that case models are not necessary as requirements are expressed in natural language (users’ stories), possibly combined with domain specific languages (DSLs) for development.
  • As phased undertakings carried out independently, using a dedicated modeling language (e.g BPMN).
  • As phased undertakings carried out jointly with system analysts using a general purpose modeling language (e.g UML).

Three ways to deal with requirements analysis: business oriented and phased (BPMN), system oriented and phased (use cases), or business driven and iterative (users’ stories).

These schemes are therefore best understood as tools whose employ may overlap or be combined:

  • BPMN and UML activity diagrams have much in common.
  • Class diagram can complement BPMN for business objects, and State diagrams for processes control.
  • Use cases can be seen as describing the part of users’ stories to be supported by systems.

How BAs will employ them is to depend on business processes and projects’ objectives.

Business & Development Processes

The responsibility of BAs is about business processes, the choice of development model being left to project managers; hence the need for business analysts to be familiar with basic options:

  • Agile: business analysts collaborate with software engineers in project teams and share responsibilities from requirements to delivery.
  • Phased: roles and responsibilities are defined specifically with regard to development tasks.

With agile schemes BAs share roles and responsibilities all along, with phased ones roles and responsibilities are defined with regard to tasks.

Agile or phased, the contribution of business analysts can be defined around three core issues, corresponding to three typical modus operandi:

  • Concepts associated to business objects and activities that are to be represented. Assuming that conceptual models are meant to be stable and shared across processes, they should be under the responsibility of business analysts independently of applications.
  • Actors (users, devices, or systems) and activities. Insofar as the impact on organization and system functional features can be localized (users interfaces) or circumscribed (business rules), business analysts can collaborate and share responsibility with software engineers all along an iterative process. Otherwise (changes in organization or business functions) business analysts will have to consolidate their work with enterprise architects.
  • Processes execution. Often labelled as non functional capabilities, they essentially deal with the different aspects of user’s experience and the synchronization of changes in business environments and supporting systems. For that purpose business analysts will have to check requirements against systems capabilities.

Business analysts core concerns and MO: conceptual model, activities, and processes.

While these issues are often interwoven, sorting them out can help to match development models with projects objectives and scope: agile for projects facing business users, phased for the ones dealing with architectures; that will also help to characterize the role of BAs depending on focus: business processes (BPM, use cases, users’ stories), functional architecture (services, conceptual models), or quality of services.

Business Analysis & Systems Architectures

When considering business opportunities, business analysts have to define requirements’ footprint with regard to system capabilities:

  • Confined: applications can be developed in collaboration with software engineers from users’ stories to code, without modeling. Assuming agile conditions about shared ownership and continuous delivery are met, that would be the default option.
  • Distributed: some modeling is needed for communication and consolidation purposes. But business processes modeling languages like BPMN make no distinction between processes’ details and the shared features of supporting systems. That puts a challenging toll on business analysts (complexity, ambiguity) with limited benefits (no easy mapping to system functions).

A primary concern for business analysts should therefore to frame projects accordingly: self-contained and business driven on one hand, shared and architecture driven on the other hand, with use cases set in between if and when necessary. For that purpose shared concerns will have to be clearly identified; taking BPMN for example:


Separation of concerns: architecture backbone and processes’ details

  • Containers for physical (locations) and logical (organizations and domains) objects have no BPMN explicit equivalents.
  • Active objects have no BPMN explicit equivalent.
  • Swimlanes and pool tally with roles (aka actors)
  • Data stores tally with entities (persistent representation of business objects).
  • Tasks, transactions, and sub-processes can be translated as activities description and processes execution.

Given backbones shared with enterprise architects, the next step is to flesh them out with specific details. Depending on methods and tools, that can be done using a domain specific language (DSL) with direct implementation, or through a generic subset of BPMN that could be unambiguously mapped to design constructs, for instance:

  • Anchors (#): instances (objects or activities) directly and consistently identified across businesses and system.
  • Collections (*): set of individuals with shared features.
  • Features: attributes or operations without identity of their own.
  • Structures (diamond): composition (black) for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own; aggregation (white) for components identified independently but used in the context of their owner.
  • Connectors: associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition. They can bear identification (#).
  • Power-types (2): define subsets of individuals objects or activities. Depending on context and modeling language, power-types correspond to classifications, extension points, gateways, branch and joins, etc.
  • Inheritance (triangle): contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance (black) is the counterpart of composition (inheritance of structural features), and weak inheritance (white) the counterpart of aggregation (inheritance functional features).

Separation of concerns: architecture backbone and anchors details

Using the same set of well accepted and unambiguous logical constructs for both objects and behaviors can greatly enhance the consistency of analysis models as well as their traceability to designs.

Business Analysis & Knowledge Architecture

As noted above, while business analysts may have to consolidate functional requirements or check the feasibility of non functional ones with enterprise architects, they should take responsibility for conceptual models, and more generally for enterprise knowledge architecture. Taking a leaf from Davis, Shrobe, and Szolovits, that will cover:

  1. Surrogates: description of symbolic counterparts (aka) of actual objects, events and relationships.
  2. Ontological commitments: statements about the categories of things that may exist in the domain under consideration.
  3. Fragmentary theory of intelligent reasoning: model of what the things can do or can be done with.
  4. Medium for efficient computation: knowledge understandable by computers.
  5. Medium for human expression: communication between specific domain experts on one hand, generic knowledge managers on the other hand.

Putting apart users interfaces (point 5), two typical approaches can be considered:

  • Domain Driven Design (DDD), which deals with domains representation and computation from a system perspective (point 4).
  • Ontologies, which put the focus on knowledge oriented languages independently of computation (points 1-3).

Besides their simplex orientation, both fall short of business analysts needs, the former being too technical, the latter too open-ended. Instead, a conceptual framework should combine bounded domains with a compact and unambiguous knowledge oriented language.

As it happens, mapping the symbolic footprint of business domains and knowledge into systems may be dictated by the generalization of networked environments and digital business flows. Along that reasoning, BAs will have to deal with knowledge from domains as well process perspectives.

With regard to domains, a distinction should be maintained between institutional (external, statutory), business specific (external, agreed), and enterprise specific (internal).


A conceptual approach to domain layers: institutional, business specific (e.g HR management) and enterprise specific (e.g supply, sales).

With regard to processes, knowledge must be understood as the dynamic and multi-faceted outcome of data analytics, production systems, and decision-making. Taking a (revised) leaf of Zachman’s framework, business and operational objectives would be reset as to cross architecture layers instead of being aligned. Using a pentagonal representation of enterprise architecture, Zachman’s sixth column (“Why” ) would be rounded as an outer range.

Knowledge: timely and multi-faceted information put to use

Such tightened integration of business processes and IT systems can be decisive in getting a competitive edge, as illustrated by the OOAD (Observation, Orientation, Decision, Action) loop, a real-time decision-making paradigm originally developed by Colonel John Boyd for USAF fighter jets:

  • Observation: operational processes must provide accurate and up-to-date analysis of business contexts as well as feedback.
  • Orientation: transparency of functional architecture is to support business positioning and the adjustment of business objectives.
  • Decision: versatility and plasticity of applications are to facilitate change of tactical options..
  • Action: integration of business, engineering, and operational processes are to ensure just-in-time business moves.

BAs must consider the benefits of systems integration for decision-making.

On a broader perspective the integration of data analytics, production systems, and knowledge management is becoming a key success factor for governance.

Governance: Metrics, Quality, & Risks

As gate-keepers, business analysts have to rank projects with regard to business value, risks, and return on investment. Assuming that business value is set independently of supporting systems, projects’ assessment and ranking should be set according to the nature of problems:

  • Intrinsic business size and complexity: requirements can be estimated from individuals (objects and activities), features, relationships, and partitions.
  • Supporting systems functionalities: intrinsic business metrics are to be combined with what is expected from supporting systems: processes and transactions, triggering events, users and devices interfaces, etc.
  • Business and functional measurements can then be weighted by non-functional (aka Quality of Service) requirements.

Assessment should be aligned with problems: business, supporting systems, operations.

If returns on investment (ROI) and risks are to be assessed consistently and decision-making carried out accordingly, value, costs, quality, and hazards have to be set within the same framework, in particular for quality and risks management:

  • Business environment: risks are external and quality is to check for timely and relevant analysis models.
  • Engineering:  risks are internal and quality is to focus on processes maturity.
  • Technologies: risks are external and quality is to address versatility, plasticity, and effectiveness of solutions.

To conclude, whereas business risks remain the primary concern of business analysts, the fusion of business and systems processes means that they can no longer ignore engineering pitfalls and the importance of quality for risks management.

Further Reading

Focus: Enterprise Architect Booklet

October 16, 2017


Given the diversity of business and organizational contexts, and EA still a fledgling discipline, spelling out a job description for enterprise architects can be challenging.


Aligning business, organization, and systems perspectives (Hans Vredeman de Vries)

So, rather than looking for comprehensive definitions of roles and responsibilities, one should begin by circumscribing the key topics of the trade, namely:

  1. Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
  2. Models: how the concepts are used to analyze business requirements and design systems architectures and software artifacts.
  3. Processes: how to organize business and engineering processes.
  4. Architectures: how to align systems capabilities with business objectives.
  5. Governance: assessment and decision-making.

The objective being to define the core issues that need to be addressed by enterprise architects.


To begin with, the primary concern of enterprise architects should be to align organization, processes, and systems with enterprise business objectives and environment. For that purpose architects are to consider two categories of models:

  • Analysis models describe business environments and objectives.
  • Design models prescribe how systems architectures and components are to be developed.

Enterprise architects must focus on individuals (objects and processes) consistently identified (#) across business and system realms.

That distinction is not arbitrary but based on formal logic: analysis models are extensional as they classify actual instances of business objects and activities; in contrast, design models are intensional as they define the features and behaviors of required system artifacts.

The distinction is also organizational: as far as enterprise architecture is concerned, the focus is to remain on objects and activities whose identity (#) and semantics are to be continuously and consistently maintained across business (actual instances) and system (symbolic representations) realms:

Relevant categories at architecture level can be neatly and unambiguously defined.

  • Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
  • Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
  • Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
  • Events are changes in the state of business objects, processes, or expectations.
  • Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.

Since the objective is to identify objects and behaviors at architecture level, variants, abstractions, or implementations are to be overlooked. It also ensues that the blueprints obtained remain general enough as to be uniformly, consistently and unambiguously translated into most of modeling languages.

Languages & Models

Enterprise architects may have to deal with a range of models depending on scope (business vs system) or level (enterprise and system vs domains and applications):

  • Business process modeling languages are used to associate business domains and enterprises organization.
  • Domain specific languages do the same between business domains and software components, bypassing enterprise organization and systems architecture.
  • Generic modeling languages like UML are supposed to cover the whole range of targets.
  • Languages like Archimate focus on the association between enterprises organization and systems functionalities.
  • Contrary to modeling languages programming ones are meant to translate functionalities into software end-products. Some, like WSDL (Web Service Definition Language), can be used to map EA into service oriented architectures (SOA).

Scope of Modeling Languages

While architects clearly don’t have to know the language specifics, they must understand their scope and purposes.


Whatever the languages, methods, or models, the primary objective is that architectures support business processes whenever and wherever needed. Except for standalone applications (for which architects are marginally involved), the way systems architectures support business processes is best understood with regard to layers:

  • Processes are solutions to business problems.
  • Processes (aka business solutions) induce problems for systems, to be solved by functional architecture.
  • Implementations of functional architectures induce problems for platforms, to be solved by technical architectures.

Enterprise architects should focus on the alignment of business problems and supporting systems functionalities

As already noted, enterprise architects are to focus on enterprise and system layers: how business processes are supported by systems functionalities and, more generally, how architecture capabilities are to be aligned with enterprise objectives.

Nonetheless, business processes don’t operate in a vacuum and may depend on engineering and operational processes, with regard to development for the former, deployment for the latter.

Enterprise architects should take a holistic view of business, engineering, and operational processes.

Given the crumbling of traditional fences between environments and IT systems under combined markets and technological waves, the integration of business, engineering, and operational processes is to become a necessary condition for market analysis and reactivity to changes in business environment.


Blueprints being architects’ tool of choice, enterprise architects use them to chart how enterprise objectives are to be supported by systems capabilities; for that purpose:

  • On one hand they have to define the concepts used for the organization, business domains, and business processes.
  • On the other hand they have to specify, monitor, assess, and improve the capabilities of supporting systems.

In between they have to define the functionalities that will consolidate specific and possibly ephemeral business needs into shared and stable functions best aligned with systems capabilities.


The role of functional architectures is to map conceptual models to systems capabilities

As already noted, enterprise architects don’t have to look under the hood at the implementation of functions; what they must do is to ensure the continuous and comprehensive transparency between existing as well a planned business objectives and systems capabilities.


One way or the other, governance implies assessment, and for enterprise architects that means setting apart architectural assets and business applications:

  • Whatever their nature (enterprise organization or systems capabilities), the life-cycle of assets encompasses multiple production cycles, with returns to be assessed across business units. On that account enterprise architects are to focus on the assessment of the functional architecture supporting business objectives.
  • By contrast, the assessment of business applications can be directly tied to a business value within a specific domain, value which may change with cycles. Depending on induced changes for assets, adjustments are to be carried out through users’ stories (standalone, local impact) or use cases (shared business functions, architecture impact).

Enterprise architects deal with assets, business analysts with processes.

The difficulty of assessing returns for architectural assets is compounded by cross dependencies between business, engineering, and operational processes; and these dependencies may have a decisive impact for operational decision-making.

Operational Decision-making

The weaving of enterprise systems within networked business environment calls for a tightened integration of business processes and IT systems, bringing new challenges for enterprise architects. Stakes can be illustrated with the OOAD (Observation, Orientation, Decision, Action) loop, a real-time decision-making paradigm originally developed by Colonel John Boyd for USAF fighter jets:

  • Observation: operational processes must provide accurate and up-to-date analysis of business contexts as well as feedback.
  • Orientation: transparency of functional architecture is to support business positioning and the adjustment of business objectives.
  • Decision: versatility and plasticity of applications are to facilitate change of tactical options..
  • Action: integration of business, engineering, and operational processes are to ensure just-in-time business moves.

The integration of maps and territories can greatly enhance strategic and operational decision-making.

That scheme epitomizes the main challenge of enterprise architects, namely the continuous and dynamic alignment of enterprise organization and systems to market environment, business processes, and decision-making.

Further Reading

On The Holistic Nature of MBSE

October 1, 2017


Interestingly, variants of MBSE/MDSE acronyms put the focus on the duality of the concept, software on one side, systems on the other.

MBSE is by nature a two-faced endeavor (Sand Painting Navajo Rug)

As that duality operates for models, systems, and organizations, MBSE offers a holistic view on enterprise architecture.

Models and Software

Models are symbolic representations of actual contexts in line with specific purposes: requirements analysis, simulation, software design, etc. Software is a subset of models characterized by target (computer code) and language (executable instructions). Based on that understanding, MBSE should not be limited to DSLs silos and code generation but employed to bring together and manage the whole range of concerns and artifacts.

Systems and Applications

The hapless track record of Waterfall and the parallel ascent of Agile have clouded the grounds for phased development processes. But whereas agile schemes are the default option when applications can be developed independently, external dependencies prevent their scaling up to system level. That’s when system engineering takes precedence on applications development, with MBSE introduced to manage shared models and support collaboration between teams.

Organization and Projects

As epitomized by agile development models, projects can be driven by specific business needs or shared architecture capabilities. Whereas the former are best carried out iteratively by autonomous teams sharing skills and responsibility, the latter entail collaboration between organizational units along time. MBSE provides the link between standalone projects, phased processes, and enterprise organization.

MBSE provides a holistic view of organisations and systems.

By providing a holistic view of changes in organizations, systems, and software, MBSE should be a key component of enterprise architecture.

Further Reading


Transcription & Deep Learning

September 17, 2017

Humans looking for reassurance against the encroachment of artificial brains should try YouTube subtitles: whatever Google’s track record in natural language processing, the way its automated scribe writes down what is said in the movies is essentially useless.

A blank sheet of paper was copied on a Xerox machine.
This copy was used to make a second copy.
The second to make a third one, and so on…
Each copy as it came out of the machine was re-used to make the next.
This was continued for one hundred times, producing a book of one hundred pages. (Ian Burn)

Experience directly points to the probable cause of failure: the usefulness of real-time transcriptions is not a linear function of accuracy because every slip can be fatal, without backup or second chance. It’s like walking a line: for all practical purposes a single misunderstanding can throw away the thread of understanding, without a chance of retrieve or reprieve.

Contrary to Turing machines, listeners have no finite states; and contrary to the sequence of symbols on tapes, tales are told by weaving together semantic threads. It ensues that stories are work in progress: readers can pause to review and consolidate meanings, but listeners have no other choice than punting on what comes to they mind, hopping that the fabric of the story will carry them out.

So, whereas automated scribes can deep learn from written texts and recorded conversations, there is no way to do the same from what listeners understand. That’s the beauty of story telling: words may be written but meanings are renewed each time the words are heard.

Further Reading

Why Virtual Reality (VR) is Late

July 25, 2017


Whereas virtual reality (VR) has been expected to be the next breakthrough for IT human interfaces, the future seems to be late.

Detached Reality (N.Ghesquiere, G.Coddington)

Together with the cost of ownership, a primary cause mentioned for the lukewarm embrace is the nausea associated with the technology. Insofar as the nausea is provoked by a delay in perceptions, the consensus is that both obstacles should be overcame by continuous advances in computing power. But that optimistic assessment rests on the assumption that the nausea effect is to be uniformly decreasing.

Virtual vs Augmented

The recent extension of a traditional roller-coaster at SeaWorld Orlando illustrates the difference between virtual and augmented reality. Despite being marketed as virtual reality, the combination of actual physical experience (roller-coaster) with virtual perceptions (3D video) clearly belongs to the augmented breed, and its success may put some new light on the nausea effect.

Consciousness Cannot Wait

Awareness is what anchors living organisms to their environment. So, lest a confusion is introduced between individuals experience and their biological clock, perceptions are to be immediate; and since that confusion is not cognitive but physical, it will cause nausea. True to form, engineers initial answer has been to cut down elapsed time through additional computing power; that indeed brought a decline in the nausea effect, as well as an increase in the cost of ownership. Unfortunately, benefits and costs don’t tally: however small is the remaining latency, nausea effects are disproportionate.

Aesop’s Lesson

The way virtual and augmented reality deal with latency may help to understand the limitations of a minimizing strategy:

  • With virtual reality latency occurs between users voluntary actions (e.g moving their heads) and devices (e.g headset) generated responses.
  • With augmented reality latency occurs between actual perceptions and software generated responses.

That’s basically the situation of Aesop’s “The Tortoise and the Hare” fable: in the physical realm the hare (aka computer) is either behind or ahead of the tortoise (the user), which means that some latency (positive or negative) is unavoidable.

That lesson applies to virtual reality because both terms are set in actuality, which means that nausea can be minimized but not wholly eliminated. But that’s not the case for augmented reality because the second term is a floating variable that can be logically adjusted.

The SeaWorld roller-coaster takes full advantage of this point by directly tying up augmented stimuli to actual ones: augmented reality scripts are aligned with roller-coaster episodes and their execution synchronized through special sensors. Whatever the remaining latency, it is to be of a different nature: instead of having to synchronize their (conscious) actions with the environment feedback, users only have to consolidate external stimuli, a more mundane task which doesn’t involve consciousness.

Further Reading

External Links

The Agility of Words

July 9, 2017


Oral cultures come with implicit codes for the repetition of words and sentences, making room for some literary hide-and-seek between the storyteller and his audience.


Stories Waiting to Happen

Could such narrative schemes be employed for users’ stories to open out the dialog between users (the storytellers) and business analysts (the listeners).

Open Storytelling

To begin with fiction, authors are meant to tell stories for readers ready to believe them at least while they are reading.

For young readers yet unable to suspend their disbelief, laser-disc games of the last century already gave post-toddlers a free hand to play with narratives.

But when the same scheme has been tried with grown-ups it has fizzled out: what would be the point of buying a story if you have to make it yourself ? the answer of agile business analysts is that users’ stories may be more pliable than budgets.

Tell Once, Tell Twice, Think Again

That’s what has just happened to “Hamlet on the Holodeck: The Future of Narrative in Cyberspace”, first published by Janet H. Murray twenty years ago with qualified ado, and now making a new debut, unedited yet clever as ever. That suggests both an observation and an interrogation.

For one, and notwithstanding readers consideration, a good story, fiction or otherwise, remains a good story which may be better appreciated in different circumstances. Then, considering the weighty mutation of circumstances since the book first appearance, the interrogation is about probable cause: should the origin of the rebirth to be looked for in technological advances, in the readers’ mind of that specific (non-fiction) book, or in the readiness of (fiction) books readers to collaborate in story building

Alternates in Narrative

As probable cause for new narrative ways, technology obviously comes first due to its means to change the relationship between readers and stories: breakthroughs in artificial intelligence, deep-learning, and computational linguistics have opened paths barely conceivable twenty years ago.

As a collateral effect of the technological revolution, opportunity may explain the renewed interest of Janet Murray’s likely readers: issues that were hardly broached before the initial publishing are now routinely mooted in the literati cognosphere.

Finally, on a broader social perspective, changes may have altered the motivation of fiction aficionados, bringing new relevancy to Janet Murray’s intuitions: as farcically illustrated by the uncritical audiences for alternative facts, the perception of reality may have been transformed by the utter sway of social networks.

Back to a literary perspective, evidences seem to point to the status of stories with regard to reality:

  • When embedded in games, stories don’t pretend to anything. On that ground changes are driven by players’ decisions regarding events or characters’ options that only affect the narratives of a plot defined upfront.
  • When set as fictions, stories, however preposterous, are meant to stand on their own ground. The meanings given to events and options are constitutive of the plot, and readers’ decisions are driven by their understanding of facts and behaviors.

So, Google’s AlphaGo may have overturned the grounds for the first category, but stories are not games and the only variants that count are the ones affecting understanding. More so for stories that use fictional realities to tell what should be.

Heed & Lead in Users’ Stories

Users’ stories are the agile answer to the challenge of elusive requirements. Definitively a cornerstone of the agile approach to software engineering, users’ stories are meant to deal with the instability of requirements, in contours as well as detours.

With regard to contours, users’ stories explore the space of requirements through successive iterations rooted into clearly identified users’ needs. Whereas the backbone (the plot) is set by stakeholders (the authors), the scope doesn’t have to be revealed upfront but can be progressively discovered through interactions between users (the storytellers) and analysts (the listeners).

But detours are where alternates in narratives may really prove themselves by helping to adjust users’ needs (the narratives) to business objectives (the plot). As a consequence changes suggested by analysts should not be limited to users’ options and ergonomy but may also concern the meaning of facts and behaviors. Along that reasoning users’ stories would use the agility of words to align the meanings of new business applications with the ones set by business functionalities already supported by systems.

Further Reading

External Links

Unified Architecture Framework Profile (UAFP): Lost in Translation ?

July 2, 2017


The intent of Unified Architecture Framework Profile (UAFP) is to “provide a Domain Meta-model usable by non UML/SysML tool vendors who may wish to implement the UAF within their own tool and metalanguage.”

Detached Architecture (Víctor Enrich)

But a meta-model trying to federate (instead of bypassing) the languages of tools providers has to climb up the abstraction scale above any domain of concerns, in that case systems architectures. Without direct consideration of the domain, the missing semantic contents has to be reintroduced through stereotypes.

Problems with that scheme appear at two critical junctures:

  • Between languages and meta-models, and the way semantics are introduced.
  • Between environments and systems, and the way abstractions are defined.

Caminao’s modeling paradigm is used to illustrate the alternative strategy, namely the direct stereotyping of systems architectures semantics.

Languages vs Stereotypes

Meta-Models are models of models: just like artifacts of the latter represent sets of instances from targeted domains, artifacts of the former represent sets of symbolic artifacts from the latter. So while set higher on the abstraction scale, meta-models still reflect the domain of concerns.

Meta-models takes a higher view of domains, meta-languages don’t.

Things are more complex for languages because linguistic constructs ( syntax and semantics) and pragmatic are meant to be defined independently of domain of discourse. Taking a simple example from the model above, it contains two kinds of relationships:

  • Linguistic constructs:  represents, between actual items and their symbolic counterparts; and inherits, between symbolic descriptions.
  • Domain specific: played by, operates, and supervises.

While meta-models can take into account both categories, that’s not the case for languages which only consider linguistic constructs and mechanisms. Stereotypes often appear as a painless way to span the semantic fault between what meta-models have to do and what languages use to do; but that is misguided because mixing domain specific semantics with language constructs can only breed confusion.

Stereotypes & Semantics

If profiles and stereotypes are meant to refine semantics along domains specifics, trying to conciliate UML/SysML languages and non UML/SysML models puts UAFP in a lopsided position by looking the other way, i.e towards one-fits-all meta-language instead of systems architecture semantics. Its way out of this conundrum is to combine stereotypes with UML constraint, as can be illustrated with PropertySet:

UAFP for PropertySet (italics are for abstract)

Behind the mixing of meta-modeling levels (class, classifier, meta-class, stereotype, meta-constraint) and the jumble of joint modeling concerns (property, measurement, condition), the PropertySet description suggests the overlapping of two different kinds of semantics, one looking at objects and behaviors identified in environments (e.g asset, capability, resource); the other focused on systems components (property, condition, measurement). But using stereotypes indifferently for both kind of semantics has consequences.

Stereotypes, while being the basic UML extension mechanism, comes without much formalism and can be applied extensively. As a corollary, their semantics must be clearly defined in line with the context of their use, in particular for meta-languages topping different contexts.

PropertySet for example is defined as an abstract element equivalent to a data type, simple or structured, a straightforward semantic that can be applied consistently for contexts, domains or languages.

That’s not the case for ActualPropertySet which is defined as an InstanceSpecification for a “set or collection of actual properties”. But properties defined for domains (as opposed to languages) have no instances of their own and can only occur as concrete states of objects, behaviors, or expectations, or as abstract ranges in conditions or constraints. And semantics ambiguities are compounded when inheritance is indifferently applied between a motley of stereotypes.

Properties epitomize the problems brought about by confusing language and domain stereotypes and point to a solution.

To begin with syntax, stereotypes are redundant because properties can be described with well-known language constructs.

As for semantics, stereotyped properties should meet clearly defined purposes; as far as systems architectures are concerned, that would be the mapping to architecture capabilities:

Property must be stereotyped with regard to induced architecture capabilities.

  • Properties that can be directly and immediately processed, symbolic (literal) or not (binary objects).
  • Properties whose processing depends on external resource, symbolic (reference) or not (numeric values).

Such stereotypes could be safely used at language level due to the homogeneity of property semantics. That’s not the case for objects and behaviors.

Languages Abstractions & Symbolic Representations

The confusion between language and domain semantics mirrors the one between enterprise and systems, as can be illustrated by UAFP’s understanding of abstraction.

In the context of programming languages, isAbstract applies to descriptions that are not meant to be instantiated: for UAFP “PhysicalResource” isAbstract because it cannot occur except as “NaturalResource” or “ResourceArtifact”, none of them isAbstract.

“isAbstract” has no bearing on horses and carts, only on the meaning of the class PhysicalResource.

Despite the appearances, it must be reminded that such semantics have nothing to do with the nature of resources, only with what can be said about it. In any case the distinction is irrelevant as long as the only semantics considered are confined to specification languages, which is the purpose of the UAFP.

As that’s not true for enterprise architects, confusion is to arise when the modeling Paradigm is extended as to include environments and their association with systems. Then, not only that two kinds of instances (and therefore abstractions) are to be described, but that the relationship between external and internal instances is to determine systems architectures capabilities. Extending the simple example above:

  • Overlooking the distinction between active and passive physical resources prevents a clear and reliable mapping to architecture technical capabilities.
  • Organizational resource lumps together collective (organization), individual and physical (person), individual and organizational (role), symbolic (responsibility), resources. But these distinctions have a direct consequences for architecture functional capabilities.

Abstraction & Symbolic representation

Hence the importance of the distinction between domain and language semantics, the former for the capabilities of the systems under consideration, the latter for the capabilities of the specification languages.

Systems Never Walk Alone

Profiles are supposed to be handy, reliable, and effective guides for the management of specific domains, in that case the modeling of enterprise architectures. As it happens, the UAF profile seems to set out the other way, forsaking architects’ concerns for tools providers’ ones; that can be seen as a lose-lose venture because:

  • There isn’t much for enterprise architects along that path.
  • Tools interoperability would be better served by a parser focused on languages semantics independently of domain specifics.

Hopefully, new thinking about architecture frameworks (e.g DoDAF) tends to restyle them as EA profiles, which may help to reinstate basic requirements:

  • Explicit modeling of environment, enterprise, and systems.
  • Clear distinction between domain (enterprise and systems architecture) and languages.
  • Unambiguous stereotypes with clear purposes

A simple profile for enterprise architecture

On a broader perspective such a profile would help with the alignment of purposes (enterprise architects vs tools providers), scope (enterprise vs systems), and languages (modeling vs programming).

Further Reading

Enterprise Architecture

External Links

EA’s Merry-go-round

June 14, 2017


All too often EA is planned as a big bang project to be carried out step by step until completion. That understanding is misguided as it confuses EA with IT systems and implies that enterprises could change their architectures as if they were apparel.

EA is a never-ending endeavor (Robert Doisneau)

But enterprise architecture is part and parcel of enterprises, a combination of culture, organization, and systems; whatever the changes, they must keep the continuity, integrity, and consistency of the whole.


Compared to usual projects, architectural ones are not meant to address specific business needs but architecture capabilities that may or may not be specific to business functions. Taking a leaf from the Zachman Framework, those capabilities can be organized around five pillars supporting enterprise, systems, and platform architectures:

  • Who: enterprise roles, system users, platform entry points.
  • What: business objects, symbolic representations, objects implementation.
  • How: business logic, system applications, software components.
  • When: processes synchronization, communication architecture, communication mechanisms.
  • Where: business sites, systems locations, platform resources.

These capabilities are set across architecture layers and support business, engineering, and operational processes.

Enterprise architecture capabilities

Enterprise architects are to continuously assess and improve these capabilities with regard to current weaknesses (organizational bottlenecks, technical debt) or future developments (new business, M&A, new technologies).

Work Units

Given the increased dependencies between business, engineering, and operations, defining EA workflows in terms of work units defined bottom-up from capabilities is to provide clear benefits with regard to EA versatility and plasticity.

Contrary to top-down (aka activity based) ones, bottom-up schemes don’t rely on one-fits-all procedures; as a consequence work units can be directly defined by capabilities and therefore mapped to engineering workshops:

Iterative development of architecture capabilities across workshops

Moreover, dependency constraints can be directly defined as declarative assertions attached to capabilities and managed dynamically instead of having to be hard-wired into phased processes.

That approach is to ensure two agile conditions critical for the development of architectural features:

  • Shared ownership: lest the whole enterprise be paralyzed by decision-making procedures, work units must be carried out under the sole responsibility of project teams.
  • Continuous delivery: architecture driven developments are by nature transverse but the delivery of building blocs cannot be put off by the decision of all parties concerned; instead it should be decoupled from integration.

Enterprise architecture projects could then be organized as a merry-go-round of capabilities-based work units to be set up, developed, and delivered according to needs and time-frames.

Time Frames

Enterprise architecture is about governance more than engineering. As such it has to ensure continuity and consistency between business objectives and strategies on one side, engineering resources and projects on the other side.

Assuming that capability-based work units will do the job for internal dependencies (application contents and engineering), the problem is to deal with external ones (business objectives and enterprise organization) without introducing phased processes. Beyond differences in monikers, such dependencies can generally be classified along three reasoned categories:

  • Operational: whatever can be observed and acted upon within a given envelope of assets and capabilities.
  • Tactical: whatever can be observed and acted upon by adjusting assets, resources and organization without altering the business plans and anticipations.
  • Strategic: decisions regarding assets, resources and organization contingent on anticipations regarding business environments.

The role of enterprise architects will then to manage the deployment of updated architecture capabilities according to their respective time-frames.

Portfolio Management

As noted before, EA workflows by nature can seldom be carried out in isolation as they are meant to deal with functional features across business domains. Instead, a portfolio of architecture (as opposed to development) work units should be managed according to their time-frame, the nature of their objective, and the kind of models to be used:

EA portfolio

  • Strategic features affect the concepts defining business objectives and processes. The corresponding business objects and processes are primarily defined with descriptive models; changes will have cascading effects for engineering and operations.
  • Tactical features affect the definition of artifacts, logical or physical. The corresponding engineering processes are primarily defined with prescriptive models; changes are to affect operational features but not the strategic ones.
  • Operational features affect the deployment of resources, logical or physical. The corresponding processes are primarily defined with predictive models derived from descriptive ones; changes are not meant to affect strategic or tactical features.

Architectural projects could then be managed as a dynamic backlog of self-contained work units continuously added (a) or delivered (b).

EA projects: a merry-go-round of work units.

That would bring together agile development processes and enterprise architecture.

Further Reading