Boost Your Mind Mapping


Turning thoughts into figures faces the intrinsic constraint of dimension: two dimensional representations cannot cope with complexity.

van der Straet, Jan, 1523-1605; A Natural Philosopher in His Study
Making his mind about knowledge dimensions: actual world, descriptions, and reproductions (Jan van der Straet)

So, lest they be limited to flat and shallow thinking, mind cartographers have to introduce the cognitive equivalent of geographical layers (nature, demography, communications, economy,…), and archetypes (mountains, rivers, cities, monuments, …)

Nodes: What’s The Map About

Nodes in maps (aka roots, handles, …) are meant to anchor thinking threads. Given that human thinking is based on the processing of symbolic representations, mind mapping is expected to progress wide and deep into the nature of nodes: concepts, topics, actual objects and phenomena, artifacts, partitions, or just terms.

What’s The Map About

It must be noted that these archetypes are introduced to characterize symbolic representations independently of domain semantics.

Connectors: Cognitive Primitives

Nodes in maps can then be connected as children or siblings, the implicit distinction being some kind of refinement for the former, some kind of equivalence for the latter. While such a semantic latitude is clearly a key factor of creativity, it is also behind the poor scaling of maps with complexity.

A way to frame complexity without thwarting creativity would be to define connectors with regard to cognitive primitives, independently of nodes’ semantics:

  • References connect nodes as terms.
  • Associations: connect nodes with regard to their structural, functional, or temporal proximity.
  • Analogies: connect nodes with regard to their structural or functional similarities.

At first, with shallow nodes defined as terms, connections can remain generic; then, with deeper semantic levels introduced, connectors could be refined accordingly for concepts, documentation, actual objects and phenomena, artifacts,…

Connectors are aligned with basic cognitive mechanisms of metonymy (associations) and analogy (similarities)

Semantics: Extensional vs Intensional

Given mapping primitives defined independently of domains semantics, the next step is to take into account mapping purposes:

  • Extensional semantics deal with categories of actual instances of objects or phenomena.
  • Intensional semantics deal with specifications of objects or phenomena.

That distinction can be applied to basic semantic archetypes (people, roles, events, …) and used to distinguish actual contexts, symbolic representations, and specifications, e.g:

Extensions (full border) are about categories of instances, intensions (dashed border) are about specifications
  • Car (object) refers to context, not to be confused with Car (surrogate) which specified the symbolic counterpart: the former is extensional (actual instances), the latter intensional (symbolic representations)
  • Maintenance Process is extensional (identified phenomena), Operation is intensional (specifications).
  • Reservation and Driver are symbolic representations (intensional), Person is extensional (identified instances).

It must be reminded that whereas the choice is discretionary and contingent on semantic contexts and modeling purposes (‘as-it-is’ vs ‘as-it-should-be’), consequences are not because the choice is to determine abstraction semantics.

For example, the records for cars, drivers, and reservations are deemed intensional because they are defined by business concerns. Alternatively, instances of persons and companies are defined by contexts and therefore dealt with as extensional descriptions.

Abstractions: Subsets & Sub-types

Thinking can be characterized as a balancing act between making distinctions and managing the ensuing complexity. To that end, human edge over other animal species is the use of symbolic representations for specialization and generalization.

That critical mechanism of human thinking is often overlooked by mind maps due to a confused understanding of inheritance semantics:

  • Strong inheritance deals with instances: specialization define subsets and generalization is defined by shared structures and identities.
  • Weak inheritance deals with specifications: specialization define sub-types and generalization is defined by shared features.
Inheritance semantics: shared structures (dark) vs shared features (white)

The combination of nodes (intension/extension) and inheritance (structures/features) semantics gives cartographers two hands: a free one for creative distinctions, and a safe one for the ensuing complexity. e.g:

  • Intension and weak inheritance: environments (extension) are partitioned according to regulatory constraints (intension); specialization deals with subtypes and generalization is defined by shared features.
  • Extension and strong inheritance: cars (extension) are grouped according to motorization; specialization deals with subsets and generalization is defined by shared structures and identities.
  • Intension and strong inheritance: corporate sub-type inherits the identification features of type Reservation (intension).

Mind maps built on these principles could provide a common thesaurus encompassing the whole of enterprise data, information and knowledge.

Intelligence: Data, Information, Knowledge

