“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.”
It may have taken some time but the symbolic nature of information systems, epitomized by the Stanford University Symbolic Systems Program, is by now better understood, if not generally accepted. That paradigm, combined with the conceptual basis of computer science established long ago, should have induced a broader consensus for the conceptual basis of information systems. Oddly enough, that paradigm didn’t make much inroads; but that may change with the rapid spread of artificial brains and knowledge graphs.
Still, what seems to be lacking is an open conceptual framework that would encompass data, information, or knowledge, and be understood by all kind of protagonists, humans or otherwise.
While a number of modeling languages and frameworks have tried to bridge the gap between business environment and systems, they are rooted in one side. That induces a double bias: first, while they encompass the whole of their native ground they can only achieve a partial view of their target; then, target semantics are coerced into original semantics. Hence the tug of war for definitions between, or even within, business and systems sides.
Taking our cue from the quote above, definition games should be replaced by language games, with concepts being defined by contexts and uses, to be brought together through conceptual hubs.
As to avoid a flight for abstraction or a rainbow chase, the scope and purpose of such hubs should be clearly circumscribed:
- Their footprint must be limited to their potential realization within business and system realms (no inroads into general knowledge management).
- They must be defined independently of their actual realization within business or system sides (no encroaching from system architecture).
As it happens, and not by chance, the design of such concepts can be aligned with their software open-source equivalents.
From Open Software to Open Mind-ware
Open concepts can be defined along the well established object oriented software design principles, except that they will denote sets of instances instead of types:
- Open-Closed Principle (OPC): open concepts should have no reason to change, they can only be refined. In other words open concepts are meant to be specialized, but not generalized. That ensures that the semantics of sub-types defined by different projects cannot be modified.
- Substitution Principle (LSP): sets of instances denoted by specialized concepts are subsets of the sets denoted by more general ones. That ensures that individuals are consistently identified across projects.
- Dependency-Inversion principle (DIP): higher levels semantics are defined independently of lower levels. That ensures that the semantics of sub-types are consistently, but not necessarily uniformly, defined across projects.
- Interface-Segregation Principle (ISP): semantics and features are congruent, i.e all features are meaningful for whoever is using the concept. That ensures that there is no overlapping of semantics even when subsets of individuals overlap.
It is worth to remind that the choice of concepts must be justified by their identified footprint, i.e the instances of business objects and phenomena whose symbolic representation is to be managed by supporting systems.
From Models to Ontologies
Open concepts are symbolic artifacts representing categories of objects and phenomena on both sides: actual instances in business environments as well as their surrogates managed by supporting systems. But while more abstract than traditional classes or types, open concepts should not be confused with meta-classes, patterns or stereotypes:
- Compared to meta-classes, supposed to describe classes on either one or the other side, open-concepts are to target instances on both sides.
- Compared to patterns, they have to saddle both business extensional (aka descriptive) and systems intensional (aka prescriptive) models; as a corollary they are not meant to be directly realized by one or the other side.
- Compared to stereotypes, they have to meet formal principles with clear derived logical properties.
As a consequence, open-concepts should be managed separately, ontologies being their natural habitat.
If open concepts are to be used by external (environment) and internal (enterprises) maps, they have to support unified identification mechanisms and tally with structural and functional features common to both sides.
Assuming that the objective is to describe interactions with systems, the first thing to do is to define physical entities carrying out the interactions. For that purpose only a small set of features are necessary: physical occurrences, persistent identity, social identity, ability to interact, communication capabilities. On that basis four categories of agents can be distinguished.
- People: active entities with biological and social identities, able to communicate with symbolic and natural languages.
- Systems: active entities, with designed physical identities, able to communicate with symbolic languages.
- Devices: active entities, with designed physical identities, unable to communicate with symbolic languages.
- Non human live organisms: active entities with biological identities, unable to communicate with symbolic languages.
Beside active entities interacting physically with systems, open concepts are to deal with:
- Passive entities with or without identities.
- Symbolic entities (contracts, organizational entities, etc) with social identities; not active per se they can only interact with systems through representatives.
As far as modeling is concerned a distinction has to be maintained between the description of activities and the control of their execution, ensuring
that the respective semantics can be aligned.
To that end, open concepts are to take into account the nature of the flows (actual or symbolic), and the type of coupling between environment and system (synchronous or asynchronous).
Regarding contents, the focus is to be put on what activities do:
- Action on symbolic representations without coupling with the context (no change).
- Action on symbolic representations with coupling with context (change in expectations).
- Interaction with actual context without direct coupling (change in process status).
- Interaction with actual context with direct coupling (change in objects).
Regarding execution the focus is to be put on how activities collaborate:
- No flows (computation).
- Information flows between activities.
- Actual flows between activities, asynchronous coupling.
- Actual flows, synchronous coupling.
That distinction between business logic and processes control is at the core of enterprise architecture.
With regard to the qualified footprint assumption, the events to be considered are those occurring between systems and environments. As a corollary events are to be classified with regard to associated changes (symbolic or actual) and their coupling with actual processes (synchronous or asynchronous):
- Actual (aka non symbolic) changes in the state of objects.
- Actual (aka non symbolic) changes in the state of activities.
- Changes in the state of expectations (e.g requests/acknowledgments).
- Neutral changes in symbolic representations (e.g messages).
It must be noted that in order to meet the open concept principles events must be continuously and consistently identified across environments, including the systems.
Partitions (aka classifications, aka taxonomies) are symbolic artifacts used to define subsets of objects or phenomena. Open partitioning concepts are the primary scheme available to saddle business and system open concepts.
- Structural partitions apply to identified objects and behaviors during the whole of their life-cycle. As a consequence they cannot change or overlap.
- Functional partitions apply to the features of objects and behaviors. They may change or overlap during their life-cycle.
Time-Frames & Address Spaces
Time-frames and address spaces (physical or organizational) are containers used to identify activities and objects.
Regarding activities, instances are identified by controlling events: changes in the states of symbolic representations, expectations, objects, or activities.
- Internal time-scales deal with the synchronization of changes limited to symbolic representations.
- Synchronous time-scales deal with the coupling between changes in objects or processes states and corresponding symbolic representations.
- Asynchronous time-scales deal with changes in expectations.
Regarding objects, instances are identified within physical or symbolic spaces, depending on coupling constraints between actual states and corresponding symbolic representations.
- Domain address spaces are used to identify symbolic surrogates.
- Organizational address spaces are used to identify agents interacting with systems.
- Physical address spaces are used to identify devices.
- Network address spaces are used to identify other systems.
From Open Concepts to Conceptual Blueprints
Assuming the OO principles listed above are fulfilled, the use of open concepts is straightforward.
When open concepts are used for entities (aka roots):
- Structural inheritance means that the domain instances considered inherit both structures and aspects: parties are a subset of social agents.
- Functional inheritance means that the domain instances considered inherit all the aspects whatever the identified structure: branch has all the features of a physical location but is not necessarily identified as such.
When open concepts are used for aspects (aka features), these aspects are defined independently of entities:
- Structural inheritance is equivalent to composition, i.e inherited aspects are bound to domain individuals whatever their structure: symbolic references are an intrinsic component of products but can be used in any kind of domain.
- Functional inheritance is equivalent to aggregation, i.e inherited aspects are not bound to domain individuals: manufacturers’ addresses can change.
Open Concepts & Enterprise Architecture
The benefits of open concepts are to be found all across enterprise architecture.
To begin with models, they provide a conceptual (i.e non programming) solution to the bounded context issue.
Then, in the broader perspective of model based systems engineering, open concepts can be used to bridge the gap between computation independent (CIM) and platform independent (PIM) models, and consequently help to redeem conceptual debts (CD). That may also leverage the restructuring of technical debts (TD) and consequently further in-depth digital transformation.
As for implementation, open concepts could be introduced step by step:
- First through conceptual thesauruses serving as some kind of back office for modeling languages and methods (a).
- Then, they would be progressively generalized as blueprints across models, consolidating business domains and mapping environments to systems functionalities (b).
- Finally, they would be refactored as to become parts of ontologies (c).
- Modeling Paradigm
- Open Concepts Will Make You Free
- Projects Have to Liaise
- Reflections for the Perplexed
- System Conceptual Thesaurus
- Ontologies & EA
- UML’s Semantic Master Key, Lost & Found
- Conceptual Models & Abstraction Scale
- Specialization vs Generalization
- The Finger & the Moon: Fiddling with Definitions
- Redeeming conceptual debts
- Digital Transformation & Homeostasis