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.

Open Concepts Will Make You Free

May 12, 2016

The idea that in order to get clear about the meaning of a general term one had to find the common element in all its applications has shackled philosophical investigation.

Ludwig Wittgenstein


Bones of contentions are not unknown to systems engineering, some across the divide between business and systems realms, other between parties on each side. Whatever the motives, the protagonists often take refuge behind extensive and punctilious standards, two a penny, one for every nook and cranny of information systems or enterprise architecture. The ensuing misunderstandings are especially harmful for the alignment of business and systems: when looking for a sound bridge with secure conceptual lanes linking business processes and supporting systems, analysts are facing a maze of shaky flyovers.

Good concepts: purposeful but elegant, and unambiguous but versatile (Noguchi)

Open Concept: Clear purpose, Minimum features, Infinite variants (Noguchi)

Assuming that standards are meant to provide analysts and architects with more freedom in their choices, de-facto proprietary schemes are clearly self-defeating. Taking example from open sources solutions, a better alternative would be to agree on open concepts to serve as building blocs for modeling languages and methods set to objectives and environments.

Open to Different Languages

With regard to systems modeling, languages can be regrouped into four categories:

  • Knowledge management relies on formal languages to chart domains of discourse. Since such domains are by nature specific, there isn’t much to expect for KM standards beyond formal logic and inference engines.
  • Business processes modeling focuses on business logic and process control. Associated languages can therefore be seen as equivalent to a combination of UML’s activity and state diagrams.
  • UML covers the whole of systems specifications. Cut to the bone it could secure some consensus as a standard.
  • Domain specific languages (DSLs) can be seen as silo implementations of UML’s class diagrams supporting comprehensive code generation.

Modeling Languages and Purposes

Each family clearly fulfills a well defined purpose; nonetheless, there seems to be no principled obstacle to their consolidation around a common conceptual hub. Yet, the practical challenge for large and complex organizations (the ones concerned) has been to find a consensus on shared definitions. That obstacle could be overcome if, instead of looking for some hypothetical overlapping between domains of discourse, their semantics would be set from open concepts.

Open to Different Methods

Beyond the expected benefits on costs and quality, two of the main objectives of methods is (1) to smooth the differences in skills and expertise and, (2) to facilitate communication across large organizations.

Broadly speaking, three schools of thought can be considered, depending on focus and perspective:

  • Agile approaches put the focus on skills and responsibilities and largely ignore communication issues across organization or along time.
  • Phased development models take the opposite view as they slice the tasks and detail development flows and intermediate deliveries.
  • Frameworks take a broader perspective, with some focusing on the definition of processes, others set on reasoned organization of models and artifacts.

All approaches could benefit from open concepts, if for different reasons:

  • As should be expected, agile methods don’t give much attention to development artifacts except the sanctified software. Nonetheless, when some unfortunate upshot make other kinds unavoidable, teams are set between the rocks and hard places of schemes deemed unsuitable. They would be in a better position if they could use open concepts to define the artifacts best suited to their situation.
  • Given their procedural nature, phased approaches are constrained by predefined tasks and deliverables whose adjustments are all too often limited to windows dressing. Process templates built from open concepts would be much more robust and versatile.
  • Frameworks focusing on processes (e.g TOGAF) have to compensate for their lack of conceptual anchors by being meticulous until they become overwhelmed with details. Open concepts could help them to factor out a compact backbone supporting a much smoother learning curve.
  • Frameworks focused on artifacts (e.g Zachman) face the opposite difficulty of mustering a consensus around their principles and semantics. That could be easier with open concepts.

As for languages, methods and frameworks serve different purposes and it would make sense to keep some options open depending on the enterprise organization and the characteristics of projects. That could obviously turn into a strenuous and costly endeavor for methods wholly and meticulously imported from outside or driven by harnessing tools. But the argument holds as well for single options with hefty upfront costs and steep learning curves: in any case methods are most successful when developed step by step from existing practices and organization, along each enterprise culture. That should make the case for mixed and pragmatic solutions.

How Concepts can Unlock Frameworks

The litmus test for assessing modeling languages, methods, or frameworks is their leverage on independence. Just like proprietary options and environments are widely and rightly opposed, choices of methods or frameworks should not preempt changes or alternatives, or incur cumbersome and costly transitions.


Simplex communication channel (left) versus conceptual thesaurus (right).

That can hardly be achieved by simplex communication channels between modeling schemes, except for small, stable, closed and unambiguous ones.  Instead, versatile methods and frameworks could be build bottom up from practices and experience around a small set of well accepted open concepts managed with a conceptual Thesaurus.

Further Readings

Brands, Bots, & Storytelling

May 2, 2016

As illustrated by the recent Mashable “pivot”, meaningful (i.e unbranded) contents appear to be the main casualty of new communication technologies. Hopefully (sic), bots may point to a more positive perspective, at least if their want for no no-nonsense gist is to be trusted.

(Latifa Echakhch)

Could bots repair gibberish ? (Latifa Echakhch)

The Mashable Pivot to “branded” Stories

Announcing Mashable recent pivot, Pete Cashmore (Mashable ‘s founder and CEO) was very candid about the motives:

“What our advertisers value most about
 Mashable is the same thing that our audience values: Our content. The
 world’s biggest brands come to us to tell stories of digital culture, 