Considering that mind maps combine intelligence and cartography, they may have some use for enterprise architects, in particular with regard to economic intelligence, i.e the integration of information processing, from data mining to knowledge management and decision-making:

  • Data provide the raw input, without clear structures or semantics (terms or aspects).
  • Categories are used to process data into information on one hand (extensional nodes), design production systems on the other hand (intensional nodes).
  • Abstractions (concepts) makes knowledge from information by putting it to use.


Along that perspective mind maps could serve as front-ends for enterprise architecture ontologies, offering a layered cartography that could be organized according to concerns:

Enterprise architects would look at physical environments, business processes, and functional and technical systems architectures.

Using layered maps to visualize enterprise architectures

Knowledge managers would take a different perspective and organize the maps according to the nature and source of data, information, and knowledge.intelligence w

Using layered maps to build economic intelligence

As demonstrated by geographic information systems, maps built on clear semantics can be combined to serve a wide range of purposes; furthering the analogy with geolocation assistants, layered mind maps could be annotated with punctuation marks (e.g ?, !, …) in order to support problem-solving and decision-making.

Further Reading

External Links

Fitting Tools to Problems


All too often choosing a development method is seen as a matter of faith, to be enforced uniformly whatever the problems at hand.

Tools and problems at hand (Jacob Lawrence)

As it happens, this dogmatic approach is not limited to procedural methodologies but also affect some agile factions supposedly immunized against such rigid stances.

A more pragmatic approach should use simple and robust principles to pick and apply methods depending on development problems.

Iterative vs Phased Development

Beyond the variety of methodological dogmas and tools, there are only two basic development patterns, each with its own merits.

Iterative developments are characterized by the same activity (or a group of activities) carried out repetitively by the same organizational unit sharing responsibility, until some exit condition (simple or combined) verified.

Phased developments are characterized by sequencing constraints between differentiated activities that may or may not be carried out by the same organizational units. It must be stressed that phased development models cannot be reduced to fixed-phase processes (e.g waterfall); as a corollary, they can deal with all kinds of dependencies (organizational, functional, technical, …) and be neutral with regard to implementations (procedural or declarative).

A straightforward decision-tree can so be built, with options set by ownership and dependencies:



Shared Ownership: Agile Schemes

A project’s ownership is determined by the organizational entities that are to validate the requirements (stakeholders), and accept the products (users).

Iterative approaches, epitomized by the agile development model, is to be the default option for projects set under the authority of single organizational units, ensuring shared ownership and responsibility by business analysts and software engineers.

Projects set from a business perspective are rooted in business processes, usually through users’ stories or use cases. They are meant to be managed under the shared responsibility of business analysts and software engineers, and carried out independently of changes in architecture capabilities (a,b).

Agile Development & Architecture Capabilities

Projects set from a system perspective potentially affect architectures capabilities. They are meant to be managed under the responsibility of systems architects and carried out independently of business applications (d,b,c).

Transparency and traceability between the two perspectives would be significantly enhanced through the use of normalized capabilities, e.g from the Zachman’s framework:

  • 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.

It must be noted that as far as architecture and business driven cycles don’t have to be synchronized (principle of continuous delivery), the agile development model can be applied uniformly; otherwise phased schemes must be introduced.

Cross Dependencies: Phased Schemes

Cross dependencies mean that, at some point during project life-cycle, decision-making may involve organizational entities from outside the team. Two mechanisms have traditionally been used to cope with the coordination across projects:

  • Fixed phases processes (e.g Analysis/Design/Implementation)  have shown serious shortcomings, as illustrated by notorious waterfall.
  • Milestones improve on fixed schemes by using check-points on development flows instead of predefined activities. Yet, their benefits remain limited if development flows are still defined with regard to the same top-down and one-fits-all activities.

Model based systems engineering (MBSE) offers a way out of the dilemma by defining flows directly from artifacts. Taking OMG’s model driven architecture (MDA) as example:

  • Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
  • Platform Independent Models (PIMs) describe systems functionalities independently of platforms technologies.
  • Platform Specific Models (PSMs) describe systems components as implemented by specific technologies.
Layered Dependencies & Development Cycles with MDA

Projects can then be easily profiled with regard to footprints, dependencies, and iteration patterns (domain, service, platform, or architecture, …).

