Open Concepts Will Make You Free

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

Preamble

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.

FRANCE. Languedoc-Roussillon region. Nimes. 1989.
Abstract & Concrete Trees (Martine Franck)

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

cc
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

Conceptual Models & Abstraction Scales

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-at-bahaus
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 an Ontological Framework for Enterprise Architectures Modeling

Along an analytic perspective, ontologies are meant to determine the categories that can comprehensively and consistently denote the instances of a domain under consideration; applied to enterprise concerns that would entail:

  • Thesaurus: for the whole range of terms and concepts.
  • Documents: for documents with regard to topics.
  • Business: for enterprise organization and business objects and activities.
  • Engineering: for systems surrogates associated to enterprise organization and business objects and activities

Ontologies provide a common conceptual framework for  models and meta-models

That would open the door to a seamless integration of business intelligence, systems engineering, knowledge management, and decision-making.

Further Reading

External Links