innovation and technology in an optimistic and entertaining voice. As 
a result, branded content has become our fastest growing revenue 
stream over the past year. Content is now at the core of our ad 
offering and we plan to double down there.


Also revealing was the semantic shift in a single paragraph: from “stories”, to “stories told with an optimistic and entertaining voice”, and finally to “branded stories”; as if there was some continuity between Homer’s Iliad and Outbrain’s gibberish.

Spinning Yarns

From Lacan to Seinfeld, it has often been said that stories are what props up our world. But that was before Twitter, Facebook, YouTube and others ruled over the waves and screens. Nowadays, under the combined assaults of smart dummies and instant messaging, stories have been forced to spin advertising schemes, and scripts replaced  by subliminal cues entangled in webs of commercial hyperlinks. And yet, somewhat paradoxically, fictions may retrieve some traction (if not spirit) of their own, reprieved not so much by human cultural thirst as by smartphones’ hunger for fresh technological contraptions.

Apps: What You Show is What You Get

As far as users are concerned, apps often make phones too smart by half: with more than 100 billion of apps already downloaded, users face an embarrassment of riches compounded by the inherent limitations of packed visual interfaces. Enticed by constantly renewed flows of tokens with perfunctory guidelines, human handlers can hardly separate the wheat from the chaff and have to let their choices be driven by the hypothetical wisdom of the crowd. Whatever the outcomes (crowds may be right but often volatile), the selection process is both wasteful (choices are ephemera, many apps are abandoned after a single use, and most are sparely used), and hazardous (too many redundant dead-ends open doors to a wide array of fraudsters). That trend is rapidly facing the physical as well as business limits of a zero-sum playground: smarter phones appear to make for dumber users. One way out of the corner would be to encourage intelligent behaviors from both parties, humans as well as devices. And that’s something that bots could help to bring about.

Bots: What You Text Is What You Get

As software agents designed to help people find their ways online, bots can be differentiated from apps on two main aspects:

  • They reside in the cloud, not on personal devices, which means that updates don’t have to be downloaded on smartphones but can be deployed uniformly and consistently. As a consequence, and contrary to apps, the evolution of bots can be managed independently of users’ whims, fostering the development of stable and reliable communication grammars.
  • They rely on text messaging to communicate with users instead of graphical interfaces and visual symbols. Compared to icons, text put writing hands on driving wheels, leaving much less room for creative readings; given that bots are not to put up with mumbo jumbo, they will prompt users to mind their words as clearly and efficiently as possible.

Each aspect reinforces the other, making room for a non-zero playground: while the focus on well-formed expressions and unambiguous semantics is bots’ key characteristic, it could not be achieved without the benefits of stable and homogeneous distribution schemes. When both are combined they may reinstate written languages as the backbone of communication frameworks, even if it’s for the benefits of pidgin languages serving prosaic business needs.

A Literary Soup of Business Plots & Customers Narratives

Given their need for concise and unambiguous textual messages, the use of bots could bring back some literary considerations to a latent online wasteland. To be sure, those considerations are to be hard-headed, with scripts cut to the bone, plots driven by business happy ends, and narratives fitted to customers phantasms.

Nevertheless, good storytelling will always bring some selective edge to businesses competing for top tiers. So, and whatever the dearth of fictional depth, the spreading of bots scripts could make up some kind of primeval soup and stir the emergence of some literature untainted by its fouled nourishing earth.

Further Readings

UML’s Semantic Master Key, Lost & Found

April 25, 2016


When its first version was published twenty years ago the prognosis for OMG’s UML (Unified Modeling Language) was of rapid and wide expansion. It didn’t happen, and notwithstanding a noteworthy usage, UML has not become  “the” unified modeling language. Beyond the diverse agendas of methods and tools providers, this falling short may have something to do with a lack of robust semantics, as illustrated by UML 2.5’s halfhearted attempt to define individuals.

(Jonathan Monk)

Actual & Digital Identities (Jonathan Monk)

UML 2.5 Aborted Attempt with Individual 

UML 2.5 has often been presented as an attempt to redress the wayward and increasingly convoluted paths taken by the previous versions. Yet, beside some useful (and long needed) clarifications and adjustments, its governing group failed to agree on some compact and unambiguous semantics and had to content itself with perfunctory guidelines introduced as an afterthought.

As a matter of fact the OMG committee may have tried to get its semantics in order, as suggested by the chapter “On semantics” making the point right away with a distinction between the things to be described and the categories to be applied:

“A UML model consists of three major categories of model elements [classifiers, events, and behaviors], each of which may be used to make statements about different kinds of individual things within the system being modeled (termed simply “individuals”in the following)”.

That straightforward understanding (UML is meant to describe individual objects, events, or behaviors) could have provided the semantic cornerstone of a sound approach. Surprisingly, and for obscure reasons, it is soon smudged by syntactical overlapping and semantic ambiguity, the term “individual” being used indifferently as adjective and noun, and then appears to be restricted to classifiers only. That leaves UML with a dearth of clear semantics regarding its scope.

Individual as a Semantic Master Key

The early dismiss of individual as a constitutive concept is unfortunate because, taking a leaf from Archimedes, it could have been the fulcrum on which to place the UML lever.