That understanding puts the light on the complementarity of agile and phased solutions, often known as scaled agile.

Further Reading

External Links

Enterprise Architects Basic Tenets


Humans often expect concepts to come with innate if vague meanings before being compelled to withstand endless and futile controversies around definitions. Going the other way would be a better option: start with differences, weed out irrelevant ones, and use remaining ones to advance.

How to keep business rolling (Tamar Ettun)

Concerning enterprise, it would start with the difference between business and architecture, and proceed with the wholeness of data, information, and knowledge.

Business Architecture is an Oxymoron

Business being about time and competition, success is not to be found in recipes but would depend on particularities with regard to objectives, use of resources, and timing. These drives are clearly at odds with architectures rationales for shared, persistent, and efficient structures and mechanisms. As a matter of fact, dealing with the conflicting nature of business and architecture concerns can be seen as a key success factor for enterprise architects, with information standing at the nexus.

Data as Resource, Information as Asset, Knowledge as Service

Paradoxically, the need of a seamless integration of data, information, and knowledge means that the distinction between them can no longer be overlooked.

  1. Data is captured through continuous and heterogeneous flows from a wide range of sources.
  2. Information is built by adding identity, structure, and semantics to data. Given its shared and persistent nature it is best understood as asset.
  3. Knowledge is information put to use through decision-making. As such it is best understood as a service.

Ensuring the distinction as well as the integration must be a primary concern of enterprise architects.

Sustainable Success Depends on a Balancing Act

Success in business is an unfolding affair, on one hand challenged by circumstances and competition, on the other hand to be consolidated by experience and lessons learnt. Meeting challenges while warding off growing complexity will depend on business agility and the versatility and plasticity of organizations and systems. That should be the primary objective of enterprise architects.

Further Reading

Squaring Software To Value Chains


Digital environments and the ubiquity of software in business processes introduces a new perspective on value chains and the assessment of supporting applications.

Michel Blazy plante
Business & Supporting Processes (Michel Blazy)

At the same time, as software designs cannot be detached of architectures capabilities, the central question remains of allocating costs and benefits between primary and support activities .

Value Chains & Activities

The concept of value chain introduced by Porter in 1985 is meant to encompass the set of activities contributing to the delivery of a valuable product or service for the market.

Porter’s generic model

Taking from Porter’s generic model, various value chains have been refined according to business specific categories for primary and support activities.

Whatever their merits, these approaches are essentially static and fall short when the objective is to trace changes induced by business developments; and that flaw may become critical with the generalization of digital business environments:

  • Given the role and ubiquity of software components (not to mention smart ones), predefined categories are of little use for impact analysis.
  • When changes in value chains are considered, the shift of corporate governance towards enterprise architecture puts the focus on assets contribution, cutting down the relevance of activities.

Hence the need of taking into account changes, software development, and enterprise architectures capabilities.

Value Added & Software Development

While the growing interest for value chains in software engineering is bound to agile approaches and business driven developments, the issue can be put in the broader perspective of project planning.

With regard to assessment, stakeholders, start with business opportunities and look at supporting systems from a black box perspective; in return, software providers are to analyze requirements from a white box perspective, and estimate corresponding development effort and time delivery.

Assuming transparency and good faith, both parties are meant to eventually align expectations and commitments with regard to features, prices, and delivery.

With regard to policies, stakeholders put the focus on returns on investment (ROI), obtained from total cost of ownership, quality of service, and timely delivery. Providers for their part try to minimize development costs while taking into account effective use of resources and costs of opportunities. As it happens, those objectives may be carried on as non-zero sum games:

  • Business stakeholders foretell the actualized returns (a) to be expected from the functionalities under consideration (b).
  • Providers consider the solutions (b’) and estimate actualized costs (a’).
  • Stakeholders and providers agree on functionalities, prices and deliveries (c).
Developing the value chain

Assuming that business and engineering environments are set within different time-frames, there should be room for non-zero-sum games winding up to win-win adjustments on features, delivery, and prices.

Continuous vs Phased Alignments

Notwithstanding the constraints of strategic planning, business processes are by nature opportunistic, and their ability to be adjusted to circumstances is becoming all the more critical with the generalization of digital business environments.

