“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’s Program, is by now better understood, if not generally accepted. That understanding, 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 didn’t happen.
What seems to be lacking is an open conceptual framework that could be applied to all protagonists, humans or otherwise: while a number of modeling languages and frameworks have their sights on that objective, most are rooted in one side, business or systems. As a consequence they encompass too much of their respective ground but not much of what should be shared.
As suggested by the introducing quote, concepts must help to choose the options best suited to the tasks at hand. With regard to systems modeling, the objective would be to set up a conceptual hub between business and system descriptions. But lest such endeavor turns into a flight for abstraction or a rainbow chase, the scope and purpose of the concepts are to be clearly circumscribed:
- Their footprint must be limited to their potential realization within business and system realms (no inroads into knowledge management).
- They must be defined independently of their actual realization within business or system realms (no encroaching from system architecture).
Taking a cue from the software open-source paradigm, they could be designated as open and built along similar principles. And to be of any use open concepts should have to be associated with a conceptual thesaurus.
Open concepts can be defined along the well established OO 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 candidates must be selected with regard to their realization footprint, namely the sets of individuals in business environments whose symbolic representation is to be managed by supporting systems.
Open concepts are symbolic artifacts representing categories of actual objects and phenomena. As such they provide a modeling bridge between business processes and supporting systems functionalities.
They represent (left to right): locations, physical objects, symbolic objects, roles, events, activities, processes, and partitions.
Open concepts should not be confused with patterns or stereotypes:
- 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.
First among these logical consequences is that open concepts can be exclusively partitioned as structural and functional, the former for structured objects or activities identified externally, the latter for features with shared semantics agreed upon by communities.
Assuming that the objective is to describe interactions with systems, the first thing to do is to define physical entities. 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 can be distinguished.
- Physical agents: active objects, with persistent physical and social identities, able to communicate with symbolic and natural languages.
- Systems: active objects, with persistent physical identities, able to communicate with symbolic languages.
- Devices: active objects, no identities, unable to communicate with languages.
- Things: passive objects, no identities, unable to communicate.
Symbolic objects (contracts, organizational entities, etc) are identified within social frameworks. They are not active per se and cannot interact directly with systems.
Activities, or more precisely performing activities, are transient occurrences set in time-frames and address spaces. Since the focus is to be on the interactions between systems and contexts, activities should be first classified with regard to what happens and to what effect:
- Activity: are systems supposed to support actual process execution.
- Coupling: are changes to be registered immediately.
Execution mode of activities
On that basis there will be two typical symbolic activities:
- Computation: no relevant change in the actual environment has to be registered, and no activity has to be supported.
- Monitoring: no relevant change in the actual environment has to be registered, but the system is supposed to keep track on some activity.
And two actual activities:
- Changes in expectations of users, systems, or devices (achievements).
- Changes in actual objects (accomplishments).
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):
- Neutral changes in surrogates (e.g messages).
- Changes in the state of expectations (e.g requests/acknowledgments).
- Actual (aka non symbolic) changes in the state of objects.
- Actual (aka non symbolic) changes in the state of activities.
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
When 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.
Such concepts are meant to be managed by a conceptual Thesaurus.
serving as some kind of back office for modeling languages and methods. The next step would be to define blueprints from open concepts and use them to map business concerns to supporting systems functionalities.