To begin with, no modeling language, especially one supposed to be unified, can do without some convincing semantics about what it is supposed to describe. Furthermore, such a requirement is of primary importance for UML whose scope straddles the divide between business and systems realms, and must therefore rigorously define what they share and how they differ.

And that could have been neatly achieved with a comprehensive and unified interpretation of individuals, combined with a clear taxonomy of the aspects to be modeled:

  • Individuals are whatever occurrences (in business or systems contexts) with identities of their own.
  • These individuals (objects, events, or behaviors) can be specified with regard to their structure and relationships.

The logical primacy of this approach is reinforced by its immediate, practical, and conclusive benefits for business processes modeling on one side, model based engineering processes on the other side.

A Key to Business Processes Modeling

As far as business processes are concerned, modeling the part played by supporting systems turns around few critical issues, and these issues can be dealt more clearly and consistently when set in reference to individuals taxonomy (objects, behaviors, events) e.g:

  • Functional or non functional requirements ? The former can be associated with individuals, the latter cannot.
  • Architecture or application ? The former affect the specification of interactions between individuals, the latter affect only their local features.
  • Synchronous or asynchronous ? Specifications can only be made with regard to life-cycles and time-frames: system (objects), process (behaviors), or instant (event).
  • Structures or Relationships ? The former are bound to individuals’ identity, the latter are used between different individuals.
  • Inheritance or Delegation ? The former is used for the specification of structural or functional features, the latter for individuals’ behaviors.

More generally that understanding of individuals should greatly enhance the alignment of systems functional architectures with business processes.

A Key to Model Based Systems Engineering

As should be expected from a lack of semantic foundations, one of the main characteristics of the UML community is its fragmented practices, regrouped around diagrams (e.g Use case or Class) or task (e.g requirements analysis or code generation).

The challenge can be directly observed for model based system engineering and software development: with the exception of Statecharts for RT modeling, Class diagrams are the only ones used all along engineering processes; the others, when used, are reduced to documentation purposes. That bottleneck in development flows can be seen as the direct consequence of UML restricted semantics: since behaviors are not identified as individuals in their own right, their description cannot be directly translated into software artifacts, but have to be understood as part of active objects descriptions before being translated into class diagrams. Hence the apparent redundancy of corresponding diagrams.

As a corollary, reinstating a unified semantics of individual for both classifiers and behaviors could be the key to a seamless integration of the main UML diagrams. Most important, that would bear out the cross benefits of combining UML and MBSE.

Further Readings

Out of Mind Content Discovery

April 20, 2016

Content discovery and the game of Go can be used to illustrate the strengths and limits of artificial intelligence.

(Pavel Wolberg)

Now and Then: contents discovery across media and generations (Pavel Wolberg)

Game of Go: Closed Ground, Non Semantic Charts

The conclusive successes of Google’s AlphaGo against world’s best players are best understood when  related to the characteristics of the game of Go:

  • Contrary to real life competitions, games are set on closed and standalone playgrounds  detached from actual concerns. As a consequence players (human or artificial) can factor out emotions  from cognitive behaviors.
  • Contrary to games like Chess, Go’s playground is uniform and can be mapped without semantic distinctions for situations or moves. Whereas symbolic knowledge, explicit or otherwise, is still required for good performances, excellence can only be achieved through holistic assessments based on intuition and implicit knowledge.

Both characteristics fully play to the strengths of AI, in particular computing power (to explore playground and alternative strategies) and detachment (when decisions have to be taken).

Content Discovery: Open Grounds, Semantic Charts

Content discovery platforms like Outbrain or Taboola are meant to suggest further (commercial) bearings to online users. Compared to the game of Go, that mission clearly goes in the opposite direction:

  • Channels may be virtual but users are humans, with real emotions and concerns. And they are offered proxy grounds not so much to be explored than to be endlessly redefined and made more alluring.
  • Online strolls may be aimless and discoveries fortuitous, but if content discovery devices are to underwrite themselves, they must bring potential customers along monetized paths. Hence the hitch: artificial brains need some cues about what readers have in mind.

That makes content discovery a challenging task for artificial coaches as they have to usher wanderers with idiosyncratic but unknown motivations through boundless expanses of symbolic shopping fields.

What Would Eliza Say

When AI was still about human thinking Alan Turing thought of a test that could check the ability of a machine to exhibit intelligent behaviors. As it was then, available computing power was several orders of magnitude below today’s capacities, so the test was not about intelligence itself, but with the ability to conduct text-based dialogues equivalent to, or indistinguishable from, that of a human. That approach was famously illustrated by Eliza, a software able to beguile humans in conversations without any understanding of their meanings.

More than half a century later, here are some suggestions of leading content discovery engines:

  • After reading about the Ecuador quake or Syrian rebels one is supposed to be interested by 8 tips to keep our liver healthy, or 20 reasons of unsuccessful attempts at losing weight.
  • After reading about growing coffee in Ethiopia one is supposed to be interested by the mansions of world billionaires, or a Shepard pup surviving after being lost at sea for a month.

It’s safe to assume that both would have flunked the Turing Test.

Further Reading

External Links

Event Oriented Analysis & Object Oriented Design

April 15, 2016

As it’s safe to assume that a primary objective of process analysis is to align business concerns (by nature specific and changing) with enterprise architectures (meant to be shared and stable), events could provide a good starting point.