Broadly speaking, the squaring of supporting applications to business value can be done continuously or by phases:

  • Phased alignments start with some written agreements with regard to features, delivery, and prices before proceeding with development phases.
  • Continuous alignment relies on direct collaboration and iterative development to shape applications according to business needs.
Phased vs Continuous Adjustments

Beyond sectarian controversies, each approach has its use:

  • Continuous schemes are clearly better at harnessing value chains, providing that project teams be allowed full project ownership, with decision-making freed of external dependencies or delivery constraints.
  • Phased schemes are necessary when value chains cannot be uniquely sourced as they take roots in different organizational units, or if deliveries are contingent on technical constraints.

In any case, it’s not a black-and-white alternative as work units and projects’ granularity can be aligned with differentiated expectations and commitments.

Work Units & Architecture Capabilities

While continuous and phased approaches are often opposed under the guises of Agile vs Waterfall, that understanding is misguided as it extends the former to a motley of self-appointed agile schemes and reduces the latter to an ill-famed archetype.

Instead, a reasoned selection of a development models should be contingent on the problems at hand, and that can be best achieved by defining work-units bottom-up with regard to the capabilities targeted by requirements:

Work units should be defined with regard to the capabilities targeted by requirements

Development patterns could then be defined with regard to architecture layers (organization and business, systems functionalities, platforms implementations) and capabilities footprint:

  • Phased: work units are aligned with architecture capabilities, e.g : business objects (a), business logic (b), business processes (c), users interfaces (d).
  • Iterative: work units are set across capabilities and defined dynamically according to development problems.
A common development framework for phased and iterative projects

That would provide a development framework supporting the assessment of iterative as well as phased projects, paving the way for comprehensive and integrated impact analysis.

Value Chains & Architecture Capabilities

As far as software engineering is concerned, the issue is less the value chain itself than its change, namely how value is to be added along the chain.

Given the generalization of digitized and networked business environments, that can be best achieved by harnessing value chains to enterprise architecture capabilities, as can be demonstrated using the Caminao layout of the Zachman framework.

To summarize, the transition to this layout is carried out in two steps:

  1. Conceptually, Zachman’s original “Why” column is translated into a line running across column capabilities.
  2. Graphically, the five remaining columns are replaced by embedded pentagons, one for each architecture layer, with the new “Why” line set as an outer layer linking business value to architectures capabilities:
Mapping value chains to enterprise architectures capabilities

That apparently humdrum transformation entails a significant shift in focus and practicality:

  • The focus is put on organizational and business objectives, masking the ones associated to systems and platforms layers.
  • It makes room for differentiated granularity in the analysis of value, some items being anchored to specific capabilities, others involving cross dependencies.

Value chains can then be charted from business processes to supporting architectures, with software applications in between.

Impact Analysis

As pointed above, the crumbling of traditional fences and the integration of enterprise architectures into digital environments undermine the traditional distinction between primary and support activities.

To be sure, business drive is more than ever the defining factor for primary activities; and computing more than ever the archetype of supporting ones. But in between the once clear-cut distinctions are being blurred by a maze of digital exchanges.

In order to avoid a spaghetti heap of undistinguished connections, value chains are to be “colored” according to the nature of links:

  • Between architectures capabilities: business and organization (enterprise), systems functionalities, or platforms and technologies.
  • Between architecture layers: engineering processes.
Tracing value chains across architectures layers

When set within that framework, value chains could be navigated in both directions:

  • For the assessment of applications developed iteratively: business value could be compared to development costs and architecture assets’ depreciation.
  • For the assessment of features (functional or non functional) to be shared across business applications: value chains will provide a principled basis for standard accounting schemes.

Combined with model based system engineering that could significantly enhance the integration of enterprise architecture into corporate governance.

Model Driven Architecture & Value Chains

Model driven architecture (MDA) can be seen as the main (only ?) documented example of model based systems engineering. Its taxonomy organizes models within three layers:

  • 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 platforms and technologies.

Engineering processes can then be phased along architecture layers (a), or carried out iteratively for each application (b).

When set across activities value chains could be engraved in CIMs and refined with PIMs and PSMs(a). Otherwise, i.e with business value neatly rooted in single business units, value chains could remain implicit along software development (b).

Further Reading

 External Links


EA: Legacy & Latency

 “For things to remain the same, everything must change”
Lampedusa, “The Leopard”


