Chapter 2 - Develop the Technotope Individual
2.1 - Skills to be developed by individuals
2.2 - Modeling and Conceptual Modeling
2.3 - Modeling as an Enabler for Change by Design
2.4 - Conceptual Models in a Learning Society
2.5 - System, Ecosystem and Social Totalities
2.6 - Models and Model Layers
2.7 - The technotope individual
To Part I (Chapter 1 - 2 - 3 - 4) _ II (5 - 6 - 7) _ III (8 - 9 - 10 - 11 - 12 - (no 13)) _ IV (14 - 15) _ V (Annexes) _ VI (References)
2.1 - Skills to be developed by individuals
In the following pages you will find guidance, tools and models for the development of practical wisdom, wisdom that can be applied in different roles in society, as it evolves towards a Technotope.
It is a journey on which this e-book can be your companion.
In Adair’s five-point plan of decision making, four of the points involve semiosis.
Four of the five steps in Adair’s five point plan can be considered specializations of the value chains that are part of the semiotic flows.
These interactions involve the taking in as content (i.e. words, drawings, numbers, models) by an interpretant (e.g. a person or a computer with a sensor) of (properties of) real-world phenomena and situations, or the interpretation of content as (current, future or past) real-world phenomena or situations.
A semiotic interaction involves a person or a sensing/actuating system (the interpretant), a sign (often content on an information carrier, from simple signs to complex models with thousands of elements and relationships), and a referent (what is denoted by the sign), again as a sign. Open source modeling tools help to make complex models understandable to ordinary people like you and me.
Elementary semiotic interactions are joined into socio-semiotic interactions, as studied for instance in Feez (2007) and the knowledge conversions of Nonaka (Nonaka et al., 2000), and as denoted by the term industrial semiosis (Goossenaerts, 2000).
Industrial semiosis illustrates for each of Adair’s four points that new tools and models open up unseen possibilities for the mind, individually and as stepping stones to collaborative or collective intelligence.
Modern open source tools also allow us to create and browse models, so making sense of such tools and the models and the possible meanings they convey is a key area for the development of the individual.
A second skill relates to understanding the nature of social entities and learning in society. Tony Lawson’s Social Positioning Theory is used to explain a theory of the social domain that supports the social constitution that would result from adopting a societal architecture.
2.2 - Modeling and Conceptual Modeling
Modeling is a technique for representing situations or systems (economic, military, mechanical etc.) by means of something else, usually at a smaller scale. Modeling is helpful because it allows us to take a good look at something that is too big or impractical to see otherwise.
Conceptual modeling is the development and use of representations to capture the features of both:
- the real-world domain, or work system, that an information system is intended to support (Wand and Weber, 2002)
- the context in which the information system will be created, and within which it will operate and evolve.
Conceptual modeling offers significant advantages throughout the information system lifecycle (ISLC), from initial requirements gathering to system development and ongoing maintenance. Here are some key benefits (summary generated by Gemini for prompt “what are the key benefits of conceptual modeling in the information system lifecycle” , but scope of use enlarged to ecosystem rather than a business or system, and to portfolios rather than projects):
- Improved Communication and Understanding: A conceptual model acts as a shared language between stakeholders (work and eco-system users, analysts, developers) by visually representing the work system’s entities, relationships, attributes, and processes. This clarity fosters better communication, reduces misunderstandings, and ensures everyone is on the same page about information and work system functionality.
- Early Identification of Issues: During conceptual modeling, potential problems or inconsistencies in requirements can be surfaced and addressed early in the development or change process. This is much more efficient and cost-effective than discovering issues later in the development or change cycle, when modifications become more expensive to implement.
- Reduced Development Time and Costs: A well-defined conceptual model serves as a blueprint for system development and planning. It provides a clear roadmap for decision-makers and developers, minimizing the need for rework or last-minute changes due to unclear requirements. This can lead to faster decision and development times and reduced overall portfolio, program, project and iteration costs.
- Stronger Ecosystem Foundation: A robust conceptual model lays the groundwork for a more robust work system and maintainable information system. It ensures the system is designed to handle the core functionalities and data structures required by the work system. This makes the work system more adaptable to future changes and the information system easier to maintain over time.
- Enhanced Data Quality: The process of defining entities, attributes, and relationships in the conceptual model helps to identify and address data quality issues. This can lead to cleaner, more consistent data within the system, which ultimately improves the accuracy and reliability of information used for decision-making in the work system.
- Documentation and Training: The conceptual model serves as valuable documentation both for the information system and its role in the work system. It provides a clear understanding of the system’s functionality for future reference and can be used for training purposes, helping users understand how to interact with the system effectively, and helping other stakeholders to plan engagements.
Here’s a table summarizing the key benefits:
| Benefit | Description |
|---|---|
| Improved Communication | Shared language for stakeholders, reduces misunderstandings |
| Early Issue Identification | Proactive problem discovery and resolution |
| Reduced Development Time/Costs | Clear roadmap minimizes rework and delays |
| Stronger System Foundation | Solid foundation for a maintainable system |
| Enhanced Data Quality | Promotes cleaner and more consistent data |
| Documentation and Training | Valuable reference and training tool |
In conclusion, conceptual modeling is a crucial aspect of the (information) system lifecycle. By investing time and effort in creating well-defined conceptual models, stakeholders can reap significant benefits throughout the development process and ensure the resulting and evolving systems meets their joint and specific needs effectively.
The various model elements and model layers of ArchiMate®, and the tool support for it, offer a very good starting point for appreciating the diversity and versatility of conceptual models. Key stakeholder benefits of using ArchiMate® in a portfolio, program or project include:
- Improved Understanding: Visual representation of the complex relationships between different components of the domain and the context.
- Enhanced Decision Making: Better-informed decisions about investments, resource allocation, prioritization, and risk management.
- Increased Transparency: Clearer communication of the tax convention’s architecture to stakeholders.
- Facilitated Change Management: Easier identification of the impact of changes on the overall architecture.
At present most professional modeling literature targets a specific specialized professional group, for instance architects, engineers or programmers.
In this book we want to demonstrate the usefulness of conceptual models and their tool support for a much broader group of mindful users, the technotope individual, who can be anyone who seeks an “untrapped” mind in journeys at any of the socio-technical levels macro, meso, micro, and pico.
2.3 - Modeling as an Enabler for “Change by Design”
For analysts and designers in a wide variety of decision making situations, the use of modeling often is related to the design or improvement of a product, a service or of the operational processes executed by service or manufacturing systems.
In policy making, modeling can be used with the purpose to improve regulations, or to enact new regulations.
But why change the operations of an existing work system? And in the “work system” of the democratic society, why change or add new regulations?
In general terms change “by design” in a work system or a stakeholder constellation can be due to three different causes: problems, directives and opportunities (Whitten et al, 2004)(Figure 2.2):
- Problems: undesirable situations that prevent a system or constellation from fully achieving its purpose, goals, and/or objectives.
- Opportunities: chances or possibilities to improve the system or constellation even in the absence of identified problems.
- Directives: new requirements or constraints that are imposed by management, government, or some external driver.
Emerging technologies, such as information and communication technologies (ICT) can offer a wide range of opportunities. Work systems for which one seizes these opportunities may become ICT-reliant work systems.
In many cases, problems occur or are perceived as a consequence of (implicit) objectives, which often also indicate desirable solutions for the problem.
Some problems can be solved directly by many people (with suitable tools available) (left hand side arrow in Figure 2.2). An example is repairing a flat tire of a bicycle.
Other problems appear new, or are indeed new. Problem analysis, root cause analysis and solution search may involve the use of models (i.e. simplified representations) of both elements of the systems and the factors that influence the problems and possible solutions. By using models it becomes possible to study some reality and possible changes to it, without actually intervening in, or disturbing that reality.
For instance in the case of production systems (assembly systems, job shops, warehouses, supply chains,…) computer models make experimental examinations possible which otherwise would have a high time and money expense. Furthermore simulation models allow quick and extensive parameter changes which are not possible using physical models.
Mathematical models are usually used in those cases where the behaviour of a system with respect to a problem can be fairly well described by means of mathematical equations that can be solved exactly or by using approximation techniques.
In many situations in which mathematical solutions are not (yet) possible it is still possible to make other models. In addition to mathematical models many other models exist (right hand branch in Figure 2.3).
Modeling is used to describe and analyze the behaviour of systems or products, ask “what if” questions about the real system, and aid in the design of real systems and products. Both existing and anticipated systems can be modelled.
Modeling is indispensable in problem-solving methodologies for many real-world problems. It is a highly interdisciplinary field since it is widely used in all aspects of industry, government and academia. One can find the teaching of modeling in almost every academic department from economics and social science to engineering and computer science (Fishwick, 1994).
2.4 - Conceptual Models in a Learning Society
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.5. - System, Ecosystem and Social Totality
2.5.1 - Social Totality
2.5.2 - Social Positioning Theory as a Social Ontology
2.5.3 - Biotope, Sociotope and Technotope
2.5.4 - Types and Tokens
2.5.5 - Classes of Agents
2.5.6 - The Range of possible Collaborations
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.5.1 - Social Totality
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.5.2 - Social Positioning Theory as a Social Ontology
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
In Annex 12 - Conceptual Models of the Social Positioning Theory the principles and concepts of the SPT are depicted by means of conceptual models.
2.5.3 - Biotope, Sociotope and Technotope
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.5.4 - Types and Tokens
The distinction between types and tokens is fundamental in conceptual modeling.
Types are abstract entities representing a category or class. They are universal in the sense that they exist independently of their instances. Types are shared by multiple instances. A single type can be instantiated multiple times.
In contrast, tokens are concrete instances of a type. They are particular and individual. Each token is unique. In an epistemic commitment, tokens belong to a specific type.
Example: Someones pet cat is a token of the type “cat”.
Understanding the type-token distinction is crucial for building conceptual models and using them in describing life-world situations and creating prescriptive norms for them. It helps define the structure of knowledge and how to represent it computationally. By clearly differentiating between general categories and specific instances, we can create more accurate and precise models.
2.5.5 - Classes of Agents
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.5.6 - The Range of possible Collaborations
This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.
2.6 - Models and Model Layers
Figure 2.7 and Figure 2.8 are examples of a conceptual model. Before using more complex conceptual models, let’s explore the utility of models in general.
A model is an abstract representation of reality in any form (including mathematical, physical, symbolic, graphical, or descriptive form) to present a certain aspect of that reality for answering the questions studied (ISO 15704).
Depending on the kind of questions studied, we can use different kinds of models. Law & Kelton (2000) mention the question of model validity: does the model accurately reflect the system for the purposes of the decisions to be made?
A (geographic) map is one kind of model that helps us in finding the road from one place to another place. If the map pretends to show the roads in the covered geographic area, then validity means that the existing roads are indeed included in the map.
A map without a directions service (calculating the optimal or feasible roads between any two points on the map) is useful, as at least one can figure out a feasible route from one point to another, for any combination of (reachable) points (in the geographic area). But in combination with a geographic positioning system (GPS) a road planner service can be offered that supports driving decisions as we progress in a trip. A distinctive feature of a map in combination with a GPS and a road planner is that it supports decision making for all possible travel needs of people within the geographic area, if they have access to the services.
Also professional disciplines are characterized by their own culture, their own viewpoint including an approach to knowledge, a range of concerns, and a way of thinking and problem solving. These are supported by specific modeling and problem solving techniques.
The need for system models of operational processes is driven by questions on the performance and behaviour of alternative designs of the relevant processes. The modeling techniques are then used to predict and analyse performance and costs.
For instance, when studying an elevator, we may be interested in the possible states of this elevator or in the possible state changes. For the first question we might define a UML class diagram to characterize the state variables, and an instance diagram to describe the different states of the elevator that is studied. A process model might then be used to describe the possible state changes.
Model Driven Architecture: Model Layers
For businesses, during the past fifty years several modeling languages and techniques have been applied as organizations have externalized their structure and operating procedures, especially with a focus on computer support for improved operations. These trends have already given rise to the large-scale use of enterprise models and the use of several dimensions to manage the complexity of enterprises applying ICT.
As consolidated models are available for the operational processes, any project or decision option will deliver a “delta-specification” to realize a particular new scenario (stylistic objective) in a given operational process (or socio-technical context). The models at the three OMG MDA layers (Miller and Mukerji, 2003) (computation independent, platform independent and platform specific) result from different development phases, each of which offers its own contribution to the reduction of risks (Dick and Chard, 2003) and to the system design (Figure 2.11).
The Computation Independent Model (CIM) shows the system in the environment in which it will operate, and thus helps in presenting exactly what the system is expected to do. Useful as an aid to understanding a problem and for communication with the stakeholders, it is essential to mitigate the risks of addressing the wrong problem, or disregarding needs. Domain models are solution-independent descriptions of a problem domain produced in the analysis phase.
Often the term “conceptual model” is used as a synonym of “domain model”. However, in the modeling literature there are diverging proposals how to define the term “conceptual model”, contrast for instance (Guizzardi & Wagner, 2012) and (Robinson, 2011). A domain model may include both descriptions of the domain’s interacting entities and exchanged objects and descriptions of its events and processes.
Domain or conceptual models are “computation-independent models” in the sense that they are not concerned with making any target system choices (for instance, simulation, electronic document interchange, shop floor operations, database management) or with other computational issues. Rather, they focus on the perspective and problem solving attitudes of the subject matter experts for the domain under consideration, and on solution choices that they can make independent of the target implementations. The idea is that one redesigns the process prior to automating (certain steps in) it.
The Platform Independent Model (PIM) describes the system in reference to a particular architectural style (e.g., agent based, micro-services or client/server) but does not show details of platform use. The structure of this model might be quite different from the structure of a CIM layer model of the same system. In this book we will not use platform independent models. In specific cases, such as distributed supply chain simulations in which the links want to participate in the (federate) simulation without disclosing their decision criteria or data to the other simulation participants, a PIM model offers a valuable common model for all participants. Each participant must refine the PIM model to reflect own choices, and then implement it by mapping it to a Platform Specific Model for its IT platform.
Various Platform Independent Models can be created for a single CIM. For instance both the tables in a database system and the messages that trading partners will exchange.
The Platform Specific Model (PSM) is produced from the PIM by further transformation. It specifies how the system makes use of the chosen platform and technologies. A PSM may provide more or less detail, depending on its purpose. A PSM will be an implementation, if it provides all the information needed to construct a system and to put it into operation, or it may act as a PIM that is used for further refinement to a PSM that can be directly implemented. The PSM is coded in the programming language and artefacts of the target platform. After testing and debugging, the implemented solution is then deployed in a target environment.
Each model layer has its own role in the life cycle of project results as depicted in the figure 2.11. In this book we will articulate CIM layer domain and process models as a means to scope initiatives and to ensure the validity and credibility of the project work. We use Archimate, UML class diagrams and BPMN to express information and process models and their integration for simulation and system processing.
Models in a project, versus those of a portfolio
Models are used a lot, yet in many initiatives as CIM and PIM are not maintained after the systems have been implemented, deltaCIM and deltaPIM are made for a specific request, and after a solution has been delivered, they are forgotten, while the PSM + deltaPSM models remain as code. The CIM and PIM models that correspond to the PSM+deltaPSM models are not or poorly maintained.
One outcome of this situation is that subject matter “experts” often know less about the legacy systems than the experienced functional and technical analysts and software developers working at the system.
Another risk is that the subject matter experts don’t know what the CIM level equivalents are of “out-of-the-box” technical artefacts such as the EDIFACT messages. As a result poor re-use is made of those artefacts, even though a lot of analysis has gone into their definition.
A poor use of CIM modeling in analysis exposes organizations to risks such as poor decision making, poor re-use and high costs that are avoidable.
Further in the book this point will be illustrated for some EDIFACT messages, but in general terms one could expect that in a Portfolio aware Collaborative Planning and Investment Methodology the CIM and PIM models of the ecosystem, sociotope or technotope would be maintained and made available at the landscape portfolio level, for instance as digital commons.
See Annex 13 - Types of Systems, Models, Representations and Simulation for further possibilities of using models.
2.7 - The Technotope Individual
The technotope individual is someone who can use modeling tools to read, interpret, and manipulate conceptual models and use them in complex decision-making situations. He or she is aware that the creation of such models is a collaborative effort and brings social savings.