(F. Handoko)

Event, concerns, processing (F. Handoko)

Business Analysis & Application Design

Taking example from the convincing track record of object oriented approaches for systems architectures and software design, the same principles have been tried for business requirements analysis. While that approach can be credited with significant realizations, success usually depends on some prior alignment of business domains with their system counterpart, in particular on the possibility to uniformly and consistently identify and define business entities as objects independently of operating processes.

Alternatively, when business entities cannot not be readily identified upfront as system objects, analysis may start with organization, entitled agents, activities, and be carried out with the definition of business flows and associated entities.

So, and whatever the approach, the question is how to ensure that the applications under consideration are designed in accordance with architecture capabilities.

System Architecture & Software Design

Words are worth the difference they make: as long as systems were not much more than an assortment of software modules, architecture and design could be understood as one and the same. But nowadays a distinction may be overdue between, on one hand the design of software components run within a single system’s address space and time-frame and, on the other hand, architectures of systems set across different spaces and time-frames.


Architecture vs Design: words are worth the difference they make

Object oriented solutions (e.g Domain Driven Design) are arguably the option of choice for the former, but services oriented approaches may be a better fit for the latter. Not by chance, events provide a sound conceptual hinge between the two approaches.

Event Oriented Analysis vs Object Oriented Design

Object oriented principles can be streamlined around three core topics: (a) information hiding and coupling between structures and methods; (b) inheritance between types; (c) communication through interfaces and polymorphism.

OO principles can be streamlined along three topics: encapsulation (a), inheritance (b), and communication through interfaces (c).

OO principles can be streamlined around three topics: encapsulation (a), inheritance (b), and communication through interfaces (c).

Of these, encapsulation and inheritance are specific to software design, but communication mechanisms are also at the core of services oriented architectures. Considering messages as the logical system counterparts of business events, event-oriented analysis should help to align business processes with systems capabilities.

From a business processes perspective, events are signaling changes in the states of activities, objects, or expectations. Given that  supporting systems are meant to deal with those changes, the analysis of business requirements could proceed from corresponding events:

  • Business events are defined with regard to time-frames (a) and sources to be authenticated and authorized (b).
  • Triggering changes must be described by messages with regard to their functional (c) and operational (d) scope.
  • Business logic (e) and entities (f) are often shared across applications and therefore better defined independently.
  • Internal changes (same space and time-frame) are hidden.
  • Triggered (external) changes are defined with regard to time-frames (h), processes (d), and devices (g).
A simplified blueprint of Event Oriented Process Analysis

A simplified blueprint of Event Oriented Process Analysis

As it happens, those facets can be aligned with OO design ones, with (c) and (d) for communication, (e) and (f) for encapsulation. On a broader perspective they also fit with the growing focus on event-driven applications and service oriented architectures.

From Event Oriented Process Analysis to Service Oriented Architectures

By moving business logic to the background, event-driven analysis fosters polymorphism at enterprise level with corresponding benefits:

  • With regard to business processes, events come with functional and operational requirements set independently of the business logic that will be carried out: trigger (what has changed), role (who is requesting), and message communication semantics (when the system is supposed to deal with the event).
  • With regard to system capabilities messages can be used to align business (aka external) events with system (aka internal) ones independently of the business entities and logic (what is to be done and how).
  • With regard to architecture and design, that approach is to uphold OO principles by dealing separately with polymorphic requests (interfaces) and business logic (methods).

Those benefits appear clearly when capabilities are realized by services defined with regard to business processes (customers), business objects (messages), business logic (contract), and business operations (policy).

Environment (bold) vs Services (italic)

Environment (bold) vs Services (italic)

It must be reminded that services are part of functional architectures and as a consequence cannot be directly addressed by users or devices.

Events & Action Semantics

With events set as modeling anchors, use cases may provide the modeling glue between processes and functional capabilities:

  • Triggering events (a) map changes in business environments (aka external events) to changes in systems objects (aka internal events).
  • Actors (b) map roles in organization to system users.
  • Messages (c) map the semantics of business processes to the semantics of applications (e) and domains (f).
Use cases (orange) provide a comprehensive and consistent mapping from processes (green) to services (blue).

Use cases (orange) provide a comprehensive and consistent mapping from processes (green) to services (blue).

On that basis, the main objective of event-oriented analysis would be to distinguish between communication and business semantics, the former dealing with interactions, the latter with business logic.

Further Reading


Models Transformation & Agile Development

April 5, 2016

Models transformation is generally recognized as the basic mechanism of model based systems engineering (MBSE). Yet, the actual scope of transformations is somewhat limited to design-to-code, and its sequential bias puts MBSE at odds with agile development approaches. Could a revisited understanding help to figure out this apparent discrepancy ?

 (Sand Painting Navajo Rug)

Weaving Life by Crossing Patterns (Sand Painting Navajo Rug)

Transformation Issues

Traditional transformation paradigm involves ordered sequences of models obtained by applying rules to their immediate predecessor(s). That organizational scheme has three critical consequences, for applicability, economics of reuse, and development processes.

  • Applicability: the effectiveness of transformations is conditioned by (a) an executable language for the description of targets, and (b) a closed and compact set of unambiguous patterns. Those conditions can only be satisfied for the downstream part of the development process.
  • Reuse: given the sequencing constraints, models are to be managed and reused along tree-like structures with duplicates introduced at branching points.
  • Development processes: sequenced models brings forth phased options and leaves out agile solutions.