Whatever the understanding of the discipline, most EA schemes implicitly assume that enterprise architectures, like their physical cousins, can be built from blueprints. But they are not because enterprises have no “Pause” and “Reset” buttons: business cannot be put on stand-by and must be carried on while work is in progress.

Refactored Legacy (E. Lusito)

Systems & Enterprises

Systems are variously defined as:

  • “A regularly interacting or interdependent group of items forming a unified whole” (Merriam-Webster).
  • “A set of connected things or devices  that operate  together” (Cambridge Dictionary).
  • “A way of working, organizing, or doing something which follows a fixed plan or set of rules” (Collins Dictionary)
  • “A collection of components organized to accomplish a specific function or set of functions” (TOGAF from ISO/IEC 42010:2007)

While differing in focus, most understandings mention items and rules, purpose, and the ability to interact; none explicitly mention social structures or interactions with humans. That suggests where the line should be drawn between systems and enterprises, and consequently between corresponding architectures.

Architectures & Changes

Enterprises are live social entities made of corporate culture, organization, and supporting systems; their ultimate purpose is to maintain their identity and integrity while interacting with environments. As a corollary, changes cannot be carried out as if architectures were just apparel, but must ensure the continuity and consistency of enterprises’ structures and behaviors.

That cannot be achieved by off-soil schemes made of blueprints and step-by-step processes detached from actual organization, systems, and processes. Instead, enterprise architectures must be grown bottom up from actual legacies whatever their nature: technical, functional, organizational, business, or cultural.

EA’s Legacy

Insofar as enterprise architectures are concerned, legacies are usually taken into account through one of three implicit assumptions:

No legacy assumptions ignore the issue, as if the case of start-ups could be generalized. These assumptions are logically flawed because enterprises without legacy are like embryos growing their own inherent architecture, and in that case there would be no need for architects.

En Bloc legacy assumptions take for granted that architectures as a whole could be replaced through some Big Bang operation without having a significant impact on business activities. These assumptions are empirically deceptive because, even limited to software architectures, Big Bang solutions cannot cope with the functional and generational heterogeneity of software components characterizing large organizations. Not to mention that enterprise architectures are much more that software and IT.

Piecemeal legacies can be seen as the default assumption, based on the belief that architectures can be re-factored or modernized step by step. While that assumption may be empirically valid, it may also miss the point: assuming that all legacies can be dealt with piecemeal rubs out the distinction pointed above between systems and enterprises.

So, the question remains of what is to be changed, and how ?

EA as a Work In Progress

As with leopard’s spots and identity, the first step would be to set apart what is to change (architectures) from what is to carry on (enterprise).

Maps and territories do provide an overview of spots’ arrangement, but they are static views of architectures, whereas enterprises are dynamic entities that rely on architectures to interact with their environment. So, for maps and territories to serve that purpose they should enable continuous updates and adjustments without impairing enterprises’ awareness and ability to compete.

That shift from system architecture to enterprise behavior implies that:

  • The scope of changes cannot be fully defined up-front, if only because the whole enterprise, including its organization and business model, could possibly be of concern.
  • Fixed schedules are to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
  • Different stakeholders may come as interested parties, some more equal than others, possibly with overlapped prerogatives.

So, instead of procedural and phased approaches supposed to start from blank pages, EA ventures must be carried out iteratively with the planning, monitoring, assessment, and adjustment of changes across enterprises’ businesses, organizations, and systems. That can be represented as an extension of the OODA (Observation, Orientation, Decision, Action) loop:

  • Actual observations from operations (a)
  • Data analysis with regard to architectures as currently documented (b).
  • Changes in business processes (c).
  • Changes in architectures (d).
EA decision-making as an extension of the OODA loop

Moreover, due to the generalization of digital flows between enterprises and their environment, decision-making processes used to be set along separate time-frames (operational, tactical, strategic, …), must now be weaved together along a common time-scale encompassing internal (symbolic) as well as external (actual) events.

It ensues that EA processes must not only be continuous, but they also must deal with latency constraints.

Changes & Latency

