Systems Semantics
If you are willing to design or compose architecture metamodels, specification languages (notably modeling languages), methods and architecture tools, or if you are simply looking for semantics to precisely align business and IT concepts then this paper is for you.
The semantics defined in this paper are used as references for creating homogenous specifications of heterogeneous systems that are not necessarily intentional and that can involve humans, software and machinery.
The semantics are these of a system (any system) that resides in any combination of the mental, digital or physical spheres.
|
|
|
Technical terms used in the industry |
Homogenizing semantics using terms defined in the reference semantics |
|
Business Process; Workflow |
A process involving resources and performers from different spheres. |
|
Entity (within a “Domain Model”) |
A resource involved in a system. Such resources are often mirrored and transphered across multiple spheres. |
|
Function (as in TOGAF) |
Role. |
|
Actor |
|
|
Functional feature |
The role of a software (digital performer) or machinery (physical performer). |
|
System Use Case |
A process involving resources to be transphered between mental and digital performers playing defined roles. |
|
Scenario |
|
|
Service |
A performer playing some instituted role to act as a delegate for other performers. The delegating performers are not necessarily predetermined. |
|
Software system; Software component; Web service; C# class |
A digital performer playing some specific role at a specific scale. |
|
Orchestration |
A process involving digital resources, roles and performers. |
|
Interface; Service contract (in web service) |
|
|
Method of a class; Operation on a service contract (in web service) |
|
|
Data contract |
The type of digital information (i.e. some specific type of resource) that can be exchanged between digital performer roles. |
Contents
Reference Systems Semantics – Quick Links
Sample Semantic Normalizations
Spheres (Physical, Mental and Digital)
Evolution, Cause, Effect, Initial State and Resulting State
Recurrent Resource Structures and Scenarios
Goal, Desired State, Desired Evolution and Desired Operation
Role, Role Player and Controlled Resource
Optimizing Role Definitions, Compositions and Assignments
System (Organized to Optimize)
Organized to Optimize across spheres
Roles and Delegation Across Spheres
Sample Processes Spanning Multiple Spheres
Integrated Systems Semantics Applicable to all Spheres
Architecture frameworks (like TOGAF, Zachman, NAF), architecture modeling tools, modeling languages (like Archimate, BPMN and UML) and IT portfolio management tools have a metamodel. Their metamodel describes the concepts and relationships that they are based upon. This is their DNA, their foundational semantics.
In a very ideal world, architecture frameworks should integrate, modeling languages should integrate and tools should also integrate by sharing a common metamodel, at least for the scope that they have in common.
Unfortunately we are still living in a world of semantic silos. Metamodels, languages and tools are often difficult to interpret, to compare and to integrate.
Automation by Nature defines some systems semantics, a less common denominator that can be used to create metamodels or to align semantics between metamodels. These semantics are notably the basis for “creating homogenous specifications of heterogeneous systems that are not necessarily intentional and that can involve humans, software and machinery.”
I personally use these also as a reference to better comprehend complex documents especially when their structure is a bit approximate. For example, in a technical document like a software requirements document, I use it to highlight some key words using specific colors corresponding to specific categories of semantics. This is useful groundwork for further refinement, formalization and for modeling in particular.
The primary goal of this paper is to define very simple and natural concepts to ease specification and communication across any domain of expertise (not only computer science). Hence, in order to reach this main goal, we decided to create some reference semantics featuring the following properties:
· Natural and intuitive as it conforms to the evolution of nature
· Easy to communicate, as we can use such common natural “language”, whatever our background and role can be
· Not formal at this stage. Yet it is focused and precise enough to be used as a reference for creating formal meta-models and specification languages.
· Flexible, as its concepts can be informally “specialized” (just referenced) for specific domains. When needed, the derived domain specific concepts can be used as formal integration points between different domains.
· Homogenous, like its concepts and terms that are common across the physical, mental and digital sphere. What is thought to be heterogeneous is actually homogeneous
Automation by Nature defines a tactical plan for reaching its goal. In this plan, the first step is the definition of these semantics that we will further describe in the following sections…
To define some systems semantics featuring the above properties, we simply follow the natural phenomenon. We follow the process of evolution, adding complexity step by step, mimicking the evolution of nature itself.
|
|
The incremental complexity of nature starts from fortuitous physico-chemical systems. |
|
|
At some point, life fortuitously appeared along with the intention to survive. |
|
|
Step by step, beyond basic intentions, humans tried to organize in order to optimize the way they fulfil their intentions. They delegated part of their work to animals and other humans, then to machinery and finally to computers. |
|
|
Today, humans try to rationalize such complex delegations into optimized heterogeneous systems. Humans want to organize and optimize systems involving the physical, mental and digital spheres. |
The concept of “spheres” is quite easy to grasp. It is just a matter of simple observation. A key observation is the fact that similar things can exist and evolve either mentally, physically or digitally.
For example, the document that you are reading now might exist and evolve in multiple forms:
· A digital resource on the Internet
· Its physical representation on your screen
· A physical paper document in your hands
· A mental resource in your brain (since you are reading and creating a perception of the document)
Similarly, humans, animals, washing machines, cars, engines, computers etc… are performers that belong to and that intentionally influence either the physical, mental or digital sphere (or a combination of those).
We define the physical, mental and digital spheres as follows:
Physical Sphere
The extension of the general conception of the physical nature; the totality of the physical resources and physical phenomena that pertain to this sphere.
Mental Sphere
The extension of the collective aspects of intellect and consciousness; the totality of the mental resources and mental phenomena that pertain to this sphere.
Digital Sphere
The extension of the collective aspects of digital resources including software; the totality of the digital resources and digital phenomena that pertain to this sphere.
Spheres are a consequence of the natural phenomenon. evolution started in the physical sphere. Today, humans are creating systems spanning the physical, mental and digital spheres.
· Life fortuitously appeared in the physical sphere (NB: We are respecting every belief and it is up to the reader to decide what “fortuitous” really means)
· The mental sphere rose from a conscious and exacerbated intention to survive.
· Intention led to conscious delegation to people, animals, machinery and software. Humans delegate to software by reproducing part of the physical and mental spheres into the digital sphere.
The semantics that we define are derived from patterns that we can easily observe in nature. The semantics provides terms to express this semantics. The natural patterns, the semantics and the semantics apply to all spheres.
Now that we have set the stage, let’s see what these semantics really are…
We start from a simple perception of the natural phenomenon including the evolution of things in general.
A fortuitous system involves non intentional physical or chemical evolutions like « salt dilution in water».
At every specific moment in time, an infinite number of resources are in a specific state. Physical and chemical phenomena naturally trigger evolutions without any intentional intervention.
Even though recurrent scenarios do take place, nothing can be considered as “intentional”. At this stage, there is no concept of “goal”. Evolutions occur without any intentional intervention. Everything is fortuitous.
At every specific moment in time, an infinite number of resources are in a specific state.
There are many types of resource and many types of state including volume, mass, temperature, location, color etc…
The state is a fundamental specification concept that we will leverage to make our specifications and creations tangible and measurable.
|
Important Note
From the perspective of living beings, every entity is a potential resource. Therefore, we use the word “resource” and not the word “entity”, “object” or equivalent.
We will further talk about “resources” while studying intentional phenomena.
|
Physical and chemical phenomena naturally trigger evolutions without any intentional intervention.
An infinite number of resource states induce an infinite number of resource states.
In other words, the continuous and fortuitous evolution of a resource state from initial state towards resulting state is caused by the fortuitous state of resources.
For instance, the evolution of water temperature might result in the water to freeze and its volume to grow. That new state causes evolutions of surrounding resources state.
A resource state can be the cause of the evolution of a resource state (the same or another resource).
The evolution of a resource state is the effect of a resource state (the same or another resource).
Location is a kind of state. Terms like “geography” and “composition” refer to the location of some resources that is related to the location of some other resources.
The evolution of resource locations and co-locations causes all sorts of other evolutions including new co-locations to appear and to disappear. This new states in turn cause other evolutions etc…
Examples are of course everywhere, like for instance, the co-location of salt and snow that triggers chained evolutions.
Evolutions are fortuitous. Evolutions lead to accidental (co-located) structures of resources that lead to other accidental evolutions and structures of resources.
See also operation and process.
A scenario is a recurrent sequence of evolutions involving recurrent types of resource.
Among the infinite number of resources, states and evolutions, some recurrences appear:
— resources organize into recurrent resource structures.
— Recurrent resource structures tend to follow some recurrent sequences of evolutions that we will call scenarios.
See also: System (Intentional), System (Organized to optimize), System (Organized to optimize across spheres)
Recurrent resource structures lead to recurrent scenarios and vice versa.
The stabilization of recurrent structures and scenarios (some call these patterns) leads, over time, to a growing number of more complex recurrences based on simpler ones.
Hence, we define a system (a system that can be fortuitous or intentional) as a recurrent structure of resources involved in recurrent scenarios.
A system following Webster’s definitions (http://www.webster-dictionary.net/d.aspx?w=system):
— An assemblage of objects arranged in regular subordination, or after some distinct method, usually logical or scientific; a complete whole of objects related by some common law, principle, or end
— (Biol.) An assemblage of parts or organs, either in animal or plant, essential to the performance of some particular function or functions which as a rule are of greater complexity than those manifested by a single organ
In the section dedicated to “Intentional systems”, you we will see that a performer is a specific kind of resource performing some operations. A performer can be human, software, machinery or any combination of these. J
And in the section called “Organized to optimize”, you will see that, within an organized system, depending on their capabilities, performers can play specific roles.
But in the phenomena that we have studied so far, everything was fortuitous. There was nothing to be considered as “intentional”. There was no concept of goal.
An intentional system involves operations (intentional evolutions) realized by performers.
A performer can be, for instance a plant, an animal, a human. It can also be a software, some machinery or a complex robot to which the human delegates.
From the viewpoint of a living being, every entity in the universe is seen as a potential resource. This resource can be used to fulfill its intention, its goal i.e. the subsistence and “good” state of its species or just of itself.
Resources, that are created or changed over time, are products of fortuitous or intentional evolutions. Basic “intentions” and basic operations are just the result of natural selection of scenarios that work.
See also performer , information and goal
A resource can be any physical, mental or Digital “thing”, any “entity”.
While complexity grows, auto-generative structures of entities and scenarios appear.
These auto-generative structures accidentally ensure their own subsistence.
From the perspective of such auto-generative structure, i.e. such being, every entity in the universe is seen as a potential resource that can be used to fulfill its intention, its goal i.e. its subsistence and its own “good” state.
This is the reason why we are not talking about the state of “entities” or “objects”. We are talking about the state of resources. For any complex being, like plants and animals, every entity, like minerals, or other auto-generative structures, is a potential resource.
And, in order to survive, every being needs useful and interdependent resources to survive as well.
Resources assemble naturally. The universe is an infinite assembly of resources. At every level of granularity, any resource is a structure of some other resources.
Resources, that are created or changed over time, are products of fortuitous or intentional evolutions.
Subsets of this infinite assembly can be acquired and relocated. These re-locatable sets of resources are often considered as a whole. They are sometimes called compositions.
Auto-generative structures “recognize” “useful” recurrent structures in their environment. In other words, this means that they classify surrounding resources.
See also performer type and performer instance
We use the word “performer” to designate a specific type of resource structure that intentionally influences the evolution of other resources. Some resources are performers and some are not.
You can think of a perfomer as a being that can be biological, artificial or a combination of both. An artificial perfomer can be, for instance, a running software instance or a washing machine. A complex performer can be for example a factory that includes humans, software and miscellaneous machines.
Since a performer is a resource, a performer can also influence the evolution of other performers. For example, we often talk about a human delegating to another human or to a machine. A more dreadful example is the predator and the prey.
Note that this evolution is not necessarily the intention of the performer itself.
For example, think about a human performer who is intentionally influencing the pace of a horse that is changing the state (the location) of a carriage.
Or consider a human performer influencing a software performer that is changing the state of an account.
So the intention can be also the intention of a first performer using a second performer as a resource. Hence in effect, we get a first resource influencing the state of a second resource which influences the state of a third resource. That is a first performer influencing the state of a second performer that in turn influences the state of a resource.
While the state of the universe evolves, the most adapted performers subsist. Others disappear. Ecosystems are made of complementary resources.
From a performer viewpoint, every entity in the universe is a potential resource including performers themselves.
As we will see further in details, resources and performers belong to one or several spheres.
For instance, a human is a mental and physical performer. A human is a resource that, obviously, belongs partly to the mental sphere and partly to the physical sphere. There is no digital dimension of the human being.
See also “capability” to find an important distinction between capabilities of performer types and performer instances.
From the surface, we can observe that operations involve resources as these resources are used, created, destroyed or modified.
Of course, we know that an operation is a chain of more elementary evolutions.
And the evolved resources are
— the performer of the operation
— the target resource that is meant to evolve
— maybe some other resource(s) involved in the operation.
Operations are Intentional
An operation is an "intentional" evolution because it is “executed” by a performer aiming at a desired state of some resource(s).
The goal of the performer might be to get such resource in order to evolve and to reach some desired state. And this evolution requires the evolution of the acting performer itself.
The evolving resource, the aim of the operation, can be the performer performing the operation or another performer as well.
The evolving resources include the performer of the operation
Fundamentally, there is a recurrent scenario in the way a performer performs a single operation:
— The performer, as a resource, performs operations to change its own state.
— This will in turn cause the state of the target resource to evolve.
For example, you have to move your hand in order to move the mouse or paper that you are holding.
An operation is an intentional evolution of both the performing resource and the target resource. If the target resource does not need the performing resource to evolve then it is no longer intentional. It is a fortuitous evolution, not an operation.
It is interesting to note that, when you are using weights to perform some physical exercise, the recurrent scenario still applies.
But the target resource is also the performer. You are the performer and you are aiming at a positive evolution of your own state. You are also changing the state i.e. the location of these weights, but that is not the original aim.
Evolution and operation have no state per se
An operation is some kind of evolution. But these are not resources. Hence they have no state to be measured.
However, a performer is a resource along with the resources that it is influencing through its operations. These resources have a state that can be measured.
When we talk about an evolution or an operation that is “stopped”, we are “stylizing” the fact that the resources involved, including the performer if any, are no longer evolving in a significant manner from a performer standpoint.
We can measure that a performer stopped evolving, stopped performing. To achieve this, we can measure its state over time.
We can also measure the state of resources that the performer is supposed to influence over time.
See also event news
An event is the appearance of some significant resource state, that state being the result of some significant evolution for a particular performer.
A single resource is subject to an infinite number of evolutions.
Some evolutions are significant because they induce significant states.
Composition is a Resource State
From the standpoint of the composite (vs the standpoint of the component)
ð The state of a resource is the state of its components
ð Adding a resource X to a resource Y changes the state of resource Y
An event indicates that the state of some resource completed some significant evolution e.g. the resource has been created, destroyed or changed.
It is significant because it will influence performers and trigger subsequent evolutions.
Information is a kind of resource
Therefore, as any other resource like water or steel, it also has a state that evolves over time.
Performers have knowledge about some resources and their state. There are resources that performers know and others that that they don’t know about.
Acquiring and Deducing information
Among operations that performers can execute, there is the recurrent acquisition and production of resources. One kind of resource that performers can acquire and produce (deduce) is information.
Information is a kind of resource that performers can acquire or deduce:
— Information can be the perception of some significant state using any kind of sensor. For example, most biological performers and some devices have sensors to capture the temperature.
— Information can also be the product of some operations performed on other information.
Whether the performer is human, software or vegetal, it is still acquiring or deducing information in its own way.
See also event
We need to distinguish the appearance of an event and the information about the event i.e. the event news.
There is often a delay between the happening of an event and the acquisition of the information about the event (the event news) by a performer.
This delay can be quite significant in the non digital sphere. And this is one of the rationales for “transphering” resources from the physical or mental sphere to the digital sphere.
A goal is a kind of information about some desired evolution, desired operation or desired state.
A goal is information like the need for food “written” in our brain, SMART goal statements written on paper, formal goal specification written using a computer readable format...
A goal is a kind of information that usually appears as a complex configuration of mental resources.
A goal is, initially, the fruit of natural selection. This information, this knowledge, this experience has been gathered over time.
Event and Motivation
An event can reflect the appearance of a desired or non desired state. This differentiates scenarios leading to success or failure. The former will lead to a desired evolution and a desired state. The latter will lead to a non desired state.
The word “goal” is a generic word usually expressing a desired state. Words like “failure”, “exception” refer to events that express the appearance of a non desired state.
Biological performers are decision makers struggling for their subsistence, turning their face to “sunlight” to keep themselves in the most acceptable state. Sunflowers and presidential candidates are quite representative biological performers.
Knowledge about desired and non-desired events (the appearance of desired and non-desired states) is important information for performers i.e. for decision makers that need to act and react following positive or negative evolutions.
Hopefully, state is measurable. So can be the desirable and undesirable. That is a benefit of state-driven approaches
What is the nature of motivation and what is motivation with regards to nature?
On a first whim, performers want resources to be in a certain desired state at a certain point in time. For instance, we might want a chocolate cake for Sunday.
To reach that state, a performer will trigger some desired evolutions i.e. perform some simple or complex desired operations. For instance, the performer might want to complete a profitable exchange of values in an optimal time-frame. Or in order to subsist, the performer might adapt itself, as a resource, to its new environment.
But more realistically, the performer wants to influence nature continuously. The performer wants to continuously influence the state of some resources towards a desired evolution. We want things to evolve towards the direction that we wish. We want “enough” love and “enough” money to acquire the resources that we need every day versus one single time.
Then to reach our goals, we want to have the necessary information (resources) to take decisions and perform adequate operations.
Biological performers are struggling for their subsistence. They are getting resources in order to evolve and to keep themselves in the most acceptable state.
In order to sustain some desired evolution towards desired states, performers will perform some desired operations.
Of course, expressing goals in terms of evolutions or operations e.g. “you’ve got to do start the dish washer” is not very useful. What is more useful, is to express goals in terms of target state “dishes must be spotless at 10PM”, or in terms of target trend e.g. ”dishes must be spotless every day at 10PM with a decreasing number of failures”.
See also: System (Fortuitous), System (Organized to optimize), System (Organized to optimize across spheres)
Earlier in this document, while analyzing fortuitous phenomena, we defined that a system is a recurrent structure of resources involved in recurrent scenarios.
While analyzing intentional phenomena, we defined, notably that the system can involve specific type of resources that we call “performers”. Such system involves specific types of evolutions that we call “operations”. The operations are performed by performers that have some defined performer goals.
resources are shown with a green
background color.
We have seen that a system can present fortuitous and intentional dimensions. Beyond simple intentional patterns like “When tired then sleep”, living beings (performers) “learned” to intentionally organize in order to optimize the way they can reach their goals.
Such organization includes resource optimization, role delegation, resource sharing and process optimization.
Resource Optimization
We have seen earlier that resources can be any physical, mental or digital entity, and that they can assemble fortuitously or intentionally into structures.
We also identified some specific types of resources including
· Performer: a specific type of resource structure (like human, software or machinery) that intentionally influences the evolution of other resources.
· Information: a kind of physical, mental or digital resource that performers can acquire or deduce. That can be the perception of some significant state or the product of some operations performed on other information.
· Goal: a kind of information about some desired evolution, desired operation or desired state.
Performers undertake different types of resource optimizations in order to reach some goals. Such optimizations typically include assorting (grouping, splitting, cloning, classifying…) and transmitting (acquiring, relocating and providing) resources.
Since performers are resources, this means that performers optimize performers.
We will see that optimizing performers includes optimizing oneself and delegating one’s roles. And we will see that delegation is itself optimized by leveraging performers’ capabilities.
See also delegate, delegation, capability, expected goal
Besides knowledge (known resources), a performer can also have some controlled resource. The performer can control that resource. He/she/it is in a position to influence the state of that resource.
Some performer can be chosen as a role player because the performer controls an expert domain of resources (see also capability).
The controlled resource can be physical, mental or digital. The controlled resources can be performers.
A role is a part that can be played by some performer. A performer can play one or several elementary roles.
A role has some expected goals. These expected goals can be explicitly expressed as desired evolution(s), desired operation(s), or desired state(s).
A role can be used as a mean to categorize performers i.e. to designate a set of performers. For example, one can consider the type of, the set of software products that have the capability to play the “Contact Manager” role.
A capability is the relative ability to play some role in a system.
A performer has the capability to play some role because the resources that the performer controls covers the expert domain of resources needed to play the role (see also controlled resource).
Here, it is important to remind that information and performer are specific types of resource, and that resources can belong to the physical, mental or digital sphere. The information that a capable performer controls can be the knowledge of some processes. Such process can involve notably the role that the performer is capable of playing.
Of course, a performer does not necessarily play all the roles that he/she/it is capable of. As an example, humans’ capabilities will always be underused.
Optimizing capabilities
A performer’s capability of playing some role is optimized when the performer controls the expert domain of resources to play that role.
For example, in order to become a strong C# developer, one need to have expert control to C# and .Net related resources. Many of these resources should be preferably located in the mental sphere i.e. the programmer’s brain. Some should be easily controllable in the digital sphere (C# forum, C# on-line library). And some should be available in the pure physical sphere (books about C# etc…).
Capabilities of performer types and performer instances
As far as capabilities are concerned, it is also important to make a distinction between a performer type and a performer instance.
Here is a “human” example: “Project Manager” is a type of human performer. The “Project manager” is typically assigned the role of “Defining the project plan”. This role is typically a subset of the “Planning“ role in a business organization.
The actual instance of the “Project Manager” (the specific person) will need to have, notably, the capability of defining the project plan.
And here is a software example: “Microsoft Project” is typically a type of software performer that is assigned the roles of “storing the definition of the project plan” and “presenting the plan on a report”. Storing and presenting the project plan are also subsets of the “Planning” role.
An actual software instance of “Microsoft Project” will need to have, notably, the capability of storing the project plan.
This illustrates some of the important differences between software and human performers:
· Software performers: If one instance of the “Microsoft Project “ software has the capability to play the role of “storing the project plan”, there are many chances that all other instances of “Microsoft Project“ will have that same capability. This means that for the case of software, the capability of a performer is very close to the capability of its performer type.
· Human performers: If a “Project Manager”, i.e. one instance of the “Project Manager” human performer type, has the capability to play the role of “Defining the project plan”, this does not guarantee at all that all other “Project Managers“ will have that same capability. This means that, for the case of humans, the capability of a performer does not necessarily correspond to the capability of its performer type.
Optimizing a system’s organization is all about optimizing delegation. We will therefore develop the concept of delegation quite extensively.
A basic intentional system organization can be made of a single performer playing all roles. For example, think of a single person company where the owner plays the executive, marketing, purchasing, sales and accounting roles.
In a more sophisticated system organization, performers use delegates: Some delegating performers delegate to delegate performers playing specialized roles. The delegating performers and the delegate performers can be human software or machinery.
For example, the accounting role can be played by an accountant (human) who in turn delegates part of his role to some accounting software that generates an account book.
As another example, think of an Ergonomic Furniture Reseller company that starts as a single person organization and evolves towards a more and more complex organization of specialized roles.
Hence, performers intentionally delegate roles to other performers for the purpose of resource specialization and optimization.
The next figure presents a farmer that delegates the sowing to a sower, assuming that the sower has the capability to play that role. In other words the farmer assumes that the sower controls a sufficient part of the expert domain of resources in order to reach some expected goals. Resources, including performers, can be physical, mental or digital.
Delegating one’s role means delegating some goals. The delegate performer now has expected goals corresponding to the role that he/she/it plays.
Human performers tend to delegate more and more to software performers. But, on the other hand, software performers also delegate to humans e.g. for taking decisions requiring resources that the software does not control. For example, an editorial software package would delegate to humans for writing the articles and for deciding whether some article will be published or not.
A role organization is a hierarchical tree while the performers that play the roles can be organized into a network.
For example, the “shipping” role can be part of your roles organization. However, the performer playing that role can be a performer standing outside your performers organization. An external performer, e.g. “The Shipping Company”, might have been selected to play the “Shipping” role because that external performer organization shows adequate capabilities to play that role.
While roles organize into hierarchical trees, specialization leads performers to get more and more organized into networks versus hierarchies. For example, in the physical sphere, an international book seller typically delegates the shipment of its books to an external a performer specialized in international shipment of goods. In the digital sphere, “service oriented architecture” applies this principal of external and specialized delegation to software.
Optimizing Role Definitions, Compositions and Assignments
Such optimizations can directly apply the concepts that we defined so far.
These optimizations can be fortuitous, intentional or both, depending on the perspective we choose. On one hand, natural selection induces some fortuitous optimization of role definitions, compositions and assignments. On the other hand, living beings perform intentional operations leading to such optimizations with more or less success.
Optimizing the role hierarchy
— A role hierarchy (and the related goals hierarchy) should reflect a decomposition of the top organization role (and long term goals).
— It should leverage available (and useful) capabilities
— It should allow for some flexibility to accommodate changes in terms of capabilities needed and performers availability.
· The role hierarchy should be free of redundant or conflicting goals. See also the “Sharing Goals and Resources”, where we analyze these aspects in further details.
Optimizing the composition of performers
Within an optimized composition of performers, each performer should have the capability to play its role. In other words, each performer should control an appropriate expert domain of resources that is required to play that role.
Sharing Goals and Resources
Sharing a goal is sharing information about some common desired evolution, desired operation or desired state.
For a performer (human, software, machinery…) to delegate some role, the performer needs to share some of its controlled resources to its delegate(s). Shared resources can be material, information… or any performer to which further delegation can take place.
Conflicting Goals
Conflicts arise from incompatible goals regarding desired state of the shared resources.
Rationalizing roles, goals and resources is much easier when it applies to software or machinery. When it comes to humans, many conflicting roles appear.
When we think about conflict or interests, we usually think of different performers or roles controlling a same resource at a specific moment in time and willing to make this evolve to a different state (including their own state since a performer is a resource as well).
In the example below, Martin and Helena want some resource, or more precisely a performer called Alfred playing the role of a Database Expert, to perform some different operations at the same time. And Alfred would like instead to attend the Microsoft Tech Ed conference.
A conflict of interest can also involve one single performer playing multiple roles. We are all playing multiple conflicting roles.
No conflict of interest per se when delegating to software and machinery
In the mental sphere, there is creativity along with the ability to manage the unpredictable. But there are also conflicting goals towards the state of some resources.
In the digital and physical spheres, precision, speed, scalability, robustness and obedience are the benefits of delegating repetitive operations to Software and Machinery. There is no conflict of interest per se. There are conflicting forces and conflicting algorithms, but these are predictable and measurable so they can be taken into account.
Expected Goal versus Performer Goal
Living beings are performers that have intrinsic performer goals. When we assign a role to a performer, we are also assigning some expected goals that are genuine to the role… but not necessarily genuine to the performer.
The problem is that performer goals often conflict with the expected goals of the role. Therefore, humans came up with “incentives”. Such incentives are actually substitute performer goals.
A well-chosen incentive will ensure that an operation, performed in the context of a role, will realize both the expected goals and some genuine performer goals.
Let’s take the example of a Sales person
Problems with “substitute goals” approach (or at least with the existing implementations of this approach)
Today, substitute goals are institutionalized and exacerbated. They are short term goals in the sense that they are rarely spanning more than one year. Substitute goals are also usually individual goals.
So here is a question bridging rational analysis and philosophy: How can substitute goals lead to genuine long term goals of a community? In other words, can a world driven by substitute goals become a viable eco-system?
|
Reminder As we have seen earlier, a scenario is a sequence of evolutions leading to some significant states. Some evolutions can be fortuitous while other can be intentional. Intentional evolutions are operations realized by performers e.g. « dropping salt in water». In this case, the performer is typically a human. Fortuitous evolutions are just physical or chemical evolutions like « salt dilution in water».
Besides delegation and resource sharing, performers also try to optimize the process starting from an initial state and trying to reach some desired state.
|
A process is a complex operation with multiple intrinsic variants. A process represents a set of scenarios that have a common initial state. Some scenario(s) will lead to the desired state. Other scenarios will lead to some other, non-desired, resulting state.
Each scenario involves a set of participants. These participants are roles performing a sequence of operations and a sequence of evolutions including operations performed by the participant roles.
See also: System (Fortuitous), System (Intentional), System (Organized to optimize across spheres)
While analyzing fortuitous phenomena, we defined that a system is a recurrent structure of resources involved in recurrent scenarios.
While analyzing intentional phenomena, we also defined, notably that the system can involve specific type of resources that we call “performers”. Such system involves specific types of evolutions that we call “operations”. The operations are performed by performers that have some defined performer goals.
And here were saw that performers intentionally delegate roles to other performers for the purpose of resource specialization and optimization. The delegate performer has expected goals corresponding to the role that he/she/it plays. The delegate performer is chosen because of her/his/its capability to play the role.
In such system that is organized to optimize, performers adopt a staged approach. In other words, they follow a defined process, a set of scenarios, to reach a specific goal.
resources are shown with a green background color. Key optimization semantics appear in orange.
Organized to Optimize across spheres
Spheres (reminder)
What we have done so far: We identified the semantics of some natural phenomenon that is common to all spheres i.e. the physical, mental and digital sphere.
Further optimization requires delegation to appropriate performers within appropriate spheres. We are already organizing systems across multiple spheres. However, the optimization is purely intuitive and ad hoc. So we need some analytical and deductive approach for optimizing a system across multiple spheres.
But let’s first recall what those spheres really are and where they come from.
The mental and digital spheres are made of resources from the physical sphere.
· The mental sphere is a construction of natural evolution towards conscious beings.
· The mental sphere includes a synoptic perception of the environment including the being's self.
· The digital sphere is a construction from the mental sphere
Within the natural phenomenon, the most fundamental concepts are the essence of nature like state, evolution and time. In that stage of fortuitous and physical evolution, there is only a mere physical sphere.
Intention appears (fortuitously), as the intention of beings is, mainly, to survive, acting and reacting adequately depending on the information that is gathered about the environment. Primitive intention based on primitive forms of information: That is the birth of the mental sphere.
Humans, along with other animals, intentionally influence physical evolutions first by using their own physical body, then by delegating to other physical instruments e.g. other humans, animals, tools and machinery.
Humans also created the digital sphere in order to delegate much of their mental operations and reach high precision or very large scales.
We can optimize heterogeneous systems by hosting resources, along with their evolutions, in the most appropriate spheres.
The following diagrams illustrate some categories of resources (including performers) that belong to specific spheres.
Performers Across Spheres
We have seen that a performer is a kind of resource. A performer can span one or several spheres.
As you can see in the diagram below…
· An automaton can be made of digital logic, digital information and hardware units.
· A hardware unit and human body can perform physical operations.
Roles and Delegation Across Spheres
Appropriate delegation also requires appropriate role decompositions.
Humans can delegate operations to software or machinery because these operations are either repetitive or because these operations require some level of performance or physical property (speed, precision, strength, mass...) that humans can’t reach.
Software and machinery delegate to humans typically when some processes require creativity or knowledge that only humans can reach.
In the next picture, potential delegations are represented by arrows that sometimes cross sphere boundaries.
A “transphere” is a relocation of resource (a transfer) across the boundary that separates different spheres.
Myriad processes span multiple spheres. Hence, such processes involve transpheres.
For example, what is usually called a “system use case” is actually a process involving resources to be transphered between mental and digital performers playing defined roles.
At the most elementary level, “transpheres” require relocation of resources across a common sphere i.e. the physical sphere.
Here are some examples of processes spanning multiple spheres:
· Read physical slide on the screen or paper and associate with existing mental knowledge
· Print digital ads to physical paper. Post paper. Receiver opens physical envelope, reads physical ads information into mental knowledge, mentally selects preferred product, types product reference onto physical keyboard and “transpheres” the reference into the digital on-line ordering system….
· Print digital recipe to physical paper, read recipe into mental knowledge, create mental cooking plan, cook…
The following example shows a student (a performer) taking a calculation exam.
NB: The purpose of these pictures is to illustrate the concepts. This s is not a proposed specification language
We can see that the state of physical and mental resources evolve in parallel. Each resource state in its sphere is a perception of the other resource state.
We can see that, at a certain level of detail, performers always exchange resources through the physical sphere.
In the next picture, we can see that resource state is exchanged between student A and student B, always stepping through the physical sphere.
In this last example, the student delegates some operations to a calculator (another performer). Resource state is mirrored and it evolves in parallel in three different spheres.
The next diagram depicts the integrated semantics where every concept applies to the physical, mental and digital sphere.
The semantics are these of a system (any system) that resides in any combination of the mental, digital or physical spheres.
We also need an elicitation approach that builds upon our common semantics and that integrates the notion of spheres. Automation by Nature includes a section dedicated to such elicitation approach. This section is called “Guidelines – Elicitation”.
Automation by Nature (C) 2005-2009 Alain De Preter - Tous droits réservés - All Rights Reserved