Assuming those issues are not conclusive, they may be overcame by revisiting the nature of transformations.

Transformation vs Inheritance & Composition

Most of the proposed taxonomies (see references below) put the focus on languages and mechanisms (e.g rules) of sequential transformation without paying enough attention to the nature and the semantics of models contents. Even when abstraction levels are taken into account, the respective contents of each level remain undefined. As it happens, that issue may be the key to a better understanding of models transformation.

To begin with, rule-based transformation has to be compared to inheritance and composition:

  • Structural inheritance can be used to refine models as to take into account business scenarii previously ignored; e.g special conditions for good customers.
  • Functional inheritance can be used to introduce new capabilities; e.g new authentication procedures.
  • Functional composition can be used to apply capabilities across different scenarii; e.g customized authentication procedures.
  • Rules-based solutions can be used by any kind of transformation.

A broader understanding of models transformation should include inheritance and composition

That taxonomy implies a clear distinction between operations executed within the same level of abstraction and those targeting artifacts defined at different levels: contrary to rules-based transformations, inheritance and composition can only be applied to artifacts sharing common semantics.

heterogeneous Models

While that would clearly prevent their use for models organized along abstraction levels, semantic pitfalls could be mastered for models built from artifacts from different abstraction levels.

Releasing models from (still to be defined) abstraction levels would bring two critical benefits:

  • Whatever the terminology (abstract, conceptual, functional, etc.), abstraction semantics are much easier to define for artifacts than for models.
  • That would remove a chunk of restrictions on the design of transformation processes.
Heterogeneous models are not bound to abstraction layers.

Releasing models from abstraction layers.

In that case transformation rules could be turned into combination ones and sequential transformation turned into cross-breeding.

Mendel, Models, Mongrels

Taking a cue from Gregor Mendel’s use of cross-fertilization, the aim of a revisited transformation paradigm would be three-fold:

  1. To refine the granularity of reuse, from models to artifacts
  2. To substitute combination for sequential transformation whenever possible.
  3. To substitute graphs for trees, with models organized along two basic layers, final (aka mongrels) or reusable (aka blueprints).

Models combination (top) replaces transformation phases (bottom) by a distinction between blueprints (full line) and mongrels (dashed line).

As far as MBSE is concerned, the genetics metaphor helps to clarify the nature of abstraction. Conceptually, it introduces a distinction between artifacts and models:

  • With regard to artifacts, abstraction layers are defined by scope: enterprise, systems, platforms.
  • With regard to models, abstraction layers are defined by capabilities: reusable (stable traits), or final (recessive traits).

That taxonomy is corroborated by its functional counterpart: artifacts transformation is carried out with inheritance and composition, models transformation relies on combination.

More important, that understanding goes a long way solving the issues regarding scope, reuse, and development processes.

Scope: Weaving Analysis & Design Traits

Definitions and taxonomies should always be assessed with regard of their applicability. On that account there isn’t much to say for abstraction layers applied to models: they don’t fit because too many traits can be defined across different layers, e.g: business rules, authentication, encryption, etc.

That difficulty can be neatly and consistently removed by models built from artifacts defined at different levels.

Models Reuse: Blueprints vs Mongrels

Reuse is all too often seen as a contentious objective with inconclusive ROI. One one hand it requires significant overheads to manage the resources, on the other hand the outcomes can introduce regressive traits. The distinction between sound reusable models and final ones significantly reduces both the costs of the former and the risks of the latter.

Processes Organization: MBSE & Agile

Model based systems engineering and the agile development model are arguably two of the most conclusive approaches to software engineering. Unfortunately they are often seen as difficult bedfellows, principally (but not uniquely) because the former insists on the importance of models with some bias toward phased processes, while the latter is all for iterative processes with models mentioned as an afterthought, if at all. Yet, both approaches could be made complementary on condition that models could be processed iteratively. And that could be achieved if sequenced transformations of homogeneous models would be replaced by the combination of heterogeneous ones.


Iterative development mixing new business requirements with existing functionalities (a) and business rules (b).

Within such a framework an agile team could, e.g, iteratively develop new business requirements, taking into account existing functionalities (a) and business rules (b), and generate code (c).

Further readings

External Links


Selfies & Augmented Identities

March 31, 2016

As smart devices and dumb things respectively drive and feed internet advances, selfies may be seen as a minor by-product figuring the scenes between reasoning capabilities and the reality of things. But then, should that incidental understanding be upgraded to a more meaningful one if virtual reality is taken into account ?

(Ditlev Blunck)

Actual and Virtual Representations (Ditlev Blunck)

Portraits, Selfies, & Social Identities

Selfies are a good starting point given that their meteoric and wide-ranging success makes for social continuity of portraits, from timeless paintings to new-age digital images. Comparing the respective practicalities and contents of traditional and digital pictures may be especially revealing.

With regard to practicalities, selfies bring democratization: contrary to paintings, reserved to social elites, selfies let everybody have as many portraits as wished, free to be shown at will, to family, close friends, or total unknowns.