Architectures are by nature shared across organizational units (enterprise level) and business processes (system level). As a corollary, architecture changes are bound to introduce mismatches and frictions across business-specific applications. Hence the need of sorting out the factors affecting the alignment of maps and territories:

  • Elapsed time between changes in territories and maps updates (a>b) depends on data analytics and operational architecture.
  • Elapsed time between changes in maps and revised objectives (b>c) depends on business analysis and organization.
  • Elapsed time between changes in objectives and their implementation (c>d) depends on engineering processes and systems architecture.
  • Elapsed time between changes in systems and changes in territories (d>a) depends on applications deployment and technical architectures.

Latency constraints can then be associated with systems engineering tasks and workshops.

EA changes & Latency

On that basis it’s possible to define four critical lags:

  • Operational: data analytics can be impeded by delayed, partial, or inaccurate feedback from processes.
  • Mapping: business analysis can be impeded by delays or discrepancies in data analytics.
  • Engineering: development of applications can be impeded by delays or discrepancies in business analysis.
  • Processes: deployment of business processes can be impeded by delays in the delivery of supporting applications.

These lags condition the whole of EA undertakings because legacy structures, mechanisms, and organizations are to be continuously morphed into architectures without introducing misrepresentations that would shackle activities and stray decision-making.

EA Latency & Augmented Reality

Insofar as architectural changes are concerned, discrepancies and frictions are rooted in latency, i.e the elapsed time between actual changes in territories and the updating of relevant maps.

As noted above, these lags have to be weighted according to time-frames, from operational days to strategic years, so that the different agents could be presented with the relevant and up-to-date views befitting to each context and concerns.

EA views must be set according to contexts and concerns, with relevant lags weighted appropriately.

That could be achieved if enterprises architectures were presented through augmented reality technologies.

Compared to virtual reality (VR) which overlooks the whole issue of reality and operates only on similes and avatars, augmented reality (AR) brings together virtual and physical realms, operating on apparatuses that weaves actual substrates, observations, and interventions with made-up descriptive, predictive, or prescriptive layers.

On that basis, users would be presented with actual territories (EA legacy) augmented with maps and prospective territories.

Augmented EA: Actual territory (left), Map (center), Prospective territory (right)

Composition and dynamics of maps and territories (actual and prospective) could be set and edited appropriately, subject to latency constraints.

Further Reading


Self-driving Cars & Turing’s Imitation Game

Self-driving vehicles should behave like humans, here is how to teach them so.



The eventuality of sharing roads with self-driven vehicles raises critical issues, technical, social, or ethical. Yet, a dual perspective (us against them) may overlook the question of drivers’ communication (and therefore behavior) because:

  • Contrary to smart cars, human drivers don’t use algorithms.
  • Contrary to humans, smart cars are by nature unethical.

If roads are to become safer when shared between human and self-driven vehicles, enhancing their collaboration should be a primary concern.

Driving Is A Social Behavior

The safety of roads has more to do with social behaviors than with human driving skills, as it depends on human ability, (a) to comply with clearly defined rules and, (b) to communicate if and when rules fail to deal with urgent and exceptional circumstances. Given that self-driving vehicles will have no difficulty with rules compliance, the challenge is their ability to communicate with other drivers, especially human ones.

What Humans Expect From Other Drivers

Social behavior of human drivers is basically governed by clarity of intent and self-preservation:

  1. Clarity of intent: every driver expects from all protagonists a basic knowledge of the rules, and the intent to follow the relevant ones depending on circumstances.
  2. Self-preservation: every driver implicitly assumes that all protagonists will try to preserve their physical integrity.

As it happens, these assumptions and expectations may be questioned by self-driving cars:

  1. Human drivers wouldn’t expect other drivers to be too smart with their interpretation of the rules.
  2. Machines have no particular compunction with their physical integrity.

Mixing human and self-driven cars may consequently induce misunderstandings that could affect the reliability of communications, and so the safety of the roads.

Why Self-driving Cars Have To Behave Like Human Drivers

As mentioned above, driving is a social behavior whose safety depends on communication. But contrary to symbolic and explicit driving regulations, communication between drivers is implicit by necessity; if and when needed, it is in urgency because rules are falling short of circumstances: communication has to be instant.

So, since there is no time for interpretation or reasoning about rules, or for the assessment of protagonists’ abilities, communication between drivers must be implicit and immediate. That can only be achieved if all drivers behave like human ones.

Turing’s Imitation Game Revisited

Alan Turing designed his Imitation Game as a way to distinguish between human and artificial intelligence. For that purpose a judge was to interact via computer screen and keyboard with two anonymous “agents”, one human and one artificial, and to decide which was what.

Extending the principle to drivers’ behaviors, cars would be put on the roads of a controlled environment, some driven by humans, others self-driven. Behaviors in routine and exceptional circumstances would be recorded and analyzed for drivers and protagonists.

Control environments should also be run, one for human-only drivers, and one with drivers unaware of the presence of self-driving vehicles.

Drivers’ behaviors would then be assessed according to the nature of protagonists:


  • H / H: Should be the reference model for all driving behaviors.
  • H / M: Human drivers should make no difference when encountering self-driving vehicles.
  • M / H: Self-driving vehicles encountering human drivers should behave like good human drivers.
  • Ma / Mx: Self-driving vehicles encountering self-driving protagonists and recognizing them as such could change their driving behavior providing no human protagonists are involved.
  • Ma / Ma: Self-driving vehicles encountering self-driving protagonists and recognizing them as family related could activate collaboration mechanisms providing no other protagonists are involved.

Such a scheme could provide the basis of a driving licence equivalent for self-driving vehicles.

Self-driving Vehicles & Self-improving Safety

If self-driving vehicles have to behave like humans and emulate their immediate reactions, they may prove exceptionally good at it because imitation is what machines do best.

When fed with data about human drivers behaviors, deep-learning algorithms can extract implicit knowledge and use it to mimic human behaviors; and with massive enough data inputs, such algorithms can be honed to statistically perfect similitude.

That could set the basis of a feedback loop:

  1. A limited number of self-driving vehicles (properly fed with data) are set to learn from communicating with human drivers.
  2. As self-driving vehicles become better at the imitation game their number can be progressively increased.
  3. Human behaviors improve influenced by the growing number of self-driving vehicles, which adjust their behavior in return.

That is to create a virtuous feedback for roads safety.

PS: A Contrary Evidence

A trial in Texas demonstrates a contrario the potency of the argument by adopting the alternative policy, making clear that self-driving vehicles are indeed machines. Apart for being introduced as a public transport within a defined area and designed stops, two schemes are used to inhibit the imitation game:

  • Appearance: design and color enable immediate recognition.
  • Communication: external screens are used for textual (as opposed to visual) notification to pedestrians and other vehicles.

Future will tell if that policy is just a tactical step or a more significant shift towards a functional distinction between artificial brains and humans ones.

Further Reading

External Links


A Brief Ontology Of Time

“Clocks slay time… time is dead as long as it is being clicked off by little wheels; only when the clock stops does time come to life.”

William Faulkner


The melting of digital fences between enterprises and business environments is putting a new light on the way time has to be taken into account.

Time is what happens between events (Josef Koudelka)

The shift can be illustrated by the EU GDPR: by introducing legal constraints on the notifications of changes in personal data, regulators put systems’ internal events on the same standing as external ones and make all time-scales equal whatever their nature.

Ontological Limit of WC3 Time Recommendation

The W3C recommendation for OWL time description is built on the well accepted understanding of temporal entity, duration, and position:


While there isn’t much to argue with what is suggested, the puzzle comes from what is missing, namely the modalities of time: the recommendation makes use of calendars and time-stamps but ignores what is behind, i.e time ontological dimensions.

Out of the Box

As already expounded (Ontologies & Enterprise Architecture) ontologies are at their best when a distinction can be maintained between representation and semantics. That point can be illustrated here by adding an ontological dimension to the W3C description of time:

  1. Ontological modalities are introduced by identifying (#) temporal positions with regard to a time-frame.
  2. Time-frames are open-ended temporal entities identified (#) by events.
How to add ontological modalities to time

It must be noted that initial truth-preserving properties still apply across ontological modalities.

Conclusion: OWL Descriptions Should Not Be Confused With Ontologies

Languages are meant to combine two primary purposes: communication and symbolic representation, some (e.g natural, programming) being focused on the former, other (e.g formal, specific) on the latter.

The distinction is somewhat blurred with languages like OWL (Web Ontology Language) due to the versatility and plasticity of semantic networks.

Ontologies and profiles are meant to target domains, profiles and domains are modeled with languages, including OWL.

That apparent proficiency may induce some confusion between languages and ontologies, the former dealing with the encoding of time representations, the latter with time modalities.

Further Readings

External Links