With regard to contents, selfies bring immediacy: instead of portraits conveying status and characters through calculated personal attires and contrived settings, selfies picture social identities as snapshots that capture supposedly unaffected but revealing moments, postures, entourages, or surroundings.

Those selfies’ idiosyncrasies are intriguing because they seem to largely ignore the wide range of possibilities offered by new media technologies which could (and do sometimes) readily make selfies into elaborate still lives or scenic videos.

Likewise is the fading-out of photography as a vector of social representation after the heights achieved in the second half of the 19th century: not until the internet era did photographs start again to emulate paintings as vehicles of social identity.

Those changing trends may be cleared up if mirrors are introduced in the picture.

Selfies, Mirrors, & Physical Identities

Natural or man-made, mirrors have from the origin played a critical part in self-consciousness, and more precisely in self-awareness of physical identity. Whereas portraits are social, asynchronous, and symbolic representations, mirrors are personal, synchronous, and physical ones; hence their different roles, portraits abetting social identities, and mirrors reflecting physical ones. And selfies may come as the missing link between them.

With smartphones now customarily installed as bodily extensions, selfies may morph into recurring personal reflections, transforming themselves into a crossbreed between portraits, focused on social identification, and mirrors, intent on personal identity. That understanding would put selfies on an elusive swing swaying between social representation and communication on one side, authenticity and introspection on the other side.

On that account advances in technologies, from photographs to 3D movies, would have had a limited impact on the traction from either the social or physical side. But virtual reality (VR) is another matter altogether because it doesn’t only affect the medium between social and physical aspects, but also the “very” reality of the physical side itself.

Virtual Reality: Sense & Sensibility

The raison d’être of virtual reality (VR) is to erase the perception fence between individuals and their physical environment. From that perspective VR contraptions can be seen as deluding mirrors doing for physical identity what selfies do for social ones: teleporting individual personas between environments independently of their respective actuality. The question is: could it be carried out as a whole, teleporting both physical and social identities in a single package ?

Physical identities are built from the perception of actual changes directly originated in context or prompted by our own behavior: I move of my own volition, therefore I am. Somewhat equivalently, social identities are built on representations cultivated innerly, or supposedly conveyed by aliens. Considering that physical identities are continuous and sensible, and social ones discrete and symbolic, it should be possible to combine them into virtual personas that could be teleported around packet switched networks.

But the apparent symmetry could be deceitful given that although teleporting doesn’t change meanings, it breaks the continuity of physical perceptions, which means that it goes with some delete/replace operation. On that account effective advances of VR can be seen as converging on alternative teleporting pitfalls:

  • Virtual worlds like Second Life rely on symbolic representations whatever the physical proximity.
  • Virtual apparatuses like Oculus depend solely on the merge with physical proximity and ignore symbolic representations.

That conundrum could be solved if sense and sensibility could be reunified, giving some credibility to fused physical and social personas. That could be achieved by augmented reality whose aim is to blend actual perceptions with symbolic representations.

From Augmented Identities to Extended Beliefs

Virtual apparatuses rely on a primal instinct that makes us to believe in the reality of our perceptions. Concomitantly, human brains use built-in higher level representations of body physical capabilities in order to support the veracity of the whole experiences. Nonetheless, if and when experiences appear to be far-fetched, brains are bound to flag the stories as delusional.

Or maybe not. Even without artificial adjuncts to the brain chemistry, some kind of cognitive morphing may let the mind bypasses its body limits by introducing a deceitful continuity between mental representations of physical capabilities on one hand, and purely symbolic representations on the other hand. Technological advances may offer schemes from each side that could trick human beliefs.

Broadly speaking, virtual reality schemes can be characterized as top-down; they start by setting the mind into some imaginary world, and beguiles it into the body envelope portraying some favorite avatar. Then, taking advantage of its earned confidence, the mind is to be tricked on a flyover that would move it seamlessly from fictional social representations into equally fictional physical ones: from believing to be with superpowers into trusting the actual reach and strength of his hand performing corresponding deeds. At least that’s the theory, because if such a “suspension of disbelief” is the essence of fiction and art, the practicality of its mundane actualization remains to be confirmed.

Augmented reality goes the other way and can be seen as bottom-up, relying on actual physical experiences before moving up to fictional extensions. Such schemes are meant to be fed with trusted actual perceptions adorned with additional inputs, visual or otherwise, designed on purpose. Instead of straight leaps into fiction, beliefs can be kept anchored to real situations from where they can be seamlessly led astray to unfolding wonder worlds, or alternatively ushered to further knowledge.

By introducing both continuity and new dimensions to the design of physical and social identities, augmented reality could leverage selfies into major social constructs. Combined with artificial intelligence they could even become friendly or helpful avatars, e.g as personal coaches or medical surrogate.

Further Readings

External Links

Conceptual Models & Abstraction Scales

March 22, 2016

Following the recent publication of a new standard for conceptual modeling of automation systems (Object-Process Methodology (ISO/PAS 19450:2015) it may be interesting to explore how it relates to abstraction and meta-models.

(Oskar Schlemmer )

Meta-models are drawn along lean abstraction scales (Oskar Schlemmer )

Models & Meta Models

Just like models are meant to describe sets of actual instances, meta-models are meant to do the same for sets of modeling artifacts independently of their targets. Along that reasoning, conceptual modeling of automation systems could be achieved either with a single language covering all aspects, or with a meta-language dealing with different sets of models, e.g MDA’s computation independent, platform independent, and platform specific models.

Modeling Languages covering technical, functional, and business concerns.

Two alternative options for the modeling of automation systems: unified language, or a meta language covering technical (e.g PSMs), functional (e.g PIMs), and business (e.g CIMs) scopes.

Given a model based engineering framework (e.g MDA), meta-models are generally used to support downstream models transformation targeting designs and code. But when upstream conceptual models are concerned, the challenge is to tackle the knowledge-to-systems transition. For that purpose some shared modeling roof is required for the definition of the symbolic footprint of the targeted business in the automation system under consideration.

Symbolic Footprint

Given that automation systems are meant to manage symbolic objects (aka surrogates), one should expect the distinction between actual instances and their symbolic representations to be the cornerstone of corresponding modeling languages. Along that reasoning, modeling of automation systems should start with the symbolic representation of actual business footprints, namely: the sets of objects, events, and processes, the roles played by agents (aka active objects), and the description of the associated states and rules. Containers would be added for the management of collections.

Automation systems modeling begins with the symbolic representation of actual instances

Automation systems modeling begins with the symbolic representation by systems of actual instances of business related objects and phenomena.

Next, as illustrated by the Object/Agent hierarchy, business worlds are not flat but built from sundry structures and facets to be represented by multiple levels of descriptions. That’s where abstractions are to be introduced.

Abstraction & Variants

The purpose of abstractions is to manage variants, and as such they can be used in two ways:

  • For partial descriptions of actual instances depending on targeted features. That can be achieved using composition (for structural variants) and partitions (for functional ones).
  • As hierarchies of symbolic descriptions (aka types and sub-types) subsuming variants identified at instances level.

On that basis the challenge is to find the level of detail (targeted actual instances) and abstraction (symbolic footprint) that will best describe supporting systems functionalities. Such level will have to meet two conditions:

  1. A minimal number of comprehensive and exclusive categories covering the structural variants of the sets of instances to be uniformly, consistently, and continuously identified by both enterprise and supporting systems.
  2. A consistent but adjustable set of types and sub-types anchored to the core structural categories and covering the functional variants .

Climbing up and down abstraction ladders looking for right levels is arguably the critical part of conceptual modeling, but the search will greatly benefit from the distinction between models and meta-models. Assuming meta-models are meant to ignore domain specific features altogether, they introduce a qualitative gap on abstraction scales as the respective hierarchies of models and meta-models are targeting different kind of instances. The modeling of agents and roles epitomizes the benefits of that distinction.

Abstraction & Meta Models

Taking customers for example, a naive approach would use Customer as a modeling type inheriting from a super-type, e.g Party. But then, if parties are to be uniformly identified (#), that would preclude any agent for playing multiple roles, e.g customer and supplier.

A separate description of parties and roles would clearly be a better option as it would unify the identification of the former without introducing unwarranted constraints on the latter which would then be defined and identified as the realization of a relationship played by a party.

Not surprisingly, that distinction would also be congruent with the one between models and meta-model:

  • Meta-models will describe generic aspects independently of domain-specific considerations, in particular organizational context (units and roles) and interactions with systems (a).
  • Models will define StaffSupplier and Customer according to the semantics of the business considered (b).
Composition, partitions and specialization can be used to detail the symbolic footprint

Composition, partitions and specialization can be used along two different abstraction scales.

That distinction between abstraction scales can also be applied to the conceptual modeling of automation systems.

Abstraction Scales & Conceptual Models

To begin with definitions, conceptual representations could be used for all mental constructs, whereas symbolic representations would be used only for the subset earmarked for communication purposes. That would mean that, contrary to conceptual representations that can be detached of business and enterprise practicalities, symbolic representations are necessarily built on design, and should be assessed accordingly. In our case the aim of such representations would be to describe the exchanges between business processes and supporting systems.

That understanding neatly fits the conceptual modeling of automation systems whose purpose would be to consolidate generic and business specific abstraction scales, the former for symbolic representations of the exchanges between business and systems, the latter symbolic representation of business contents.

At this point it must be noted that the scales are not necessarily aligned in continuity (with meta-models’ being higher and models’ being lower) as their respective ontologies may overlap (Organizational Entity and Party) or cross (Function and Role).

Toward a System Modeling Ontology

Along an analytic perspective, ontologies are meant to determine the categories that can comprehensively and consistently denote the instances of a domain under consideration. With regard to the modeling of automation systems, a relevant ontology would map a subset of semantic categories (for conceptual representations) to functional ones (for systems symbolic representations).

Further Reading

External Links

AlphaGo & Non-Zero-Sum Contests

March 14, 2016

The recent and decisive wins of Google’s AlphaGo over the world best Go player have been marked as a milestone on the path to general artificial intelligence, one that would be endowed with the same sort of capabilities as its human model. Yet, such assessment may reflect a somewhat mechanical understanding of human intelligence.


Human intelligence goes well beyond winning zero-sum contests (Paolo Uccello)

What Machines Can Know

As previously noted, human intelligence relies on three categories of knowledge:

  1. Acquired through senses (views, sounds, smells, touches) or beliefs (as nurtured by our common “sense”). That is by nature prone to circumstances and prejudices.
  2. Built through reasoning, i.e the mental processing of symbolic representations. It is meant to be universal and open to analysis, but it offers no guarantee for congruence with actual reality.
  3. Attained through judgment bringing together perceptions, intuitions, and symbolic representations.

Given the exponential growth of their processing power, artificial contraptions are rapidly overtaking human beings on account of perceptions and reasoning capabilities. Moreover, as demonstrated by AlphaGo, they may, sooner rather than later, take the upper hand for judgments based on fixed sets (including empty ones) of symbolic representations. Would that means game over for humans ?

Maybe not, because human intelligence has evolved against survival stakes, not for games sake, and its innate purpose is to make fateful decisions when faced with unpredictable prospects: while machines look for pointless wins, humans aim for meaningful victories

What Animals Can Win

Left to their own, games are meant to be pointless: winning or losing is not to affect players in their otherwise worldly affairs. As a corollary, games intelligence can be disembodied, i.e detached from murky perceptions and freed from fuzzy down-to-earth rules. That’s not the case for real-life contests, especially the ones that drove the development of animal brains aeons ago; then, the constitutive and formative origins of intelligence were to rely on senses without sensors, reason without logic, and judgment without philosophy. The difference with gaming machines is therefore not so much about stakes as about the nature of built-in capabilities: animal intelligence has emerged from the need to focus on actual situations and immediate decision-making without the paraphernalia of science and technology. And since survival is by nature individual, the exercise of animal intelligence is intrinsically singular, otherwise (i.e were the outcomes been uniform) there could have been no selection. As far as animal intelligence is concerned opponents can only be enemies and winners are guaranteed to take all the spoils: no universal reason should be expected.

So, animal intelligence adds survival considerations to the artificial one, but it lacks symbolic and cooperative dimensions.

How Humans Can Win

Given its unique symbolic capability, the human species have been granted a decisive superiority in the evolution race. Using symbolic representations to broaden the stakes, take into account externalities, and build strategies for a wider range of possibilities, human intelligence clearly marks the evolutionary edge between human and other species. The combined capabilities to process non symbolic (aka implicit) knowledge and symbolic representations may therefore define the playground for human and artificial intelligence. But that will not take the cooperative dimension into account.

As it happens, the ability to process symbolic representations has a compound impact on human intelligence by bringing about a qualitative leap not only with regard to knowledge but, perhaps even more critically, with regard to cooperation. Taking leaves from R. Wright, and G. Lakoff, such breakthrough would not be about problem solving but about social destiny: what characterizes human intelligence would be an ability to assess collective aims and consequently to build non-zero-sum strategies bringing shared benefits.

Back to the general artificial intelligence project, the real challenge would be to generalize deep learning to non-zero-sum competition and its corollary, namely the combination and valuation of heterogeneous yet shared actual stakes.

However, as pointed by Lee Sedol, “when it comes to human beings, there is a psychological aspect that one has to also think about.” In other words, as noted above), human intelligence has a native and inherent emotional dimension which may be an asset (e.g as a source of creativity) as well as a liability (when it blurs some hazards).

Further Readings

External Links

Agile Business Analysis: From Wonders to Logic

March 7, 2016

Time and again new recruits will ask about the role of business analysts. Considering that such a question is seldom heard from software engineers, are BAs more curious about their job, or are they standing on more tentative grounds ? If that’s the case agility would help them to flip-flop between business quicksands to systems hard rocks.


How to make sense of business wonders (Hieronymus Bosch)

Holding the fort vs scouting outskirts

Systems architects and software engineers may have to meet esoteric business requirements, but their responsibility is first and foremost to guarantee the functional and economic sustainability of systems. On that account they are given licence to build solid walls and secure gateways, and to enforce their own languages and rules upon well vetted parties.

Business analysts don’t get such a free hand: while being straitened by software engineers constructs and constraints, their primary undertaking is to explore business wilds, reconnoitre competitors, trace new tracks, and learn the dialects of any nicknamed natives ready to trade.

No wonder the qualms of new business analysts.

Great businesses make their own rules

The best rules in business are the ones still unbeknownst, as success is most often brought by disruptive initiatives taking advantage of previously undiscovered opportunities. It ensues that at its core, BAs’ job description is to relentlessly look across the frontier for still uncharted businesses, and bring them back to the digitized world of shipshape business domains and processes.

For that purpose BAs will have to juggle with the fuzzy idiosyncrasies of new business openings until they can be aligned with the functionalities of “legacy” systems.

BA’s Agility

While usually presented as a software engineering hallmark, agility may be equally useful for business analysts as they have to balance two crossing perspectives:

  • Analysis: sorting detailed activities into business processes.
  • Synthesis: factoring out business functions and mapping them to systems capabilities.

That could be a challenging achievement if carried out sequentially: crossing back and forth between changing scope and steady capabilities could generate unsettling alternatives and unbounded complexity.

The agile development model is meant to tackle the difficulties through iterations and collaboration without being too specific about the kind of agility required from business analysts and software engineers.

Yet the apparent symmetry between the parties may be misleading: whereas software engineers don’t have (and shouldn’t even try) to second guess business analysts, business analysts shouldn’t forget that at the end of the day business expectations, however exotic or esoteric, will have to feed very conformist logical beasts.

Further Readings


Get every new post delivered to your Inbox.

Join 455 other followers