Societal Architecture and Collaborative Decision Making
Societal Architecture and Collaborative Decision Making
Jan Goossenaerts
Buy on Leanpub

Table of Contents

Publisher

Wikinetix bv

Acacialaan 6

2390 Malle

Belgium

E-mail: info@wikinetix.com

www.wikinetix.com


 

Acknowledgments

The idea for this book originated many years ago. However, in those days the proposition seemed merely academic with unclear chances for a large scale practical use of a society wide architectural approach.

Happily, during the past years there has been substantial progress in a number of areas.

In international development, the post-2015 process in particular has triggered a much more inclusive global discourse about development challenges. Today the 2030 Agenda for Sustainable Development and the accompanying Addis Ababa Action Agenda are in need of portfolio thinking and an enterprise architect’s perspective. The proposed Collaborative Planning and Investment Methodology and society wide enterprise architecture approach aim to meet that need.

Enterprise architects must handle many concepts and views which are native to several disciplines. The ArchiMate standard, the Archi modelling tool, and the Common approach to the US Federal Enterprise Architecture have been very helpful in structuring and supporting the enterprise architecture discourse. ArchiMate offers a rather complete set of concepts and views for presenting the enterprise architecture models and ideas I wished to pass on to the reader. ArchiMate 2.1 has added Motivation and Implementation and Migration extensions. The Common approach to Federal Enterprise Architecture has shown awareness and introduced jargon for dealing with multiple levels of scope, it has expressed general principles for dealing with enterprise architecture in “partnerships”, and it has defined a succint collaborative planning methodology which has influenced the methodology presented in this e-book.

A third area that I must acknowledge is the availability of open-source tools and software. We know that the majority of the target beneficiaries of the 2030 Agenda for Sustainable Development are resource-constrained, yet they also need online content and means to clarify their own requirements, and launch their own digital initiatives. The open-source and tool support for such work is invaluable. Regarding wiki’s, I like to mention wikidot.com and wiki.js. Mastodon is an open-source alternative for Twitter. In addition, being able to add actionable models as add-ons to an e-book creates much additional value for the reader. Archi is a free tool which supports the creation of coherent and consistent ArchiMate models. Modelio is an open source UML and BPMN modeller that supports also integration specifications, and Leanpub is the publishing platform through which this e-book is being offered. To the makers of Wikidot.com, Wiki.js, Mastodon, Archi, Modelio, Leanpub and Notepad++: you all have done a great job!

A fourth area is the activism, scholarship and policy proposals regarding digital commons. A societal architecture is a digital commons, where the resources are data, information, culture and knowledge which are created and/or maintained online. A societal architecture is supportive to an ecology of interoperable projects.

My acknowledgements go to all people who in an official capacity, on contract basis, or as volunteers have contributed to the before mentioned initiatives. Without your enthusiasm, insight and effort, writing this book would have been impossible.

Finally, my gratitude goes to my wife and our daughter for their love and patience.

the author, March 15, 2023

The ‘untrapped mind’ is open enough to see many possibilities, humble enough to learn from anyone and everything, perceptive enough to see things as they really are, and wise enough to judge their true value.

Komusuke Matsushita

Preface

This book has a focus on digital enablers for the human side of the enterprise “big three subjects”: Leadership (Humanity), Decision Making and Communication.

Key accelerators for the book’s finishing have been multiple, and include:

  • the availability of open source modeling tools that cover various dimensions of public and private decision making;
  • the availability of Open PM² guides on portfolio, programme, project and agile management;
  • the work done by UN/CEFACT on the EDIFACT messages (Electronic Data Exchange For Administration Commerce and Transport) and the UN/CEFACT Modeling Methodology (UMM) in support of Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport;
  • the presentation by John Adair of some key, yet simple decision making frameworks:
    • five steps: Define objective, Collect information, Develop options, Evaluate and decide, and Implement, and
    • three circles: achieving the Task, building the Team and developing the Individual;
  • the availability of methods, tools and modeling concepts that support each of the steps in the framework and enable a transformation of the workings in each of the three circles;
  • the digital capability principles;
  • the SDGs and related initiatives by the United Nations;
  • access to a wide range of opinions, both smart and little informed, via Twitter.

Consider as task the 2030 Agenda, as team the living members of mankind and as individual each one of us, but as you are reading this book, especially also you.

At first sight, decision making appears to be solely relevant to that first circle “achieving the task” at the top, whatever that may be.

But, as Adair reminds us in his books, in the context of leadership (human) decision making (which here includes problem solving and creative thinking) by necessity involves the Team (collaboration) and Individual (skills) circles as well, and these circles are always interactive.

In the age of digital interdependence, those circles are also globally to locally connected, and the teams include a wide variety of (ICT) professionals delivering and running the digital platforms that empower the human side in an increasing number of contemporary enterprises. Those digital platforms and the digital artefacts that flow through them have been created over the past decades and following a lot of analyses.

Currently, these circles are plagued by a variety of divisions, including those of content versus ICT, those with access to externalized knowledge versus those without that access, rich versus poor, center versus periphery, information versus dis-information, and destructive versus constructive attitudes.

In the #tagcoding handbook and the #xy2wiki portfolio, the focus has been on skills and platform for reducing the “digital” divide between those with access to externalized knowledge and those lacking such access, between the centers and periphery of human development.

In recent years, I have prioritized the #tagcoding handbook and online tools, because the contradictions about access and center versus periphery are the most salient. But given the slow adoption of #tagcoding and #xy2wiki, I concluded that the separation between content and ICT also needed urgent treatment. If only to clarify the importance of #tagcoding and #xy2wiki for the 2030 Agenda.

The message of this book is that through semi-formal models delivered via and evolving in a societal architecture, communication between content and ICT professionals can be dramatically improved, to the extent that a talent explosion for sustainable development becomes feasible.

With a little effort and smart use of methods, models and tools everyone in the “content and ICT eco-system” can “free her or his minds of all kinds of traps” and thus dramatically improve decision making effectiveness and efficiency, for all kinds of capabilities and enterprises, but in particular also collaboratively, when deploying digital capabilities in society, and when contributing to the 2030 Agenda.

Of course, if your depth mind has been deeply entrenched in some levels in societal or organizational roles it may take more efforts, practice and experience to free it of all habitual traps.

If you apply the principles, models, and tools described here, if you can de-entrench your depth mind, and if you reflect on the collective experience - both successes and failures - you will be able to contribute to the progress of humanity as envisioned in the 2030 Agenda.

Who knows, an increasing number of members of mankind may one day acquire that attribute the ancient Greeks prized so highly in their leaders, which they called phronesis. We can best translate that Greek word as “practical wisdom.” It is the product of a rare combination of keen intelligence, wide experience and profound goodness.

On the following pages you will find pointers to lead and involve tools, and reuse models in the development of practical wisdom, wisdom that can be applied in various roles in society.

It is a journey this e-book may accompany you on.

In the five point plan of Adair, four of the points involve semiosis.

These interactions involve the capturing as content (i.e. words, drawings, numbers, models), by an interpretant (for instance a person, or a computer with sensor) of (properties of) real-world phenomena and situations, or the interpretation of content as (actual, 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 having thousands of elements and relationships), and a referent (what is denoted by the sign), again as the sign. Open source modeling tools support making complex models intelligable to ordinary people, as you and me.

Elemental 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 unseen possibilities for the mind, seen individually and as stepstones for a collaborative or collective intelligence.

In modern open-source tools we can create models, and that’s why models and the possible meanings they convey are a first topic.

As decisions often involve multiple elements, architecture is a key factor in structuring the problem space and ordering the drivers and decision alternatives of multiple stakeholders.

Architecture is a discipline that is closely linked to innovation. Construction, product development, enterprises and information system development, each has seen the emergence of an architecture discipline, and these diciplines have been key to the creation and evolution of increasingly valuable products, services, systems and infrastructure: houses and public buildings, transportation infrastructure, vehicles, airplanes, telecommunication networks, computers and communication devices, software, digital service platforms, and so forth.

Following the emergence and consolidation of enterprise architecture as a discipline that supports the creation and evolution of business and IT systems “within organizations,” societal architecture is proposed as an extended discipline to support collaborative socio-economic development in any territory, from local to global, and by any actor in society, including small business and households.

Today, the ArchiMate modeling elements and layers are extensively applied within enterprises, and this book illustrates how they can be scaled out to society-wide. In essence, such scaling out is a collaboration of minds for which open access to digital content is a key and just requirement (see also Goossenaerts et al, 2007a).

In societal architecture we extend the “intra-enterprise” use of elements to society “at large”. The 2030 Agenda for Sustainable Development that was approved at the September 2015 United Nations General Assembly provides a suitable setting for articulating the societal architecture. In support of this global agenda we propose the 2030 Societal Architecture.

Sustainable development is knowledge intensive. Applying and growing a societal architecture as part of a collaborative planning and investment methodology for sustainable development is one way of improving open access to increasingly complex economic and political institutions in order to foster both political and economic competition, and development within the limits of the earth, our collective resource endowment.


Standing on the (open) achievements of a generation

The Common Approach to the U.S. Federal Enterprise Architecture has recognized the relationship between the level of scope and the mission impact and planning detail of enterprise architecture.

For actors at different socio-technical levels: the territory (macro); the sector or discipline (meso), the company or organization (micro) and the person or household (pico), the steps in collaborative planning and investment using the Societal Architecture will vary in accordance with the claims on resources that are typical for the actors at each level. By articulating the principles that guide these claims and the constraints that matter for the resources, we can achieve balanced reuse practices and services that empower actors in constructing sustainable and equitable futures that are better aligned with resource endowments, individually, as communities, as nation states, and as mankind.

Methodologically and technically, the jargon and practice of enterprise architecture as practiced in organizations - this is at the micro level -, is transferred and elaborated as a multi-level knowledge infrastructure, with reference levels pico, micro, meso, and macro. The generic term technotope is used to refer to the object-system at the various levels: from the techno-globe, as coined by Hiroyuki Yoshikawa, to the techno-house implementing domotics.

Because an extensive jargon exists, and in order not to inflate this book, we assume the reader is somewhat familiar with the enterprise architecture jargon, for instance as defined in the Common Approach to the U.S. Federal Enterprise Architecture, the TOGAF® 9.1 Architecture Development Method (ADM) or the ArchiMate® 3.1 Specification.

As the key service of enterprise and societal architecture is to the lean implementation of change in complex settings - organizations or other technotopes - also the portfolio, programme and project management jargon is relied upon. Here we will use the terms and meanings that have been consolidated in the open PM² Project Management Methodology and Portfolio and Programme Management Guides that have been published by the Publications Office of the European Union, and are free to access and use.

Except when indicated otherwise, terms from these standards are used in accordance with their definition there. For the reader who is not yet familiar with those standards, some key definitions with their mutual relationships and examples have been included in the Techno order chapter of the ens.wiki.

Societal architecture applies methods and components from enterprise architecture frameworks such as TOGAF and the architecture description standard ArchiMate. But in the society-wide landscape, we can assume that participants in the “social enterprise” bring their domain knowledge, their own devices and applications. The domains where we anticipate application of the Societal Architecture include both public services, industry and households.

The focus of this book is on the Preliminary, Vision and Business Architecture phases, that is getting the scope, requirements and architecture right. For these phases in Societal Architecture development there is no chief executive. This book aims to support many autonomous stakeholders in finding common ground and discovering what they could contribute to the Societal Architecture as a cognitive infrastructure.

An extremely positive circumstance however is that the United Nations system is revolutionising the approach to development and communications as can be witnessed from the Sustainable Development Knowledge Platform, with global consultations and a more open approach to initiatives. Thus the notion of global to local societal portfolios is gaining ground.


What next in societal portfolios: Transition Planning?

It is the author’s hope that the United Nations will sooner or later adopt and advocate the Societal Architecture as an Unsollicited Proposal (USP), (this is an exception to public initiation of Infrastructure public-private partnerships). Such an adoption would facilitate and accelerate the Societal Architecture growth and follow on phases: Opportunities and Solutions, Transition Planning, Implementation Governance, and Architecture Change Management.

Whereas this book is targetted at professionals participating in portfolios, programmes and projects in both public and private sector, I also have created reference works for the general audience in which #tagcoding hashtags are defined for all topics in relation to which public or private portfolios, programmes and projects could seek change or communication.

Of the #tagcoding guide, there are e-handbook versions in English, French, Spanish and Tagalog, and online versions in some other languages, including Arabic, simplified Chinese, Swahili, Russian, Japanese, Hindi, Telugu, German, Ilonggo and Dutch. #tagcoding supports the communications in social media platforms for all possible initiatives in global to local societal portfolios.

Regarding communications in the Public Sphere, the principles of Societal Architecture lead to the establishment of distinctive communications channels in which everyone can publish, and which everyone can consult. It is in such a communications infrastructure that #tagcoding hashtags play a key role.

One of this book’s purposes is to recruit more supporters for a Societal Architecture infrastructure public-private partnership as an Unsollicited Proposal to the UN and its member states. While our leaders follow their agendas, you as a reader can do more to strengthen the proposal.

Before embarking on the book proper, I wish to explain some features that are extensively used in this book and in the #tagcoding handbooks and wikis, amongst others to give readers the possibility to join in making the societal architecture a cooperative one.


Not an ordinary e-book

This e-book is not an ordinary e-book. It explicitly aims to use hyperlinks to online and inline content.

Hyperlinks to online content make it a media-extended book.

In the pdf-version of the e-book, such hyperlinks will appear as footnotes.

A media-extended book offers benefits to the participants in the knowledge chain. These benefits build upon the use of hyperlinks and hashtags to extend the book’s storyline with content that is on the internet, and with discourse on social platforms. Content in the public domain is referred to as content commons and in principle should be available to all under the same access regime, this is for free and with no restrictions to reuse. Content that is protected by copyright is called proprietary content. It can be accessed for a fee or for free, and it cannot be reused without approval by the copyright holder. Access conditions should be comparable for all participants in a same market.

Using hyperlinks to online content commons and proprietary content has several advantages:

  • The author can avoid to reword and repackage existing content, and can build upon others’ work in a direct and transparent manner;
  • Content that is on the internet could evolve and improve between the point in time when the e-book was first produced, and the point in time that one is reading it, making use of the hyperlink;
  • Where the hyperlinked content is in wikis or blogs that support discussion or comments, readers can give comments, to further improve the state of knowledge in the area covered.

Systematized content commons referenced via hyperlinks draw the attention of authors and readers to the possibility to contribute to the wider dissemination of content commons, or to make use of them in other situations where they can bring benefits. By using and expanding the systematized content commons, their quality and utility will gradually improve.

While editing the #tagcoding handbooks, which often amounted to putting wiki content in e-book format, I was missing the convenience of the wiki breadcrumbs, to navigate from sub-sections higher up in the content hierarchy. Markdown and related editing formats support linking within a work.

In this e-book and in the #tagcoding handbooks inline hyperlinks are extensively used for tables of contents of chapters, sections and subsections, for links to return to the next level up in the content hierarchy, and for links between the chapters and between the parts.

In this way a thousand+ page #tagcoding e-handbook can be read with the convenience of a wiki, without being online. Within the source text, #tagcoding hashtags are used to tag their defining sections. And access to the source texts for the classifications is (or will be) included when buying the e-book on leanpub. The source texts, or parts thereof can thus easily be reused in other electronic publications, or at websites.

Other uses of hashtags

Using hashtags as a means to promote and follow-up a discussion topic has also several advantages, including:

  • Everyone with a platform profile that allows tagged posts, is empowered to contribute to the discussion (it is better the platform provides read-access also to non-members),
  • When systematically defined hashtags are used, it becomes possible to discuss very specific topics, for instance, marine aquaculture in Indonesia via #isic0312ID
  • The use of hashtags by authors and readers supports collaborative scoping and avoids information overload,
  • Each hashtag supports a “single-version-of-the-truth” “search” for the discourse on the searched platform(s), at any point in time, and across languages.

Tagged discourse supports authors and readers in updating their knowledge about a specific topic.

If needed, an author can update and republish an e-book – for instance as supported by Leanpub –.

When realized as wikis, the systematized content commons can easily be updated as well.

The expectation of improved quality gives a reason for later returns to specific “content commons” or hashtag searches.

The systematized content commons in #tagcoding guidelines are intentionally offered free of charge. Together we can demonstrate the feasibility of content commons and tagged discourse as pillars for development and low hurdle access to knowledge that matters to people’s livelihood.


Providing #tagcoding handbooks in your language

While the #tagcoding handbook is already available in a few languages, the provision of systematized content commons in other languages will support reaching a wider readership and user base for the Societal Architecture. Thus we can overcome the digital and knowledge divide globally, and achieve more poverty reduction and sustainable development impacts. Cooperatively, we can also make such provide economically viable.

A number of conditions mutually enforce one-another as enablers for the translation of this e-book:

  • The 2030 Agenda hashtags defined in the Actor Atlas are language independent;
  • Google Translate supports a page by page translation of content commons;
  • Translation of models in modeling tools is efficient as only the elements (and comments) must be translated to translate all views;
  • Leanpub supports royalty sharing according to an agreed division between author and (co-author) translator.

On this e-book being work in progress

Not all chapters have reached a sufficient maturity. This will be indicated in remarks following those chapters’ table of contents.

Also, whereas the open source tools Archi for ArchiMate and Modelio for UML and BPMN would be sufficient to do all the modelling needed for this e-book, I have not had the time yet to transfer some older materials to these tools. As a consequence you find some older materials that were modelled in other tools, some of which, such as UML in Visio, are no longer available.

Happily, the Leanpub Publish Early, Publish Often model allows me to publish this e-book early to get reader feedback, and to publish new versions as often as is needed.


Part I - Putting Societal Architecture to Work


Chapter 1 - Introduction

Chapter 2 - Towards a Talent Explosion for Sustainable Development

Chapter 3 - Understanding through Modeling and Simulation


To Part I - II - III - IV - V - VI-Annexes - VII-References


Chapter 1 - Introduction


1.1 - Global Challenges in a Planetary Context
1.2 - Towards Digitally Empowered Humans
1.3 - Capabilities in Partner Journeys
1.4 - Digital Capability Principles
1.5 - Stakeholders, Initiatives & Reporting
1.6 - An Abstract Partner Journey
1.7 - Access Characteristics of the Resources
1.8 - Case Materials
1.9 - Outline of the Book
1.10 - What you should take away: a Promise
1.11 - Tools, Models and Resources


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


1.1 - Global Challenges in a Planetary Context

The global 2030 Agenda for Sustainable Development, and the national and local action plans that are being launched in reference to it, will have to impact the decision making, investments and operational choices of many partners: agencies, businesses and households. Successful implementation of the agenda demands improved services for making choices, deciding investments, adopting technology, and exchanging data and information at all levels and in all corners of society.

In order to reduce the perceived complexity in the global problem mess, and to compare values that people will reference when making choices, it is convenient to distinguish three orders:

  • Natural order : the natural environment in which humankind dwells. Notable aspects such as time, land, climate, biotope and person are addressed as well. It includes material, those material resources that humankind exchanges with the natural environment.
  • Social Order: institutional arrangements and socio-cultural actor networks that humankind has evolved to govern relationships and interactions, mutually and with the natural order. It is the order in which also Produced Assets and content come into play. Produced assets are non-financial and non-content assets that have come into existence as outputs from production processes and as inputs of consumption processes and services. Produced assets consist of fixed assets, inventories and valuables. Content are non-tangible resources such as those that could be protected by Intellectual Property Rights, authored works (in the public domain), data, etc
  • Techno Order: institutional arrangements and actor networks that are related to constellations and interactions involving complex produced assets, complex content collections, and multiple institutional arrangements.

In these orders the entelechy proceeds by interactions in Biotope, Sociotope or Technotope.

Biological and physical systems become in the biotope which offers an area of uniform environmental conditions providing a living place for a specific assemblage of plants and animals. Biotope is almost synonymous with the term habitat, but while the subject of a habitat is a species or a population, the subject of a biotope is a biological community.

Physical, chemical and bio-physical interactions in the Natural Order. These are studied in dedicated sciences and are not specifically addressed here. Yet insights stemming from these sciences should be considered when taking decisions.

Climate change, which is a global natural order process, is threatening the biotope of mankind.

Mankind’s response to challenges such as climate change involve socio-technical interactions in the Social Order and in the Techno Order.

Patterns for these interactions have an impact on how effective and efficient we are in coping with challenges.

In more general terms the entelechy, or becoming in sociotope and technotope rely on biological and physical systems, but involve additional systems such as legal systems, businesses and agencies and the products and services they provide to society.

A sociotope is a defined space that is uniform in its use values and social meanings. It can be described as the collective life world of a place, its use and meaning, in a specific culture or group of people. The sociotope is defined in the real world where it is shaped by a multiplicity of lifestyles, trades, regulations and services connected to a specific place which can be local, national, regional or global.

For the group of social actors, the sociotope typically includes a number of regimes and a public sphere.

A technotope is an external space that is uniform in its use values, social meanings and technology uses. It can be described as the collective life world of a Sociotope enhanced with cyberspace, its use and meaning, in a specific culture or group of people. The technotope is defined simultaneously in the real world and cyberspace where it is shaped by a multiplicity of lifestyles, trades, regulations and services connected to a specific place which can be local, national, regional or global, and which involve technical artefacts such as smart phones, computers, digital service platforms, and so forth.
Note that the term Sociotope as defined in Wikipedia also covers the term technotope. In this book a distinction is introduced to reflect the digital revolution that we are experiencing since the sixties.

Thus three related systems in context are of interest to our decision making:

  • the natural system in the biotope,
  • actors in the sociotope, and
  • digitally empowered actors in the technotope.

Improved use of modeling and modeling tools is proposed as an essential skill for people to participate as decision makers in the techno-order, and a key skill to participate in the social order.

For the social actors, the technotope typically includes regimes that also involve techno-order items.

To the chapter


1.2 - Towards Digitally Empowered Humans

As a wide range of actors learn about the agenda, and commit to contribute a share to improving society’s resilience, they will start a partner journey that will last for years, will involve diverse teams, and will contain episodes for awareness, advocacy, analysis, design, conflict, implementation, and monitoring Global Task Force of Local and Regional Governments.

These journeys will proceed in a society with a complexity that no-one can comprehend on his own, and with numerous interdependencies for all, and in which multiple initiatives proceed simultaneously.

Peace, of mind and in reality, requires a fragile equilibrium that involves both some control over our natural environment, oversight of actions that impact all, and trust in the other, both nearby and at a large distance. The trust is both in people that speak our language and share our culture, and in people that speak other languages and hold different views.

In this book we refer to an open portfolio, programme and project management method and use modeling techniques to present key ideas about both public and private initiatives, resource use and their interdependencies.

The purpose of those methods and models is to escape entrenchments that limit our ability to cope individually and collaboratively with contemporary problems, from climate change, over conflict and poverty to failures of democratic governance and the justice system.

The challenge in the presentation is that both the subject, the methods and the modeling approach are rather complex and multi-facetted.

First one can present and explain each of a number of content slices with a limited number of different concepts, and next establish relationships between the slices, from a small number to public-private chains that are typical of the contemporary society.

To let come to life the interactions amoung concepts in a small number of slices (or dimensions), we will use a number of cases and describe them, first in each of the slices, and next we will use elements from different slices in the analyses.

Mapping the partner journeys for the partners at various socio-technical levels helps us develop content sharing services and resources that better cope with dependencies among and complementarity of initiatives worx.wiki/Initiative Management, better than conventional communication, decision making, development and conflict resolution approaches.

To the partners we want to provide model and data-driven decision making, capacity-building, analysis and design, and negotiation technology even in the case of frequent changes in the environment, and where many actors are involved.

A first starting point for shared services and mutual capacities for the partners are the Common Approach to the US Federal Enterprise Architecture which emphasises a number of General Principles and a Collaborative Planning Methodology to explicitly look outside the agency addressing new requirements. In our case, it are partners looking in the partnership for solutions and joint capabilities.

The launch, in 2015 of the 2030 Agenda for Sustainable Development offers a key occasion for promoting and explaining collaborative approaches to partner journeys as a foundation for effective partnerships for sustainable development, partnerships from global to local scope.

As the requirements for successful initiatives become harder for the successive phases in the partner journey: awareness, advocacy, analysis, design, implementation, and monitoring, we introduce touch points, tools and resources for each of these phases:

  • Raising Awareness for sustainable development and one another
  • Advocacy for local change
  • Analysis of information eco-systems
  • Design of digital interventions, for instance to support peace,
  • Joint implementation
  • Collaborative monitoring

A second starting point is a practical model-based approach to decision making. For the decision making approach we use the one described by John Adair(2009), and for making it model-based we rely on open-source tools Archi and Modelio for sharing models in ArchiMate, BPMN and UML, the three most popular modeling standards.

To the chapter


1.3 - Capabilities in Partner Journeys

Within the journey of the operational entity, the strategic investment planning utilizes practical thinking, the functions of the mind, the five point plan and decision drivers as described by Adair (2009). These topics and their relationships are modelled in the figure below.

Figure 1.1: Leadership, decision making and communication in effective decision making (Adair,2009)
Figure 1.1: Leadership, decision making and communication in effective decision making (Adair,2009)

In the figure, note Adair’s interactive three circles (C1, C2 and C3), the five point plan, functions of the mind, practical thinking and decision drivers of the public sector.

In the following sections we merge the collaborative aspect of the Generic Capability Model for the Sustainable Development Partnership, with effective situated decision making as described by John Adair.

How do stakeholders identify a need to change their work system or its surroundings?

For the “operations manager” change to the operations is usually problem driven and asset enabled. In general, a problem refers to a situation, condition, or issue that is unresolved or undesired.

In society, a problem can refer to particular bio-, socio-, or techno-tope issues, which if solved would yield social benefits including resilience, and conversely diminished hostility and disruption.

For instance, for emission accounting the issue is global warming and polution that may be both global and local. The problem is identified by the research community, and communicated to governments and international organizations.

In business a problem is a difference between actual conditions and those that are required or desired.

In the abstract Figure 1.2 ArchiMate model elements are used to depict several aspects of a work system that may become subject to an investment plan. A facility performs operations, and is subject to drivers of change of three types (Whitten et al, 2004):

  • Problems: for instance the breakdown of a component, or the discovery of human activity induced global warming;
  • Directives: for instance new regulations to mitigate global warming, act as norms to which operations (partner journeys) should comply;
  • Opportunities: for instance the emergence of new technology that could be used to improve the operations, for instance digital technologies replacing paper-based operations planning or emission accounting methods.

For the planning, performance and monitoring of the operations, an information system is used. To keep track of the work that must be done, and of the performances. Indicators support the decision making, for instance in the case where a choice must be made between various action alternatives. An action alternative typically involves setting a decision variable to a certain value to better achieve objectives. Performance indicators support verifying to what extent objectives are achieved as decision variables are changed.

Figure 1.2: A Work System and its Change Drivers
Figure 1.2: A Work System and its Change Drivers

The decision making involves the three mutually related decision making capabilities (Figure 1.3):

  • Strategy and leadership,
  • Management of operations, and
  • Development of capability.

All three decision-making activities react to directives, opportunities and peer intelligence, as depicted in the asset offer group.

In below figure the three capabilities Strategy and Leadership, Manage Operations and Develop Capability are positioned as decision making activities for the work system operations.

Figure 1.3: Decision making in Work Systems
Figure 1.3: Decision making in Work Systems

Due to the interdependence of work system and its environment, we also depict the work system in its environment, its socio-tope or techno-tope (Figure 1.4).

We assume that the values held by society and its members are related to the so-called livelihood assets: human, natural, physical, social assets in addition to financial assets (Rudd, 2004). Given an indicator system and performance measures, objectives can be expressed and evaluated for a work system (object system) that offers one or more capabilities and performs various functions. The environment is the source of inputs and the sink (market) for the outputs. An important aspect of the surroundings of a system is the infrastructure, for transportation and communications, and providing access to water, energy and waste disposal services.

The model in Figure 1.4 is called the Extended Generic Activity Model (EGAM). Besides an abstraction of the operational processes (object system operations), it includes the reflective activities that influence the operations of an object system. These reflective activities are governance, management and analysis&design.

The governance activity (or process) determines the required outcomes and provides performance indicators to measure these. A quantitative difference between objectives and performance data (gathering of these requires that an information system is in place) signals a problem to the management activity. If addressing the difference is within the mandate of the management, then it will use controls or instruct the “analysis, design and implementation” capability to modify the work system.

Figure 1.4: Work system and environment in the Extended Generic Activity Model
Figure 1.4: Work system and environment in the Extended Generic Activity Model

Management calls upon the analysis&design activity to analyse the problem of the object system, to create new designs (TO_BE model & technology), and to evaluate performance. Governance and management activities decide about the implementation of an improvement proposal or the acquisition of new capability recommended by the analysis and design activity in a management or governance advice (m_advice or g_advice). In particular, the activities are defined as follows:

  • The object-system operations: The operational processes that are performed by the object system, and for which performance objectives are expressed and evaluated; the object-system performs the primary process for which a certain performance is required; often this is a production or supply chain process.
  • The environment processes: The processes of the environment in which the object system operates or performs a function – the environment is the source of inputs and the sink (market) for the outputs. Also resources originate from the environment, and wastes are deposited there (not in the figure),
  • The governance activity: The activity in which the desired outcomes of the object system are set, as well as the related performance targets, taking into consideration relevant constraints (natural, social, etc.) that exist for the capital assets in the facility’s environment, it defines the mandate of the management activity.
  • The management activity: The activity in which the operations of the object system are monitored and controlled. If one or more performance targets are not met, a problem is signalled to the analysis & design activity,
  • The design and analysis activity: In this activity, performance problems of the object system are analysed, redesigns performed and evaluated, and advices given to the management or governance activity.

A decision making engagement is one of the possible studies that an analysis and design activity may perform to found its decision proposals or advices.

The decision making engagement has interfaces to multiple assets that a work system creates and maintains to support its reflective activities. Modeling and simulation are often part of change management. One approach to characterize the change capability of a work system is by using the Maturity Stages of the Capability Maturity Model (CMM):

  • initial: the process is unpredictable and poorly controlled;
  • managed: the process is characterized for projects and is often reactive;
  • defined: the process is characterized for the organization, and is pro-active;
  • quantitatively managed: the process is measured and controlled;
  • optimizing: process improvement is continuous.

For the operational process (the primary process performed by the facility), the quantitatively managed or optimizing stages are recommended.

For the reflective activities and change management the defined stage is recommended (at first). The reflective activities are initiated and punctuated by objectives, opportunities or problems as perceived by key stakeholders.

The work system has a life history which is, in accordance with GERAM and ISO/FDIS 15704 represented as in Figure 1.5.

Figure 1.5: Activities in the work system life history
Figure 1.5: Activities in the work system life history

An work system, its governance, management, and its analysis & design activities evolve over time. The facility models are in the assets group (Figure 1.4). They also evolve and are modified as facilities and processes change. The notion of life history is concerned with what happens between the point in time that an entity or system is created, and the point in time at which it will vanish.

ISO FDIS 15704 proposes the following phases in the adaptive cycle in which the enterprise copes with new necessities:

  • Identification: This is the set of activities that identify the new problem.
  • Concept: The set of activities that are needed to develop the new concepts of the entity.
  • Requirements: The activities needed to develop descriptions of the new requirements (additional requirements).
  • Design: The activities needed to extend the specification of the entity (extended model).
  • Implementation: The activities that define the new tasks, which must be carried out to modify or re-build the entity.
  • Operation. The new model is in use, meeting the (new) requirements.

As the reflective activities of a work system acquire a digital capability, they will need various models and data of its facility and experiment or study designs, to evaluate the different decision options. Increasingly, partial information and process models and data of organizations and their business environments are available, and therefore we should consider the possibility to reuse more digital resources during all phases of a decision making engagement.

To the chapter


1.4 - Digital Capability Principles

Digital capability principles have had little visibility in the description of the decision-making context and activities.

However, digital capabilities are among the defining features of our age. So what would their impact be?

To understand this impact, we briefly address the principles for digital development which have been coined by an international consortium, and which are widely applied.

A Societal Architecture is proposed as a coherent way to leverage these digital principles in a wide range of initiatives.

In Figure 1.6 it is illustrated how the digital capability principles are related to the valuestreams of CPIM and to the resources that make up the Business Model Sustainability Toolkit.

Figure 1.6: Digital capability principles
Figure 1.6: Digital capability principles

Working with models and data are a key aspect of applying the principles for digital development:

Specifically for public sector entities, the European Interoperability Framework (EIF) proposes the principles in figure 1.7.

Figure 1.7: The principles of the European Interoperability Framework (EIF)
Figure 1.7: The principles of the European Interoperability Framework (EIF)

Design With the User

Design With the User starts with getting to know the people you are designing for through conversation, observation and co-creation:

  • Develop context appropriate solutions informed by user needs.
  • Include all user groups in planning, development, implementation and assessment.
  • Develop projects in an incremental and iterative manner.
  • Design solutions that learn from and enhance existing workflows and plan for organizational adaptation.
  • Ensure solutions are sensitive to, and useful for, the most marginalized populations: women, children, those with disabilities, and those affected by conflict and disaster.

Understand the Existing Ecosystem

Understand the Existing Ecosystem.

Well-designed initiatives and digital tools consider the particular structures and needs that exist in each country, region and community:

  • Participate in networks and communities of like-minded practitioners.
  • Align to existing technological, legal, and regulatory policies.

Design for Scale

Design for Scale.

Achieving scale requires adoption beyond an initiatives pilot population and often necessitates securing funding or partners that take the initiative to new communities or regions:

  • Design for scale from the start, and assess and mitigate dependencies that might limit ability to scale.
  • Employ a “systems” approach to design, considering implications of design beyond an immediate project.
  • Be replicable and customizable in other countries and contexts.
  • Demonstrate impact before scaling a solution.
  • Analyze all technology choices through the lens of national and regional scale.
  • Factor in partnerships from the beginning and start early negotiations.

Build for Sustainability

Build for Sustainability.

Building sustainable programs, platforms and digital tools is essential to maintain user and stakeholder support, as well as to maximize long-term impact.

  • Plan for sustainability from the start, including planning for long-term financial health i.e., assessing total cost of ownership.
  • Utilize and invest in local communities and developers by default and help catalyze their growth.
  • Engage with local governments to ensure integration into national strategy and identify high-level government advocates.

Be Data Driven

Be Data Driven

When an initiative is data driven, quality information is available to the right people when they need it, and they are using those data to take action.

  • Design projects so that impact can be measured at discrete milestones with a focus on outcomes rather than outputs.
  • Evaluate innovative solutions and areas where there are gaps in data and evidence.
  • Use real-time information to monitor and inform management decisions at all levels.
  • When possible, leverage data as a by-product of user actions and transactions for assessments.

Use Open Standards, Open Data, Open Source, and Open Innovation

Use Open Standards, Open Data, Open Source, and Open Innovation

An open approach to digital development can help to increase collaboration in the digital development community and avoid duplicating work that has already been done.

  • Adopt and expand existing open standards.
  • Open data and functionalities and expose them in documented APIs (Application Programming Interfaces) where use by a larger community is possible.
  • Invest in software as a public good.
  • Develop software to be open source by default with the code made available in public repositories and supported through developer communities.

Reuse and Improve

Reuse and Improve

Reusing and improving is about taking the work of the global development community further than any organization or program can do alone.

  • Use, modify and extend existing tools, platforms, and frameworks when possible.
  • Develop in modular ways favoring approaches that are interoperable over those that are monolithic by design.

Address Privacy & Security

Address Privacy & Security

Addressing privacy and security in digital development involves careful consideration of which data are collected and how data are acquired, used, stored and shared.

  • Assess and mitigate risks to the security of users and their data.
  • Consider the context and needs for privacy of personally identifiable information when designing solutions and mitigate accordingly.
  • Ensure equity and fairness in co-creation, and protect the best interests of the end end-users.

Be Collaborative

Be Collaborative

Being collaborative means sharing information, insights, strategies and resources across projects, organizations and sectors, leading to increased efficiency and impact.

  • Engage diverse expertise across disciplines and industries at all stages.
  • Work across sector silos to create coordinated and more holistic approaches.
  • Document work, results, processes and best practices and share them widely.
  • Publish materials under a Creative Commons license by default, with strong rationale if another licensing approach is taken.

To the chapter


1.5 - Stakeholders, Initiatives & Reporting

The organizational or external roles that assume responsibility for object system operations and reflective activities and assets are also called the stakeholders. In portfolios, programmes and project studies, specific tasks are performed to support the communication with these stakeholders. Moreover, these stakeholders will have specific interests regarding the study; they may have a say in the go/no go decision regarding the initiative and study.

In an enterprise architecture described in accordance with the ArchiMate framework stakeholders (for the enterprise architecture with respect to which the service solution will be positioned) are included in the motivation extension. The rationale for their involvement will often be related to their role in the Business collaboration that must be supported by the service solution.

Hands-on users (of the product for which requirements are collected) are addressed as part of the active structure aspect: the Business actor would include the “stakeholder” descriptive elements and Business role would include the “user role”.

Stakeholders of Stakeholder class “Interfacing technology” are named application components and are described as part of the framework’s Application layer; The rationale for their involvement will often be related to their role in a Application collaborations among “services”.

In Chapter 14 - Stakeholders we bring together insights regarding these stakeholders of global to local societal portfolios, stakeholders that will drive the talent explosion for sustainable development.

The global societal portfolios considered in detail are:

As both portfolios matter to all listed stakeholders, we pay special attention to the consideration of stakeholders that are beneficiaries of multiple simultaneous initiatives.

Governance Activity determines the outcomes of the object system (of projects) that must be monitored and evaluated. Whenever a redesign or change is proposed, it must be evaluated in terms of its impacts on system outcomes as well as its fit with initiatives of others.

One cannot set indicators before determining outcomes because it is the outcomes—not the indicators—that will ultimately produce the benefits.

Triple bottom line reporting for businesses is being harmonized in the context of the Global Reporting Initiative (GRI). GRI distinguishes three categories of indicators to achieve a better aligned reporting for business w.r.t. outcomes in the context of global challenges:

  • economic: The economic dimension of sustainability concerns an organization’s direct and indirect impacts on the economic circumstances of its stakeholders and on economic systems at the local, national and global levels.
  • environmental: The environmental dimension of sustainability concerns an organization’s impacts on living and non-living natural systems, including ecosystems, land, air and water.
  • social: The social dimension of sustainability concerns an organization’s impacts on the social systems within which it operates. Social performance can be gauged through an analysis of the organization’s impacts on stakeholders at the local, national, and global levels. In some cases, social indicators influence the organization’s intangible assets, such as its human capital and reputation.

Indicators are only relevant when they measure against an objective. Thus, measuring indicators will show the progress made toward reaching the intended objectives. Decisionmakers and stakeholders are positioned to make the intended outcomes of the object-system as explicit as possible. Articulating outcomes is crucial to achieve ownership on the part of the stakeholders.

Indicators are the quantitative or qualitative variables that provide a simple and reliable means to measure achievement, to reflect the changes connected to an intervention, or to help assess the performance of an organization or object system against the stated outcome. Indicators are needed to monitor progress with respect to inputs, activities, outputs, outcomes, and goals. In complex systems, progress needs to be monitored at all levels of the system to provide feedback on areas of success and areas in which improvement may be required.

For each of the stakeholders affected by the expected outcome of a portfolio, the progress reports should identify the relevant aspects.

For each of the asset components in the organization (see “assets” place in Figure 1.4) progress reports should identify the changes in the component. Consider for instance the task descriptions for the workers, the performance measurement requirements, reporting activities, etc.

To the chapter


1.6 - An Abstract Partner Journey

A talent explosion for sustainable development must involve many, many partners. For each of those partners, and everyone is invited to be one, the partner journey will involve four considerable transformations. These transformations will apply specific tools in touchpoints and they will also depend on the type of social actor and the resources it owns, produces and consumes - the so-called resource endowment.

For each actor some operational, motivational and business aspects of their resource endowments are presented. As for the accounts, they include resources with specific characteristics:

  • Material resources that are in finite supply;
  • Content resources that are not depleted by being used;
  • Monetary resources of which the supply is socially controled.

The figure below mutually positions actors at the different levels of scope that will be addressed in this book.

Figure 1.8: An abstract multi-level landscape
Figure 1.8: An abstract multi-level landscape

Awareness building in the Partner journey

What are effective tools and resources for raising awareness of social actors? How to achieve “awareness episodes” that bring social actors to the start of an advocacy episode at a minimal expense and with a minimal trap and maximal openess. We will show that the internet and social media can play a major role in the “Awareness Building for Global Partnership”. Beyond the awareness episode, we call the social actor a partner, and we can rightly speak of a partner journey.

Advocacy for local change

What are effective tools and resources for the advocacy episode in the partner journey? How does the “advocacy episode” of a partner look like during the internet age? During the advocacy episode, partners envision possible futures that evolve towards meeting the sustainable development goals. The future of various social actors must be mutually aligned to achieve virtuous circles and commitment to change. Such commitment is essential to embark upon implementation and start the next episode.

Modeling and decision making in complex contexts

Using analysis and design, applying shared knowledge resources.

The sharing of knowledge resources involves a wide variety of stakeholders, each with a particular scope, each depending on decisions by many others. In order to support clarity on focus throughout the models and presentation in this book, the below indexes will be used extensively.

Figure 1.9: Indexes for the partnership
Figure 1.9: Indexes for the partnership

Whenever a term can be instantiated at various levels of scope, the indexed term will clarify the level of scope intended in the figure or an explanation.

Figure 1.10: The various decision making value streams in the contemporary society
Figure 1.10: The various decision making value streams in the contemporary society

Joint implementation

What are effective tools and resources for the implementation episode in the partner journey ?

The figure below introduces an abstract 2030 Agenda roadmap with mutually dependent workplans of stakeholders in the implementation episode. The index ranges for the types of stakeholders that are engaged in the 15 year agenda are as follows: about 200 countries, over hundred functions of government, more than a million sub-national governments, about 450 industry sectors, hundreds of millions of businesses, and about 2 to 4 billion households. We will use the term Global Partnership to refer to this total group of stakeholders in the 2030 Agenda.

Figure 1.11: An abstract 2030 Agenda roadmap
Figure 1.11: An abstract 2030 Agenda roadmap

In the abstract roadmap we use several ArchiMate model elements to represent implementational and motivational concepts of the 2030 Agenda roadmap:

  • plateau is used to represent the world, country and sub-national operations at different points in time (i = 2016 .. 2030) with a year, half year or quarterly time interval;
  • work package is used to represent the plans of the various types of stakeholders, with the index range as indicated per type;
  • driver is used to represent the goals in the 2030 Agenda for Sustainable Development (SDGs) as well as the goals that each country has selected;
  • goal is used to represent the end-state that stakeholders want to achieve, in this case it is the achievement of selected goals (driver) in the 2030 operations within the scope of the governing agents (or partnerships).
  • assessment and gap are used with their common meaning.

Collaborative monitoring

What are effective tools and resources for the monitoring episode in the partner journey?

The role of national statistics systems is modeled in the Generic Activity Model for Statistical Organizations. The capabilities and value streams of GAMSO have been slightly modified to create a Generic Capability Model for the Sustainable Development Partnership (Chapter 2).

To the chapter


1.7 - Access Characteristics of the Resources

Material resources (and biological entities) have life cycles during which they participate in the socio-economic interactions of human society (Goossenaerts, 2000). An entity (ens) has a life time, during which it exists at each point in time. This is called the continuant property.

For material ens and (physical) money, this means they must be at a unique location. Their consumption is rivalrous. Content on the other hand, which we also call a cognitive means in support of the CPIM, may exist simultaneously at multiple places. Its consumption is non-rivalrous.

Each material entity has an ontogenic life cycle.

Entities that are mutually exchangeable or non-distinguishable have a typogenic life cycle: for instance all cars of type X produced by manufacturer Y.

A phylogenic life cycle refers to the collective existence of all entities with comparable functions, for instance all cars.

Resource management policies and procedures will involve the ontogeny, typogeny and phylogeny of entities.

The ontological characteristics will influence the options for such policies and procedures, especially for what concerns:

  • the use, depletion and discovery of resources;
  • the stocks and flows of resources; and
  • technologies required for handling the resource, recycling and substitution.
Figure 1.12: Characteristics of resources
Figure 1.12: Characteristics of resources

The fundamental properties of entities have implications for how to involve them in planning and change. Below table illustrates some differences that are elaborated in the related chapters.

Ens Category use, depletion and discovery stocks and flows technologies, recycling and substitution
Material often as input to many possible products; depletion possible material stocks and flows materials oscillate between being captured in products or stocks, and being in the natural environment
Produced Assets use for specific purpose (low flex); depletion depend on required materials and availability of production facility, “invented” product inventory and product life cycle technological facility is required for production and recovery; recycling of material content; substitution within the typogeny or phylogeny
Content non-depletable use by reading, “creation” with copyright protection depending on the carrier technologies required for capturing, recycling of material carriers, different media come with very different access properties
Monetary many uses, use and depletion are socially controlled savings versus transactions, asset and liability, as a proxy for size of the economy embodied monetary flows are often (perfectly) substitutable

Social order preferences regarding access to resources

Paradox of wealth: capitalism and ecological destruction (Bellamy Foster & Clark, 2009).


Societal Architecture: Open access versus private control?

The question whether or not the Societal Architecture for the 2030 Agenda should be privately controlled is a pertinent one. At present, many governments hire expensive consultants in order to guide them in taking decisions that would otherwise fall within the application area of enterprise architecture.

An Infrastructure Resource is a resource that satisfies the following demand-side criteria (Frischmann, 2005, p. 956):

  • the resource may be consumed non-rivalrously;
  • demand for the resource is driven primarily by downstream productive activity that requires the resource as an input; and
  • the resource may be used as an input into a wide range of goods and services, including private goods, public goods, and nonmarket goods.

Three key insights emerge from this demand-side analysis focussed on value-creation. First, infrastructure resources are fundamental resources that generate value when used as inputs into a wide range of productive processes. Second, the outputs from these processes are often public and nonmarket goods that generate positive externalities that benefit society. Third, managing infrastructure resources in an openly accessible manner may be socially desirable when it facilitates these downstream activities.

Given these considerations, we classify the Societal Architecture as a global digital public good. For background on digital public goods, check the website of the Digital Public Goods Alliance.

To the chapter


1.8 - Case materials

This book is ambitious and must proof that wide scope principles can indeed be linked to interdependent decision making in a wide range of practical situations.

To do this we provide and apply models that are characteristic of the various levels of planning addressed in the Collaborative Planning and Investment Methodology (CPIM): open portfolios, programmes, projects and iterations.

After introducing the Methodology in Chapter 4 and the Societal Architecture in Chapter 5 (Part 2 of the book), we are ready to illustrate the use of models for each of the four levels of planning, for a number of cases:

The value framework to drive change in the cases is derived from the 2030 Agenda for Sustainable Development, which as such is also presented as a model in an open portfolio.

In the overal methodology, executable model and experimentation are included but in the current version of this e-book they are not elaborated. For such models we refer to simulation and programming courses and handbooks.

To the cases - To the chapter

Case 1 - 2030 Agenda

In this case, models at the four levels of planning matter to stakeholders at the different socio-technical levels.

Models in portfolios matter for the Global Partnership comprising National Governments, Local Authorities, UN Country Teams, and Aid and international organizations.

Programmes would typically involve multiple members of the Global Partnership, setting rules and patterns for the landscape, as well as Schools, Publishers and right holders and Libraries operating within the “regulated” landscape.

Figure 1.13: Values and goals of the 2030 Agenda
Figure 1.13: Values and goals of the 2030 Agenda

To the cases

Case 2 - Library Services

Library services involve works by Publishers and right holders as well as digital public goods, encouraged by the global digital public goods portfolio, of which the Digital Public Goods Alliance is a steward and advocate.

Projects and iterations would involve citizens and households, Schools, Publishers and right holders and Libraries.

Publishers and right holders could develop their own portfolio regarding the provision of copyrighted works in libraries, especially also digital works.

Again models at the four levels of planning matter at the different socio-technical levels, in this case especially from meso (publisher organizations and library organizations), over micro (libraries and publishers) to pico (author and library patrons).

To the cases

Case 3 - The Petrol Station

The owner of the petrol station has the feeling that some potential clients are leaving the station because there is no place to wait for service. But he doesn’t know to which extend this assumption is true. So he would like to know what is the influence of the capacity size of the pump on the percentage of cars leaving without being served.

In the current situation, three cars at most can wait for petrol filling at the petrol pump. The cars in the queue follow a First In First Out Rule (FIFO).

Figure 1.14: Description of the Petrol Station Situation.
Figure 1.14: Description of the Petrol Station Situation.

This case is situated at the micro level and illustrates the possible scope of a project or iteration.

This case has been part of a course on the Simulation of Operational Processes that colleagues and me have been teaching between 2004 and 2008. If there is interest, more details on executable model and experimentation can be included in the extras with this e-book.

To the cases

Case 4 - A Harbour

A harbour can host two types of ships; Small and Big ships. Small ships arrive with an interarrival time exponentially distributed with a mean of 5,5 hours. Big ships arrive with an interarrival time exponentially distributed with a mean of 6,7 hours. There are two docks (dock1 and dock2) at this harbour where ships can be unloaded.

Small ships are unloaded at dock1 with a service time uniformly distributed between 3 and 7.

Big ships are unloaded at dock2 with a service time uniformly distributed between 2 and 8.

If dock1 is empty and there are Big ships waiting at dock2 then a Big ship can go to dock1 and is served with 1,5*Uniform(2,8).

If dock2 is empty and there are Small ships waiting at dock1 then a Small ship can go to dock2 and is served with 2*Uniform(3,7).

For both docks the queue discipline is SPT (Shortest processing time first).

The management team of the harbour wonders if closing dock1 to Big ships and dock2 to Small ships would improve the mean expected throughput time of ships at the harbour. Another question is if it is better to use simply a FIFO rule (First In First Out) instead of the SPT rule? How can we help the management team to get answers to their questions?

Figure 1.15: Description of the Harbour Situation: SPT
Figure 1.15: Description of the Harbour Situation: SPT

This case is situated at the meso level and illustrates the possible scope of a project or iteration.

This is a typical case from a simulation course.

This case has been part of a course on the Simulation of Operational Processes that colleagues and me have been teaching between 2004 and 2008. If there is interest, more details on executable model and experimentation can be included in the extras with this e-book.


To the chapter

1.9 - Outline of the Book

Within the context described so far.

The second chapter explains how we can achieve a talent explosion for sustainable development.

The third chapter offers a general explanation of the utility of modeling and simulation for collaborative planning at multiple levels, that is in portfolios, programmes, projects and iterations, where collaboration engages actors at multiple socio-technical levels: macro, meso, micro and pico.

The chapters 4 to 6 (part II of this book) explain the support that collaborative planning and societal architecture provide to the four “semiotic” points in Adair’s five point plan of practical thinking.

The running cases are then used to illustrate the application of collaborative planning and the societal architecture in Part III on models and tools in early planning and analysis:

In each of these chapters we link one of Adair’s points to a step of the Collaborative Planning and Investment Methodology (CPIM) or to a step in conceptual modeling.

The implications of the general principles, and the characteristics of and constraints regarding the used resources have an impact as to how the various stakeholders best engage with the resources, including the use of suitable tools.

The cognitive means that can be reused are illustrated for each of the early Societal Architecture CPIM steps.

Part IV addresses the Societal Architecture benefits beyond the early planning and analysis:

Part V addresses Stakeholders and Global Portfolios in more detail, we elaborate the implications of using a Societal Architecture for actors, members of the global partnership, at each of the socio technical levels, for pico, micro, meso and macro journeys:

In this part the material is presented in an accessible, stepwise and low hurdle manner, and in such a way that stakeholders can extend the architecture documentation for their own initiatives.

Part VI Annexes and Part VII References conclude the work.

Given that the 2030 Societal Architecture is a first ever effort (I am aware of) to translate and extend enterprise architecture practices and lessons to a global partnership, I am aware of numerous imperfections in this book. I intend to correct them soon. Reader feedback is greatly appreciated.

To the chapter


1.10 - What you should take away: a promise

After reading this book, you should be able to apply the Societal Architecture and CPIM in the stakeholder role and for the partnership episode that fits your context, making use of the Archi or Modelio models that accompany this e-book. As you apply the proposed activities for one episode of the partner journey, you will build the skills to move to the next episode with the recruited partnership. Value creation and the avoidance of value erosion will found virtuous and viral circles in support of high priority sustainable development targets and goals. The additional resources that will be acquired will enable the partnership to also address new and bold targets and goals.

As you will discover, the vast systematized online content that accompanies this book, plays a key role in virtuous and viral knowledge creation for development.

To the chapter


1.11 - Tools and Resources

Before closing the introductory chapter I like to draw your attention to some resources and tools that will be instrumental throughout the book.

The Principles of Doing Development Differently

Source: The Doing Development Differently Manifesto:

  • (#ddd1) - Focus on solving local problems: Initiatives focus on solving local problems that are debated, defined and refined by local people in an ongoing process.
  • (#ddd2) - Legitimate at all levels and locally owned: Initiatives are legitimised at all levels (political, managerial and social), building ownership and momentum throughout the process to be ‘locally owned’ in reality (not just on paper).
  • (#ddd3) - Local conveners mobilise all with a stake in progress: Initiatives work through local conveners who mobilise all those with a stake in progress (in both formal and informal coalitions and teams) to tackle common problems and introduce relevant change.
  • (#ddd4) - Rapid cycles of planning, action, reflection and revision: Initiatives blend design and implementation through rapid cycles of planning, action, reflection and revision (drawing on local knowledge, feedback and energy) to foster learning from both success and failure.
  • (#ddd5) - Manage risks by making ‘small bets’: Initiatives manage risks by making ‘small bets’: pursuing activities with promise and dropping others.
  • (#ddd6) - Foster real results: Initiatives foster real results – real solutions to real problems that have real impact: they build trust, empower people and promote sustainability.

These principles suggest the use of multiple iterations in development initiatives.

Hashtags that digitally support a local discourse

Hashtags that support a local development discourse on social media and when using the internet are listed on country initiative pages as part of the Actor Atlas: Enabling the Sustainable Development Debate in the Digital Public Sphere.

Open source modeling tools

To the chapter


Chapter 2 - Towards a Talent Explosion for Sustainable Development


2.1 - The Digital Commons Potential
2.2 - Partnership Interactions
2.3 - Implications for the decision making
2.4 - Operations
2.5 - Monitoring and evaluation
2.6 - Change
2.7 - Partnership and capability development
2.8 - Towards a Talent Explosion


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


2.1 - The Digital Commons Potential

In the definition proposed by Dulong de Rosnay & Stalder (2020): the digital commons are a subset of the commons, where the resources are data, information, culture and knowledge which are created and/or maintained online. They are shared in ways that avoid their enclosure and allow everyone to access and build upon them. The notion of the digital commons lies at the heart of digital rights, the political fight to expand, rather than restrict, access to information, culture and knowledge (Kapczynski & Krikorian, 2010).

A society that fully deploys digital commons, open data and smart media solutions in its decision making “differs from” the current society in each of the three realms Operations, Monitoring & Evaluation and Change.

Figure 2.1: Global landscape change
Figure 2.1: Global landscape change

In each realm, partnerships face specific capacity and capability problems as they implement portfolios, programmes and projects (see the right-hand side of the figure below), and specific improvement targets could be expressed (left-hand side of the figure).

Solving the realm-specific problems by fit “collective and open access” institutions and by creating fluid and lean content will spur a Talent Explosion in the (sustainable) development interactions in each of many economic activities and functions of government, in all engaged national and local constituencies, for agreed sustainable development goals and targets.

Synergy by fluid, lean, engaging and open content should become effective in the decision making and partnership interactions across realms and “sector-specific” initiatives. This is explained in more detail and with several references at Collective Decision Frames (Ens Wiki) and in the worx.wiki page about the Post 2015 Partnership Capability.


2.2 - Partnership Interactions

Partnership interactions under the Addis Ababa Action Agenda involve actors at the four “socio-technical” levels in the societal architecture:

  • pico, the persons members of households,
  • micro, the organizations including business,
  • meso, federations of organizations in the same sector or with a similar interest, and
  • macro, entities with transversal, landscape-wide responsibilities;

All three realms matter for all actors:

and are differentiated by:

  • their material and content scope, ranging over many economic activities and functions of government,
  • the implied economies (scale, scope, quality) that are possible, and
  • the desirability of collective action.

The chapter concludes with a capability development perspective on the partnership, and a Small World blueprint that could enable a talent explosion.

To the chapter


2.3 - Implications for the Decision making

Focus in this book is on interactions with strong improvement potential for collaborative approaches. The approaches we advocate include:

To the chapter


2.4 - Operations

Background

With operations we mean a series of actions or interactions that are done by one or more actors to produce a particular result and measure the production. Operations are always specific to either private sector activities, functions of government , or their interactions. Consider for instance the attending of school by a child, the paying of teacher salaries, or the paying to an agency of income taxes on declared or estimated income.

In these operations we recognize individual persons, such as the pupil, the teacher, and the tax payer. These are called pico level actors. The school is an organization and is a micro level actor. Its performance is measured by specific indicators. The tax collecting agency is interacting with all “taxable” persons in the constituency and is a macro level actor.

This dictionary’s first focus is on the operations performed in socio-economic entities such as countries, sub-national states or municipalities, or the global society.

Poverty can be equated to, or considered as an insufficient outcome of the “livelihood operations” of poor people in World AS-IS. Fighting poverty will require change to those operations and the context in which they are performed. Such change will consist of initiatives taken by various actors.

Improving the global society operations (World operations 2016), is the purpose of the 2030 Agenda for Sustainable development which proposes nearly 170 targets (#SDGS) for evaluating the “performance of the society operations”, including the elimination of poverty, in World operations 2030.

When discussing workplans that are created under such agendas it is important to clarify which operations are in their scope. Via indicators and data about the operations, for instance the Poverty headcount ratio at $2 a day (PPP) (% of population) we can obtain insight about the extent of a problem (the gap between actual and targeted “performance”) and express the intended outcome of an initiative (World Plan[i], Country[j].Plan[i], ..). After the implementation of the initiatives we can then evaluate their performance, by checking whether the achieved values match the targets.

Obtaining indicator data for operations, and evaluating both the operations and the impact of change initiatives is the object of monitoring and evaluation (which includes assessments). The figure displays the interrelationships between the three realms for the 2030 Agenda and the Addis Ababa Action Agenda. In this figure we use motivation, implementation and migration concepts and notations from ArchiMate.

Figure 2.2: Composition of the Addis Ababa Action Agenda
Figure 2.2: Composition of the Addis Ababa Action Agenda

Action plans must have a shorter time window than 15 years, and therefore we introduce intermediate “operations plateaux” to make current action plans more concrete. For a country or sub-national territory, to be at an operations plateau means that the various functions of government, and the corresponding market and non-market interactions by agencies, organizations and individuals perform at a certain level, with indicators between certain ranges.

The world operations are composed of the country operations of the countries that take part in the global economy, and these in turn are composed of sub-national operations, for instance in a state, province, region, district or city.

In the monitoring and evaluation function we need performance data about the operations. These data support us in making decisions about where to invest in change, for instance to improve health care, education, roads, utilities, environmental protection, etc. It will be clear that not all change can be implemented simultaneously and therefore it is useful to introduce the concept of plateau for the operations: it are operations as enabled by a relatively stable societal architecture which exists during a limited period of time.

Material and Content Scope

The focus is on interactions which may take place both in the content and the material stratum. Material stratum activities such as growing crop or raising livestock may have narrow interfaces with the content such as plans (prescribing what to do when), and recording applications (recording what has happened, for instance for monitoring and evaluation purposes).

Operations are particular to sectors and their localization to conditions, such as geography, ecology and regulations in the countries of the world.

Possible Economies

Economies of scale and skill are the economies typically achieved in production systems and supply and distribution chains.

Figure 2.3: Improving operations
Figure 2.3: Improving operations

Collective or Individual Action?

Excessive collective action in the operations realm harms competitiveness, innovation and creativity. Also regulation may harm competitiveness.

The decision monopoly that is characteristic of government or any other collective decision making has a tendency to harm diversity and accumulate more operational tasks than is optimal.

This is a major concern of free market advocates. In the operations realm, individual action and its aggregation in competitive firms tends to yield progressive outcomes.

On the other hand, there is the paradox of capitalism.

The elements of operations

The below figure from Worksystem (Do) (Ens.wiki) uses the model elements and layers of the Archimate Architectural Framework for describing the elements of operations.

Figure 2.4: The elements of operations in the facility or work system pattern
Figure 2.4: The elements of operations in the facility or work system pattern

A role for cooperatives

Cooperative entities may create for their members low hurdle access to multiple critical resources that matter to achieving economies of scale and skill. Such cooperative entities are classified as meso actors in the Societal Architecture.

To the chapter


2.5 - Monitoring and evaluation

Background

Material and Content Scope

The interface of monitoring and evaluation with the material stratum is limited, for instance via printed matter or the energy use of computing centers and communications devices.

In this realm the focus is on communications and the formulation of goals and targets, indicators and the collection of data, the interpretation of data, and other types of content (content life cycle).

Figure 2.5: Material and content in Monitoring and Evaluation
Figure 2.5: Material and content in Monitoring and Evaluation

As decision making is becoming increasingly knowledge intensive (and data-driven) there is a risk of excessive use of print, including for content that is only useful for a short period of time.

Possible Economies

Economies and shared value can be achieved by a “collaborative” adhering to the Digital Capability Principles, for instance via reuse (reusing content via social web solutions) and the use of open standards (much content can be easily accessed, navigated, analysed, and experimented with (simulation)).

Collective or Individual Action

Too little collective action would increase costs of monitoring and evaluation while reducing the diffusion of best practices: if peers measure different properties and performances, how could investments be allocated efficiently, or how could they practice benchmarking? And how to avoid that competitive pressures on price harm quality and service levels? In the monitoring and evaluation realm important synergies can be achieved by collective approaches.

The elements of monitoring & evaluation

The below figure from Driver-Goal-Gap pattern (Ens Wiki) uses the model elements and layers of the Archimate Architectural Framework for describing some of the elements of Monitoring and evaluation.

The next figure shows the elements of monitoring and evaluation in the Driver-Goal-Gap pattern (using ArchiMate’s model elements).

Figure 2.6: The elements of monitoring and evaluation in the Driver-Goal-Gap pattern
Figure 2.6: The elements of monitoring and evaluation in the Driver-Goal-Gap pattern

To the chapter


2.6 - Change

Background

The change management process has been extensively studied and there are several methods to support it (Educational Business Articles, 2022).

The steps in the process are recurrent for change processes at different socio-technical levels in the Societal Architecture.

In a multi-stakeholder sociotope, several change initiatives may be ongoing simultaneously, as described at initiative management (worx.wiki).

Multiple change initiatives could be developed during overlapping time windows, taking into consideration dependencies and other initiatives in which interested parties are involved.

A recent Dutch study Staat van de Uitvoering (State of the implementation) uses the term “stacking of policies” to indicate a major cause of complexity and the incompetence of public service providers to realize the policy promises.

Material and Content Scope

Overall both content and material stratum matter, yet depending on the stage of the initiative either of these strata will be dominant.

When multiple stakeholders are affected by the decision it is recommended that all are consulted from the early phases onwards. In CPIM this would mean, from the Identify and Validate phase onward.

As Understanding through Modeling is a key feature of the communication on complex problems, this book advocates for a shared use and elaboration of several models. With a depth of modeling and analysis that depends on the problems, disagreements or dilemmas that must be solved.

The Research and Leverage phase in the portfolio would typically conclude when all stakeholders have reached an agreement on the definitions and planning of the required changes, and together are ready to commit the investments for the execution (Invest and Execute).

Possible Economies

Benchmarking, exchange of best practices. This is preferably organized by a cooperative meso-level organization.

Figure 2.7: Material and content in Change
Figure 2.7: Material and content in Change

Individual, collaborative or collective action?

For interventions in a particular work system (operations), individual action must be relied upon.

Collaborative approaches are suitable (or recommended) where common or complex problems are at the origin of the change initiative, and where analysis and design has confirmed that multiple stakeholders need to act in order to solve the problem. Also when much prior knowledge must be relied upon, a collaborative approach is recommended.

See for instance Multisystemic Therapy and Collaborative therapeutics.

Via the social contract the “collective action” is enforceable by the government. Increasingly governments use collaborative approaches during the preparation of bills.

The elements of change

The below figure from Change (Adjust|Act) (Ens Wiki) uses the model elements and layers of the Archimate Architectural Framework for describing the elements of change.

Figure 2.8: Changing a facility or work system - pattern
Figure 2.8: Changing a facility or work system - pattern

To the chapter


2.7 - Partnership and Capability Development

“Business capability maps are used for a variety of strategic change purposes such as to align business leaders and other stakeholders on investment decisions. Capabilities are not IT concepts but are used to describe the abilities of an enterprise, i.e. what activities it’s able to do, either now or in the future, rather than how a business performs these activities. Leadership uses capabilities to advance their strategy and guide investment plans.” (Reed & Ihnen, 2021)

To scale capability mapping for strategic investment planning from a business to society “at large” we have slightly modified the Generic Activity Model for Statistical Organizations v1.2 (GAMSO v1.2, UNECE (2019)) to create the Generic Capability Model for the Sustainable Development Partnership depicted in the figure below.

Figure 2.9: The Generic Capability Model for the Sustainable Development Partnership
Figure 2.9: The Generic Capability Model for the Sustainable Development Partnership

Some of the notable changes with GAMSO V1.2:

  • Strategy and leadership is positioned as a foundational capability to indicate that it underpins the capability development and partnership support to a vast range of different partner journeys.
  • In all capability and value stream definitions, the reference to statistical organizations is replaced by one to partners.
  • The GAMSO “Production” activity is replaced by the Courses of action “Macro, Micro, Meso and Pico journeys”, the operations of entities at macro, meso, micro or pico socio-technical level (of scope), each of which can be the focus of the Action Options.

The courses of action are supported by capabilities that consist of specific value streams:

In the definition of the value streams, we focus on shared aspects in the techno- and socio-tope. However, an operational entity may also nurture capabilities independent from its peers, often competitors, investors, and customers. We are aware that such independent capability development receives most attention in the literature, and in consultancy, yet it is not the primary focus of this book.

To illustrate the definitions, consider emission accounting as a capability in a techno-tope.

Value streams of the Strategy and Leadership Capability

In the Strategy and Leadership capability, the value streams are:

  • Define vision: This value stream ensures that operational entities understand the environment in which they operates and the emerging issues they are confronted with, so that it is clear where they can provide specific products or services for use by the broader community. Aware of the shared vision, each operational entity determines its high-level goals and directions, including the values which will guide it, so they set their change initiatives accordingly. This also includes communicating the mission, values and expectations internally and externally, to lead and inspire staff and to increase government and community trust and confidence in the organization and its products or services in general.
  • This value stream includes:
    • Understand sector specific, national and international directions and factors
    • Determine vision, mission and strategic goals, and interdependencies between common and individual aspects,
    • Determine organizational value proposition
    • Determine and communicate values and expectations
    • Create interest and awareness
  • Govern and lead: This value stream covers the development of strategies to achieve the goals and directions set under Define Vision, the common and individual aspects. They include identification and prioritisation of the initiative portfolio and work programme, prioritisation of the capital investment programme, and the allocation of resources (capital and labour) to implement the agreed programmes defined in the product, service and capability portfolios. Under Govern and Lead the need for capability improvements is identified and requested by prioritising the capability portfolio, under Capability Development the requested and prioritized capability improvements are planned in more detail, developed, monitored and after their full integration in the operations their support is transferred to Corporate Support.
  • Activities under Govern and Lead include:
    • Develop strategies for achieving organizational goals
    • Prioritise capability portfolio
    • Prioritise the product and service portfolio
    • Define and manage change programmes
    • Allocate project and programme portfolio budgets
    • Build and maintain internal and professional excellence
    • Ensure general coordination and alignment
    • Define general organizational policies
    • Publish policies, guidelines and normative documents
  • Manage Strategic Collaboration and Cooperation: This value stream covers collaboration, cooperation and coordination with other organizations and other external stakeholders. They can include coordination within a sociotope or technotope, which may be based on a geographical hierarchy of entities (local, regional, national, multi-national), or a split of responsibilities between organizations based upon activities. They include activities undertaken to identify new opportunities for portfolios. They provide the community with opportunities to exchange knowledge, to improve infrastructure and practices and to influence operational standards. These activities contribute to the building and enhancing of shared capabilities managed by partners, leading to increased understanding of sustainability among peers, and improved application and use. They include organization and coordination with other organizations as part of sector, national or international systems.
  • Activities under this value stream include:
    • Build and maintain strategic relations, in the value stream, nationally and internationally
    • Build and maintain operational excellence for the own operations
    • Advance inter-organizational and international collaborations
    • Secure support for improving the sustainability of the product, service and capability portfolios

Value streams of Develop Capability

This capability includes research, development and innovation activities i.e. the development of capabilities that enable the partner to undertake new activities, or to improve the efficiency of existing ones. It promotes the re-use and sharing of infrastructure (content and technical), both inside the organization and across organizations, to facilitate harmonisation and to improve the coherence of inputs and outputs. Some of these activities may be outsourced to partners in the private or academic sectors, or even to other peer organizations. When a new capability or a capability improvement is fully integrated in the operations, its support is transferred to one or more activities of Manage Operations.

This capability is broken down into 4 value streams. The value streams are:

  • Plan Capability Improvements: This value stream aim at planning the best way forward to develop a new capability or improve an organization’s capabilities. They require a thorough organizational view of change requirements, the prioritisation of options through an efficient, iterative approval process until a work programme for capability improvements is finalised. This capability further coordinates the planning and resourcing of cross-cutting/reusable capability improvement projects (both large and small), to ensure key improvement work is integrated across the organization, with interdependencies understood and the resources optimized across the work programmes and portfolios. This capability also monitors the ongoing progress of the work programme and report to the relevant governance fora to ensure all required change requests occur in an efficient and effective manner.
  • Activities under this value stream include:
    • Identify disruptions and capability improvements
    • Propose capability improvement projects
    • Manage capability improvement programmes
  • Develop Capability Improvements: This value stream develops approved improvement projects from the requirements stage through to their completion. The developers will undertake background research, define the detailed requirements, coordinate the design and building, and finalize all aspects of the capabilities being developed, including their deployment for operational use. The activities mainly concern the development of capability improvements for multiple operational processes, including cases where capability improvements are developed through partnering with other organizations or through implementing reusable infrastructure originally developed by others. Capability improvements in the context of a single operational process are included in the manage operations value stream.
  • Activities under this value stream include:
    • Undertake background research
    • Define detailed capability requirements
    • Design capability solution
    • Build/procure and deploy capability solution
  • Monitor Capability Improvements: This value stream aims at monitoring the organization capabilities, ensuring the organization reaps maximum benefits from investments. They involve maintaining capabilities, evaluating them or suggesting where improvements are required. Staff members undertaking these activities effectively become the custodians/reference persons for the capabilities, taking responsibility for their fitness for purpose.
  • Activities under this value stream include:
    • Maintain capability improvements
    • Promote capability improvements
    • Evaluate capability improvements
  • Transfer Support of Capability Improvements: This value stream provides the technical hands-on assistance required across the organization to ensure that the capability improvements are actually used in support of the statistical work programme. These activities also guide the successful operation of individual reusable business processes and transfer of shared infrastructures. When a capability improvement is fully integrated in Production, its support is transferred to one or more activities of Corporate Support.
  • Activities under this value stream include:
    • Transfer design
    • Transfer operations
    • Transfer user support

Value streams of Manage Operations

This capability supports standardisation. It covers the cross-cutting activities required by any organization to deliver its work programme efficiently and effectively. When a capability improvement is fully integrated in the operations, its support is transferred to one or more activities of Manage Operations.

This capability is broken down into these value streams (which are not described in further detail as extensive literature exists about each of them):

  • Manage Operations
  • Manage Monitoring & Evaluation
  • Manage Quality
  • Manage Information and Knowledge
  • Manage Partners
  • Manage Data Suppliers
  • Manage Finances
  • Manage Human Resources
  • Manage Information Technology (IT)
  • Manage Buildings and Physical Space

To the chapter

2.8 - Towards a Talent Explosion

Figure 2.10: Talent Explosion and Small World Blueprint
Figure 2.10: Talent Explosion and Small World Blueprint

Chapter 3 - Understanding through Modeling and Simulation


3.1 - Modeling and Simulation
3.2 - Values for a Universal Agenda
3.3 - Why Study Modeling and Simulation?
3.4 - General Reasons to Model
3.5 - System and Ecosystem
3.6 - Models and Model Layers
3.7 - Classification of Systems and Models
3.8 - Types of Models and Representations
3.9 - Activity & Tool “Parameters” in Simulation and Experimentation
3.10 - Towards a Comprehensive Simulation and Experimentation Method?


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


3.1 - Modeling and Simulation

Modeling and simulation are techniques for representing situations or systems (economic, military, mechanical etc.) by means of something else, usually at a smaller scale. Modeling and simulation are helpful because they allow you to take a good look at something that is too big or impractical to see otherwise.

Modeling and simulation are therefore much used in analysis, design and decision making.

Since more than two decades now, digital modeling and simulation tools have been developed.

Modeling and simulation are applied and performed in different ways in the talent explosion.

The various model elements and model layers of Archimate offer a very good starting point for appreciating the diversity in such models.

At present most professional modeling literature targets a specific target group, the so called enterprise and ICT architects. In this book we want to demonstrate the utility of these model elements for a much broader group of mindful users: anyone who aims for an “untrapped” mind in journeys at any of the socio-technical levels macro, meso, micro and pico.

As the complexity of society has grown, also the mind traps have become much more sophisticated.

But how to avoid mind traps at all levels in society, in all walks of life?

The objective of this book is to show that modeling and simulation tools can help us, and in particular those people who aim to participate directly in the value-based rule making.

For analysts and designers in a wide variety of decision making situations, the use of modeling and simulation 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 and simulation can be used with the purpose to improve regulations, or to enact new regulations. But why change the operations of an existing work system, or why change regulations?

In general terms change “by design” in a worksystem or a stakeholder constellation can be due to three different causes: problems, directives and opportunities (Whitten et al, 2004):

  • 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 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 3.1). An example is repairing a flat tire of a bicycle.

Other problems appear new, or are indeed new. Solution search in such cases may involve the use of models (i.e. simplified representations) of the systems in which the problems occur. 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 often possible to make other models. In addition to mathematical models many other models exist (right hand branch in Figure 3.1).

Figure 3.1: Solving problems in different ways
Figure 3.1: Solving problems in different ways

Modeling and simulation are 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 and simulation are indispensable 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 and simulation in almost every academic department from economics and social science to engineering and computer science (Fishwick, 1994).

To the chapter


3.2 - Values for a Universal Agenda

But what problems do we want to solve in sustainable development? To answer this question, one must first decide what to value.

The road to dignity by 2030: ending poverty, transforming all lives and protecting the planet (Synthesis report of the Secretary General on the post-2015 sustainable development agenda, December 4, 2014) proposes six values as essential elements for delivering on the sustainable development goals:

  • Dignity: to end poverty and fight inequalities
  • People: to ensure healthy lives, knowledge and the inclusion of women and children
  • Prosperity: to grow a strong, inclusive and transformative economy
  • Planet: to protect our ecosystems for all societies and our children
  • Justice: to promote safe and peaceful societies and strong institutions
  • Partnership: to catalyse global solidarity for sustainable development

The figure below shows these values in their “official” graphical form.

Figure 3.2: Values in The road to dignity by 2030
Figure 3.2: Values in The road to dignity by 2030

A second figure shows the values using the Archimate value model element.

Figure 3.3: Values in The road to dignity by 2030 (Using the value model element)
Figure 3.3: Values in The road to dignity by 2030 (Using the value model element)

To the chapter


3.3 - Why Study Modeling and Simulation?

For decades already, modeling and simulation are among the most widely used operations research and management science techniques (Law & Kelton, 2000, page 2). With this book we want to position and launch them also as a powerful and innovative knowledge sharing technique, and as a tool for understanding complex situations.

Both modeling and simulation are software, knowledge and data-intensive decision techniques. Yet as the software tools have become very conducive for working with models, the knowledge needed to work with the tools has become far less elaborate than it used to be.

A small investment in learning tools yields a huge dividend in ability to understand the issues that keep us from more sustainability.

An introductory level area of applying modeling is in the reuse of reference models.

One advanced area of application is in the analysis and design of operational processes. Another one is in the area of software development.

In this book we will focus especially on the areas which require introductory kinds of modeling, as modeling in all other areas build on those basic models.

The modeling of operational processes belongs to the core competences of work system analysts and designers in Management Science whose focus is the (re-) design of business processes in order to achieve a desired performance or to improve the actual performance. Several skills of the decision maker are challenged in modeling and simulation studies, these include:

  • describe adequately the problems and objectives of the system of interest;
  • describe adequately business processes and their performance;
  • analyze actual business processes and their performance, aimed at an explanation of the relation between the performance and the chosen or actual design;
  • create alternative designs for business processes, aimed at achieving the desired (change in) performance;
  • choose between alternative designs;
  • test the chosen design on relevant aspects;
  • make a realistic planning for implementation or further research.
Figure 3.4: Operational processes
Figure 3.4: Operational processes

In order to describe and analyze business processes and evaluate their performance, the decision maker should be able to use quantitative methods, both in a statistical way (data gathering and analysis) and in the modeling (logical and quantitative modeling and analysis). Hence, modeling and simulation studies also require a lot of knowledge, on project definition in the decision making context, on the modeling of the operational processes, on statistical inferences, and (for validation purposes) on relevant classes of systems with analytically computable performance. Last but not least, modeling and simulation studies require the use of software tools, to design and manage the models, to execute the models, and to analyse the simulation results. In this book you will apply and extend knowledge and skills of qualitative techniques that can be extended with quantitative techniques. Such extensions will be illustrated but not explored at great lenght.

To the chapter


3.4 - General Reasons to Model

  1. To understand
  2. To improve service
  3. To predict performance/outcomes
  4. To guide
  5. Because analytical models are not feasible, not practical, or not valid
  6. Trial by implementation can be too costly, or too time consuming, or even too dangerous
  7. Timescale may be too long to get accurate real measurements
  8. To learn doing something

Example: flight simulators.

To understand

One example are climate models that are used to understand and predict the impact of solar radiation and greenhouse gases on the earth’s surface temperature.

In a very different strand of modeling, we will use models to understand the details of the EDIFACT messages that have been designed by the International Trade and Business processes groups listed in Figure 3.5.

Figure 3.5: The International Trade and Business process groups of UN/CEFACT
Figure 3.5: The International Trade and Business process groups of UN/CEFACT
To improve service

Example: use of a simulation model to reduce waiting time of patients in a hospital emergency room

To predict performance/outcomes

It is used to test scenarios.

Example: Modeling of a potential layout for a new factory.

To guide

Example: Modeling of student demand for computers in the laboratory room.

Because analytical models are not feasible, not practical, or not valid

Most systems are stochastic and dynamic

Trial by implementation can be too costly, or too time consuming, or even too dangerous.
Timescale may be too long to get accurate real measurements
To learn doing something

Example: flight simulators.

To the chapter


3.5. - System and Ecosystem

If we want to use modeling for the study of systems that matter to sustainable development we must be aware also of the difference between a system and an ecosystem.

A system is a collection of interrelated components existing in the natural world or organised for a given purpose. A system may be declared a component of a larger system, and each component in a given system may also be a system.

Examples of systems in the natural world included the solar system. In the human body, itself a system, we refer to sub-systems, such as the nervous system and the digestive system.

In addition, all so-called “things” (objects) are (part of) systems. For example, a cup is an object, but it is also a system for holding hot or cold liquid, or other material. A cup has been put together in such a way as to provide a useful function.

A collection of components organized to accomplish a specific function or set of functions is also a system (IEEE Std 1471-2000).

A collection of real-world items organised for a given purpose. A system is characterized by its structure and its behaviour (ISO 15704).

A system is a collection of different things which together produce results unachievable by the elements alone (Rechtin and Maier, 1997).

An ecosystem is a community of organisms (plant, animal and other living organisms - also referred as biocenose – the totality of organisms in the ecosystem) together with their environment (or biotope), functioning as a whole.

An ecosystem can be defined as any situation where there is interaction between organisms and their environment. It is composed of the entirety of organisms (called the biocenose) and the medium these organisms exist in (the biotope). Within the ecosystem, species are connected and dependent upon one another in the food chain, and exchange energy and matter between themselves and with their environment.

Some questions in the study of ecosystems are:

  • What are the ecosystems dynamics and changes ?
  • How does an ecosystem interact at local, regional and global scale?
  • Is the current state stable?
  • What is the value of an ecosystem? How does the interaction of ecological systems provide benefit to humans?

Ecosystems can be classified by reference to the biotopes concerned, or by reference to the biocenose. Examples of the former are forest ecosystems and agro-ecosystems (agricultural systems).

Whereas the term ecosystem is mostly used in reference to natural systems, several analogies with economic systems exist. This is leading to a wider use of the term (business) ecosystem, for instance to cover also the existence of businesses in their socio-economic environment.

Ayres (2004) explores the analogies between natural functions and industrial activities and notes similarities regarding the cycle of consuming, producing and sinking (eat, digest, waste excretion), and that firms like organisms compete for resources. He especially warns for the unjustified use of ecological concepts in an economic context (the analogy between ecology and economics has very little value). One of the differences is in the evolution of the ecosystem.

Evolution in nature is driven by differentiation by random mutations of the genome and Darwinian selection based on reproductive success.

In economics, differentiation is based on discovery, invention and innovation by intelligent economic agents and selection is based on competition at the individual or firm level.

Figure 3.6: Decision making in a complex society
Figure 3.6: Decision making in a complex society

3.5.1 - Biotope, Sociotope and Technotope

In society the entelechy proceeds by interactions in Biotope, Sociotope or Technotope.

Biological and physical systems become in the biotope which offers an area of uniform environmental conditions providing a living place for a specific assemblage of plants and animals. Biotope is almost synonymous with the term habitat, but while the subject of a habitat is a species or a population, the subject of a biotope is a biological community.

Physical, chemical and bio-physical interactions in the Natural Order. These are studied in dedicated sciences and are not specifically addressed here. Yet insights stemming from these sciences should be considered when taking decisions.

Climate change is threatening the biotope of mankind, which is a natural order problem.

Socio-technical interactions occur in the Social Order and in the Techno Order. Patterns for these interactions have an impact on how effective and efficient we are in coping with challenges.

In more general terms the entelechy, or becoming in sociotope and technotope rely on biological and physical systems, but involve additional systems such as legal systems, businesses and agencies and the products and services they provide to society.

A sociotope is a defined space that is uniform in its use values and social meanings. It can be described as the collective life world of a place, its use and meaning, in a specific culture or group of people. The sociotope is defined in the real world where it is shaped by a multiplicity of lifestyles, trades, regulations and services connected to a specific place which can be local, national, regional or global.

For the group of social actors, the sociotope typically includes a number of regimes and a public sphere.

A technotope is an external space that is uniform in its use values, social meanings and technology uses. It can be described as the collective life world of a Sociotope enhanced with cyberspace, its use and meaning, in a specific culture or group of people. The technotope is defined simultaneously in the real world and cyberspace where it is shaped by a multiplicity of lifestyles, trades, regulations and services connected to a specific place which can be local, national, regional or global, and which involve technical artefacts such as smart phones, computers, digital service platforms, and so forth.

Note that the term Sociotope as defined in Wikipedia also covers the term technotope. In this book a distinction is introduced to reflect the digital revolution that we are experiencing since the sixties.

Thus three related systems in context are of interest to our decision making:

  • the natural system in the biotope,
  • the actor in the sociotope, and
  • the digitally empowered actor, in the technotope.

When considering the Extended Generic Activity Model (Figure 1.4), the sociotope adds a first layer of semiotic flows to the material flows of our lifeworld, and its facilities. The technotope adds a second layer of semiotic flows. In general, the technotope semiotic flows are more complex than the sociotope semiotic flows, to the extent that for the “average” human mind advanced models are needed to make sense of the technotope semiotic flows.

Improved use of modeling and simulation tools is proposed as an essential skill for people to participate as decision makers in the techno-order, and a key skill to participate in the social order.

For the group of social actors, the technotope typically includes regimes that also involve techno-order items.

In a sociotope or technotope, the operational processes that are executed in the context of the firm interact with those of other firms, those of state-actors and those of consumers and employees. Moreover these processes must be designed such that they are compliant with rules and norms that exist in the socio-economic environment, and such that they can be performed with affordable equipment and available human skills.

The terms ecosystem, sociotope and technotope are used to reflect the subtle relationships that exist between the operational processes of a system on the one hand, and the assets in the environment of the system on the other hand.

3.5.2 - Classes of Agents

The decision making in the Biotope, Sociotope and Technotope is performed by different classes of agents with a differentiated power range.

The broad classes of these agents are depicted in figure 3.7 which shows a UML class diagram that includes several concepts from the e-Government Core Vocabularies

Figure 3.7: Classes of Agents
Figure 3.7: Classes of Agents

3.5.3 - The Range of possible Collaborations

The decision making in the Sociotope and Technotope is related to a wide range of collaborations in which agents participate optionally, or mandatory by governments in the context of the social contract that prevails in the jurisdiction where the natural or legal person lives.

Some typical properties of the collaborations are depicted in figure 3.8. The UML class diagram includes several concepts from the e-Government Core Vocabularies. It uses the EDIFACT elements to illustrate possible variations in those collaborations and also invokes the ISIC and CPC classes to indicate the expressiveness of the conceptual model.

Figure 3.8: Collaborations in Sociotope and Technotope
Figure 3.8: Collaborations in Sociotope and Technotope

There is a reference to tax types as chapter 15 will address a Global Tax Portfolio.

To the chapter


3.6 - Models and Model Layers

Figure 3.7 and Figure 3.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 externalised 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 3.9).

Model driven software engineering versus model driven simulation engineering

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 and simulation 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 3.9. In this book we will articulate CIM layer domain and process models as a means to scope initiative 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.

Figure 3.9: Project Activities, Models (and Data) and Risks (Goossenaerts, 2004)
Figure 3.9: Project Activities, Models (and Data) and Risks (Goossenaerts, 2004)

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

To the chapter


3.7 - Classifications of Systems and Models

In general systems can be classified as:

  • Static versus dynamic,
  • Continuous versus discrete,
  • Deterministic versus Stochastic,
  • Terminating (or steady-state) versus non-terminating systems.

To cover such models, note that experiments and simulations can be classified as:

  • Statistical,
  • Discrete,
  • Continuous,
  • Combined discrete and continuous.

Static versus dynamic

A static system refers to a system that is not influenced by time, or for which the time factor can be neglected. An example is a cup as a system for holding liquids, or a map (for as long as there are no changes to the roads).

A static simulation model refers to a model that is not influenced by time. Time doesn’t play a natural role in static models. There is no simulation clock involved. Seconds, hours, days and months play no role in a model. The state of a model does not change with respect to time.

A simulation model that imitates the roll of a die is an example.

The output of the model, (1,2,3,4,5 or 6) is not affected by time. An experiment is a sample from the discrete uniform distribution [1..6].

A dynamic system is a system which changes over time. The state of the system evolves as time flows.

A dynamic model is a model in which the flow of time is approximated by simulated time. The model has state variables, the value of which evolves according to simulated seconds, hours, days and/or months. A mathematical clock is used to track simulated time.

Service and manufacturing related systems are generally represented with this type of model. Production schedules, equipments utilizations, customer arrival rates, and throughput are a few examples of dynamic variables. Their values can change with respect to time (Gogg and Mott, 1996).

A simulation model that is executed in a simulation environment is also a system. Its components are chunks of data in the simulation environment and its dynamics consists of the changes to these data elements.

Continuous vs. Discrete

Discrete-event-simulation concerns the simulation of a system as it evolves over time by a representation in which the state variables change instantaneously at separate points in time. (In more mathematical terms, we might say that the system can change at only a countable number of points in time). These points in time are the ones at which an event occurs, where an event is defined as an instantaneous occurrence that may change the state of the system. Although discrete event simulation could conceptually be done by hand calculations, the amount of data that must be stored and manipulated for most real-world systems dictates that those discrete-event simulations are done on a digital computer (Law and Kelton, 2000).

Applications: manufacturing, network models, and service enterprise models.

Continuous simulation concerns the simulation over time of a system by a representation in which the state variable changes continuously with respect to time. Typically, continuous system models involve differential equations that give relationships for the rate of change of the state variables with time. If the differential equations are particularly simple, they can be solved analytically to give the values of the state variables for all values of time as a function of the values of the state variables at time 0. For most continuous models analytic solutions are not possible, however, numerical-analysis techniques are used to integrate the differential equations numerically, given specific values for the state variables at time 0.

A typical example of continuous simulation involve models built in so called analogue computers. In an analogue computer differential equations are modelled as electronic circuits that add, multiply, integrate or differentiate electronic signals. As long as digital computers were relatively slow, they have been used intensively to analyse e.g. mass-spring systems, like the suspension of a car. Also models of economic systems have been constructed with analogue computers. Today digital computers are fast and cheap enough to approach the continuous behaviour of differential equations and analogue computers are rarely used anymore. However, a digital computer is a discrete system by nature so, even if the mathematical model is a continuous model, the execution of that model in a digital computer is always in discrete steps.

Several simulation products have been specifically designed for building continuous system models (SIMULINK, Dymola and Vensim). In addition the Discrete Event Simulation packages JaamSim, Extend and AweSim have continuous Simulation capabilities. (Check: JaamSim - https://en.wikipedia.org/wiki/List_of_discrete_event_simulation_software)

Examples. For each case in Table 3.1 confirm if the system is best modelled as a discrete event system or as a continuous event system:

System Discrete Event Continuous Event
The flow of customers through a bank’s drive-in teller window X  
The consumption of fuel by a fighter jet during routine flight manoeuvres   X
The spread of cancer through a victim’s lymphatic system   X
The assembly of cars at an automobile assembly plant X  

Table 3.1: Examples of discrete and continuous event systems.

Combined Discrete-Continuous Simulation.

Since some systems are neither discrete nor completely continuous, the need may arise to construct a model with aspects of both discrete-event and continuous simulation, resulting in a combined discrete-continuous simulation. This kind of simulation can be built using for example JaamSim, AweSim and Extend.

Example. Consider an underground railway in which trains move from station to station, picking up and depositing passengers at each. Viewed from the perspective of discrete change there are number of obvious systems events. For example:

  • Train stops at station,
  • Doors now open,
  • Doors now close,
  • Train starts to leave station.

Thus to simulate this system using a discrete model, the time taken to travel between stations or to open the doors would either be known deterministically or could be sampled from some appropriate distribution. Thus, for example, when the train starts to leave a station its arrival at the next station could be scheduled by referring to this “known” journey time. In a discrete simulation, the variables are only of interest as and when they point to a change in the state of the system.

If the underground railway were to be simulated via a model which allowed continuous changes, then the variables would be continuously changing their values as the simulation proceeds. Consider for example the train as it travels between stations. If the locomotive is electrically powered, its speed will increase smoothly from rest until it reaches an appropriate cruising rate. The speed does not change by discrete amounts. Thus, if the results of the simulation are to include the state of the system in relation to the continuous variable “speed, then a continuous change model is needed. These continuous changes could be represented by differential equations which would, in theory, allow the variables to be computed at any point of time (Pidd, 1998).

Deterministic vs. Stochastic

A stochastic model contains processes controlled by random variables (See Table 3.2 for examples of random events). The word variable implies that something is capable of changing. It does not have a specific value, but rather a range of values. Random signifies that the changes can occur with no particular pattern. A stochastic process is composed of a sequence of randomly determined values. Time between failures on a piece of equipment is an example of a stochastic process. The time required to repair the equipment is another. Time values for both can change indiscriminately with each occurrence. Most queuing and inventory systems are modelled stochastically. Stochastic system models produce output that is itself random, and must therefore be treated as only an estimate of the true characteristics of the model; this is one of the main disadvantages of simulation.

Examples of random occurring events
Schedule changes
Engineering changes
Equipment failure
Test times
Customer arrival into a system
New product development times
Defect/scrap rates
Operation cycle times
Absenteeism
Material shortages
Wait time between operations
Repair time

Table 3.2: Examples of random occurring events.

A deterministic model is any model that does not contain random variables. Results produced by this type of model are not influenced by probability. In deterministic models, the output is “determined” once the set of input quantities and relationships in the model have been specified; even though it might take a lot of computer time to evaluate what it is. An example is a model which solely uses average values or constants to represent the functions and characteristics of its entities. A spreadsheet analysis could be considered as a deterministic model. Another example is a complicated (and analytically intractable) system of differential equations describing a chemical reaction. Many systems, however, must be modelled as having at least some random input components, and these give rise to stochastic system models (see the example below).

Example. Simulation analysts have sometimes replaced an input probability distribution by its mean in their simulation models. This practice may be caused by a lack of understanding on the part of the analyst or by a lack of information on the actual form of the distribution (e.g., only an estimate of the mean of the distribution is available).

Consider a manufacturing system consisting of a single machine tool. Suppose that “raw” parts arrive to the machine with exponential inter-arrival times having a mean of 1 minute and that processing times at the machine are exponentially distributed with a mean of 0.99 minute. Thus this system is an M/M/1 queue with utilization factor = 0.99. Furthermore, it can be shown that the average delay in queue of a part in the long run is 98.0 minutes. On the other hand, if we replace each distribution by its corresponding mean (i.e. if customers arrive at times 1 minute, 2 minutes,…, and if each part has a processing time of exactly 0.99 minutes), then no part is ever delayed in the queue! In general, the variances as well as the means of the input distributions affect the output measures for queuing type systems (Kelton et al, 2000).

Terminating vs. non-terminating systems (or steady-state)

A non-terminating systems state keeps on changing. A steady state simulation implies that the system state is independent of its initial start-up conditions. Analyses from these models are based on output data generated after steady-state conditions are achieved. The cumulative average of multiple die rolls can be used to demonstrate this principle. After a certain number of rolls, the cumulative average of all values rolled will remain at approximately 3.5. The point at which this occurs exemplifies a steady-state condition. A steady state condition for the average value of a die roll occurs approximately after the 500th roll. Another non-terminating system is a 3-shift production factory. Process industries are also examples of non-terminating systems (oil refineries, Steel industries…).

A non-terminating system is a system that reaches a steady state at a certain moment.

A terminating simulation runs for a predetermined length of time or until a specific event occurs. Analyses and conclusions are based on output values produced at the stopping point. The results of terminating simulations are usually dependent upon the initial values and quantities used when starting the model. For this reason, the start-up conditions in terminating models should accurately reflect the start-up circumstances exhibited in the real world system that is being studied.

An example of a terminating system is the number of customers in a supermarket, considered the limited opening hours.

The decision whether to employ a steady-state or a terminating simulation is made during the preliminary planning stages of a simulation project. The choice is dependent upon the type of system being modelled. A facility which manufactures bottles twenty-four hours per day would likely be analyzed with a steady-state simulation.

Many real-world systems may never reach a steady-state condition. Consider an automated storage/retrieval system consisting of six independently functioning carrousels. The carrousels contain tote-pans which house parts for a production process. Each carrousel is subjected to random storage/retrieval requests for parts during production hours. All totes are returned to the carrousels at the end of each production shift, such that each carrousel begins a new shift with zero storage/retrieval requests.

Suppose the objective of a decision making engagement is to determine the average waiting time an order request experiences at a carrousel during a single production shift. Steady-state conditions for order queue lengths may not occur during this time duration. Given these circumstances, a terminating simulation would probably be used to analyze the system (Gogg and Mott, 1996).


To the chapter

3.8 - Types of models and representations

The simulation of physical and digital systems, the use of the resulting models in simulation and experimentation, and the evaluation of the simulation and experimentation results provides insight and understanding of the systems of interest. A simple example of a simulation involves the tossing of a ball into the air. The ball can be said to “simulate” a missile, for instance. That is, by experimenting with throwing balls starting at different initial heights and initial velocity vectors, it can be said that we are simulating the trajectory of a missile. This kind of simulation is known as analogue simulation since it involves a physical model of a ball. A computer simulation, on the other hand, is a simulation where the model is a computer program. We build a computer-based missile simulation by constructing a program that serves to model the equations of motion for objects in flight. If we regard the actual, physical system under study as being exact then we can create approximations of that model as being at different levels of abstraction. The scale in Figure 3.11 demonstrates different types of simulation, and gives an example of each type in the missile domain.

Figure 3.10: Different types of representations.
Figure 3.10: Different types of representations.

Let’s discuss the types in Figure 3.10 The physical model is the system under study - the missile in flight. That is, we seek to study a missile in flight by creating a model of it. One way of simulating this system is to create a smaller (or scaled) version of the system. A bullet is actually a miniature missile - therefore, we can study missiles in flight by shooting bullets instead. Bullets are, after all, much cheaper than missiles when it comes to experimentation. We can then answer questions about missile simulation by following this general procedure:

  1. Obtain the question to be answered or the problem to be solved in a given domain - such as ballistics. For instance, we can ask “How far does the missile go horizontally when the gun turret is placed 30 feet above the ground and aimed at a 40 degree elevation?”
  2. Translate the question and problem into the simulation model. We then translate the above problem into a small scale model using a bullet fired from a rifle. This involves correctly scaling down all aspects of the problem. This is not trivial, and many physical phenomena are not invariant to the scaling operation.
  3. Perform the simulation experiments. Fire the rifle several times.
  4. Measure the relevant quantities. Measure the horizontal distance of the bullet after it has hit the target.
  5. Scale the answer back to the missile domain.
  6. Provide the answer to the original question.

These six steps reflect the general method of modeling as applied to problems of prediction. The analog model takes some liberties with respect to modeling the physical system. Scale invariance is one such liberty. For missiles, any object can really be used to simulate a missile by simply throwing that object. Therefore, a tennis ball might serve as a reasonable model. Already we can see the need for picking a model that accurately reflects the system for the purpose of answering the questions. Balls might not be so good in the end, since balls have greater drag than missiles. Also, there are many other factors such as the amount of propellant to use that will help us to faithfully model the original system.

The first electronic computers were analog as opposed to digital. The primary use of an analog computer is to simulate a physical system that can be modelled as a set of differential equations. Electronic devices such as operational amplifiers when used in conjunction with resistors and capacitors function as integrators and differentiators. This means that one can simulate a set of equations by “patching” a panel (i.e., creating a program) on an analog computer. The most abstract type of simulation model is the digital model in which a computer program permits us to execute the model. Our interest is in digital models since they are the most flexible and can be easily programmed.

The physical model

It might be possible to experiment with the actual physical system. For instance:

  • Some cities have installed entrance-ramp traffic lights on their freeway systems to experiment with different sequencing to find settings that make rush hours as smooth and safe as possible,
  • A supermarket manager might try different policies for inventory control and checkout personnel assignment to see what combinations seem to be most profitable and provide the best service,
  • A computer facility can experiment with different network layouts and job priorities to see how they affect machine utilization and turnaround.

This approach certainly has its advantages. If you can directly experiment with the system and know that nothing else about it will change significantly, then you are unquestionably looking at the right thing and needn’t worry about whether a model or proxy for the system faithfully mimics it for your purpose.

Sometimes you can’t or shouldn’t play with the system. In many cases it’s just too difficult, costly, or downright impossible to do physical studies on the system itself.

  • Obviously, you can’t experiment with alternative layouts of a factory if it’s not yet built,
  • Even in an existing factory, it might be very costly to change to an experimental layout that might not work out anyway,
  • It would be hard to run twice as many customers through a bank to see what will happen when a nearby branch closes,
  • Trying a new check up procedure at an airport might initially cause a lot of people to miss their flights if there are unforeseen problems with the new procedure,
  • Fiddling around with emergency room staffing in a hospital clearly won’t work.

In these situations you might build a model to serve as a stand-in for studying the system and ask pertinent questions about what would happen in the system if you did this or that, or if some situation beyond your control were to develop. Nobody gets hurt, and your freedom to try wide-ranging ideas with the model could uncover attractive alternatives that you might not have been able to try with the real system.

The scaled model

There are different kinds of scaled models. On kind is the physical replica or scale model of the system, sometimes called an iconic model. For instance:

  • People have built tabletop models of material handling systems that are miniature versions of the facility, not unlike electric train steps, to consider the effect on performance of alternative layouts, vehicle routes and transport equipments,
  • A full-scale version of a fast-food restaurant placed inside a warehouse to experiment with different service procedures was described by Swart and Donno in 1981. In fact, most large fast-food chains now have full-scale restaurants in their corporate office buildings for experimentation with the new products and services,
  • Simulated control rooms have been developed to train operators for nuclear power plants,
  • Physical flight simulators are widely used to train pilots. There are also flight Modeling computer programs, with which you may be familiar in game form, that represent purely logic models executing inside a computer. Further, physical flight simulators might have computer screens to simulate airport approaches, so they have elements of both physical and computer-simulation models.

The mathematical models

A mathematical model represents a system in terms of logical and quantitative relationships that are then manipulated and changed to see how the model reacts, and thus how the system would react if the mathematical model is valid. (Law and Kelton, 2000) Such a model is just a set of approximations and assumptions, both structural and quantitative, about the way the system does or will work. A mathematical model is usually represented in a computer program that is executed to address questions about the model’s behaviour; when the model is a valid representation of the system, one hopes to learn about the system behaviour too. And since one is dealing with a mere computer program rather than the actual system, it is usually easy, cheap, and fast to get answers to a lot of questions about the model and system by simply manipulating the program’s inputs and specification. Thus, mistakes can be made on the computer where they don’t count, rather than for real where they do. As in many other fields, recent dramatic increases in computing power (and decreases in computing costs) have impressively advanced your ability to carry out computer analyses of logical models.

Models for computational simulation

In this book we are specifically interested in designing a mathematical-logical model of a real system. Implementing this model and experimenting with it on a computer is of less interest for us, but the interested reader may consult (Pritsker, 1986) or many other materials about the topic. In a computer simulation one would use a computer to evaluate a model numerically over a time period of interest, and data is gathered to estimate the desired true characteristics of the model (Law and Kelton, 1982).

During the past decades, and under the influence of the SIMULA programming language (see Griep and Flapper, 1987 for examples of system models specified in the SIMULA language) the description of computer programs has strongly evolved. Principles of object-oriented programming and modeling have been at the root of the UML development.

In general, the specification of system models draws on the contents of three other knowledge domains: Process Modeling, Data and Object Modeling and Programming.

To explain the way in which the models of those knowledge domains are applied in this book, we refine the notion of model which up to now has been defined in a very general sense.

We draw the distinction between the rather specific token model and the generic model which allows the generation of multiple token models.

Consider now a garage with 20 parking lots, and the arrival of cars, each of which must park for some time.

In the data and object model, we might represent the 20 parking lots by twenty squares on a blackboard, and the cars by stickers. In this case the model is built by representing elements from the system of interest by an object diagram. The situation that a car occupies a lot is represented by a link between the car’s sticker and the lot’s square.

It is now easy to perform a Hand simulation. Each time a car arrives, a new instance is created, and if possible, it is linked to a parking lot. The changes in the object diagram simulate the behaviour of the parking garage. The object diagram is the basic state variable of the system. For measurement purposes, we may introduce some auxiliary objects, for instance to measure the average occupation time, or to count the percentage of cars that doesn’t find a parking place. Such a model is called a token model.

In data and object modeling class models are used as a kind of generator for instance diagrams (or token models): each class classifies objects of a certain type (e.g. the stickers or the squares), each association classifies the links of the same type between the objects, and constraints limit the allowed configurations of instances that can be generated in reference to the class model.

The meaning of a class diagram is an infinite set of parking garages with cars parked, or looking for a parking lot. Each decision option will comprise an initial object diagram (token model). The token model will change in accordance with the arrivals and (simulated) decisions of the arriving cars.

A decision option would specify a size of the parking garage for a known car arrival process, with profit per car (as a function of time of the day, and some random distribution), and a given investment cost per parking lot.

In computing and computer programming one specifies the “computational changes” that, in response to an event, transform one token model into another one, the next one.

In process modeling one specifies possible successions of such events by means of Petri Nets or in BPMN models. The token progresses in the flow.

All these techniques allow the specification of (parts of) a computer-readable system model.

Computer simulation involves experimentation on the computer-readable model. The model is used as a vehicle for experimentation, often in a ‘trial and error’ process to demonstrate the likely effects of various policies. Thus, the policy which produces the best experimental results would be implemented in the real system. Figure 3.11 shows the basic idea.

Figure 3.11 Models enabling experimentation.
Figure 3.11 Models enabling experimentation.

Sometimes these experiments may be quite sophisticated, involving the use of statistical design techniques. Such sophistication is necessary if there is a set of different effects which may be produced in the results by several interacting policies. At the other extreme, the experimentation may be very simple, taking the form of “what if?” questions. Thus, if the simulation model represents the financial flows in an organization over the next 12 months, typical questions might be, “what if the interest rate rises by 3%?” or “what if the market grows by 5% this year?”. To answer these questions the modeling is carried out with the appropriate variables of the program set to these values (Pidd, 1998).

A simulation experiment serves as a “theory” or “hypothesis” for how a system really behaves over time. We may also simulate non-real systems by varying parameters, initial conditions and assumptions about the model. Modeling missile flight on a planet other than Earth, for instance, would involve a different gravitational constant and different parameters for the planet’s atmosphere. Fictional models are very popular in the form of role-playing modeling games, and they permit the modeling user to learn about a new environment by interactively exploring it. The concept of learning is paramount in modeling.

By modeling we can learn about a system and its environment in an extremely effective way and modify rules while seeing the effects of our interaction.

Computer simulation refers to methods for studying a wide variety of models of real world systems by numerical evaluation using software designed to imitate the system’s operations or characteristics, often over time. From a practical point of view, Modeling is the process of designing and creating a computerized model of a real or proposed system for the purpose of conducting numerical experiments to give us a better understanding of the behaviour of that system for a given set of conditions. Although it can be used to study simple systems, the real power of this technique is fully realized when we use it to study complex systems. While modeling may not be the only tool available to study the system, it is frequently the method of choice. The reason for this is that the simulation model can be allowed to become quite complex, if needed to represent the system faithfully, and you can still do a simulation analysis. Other methods require stronger simplifying assumptions about the system to enable an analysis, which might bring the validity of the model into question.

Models for Iterations

Use of mock-ups and wireframes to illustrate possible interface changes for actual systems, and clarify what these changes mean to the stakeholders.

3.9 - Activity & Tool “Parameters” in a Simulation Method

In spite of the fact that the modeling of operational processes is a mature discipline in the decision sciences, the ongoing innovations in information and computer systems give rise to a rapid evolution of the toolbox of the modeling expert.

For this reason, a methodology could distinguish the conceptual model and tool specific models, and make a selection of contents for those models, yet be aware that alternative contents could be provided. Table 3.3 lists steps, and choices of content alternatives for a course on simulation that colleagues and me have been teaching at the Eindhoven University of Technology. In the methodology, the first step is named Project Definition, and the second step Black Box and Assumptions as can be seen in Table 3.2.

CPN is the abbreviation of Colored Petri nets. CPN Tools is the name of a tool for editing, simulating, and analyzing Colored Petri nets.

Table 3.3: Content Alternatives for Step 3 and 4 of a Methodology
Table 3.3: Content Alternatives for Step 3 and 4 of a Methodology

A second consideration is related to the scaling of decision making between the scope of the “landscape” (macro and meso journeys) to the scope of the micro and pico levels.

While this e-book will not elaborate on simulation and experimentation, the modeling techniques presented could well be used to create simulation models and support experimentation. Possible steps beyond the conceptual modeling are described in Table 3.4. This table describes typical steps and their deliverables in a simulation method.

Table 3.4: Seven Steps in a Simulation Study
Table 3.4: Seven Steps in a Simulation Study

When comparing the table to the “steps in a sound decision making engagement” proposed by Law and Kelton (2000, pages 83-86) some differences and ressemblances are noted:

  • In step 1, the use of a decision frame to state the problem;
  • In step 2, the use of a black box representation;
  • In step 3, the use of a conceptual modeling language to define the conceptual model; this model could serve in a structured walk-through with the stakeholders to determine if the conceptual model is valid.
  • In step 4, the use of a simulation environment to develop platform specific models (or Construct a computer program and verify).
  • Step 5, Validation, maps to Law & Kelton steps 5 (make pilot runs) and 6 (Is the programmed model valid?)
  • Step 6, Experiments and Results, maps to LK steps 7 (Design Experiments), 8 (Make production runs) and 9 (Analyze Output Data).

On the other hand, the sound decision making engagement of Law and Kelton emphasizes the position of some additional activities, in particular input data analysis.

To the chapter


3.10 - Towards a Comprehensive Simulation Methodology?

Simulation must not be seen as a stand-alone endeavour.

Portfolio or programme models (knowledge assets in the left column) can be incorporated into the modeling efforts of projects and iterations in the different steps of a Comprehensive Simulation Methodology (CSM) (Figure 3.12) (adapted from Op den Kamp, 2004). In this way one can overcome some typical disadvantages and risks of simulation or extensive conceptual modeling:

  • Improved communication between the modeling analysts and the team during the project. This is achieved by the various milestones, presentations and documentation in each phase of the CSM Model (knowledge asset accumulation).
  • The CSM Model encourages the development of a modular simulation model that can partly be replicated for each decision variable. This will save a considerable amount of time because most time is spent in the development phase of the model. With the help of these pre-programmed modules, more time can be devoted to analyzing the problem and the effect of the decision variables on the performance indicators.
  • People without any statistical or mathematical knowledge can easily be involved in the decision making engagement when the CSM Model is applied. They can cooperate from the project definition onwards, execute the design study and can also give support during the implementation phase.
Figure 3.12 - Phases & Supporting Artifacts in a Comprehensive Simulation Methodology (CSM)
Figure 3.12 - Phases & Supporting Artifacts in a Comprehensive Simulation Methodology (CSM)
  • The CSM Model states clearly that the performance indicators of the decision making engagement must be in line with the stated objectives of the organization. During the project definition the performance indicators are derived from the objectives. These are a central issue during the whole study and are used to support the decision outcomes.
  • In each phase of the CSM Model there are various tools available which help to gain the confidence of the management. By applying these tools, management can understand and monitor the progress of the decision making engagement without the help of in-depth simulation knowledge.
  • One of the objectives of the CSM Model is to analyze various decision options and compare them using the performance indicators. The brainstorm session in the project definition phase identifies all the possible decision proposals. After a selection, the CSM Model guides the analyst towards investigating the effect of the more complex decision variables within a decision making engagement. This puts simulation into practice in the areas where it is really useful.

In the ideal situation, the CSM model must be surrounded also with data management tools, for instance to keep track of the input events, or of their probability distribution. The probability distribution of input events, or past input events could be used as input for the simulation experiments.

For the time being, the data and model reuse among object system and the modeling capability is often limited, or non-existing. In the context of enterprise operational processes, this is a problem of interoperability of (enterprise) software applications and data, and a very common hurdle to the effective deployment of simulation. Although the CSM offers solution directions towards resolving some of the interoperability issues, the current simulation tools and environments need to be further developed before the capability of simulating operational processes can be practically used on a large scale.

To the chapter


Part II - CPIM - A Collaborative Planning and Investment Methodology


Chapter 4 - An Asset-Aware Collaborative Planning and Investment Methodology (CPIM)

Chapter 5 - A Societal Architecture for the Techno Globe

Chapter 6 - A Societal Architecture Repository enabling CPIM Phases


To Part I - II - III - IV - V - VI-Annexes - VII-References


Chapter 4 - An asset-aware Collaborative Planning and Investment Methodology


4.1 - Scaling Communication and Decision-Making
4.2 - Reuse of Knowledge Assets in Communications
4.3 - Reuse of Knowledge Assets in a Decision Support Study
4.4 - Capabilities for CPIM
4.5 - Principles that are Realized by the CPIM Capabilities
4.6 - Including Investment Decision Making in CPIM
4.7 - Implications for CPIM of General Requirements and Constraints


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


4.1 - Scaling Communication and Decision-Making

To the chapter

Levels of Scope

The Collaborative Planning Methodology (CPM) defined in the Common Approach to the US Federal Enterprise Architecture offers a simple, repeatable process that consists of integrated, multi-disciplinary analysis and results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers.

Figure 4.1 - Collaborative Planning Methodology
Figure 4.1 - Collaborative Planning Methodology

The first release of the CPM includes the master steps and detailed guidance for planners to use throughout the planning process. Enterprise architecture is but one planning discipline included in this methodology. Over time the methods and approaches of other planning disciplines will be interwoven into this common methodology to provide a single, collaborative approach for organizations to use.

Both CPM and CPIM can serve as a full planning and implementation life cycle for use at all levels of scope described in the common approach:

Therefore we propose it as a pattern from which we derive methods that are customised for actors in

Target outcome: Consistent planning and decision making that leverage experiences and results of other agencies and levels of scope as a means to address priority needs in the most efficient way possible, following recommendations formed in collaboration with local beneficiaries, leaders, interested parties, planners, and implementers.

In its most successful form, enterprise architecture is used by organizations to enable consistent planning and decision making beyond the boundaries of a single initiative, agency or business.

The Societal Architecture needs a community of practice and collaborative method that support efforts to leverage experiences, services and capital provided by others in order to achieve more efficient government service delivery and private sector operations, and synergy.

CPM served as the main source of inspiration for the Collaborative Planning and Investment Methodology (CPIM).

CPIM adds these features to CPM:

  • Clarifying reuse of models (and data) in the content stratum, from portfolios, through programmes to projects and small scale initiatives;
  • Clarifying the link to principles;
  • Adding attention for investment;
  • Positioning of the steps (phases) with respect to the asset strata: content and knowledge, material, finance;
  • Splitting of investment in a substeps involving material and financial resources;

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.

Figure 4.2 - The Five point plan of decision making and the Collaborative Planning Methodology (CPIM)
Figure 4.2 - The Five point plan of decision making and the Collaborative Planning Methodology (CPIM)

Scaling decision making thus means that generalizations and specializations are performed for those steps, and in these an advanced use is made of Modeling tools.

To the section

Portfolio, Programme, Project and Iteration

Figure 4.3 positions several management capabilities and resources and gives an impression of the potential dependencies among the planning levels Strategy, Portfolio, Programme, Project and iteration.

In this book, we will focus on “model-based” dependencies among the resources that CPIM leverages:

  • the 2030 Agenda Strategy must provide resources upon which the various portfolios can build,
  • portfolio resources must support programme, project and iteration resources,
  • programme resources must support project and iteration resources, and
  • project resources must support iteration resources, and
  • that capability/resource pairs may rest upon one another in the collaborative planning methodology.
Figure 4.3 - Planning levels: Strategy, Portfolio, Programme, Project and Iteration
Figure 4.3 - Planning levels: Strategy, Portfolio, Programme, Project and Iteration

The nature of the dependencies will be explained in the sections introducing each of the steps:

But first lets take a look at key concepts of each of the “planning” levels as defined in the Open Project Management Methodology (PM²) series by the European Commission Centre of Excellence in Project Management (European Commission, 2021 and 2022), pdf versions of which are free from the website of the Publications Office of the European Union:

  • PM² Agile - Guide 3.0.1
  • PM² Project Management Methodology - Guide 3.0.1.
  • PM² Programme Management - Guide 1.0
  • PM² Portfolio Management 1.5

Note that these concepts cover only the phases CPIM01 - Identify and Validate to CPIM04 - Invest and Execute and that relatively little attention is given to the quantification of the investment, and its “recuperation” during the CPIM05 - Perform and Measure phase.

Concepts from the area of public-private partnerships may be useful for elaborating the financial aspects of the colaborative planning.

To the section

Portfolio Management

A partnership or organization usually has multiple strategic objectives to achieve, each requiring programmes or projects with different stakeholders, who bring benefits from using a specific approach. Therefore, synergies and efficiency can be obtained when programmes and projects having the same characteristics are managed together in one portfolio or in a structure of portfolios.

A portfolio is a collection of projects, programmes, sub-portfolios, and other work packages, grouped for better financial and other resources control to facilitate effective management in achieving strategic objectives. The projects or programmes in the portfolio, also known as the portfolio components, may not necessarily depend on or relate to each other. All portfolios together constitute the corporate or partnership portfolio that echo the wider governance/decision-making structures.

Figure 4.4 summarizes key concepts of portfolio management. If you are not (sufficiently) familiar with these concepts, we recommend to consult the PM² Portfolio Management Guide 1.5 (European Commission, 2021).

Figure 4.4 - Value streams and key concepts in portfolio management
Figure 4.4 - Value streams and key concepts in portfolio management

To the section

Programme Management

Figure 4.5 summarizes key concepts of programme management. If you are not (sufficiently) familiar with these concepts, we recommend to consult the PM² Programme Management Guide (European Commission, 2021).

Figure 4.5 - Value streams and key concepts in programme management
Figure 4.5 - Value streams and key concepts in programme management

To the section

Project Management

Figure 4.6 summarizes key concepts of project management. If you are not (sufficiently) familiar with these concepts, we recommend to consult the PM² Project Management Methodology Guide (European Commission, 2021).

Figure 4.6 - Value streams and key concepts in project management
Figure 4.6 - Value streams and key concepts in project management

To the section

Iterations in Continuous Improvement and Agile Management

A core philosophy of Agile is that of continuous improvement and learning. This is done through frequent reviews and retrospectives, which are described as rituals where teams learn from the experience and plan changes for the next cycle. Reviews are a great tool to collect feedback from the stakeholders and learn about the solution. Retrospectives are a great tool to collect feedback and learn about the process and the Agile Team itself. Both are key in delivering a successful project and solution as they will guide the overall improvement process.

Two situations:

1) There is no solution yet and an minimal viable product is a first deliverable of the project effort.

2) The current situation is viable, yet faces value gaps.

Building Start-ups involves many risks and timing. It is safer for start-ups to experiment on their idea by preparing early prototypes and test them with their potential clients as early and continuously as possible. They came up with the idea of an MVP since there was not much time to build something cheap and fast that would allow them to gain learning and lead the market.

Building an MVP doesn’t necessarily mean that a fully functional piece of coded software needs to be developed. The most important aspect is that the usage of the MVP can be measured and the data collected is used to learn and generate new ideas. This is what will keep the cycle going and consequently, make the solution grow towards the right solution. The Lean UX process (another cornerstone of PM²-Agile) goes hand in hand with the Lean start-up model by helping to generate the MVP with rapid prototyping and gain fast learning.

The Lean start-up model and Lean UX process have been implemented also by the public sector worldwide to reduce the uncertainty of costs and risks at later stages of product development, where many stakeholders and governmental budgets are involved.

The Minimum Viable Product (MVP) is the result of continuous validated learning that gives the green light for Incremental Development or even an indication of a non-continuity of an idea.

The Purpose of an MVP:

  • Be able to test a product hypothesis with minimal resources.
  • Accelerate learning.
  • Reduce wasted engineering hours.
  • Get the product to early customers as soon as possible to learn from its use.
  • Base for other products.

An MVP must include and focus on the following key elements:

  • Functionality: the set of features must deliver/demonstrate clear value to the user.
  • Accessibility: the MVP must comply with accessibility standards.
  • Reliability: the adequate evidence that confirms that the initial problem or goal is solved in a manner that it is coherent and relevant to move forward.
  • Design: the design of the MVP must be up to the highest industry standards.
  • Usability: the MVP must be easy to use and intuitive.
  • Value: the MVP brings organizational value and serves user needs.

Success criteria:

  • Comply with all key elements.
  • Define from the beginning key performance indicators (KPIs) and metrics.
  • Conduct frequent user research with users and validate with stakeholders. Try to keep up the research up to five users to avoid wasted time with over-analysis.

To the section - To the chapter


4.2 - Reuse of Knowledge Assets in Communication

At each planning level, communication with stakeholders is important.

In this section we will explore how communication products of initiatives with narrow scope build upon the communication products of those with a wider scope.

To the section - To the chapter


4.3 - Reuse of Knowledge Assets in Decision Support Studies

Asset awareness

Figure 4.7 distinguishes three fundamentally different types of assets that are involved in a collaborative planning:

  • Intellectual assets that serve semiotic flows,
  • Financial assets that enable the financial flows, for instance for investing and “pay for use” of “delivered services”
  • The planet and its biosphere that provide a context for material flows, such as ecosystem, infrastructure and commercial services (biotope, socio-tope and techno-tope)
Figure 4.7: Asset awareness in the Collaborative Planning Methodology (CPIM)
Figure 4.7: Asset awareness in the Collaborative Planning Methodology (CPIM)

Each kind of flow is home to specific drivers, hurdles, goals and outcomes. To fit them in the three stratum flows framework the CPIM04 - Invest and execute, and CPIM05 - Perform and measure have been divided into sub-value chains in order to clarify some cyclic dynamics as indicated by flow relations between the various value chains as they affect the three strata.

In the material flows domain, mankind has to cope with drivers such as pollution, erosion, and climate, and the UN has proposed Sustainable Development Goals.

To implement and deliver materially inclusive capabilities and services in the material flows domain, we must use intellectual and financial assets and will create financial liabilities.

As indicated in Figure 1.11, content - that is an important ingredient of semiotic flows - enjoys non-depletable use by reading, and easy reproduction, yet such use can be made exclusive by pay walls and copyright protections. Such protections reflect social order preferences regarding access to resources, yet these social-order preferences encourage multiple hurdles to the semiotic flows.

Four phases of the CPIM primarily involve semiotic flows. These are:

  • CPIM01 - Identify and validate
  • CPIM02 - Research and leverage
  • CPIM03 - Define and plan
  • CPIM05d - Measure (of performance)

When looking at current practices, one might conjecture that greed-induced over-emphasis on hurdles to semiotic flows harm CPIM04b execution and CPIM5a service delivery in collaborative planning and investment.

This e-book aims to clarify the situation and proposes new social-order preferences to reduce hurdles to semiotic flows, specifically for sustainable development initiatives. Reduced hurdles and improved capabilities in dealing with intellectual assets would then enable a talent explosion.

The criteria for deciding whether or not to use “wide scope models”, and the use of different kinds of reusable models (CIM and PSM) as pointed at in Figure 3.10, should be clarified. The reuse of portfolio, programme, or project models in the next planning level would be covered in the Left column “knowledge assets”, with each more foundational level providing assets to the levels building upon it.

To appreciate the benefits of the method, lets look into the impact of using this reuse approach for the general and difficult problem of determining several forms of “faithfullness” between systems and models (at different layers). In particular, we consider (Law and Kelton, 2000):

  • Validity, this is a relationship between the content model and the object system: a content model is valid if it can be used to make decisions about the system that are similar to those that would be made if it were feasible and cost-effective to experiment with the system itself. Validation is the process of determining whether a model is an accurate representation of the system for the particular objective of the study.
  • Verification, this is a relationship between a “computation independent model (conceptual model, model assumptions) and a platform specific model (or computer program): a Platform specific or executable model or computer program is verified with respect to a conceptual model (CIM layer).
  • Credibility, this is a quality of a model and its (simulation or application) results in the eye and mind of the management entity or “problem owner”: a model and its results have credibility if the manager or other key project personnel accept them as “correct”.

The credibility for a model is established a.o. by the management entity’s understanding and agreement with the model’s assumptions, and the management entity’s ownership of and involvement with the object system (of a project). For these factors it is important that the Identify and validate phase can start with expressed objectives for the target object system. The scoping of a decision problem in terms of computation independent models helps the analyst in gaining precision and avoiding risks when proceeding from the project definition to the creation of platform specific or executable models. Throughout the project the reuse of pertinent validated models, will accelerate the identification and validation and the research and leverage phases of a project (or programme): it can focus on the increments that are built (as specializations, aggregations and refinements) from the available elements (externalised knowledge assets).

Regarding the verification, the use of appropriate mapping and debugging tools can help this process.

Both credibility and validation do not only concern the system models but also the (simulation) experiments and their results.

To the chapter


4.4 - Capabilities for CPIM

The Societal Architecture General Capabilities matter for all members of the 2030 Agenda Partnership, across the public services they provide and consume, and across the initiatives to achieve the sustainable development goals. These society-wide capabilities have been derived from the General Principles of the Common Approach to the US Federal Enterprise Architecture. Each capability is introduced and where possible a link is added to an Actor Atlas page with related principles that stem from the development research.

In the socio-technical landscape where innovations involve value systems, dashboards, operational processes and supporting information systems of multiple stakeholders, the total number of requirements pertaining to the operations and systems is huge.

Where state-of-the art practices indicate a strong intra-enterprise utility of architectural frameworks, our work indicates important additional gains from the cross-level alignment of requirements captured as models at macro and meso levels and provided to the micro level and to the pico or household levels.

Figure 4.8 - Capabilities for CPIM
Figure 4.8 - Capabilities for CPIM

To the chapter

The Future Ready Capability

Societal Architecture helps all members in the partnership to be successful in completing the many missions that others and the members themselves depend on.

Mission requirements continually change, and resources are often limited.

Collaborative Planning and Investment is the key business and technology best practice that enables:

  • agencies to evolve their capabilities to effectively deliver needed services,
  • businesses and households to thrive in a changing world.

Achieving the Future Ready Principle at a global scale for all participants in the economy is not straightforward. In an increasingly complex world, with an increasing number of actors who can set rules, coping with change could become a major driver for costs to participants.

An example are regulatory changes. With the appearance of Sarbanes-Oxley (SOx) in 2004 many companies had been confronted with a compliance challenge, the costs of which were largely underestimated by the regulator. Suddenly it was articulated that requirements for enterprise systems do not only emerge in the value chain, but also in regulations prevailing in the market. Remembering the efforts enterprises had spent to cope with SOx, institutional designers may grow uncomfortable with the risk that enacting yet-another-rule will harm companies and scare investors, or that it will harm the competitiveness of the industry. On the other hand, the more recent financial crisis has demonstrated that also the absence of fit regulations exposes both industries and society to severe risks and crises.

Using the case of value added tax compliance in enterprise resource planning systems, the paper (Goossenaerts et al, 2009) illustrates how enterprise architecture and model driven engineering in a multi-level perspective would provide an efficient solution of compliance problems if enterprises could build upon shared domain models that reflect regulations, and evolve as the regulations change.

This principle, although it reflects a major issue in a dynamic society, has not been highlighted in the several principle excercises that I am aware of, such as:

To the section

The Investment Support Capability

Collaborative Planning and Investment enabled by Societal Architecture supports intra- and inter-actor investment decision-making through an “architect – invest – implement” sequence of activities.

Actors must ensure that investment decisions are based on architectural solutions that result in the achievement of strategic and/or tactical outcomes by employing technology and other resources in an effective manner.

In a global partnership, investment support is needed for various target groups, with missions competing for limited financial resources, for instance:

  • Productive investment support to private beneficiaries to increase economic performance/business competitiveness;
  • Investment support to private beneficiaries for investments required to meet minimum standards under specific measures, other than those which improve the economic performance of the holding;
  • Investments in public infrastructures which are complementary to private investments intended to improve economic performance/business competitiveness;
  • Non-productive investments to private beneficiaries for environmental or non-market purposes.

As only limited financial resources are available it is reasonable to pursue reducing costs in the planning steps (without harming quality).

Principles that are related to investments are the UN approved Principles for Responsible Investment.

Societal Architecture could play a role in these actions under “Principle 1: We will incorporate environmental, social, and corporate governance (ESG) issues into investment analysis and decision-making processes.”:

  • Address ESG issues in investment policy statements
  • Support development of ESG-related tools, metrics, and analyses
  • Assess the capabilities of internal investment managers to incorporate ESG issues
  • Assess the capabilities of external investment managers to incorporate ESG issues
  • Ask investment service providers (such as financial analysts, consultants, brokers, research firms, or rating companies) to integrate ESG factors into evolving research and analysis

Public Private Partnerships (PPP)(World Bank Group, 2014) and Unsolicited Proposals (USPs) (PPIAF, 2014) play an increasingly important role in the financing of infrastructure projects. There is a need for developing countries to grow their capacity in dealing with both PPP or USP capacity. The latter report, further referred to as the USP report, identifies ten key factors that are hard to achieve in developing countries, yet are underpinning the objectives of unsolicited proposals:

  • To identify, prepare and implement economically valuable projects
  • To create value for money (better deal than alternative)

Five of these factors are on the macro-level (context), and five on the micro-level (project implementation). The table below lists only the factors and challenges at the macro level.

Factor Challenge
Private-sector interest Market appetite is directly dependent on the ability to make sufficient return on project investment
Private-sector capacity Many USPs are opportunistic and of poor quality
Public-sector capacity The lack of human and/or financial capacity of the responsible agency to identify, prioritize, prepare and procure projects is a common challenge and also a motivation for USPs
Public-sector coordination Both inter- and intra-public-sector coordination and communication issues often hinder implementation of USPs
Clarity on procedures USP frameworks should increase the clarity of procedures, yet in some instances, USP procedures and their enforcement remain unclear

The potential of Societal Architecture is especially in addressing the public sector challenges, as explained in the table below for three factors.

Factor Problems Societal Architecture based enablers for capacity, coordination and clarity on procedures
Public-sector capacity The paradox: lack of PPP capacity motivates the interest in USPs, yet their successful implementation requires a high level of expertise in project development and contract procurement. In many countries the public sector is slow in acquiring the required capacity, primarily on the basis of own experience, or by engaging/hiring consultants. Facilitate accelerated learning via improved access to reference and case materials, for instance by publishing a “standard PPP guideline as part of the Societal Architecture.
Public-sector coordination Under a decentralized model of realizing (development and implementation) infrastructure PPPs, management of USPs is often hindered by coordination and communication issues. A dispersed point of entry for USPs makes it harder to track USPs received by the government, and that makes the management of the USPs less transparent and more prone to abuse. In addition to the recommendations in the USP report, the legislature (parliament) could demand from the executive, ministries and agencies to document their idea, initiative and project pipeline via a shared wiki-based solution, such that a Mutually Exclusive and Collectively Exhaustive view of the pipeline(s) is achieved.
Clarity on procedures Unclear or poorly applied (enforced) procedures can lead to high transaction costs, loss of market interest, and perception issues with the general public. The USP report recommends more attention to the socializing and communicating of USP frameworks. Online, and easy to navigate publishing of procedures, with explanations how and why they deviate from a standard can achieve improved socializing and communication.

Further reading: PPP Knowledge Lab.

To the section

The Shared Services Capability

Actors should select reusable and shareable services and products to obtain mission or support functionality.

Increasingly, the United Nations and the national governments are becoming the coordinators and consumers as opposed to being producers of products and services.

Standardization on common functions and customers will help all actors in constituencies to implement change in a timely manner.

The shared service principle has been recognized as part of two Principles for Digital Development:

  • The 6th Principle: Use open standards, open data, open source and open innovation
  • The 7th Principle: Reuse and improve

The 2nd step of the Collaborative Planning and Investment Methodology, Research and Leverage, pays explicit attention to achieving this principle. By pursueing this step in a Global Partnership enormous gains in the planning steps are achievable.

One key limitation on the application of this principle are the intellectual property rights that entitle right holders to put rather arbitrary prices for the use of their intellectual property.

Another consideration is that there is insufficient attention for the provide of content commons as an Infrastructure Resource. Frischmann (2005) defines an infrastructure resource as a resource that satisfies the following demand-side criteria:

  • the resource may be consumed nonrivalrously;
  • demand for the resource is driven primarily by downstream productive activity that requires the resource as an input; and
  • the resource may be used as an input into a wide range of goods and services, including private goods, public goods, and nonmarket goods.

It is clear that through the Societal Architecture, we can dramatically improve the provision of planning content as an infrastructure resource. In many use situations the commons may found a sufficient solution given the resource constraints of the target beneficiaries. Currently such solutions may not be considered as they are not being conceived as feasible alternatives for commercially offered solutions that are often more expensive as they involve intellectual property.

To the section

The Interoperability Standards Capability

Collaborative Planning and Investment enabled by Societal Architecture promotes intra- and inter-actor standards for aligning strategic direction with business activities and technology enablement.

Actors should ensure that selected solutions conform to international or nation-wide standards whenever possible.

See also: Open Standards Principles and the earlier cited 6th Principle for Digital Development: Use open standards, open data, open source and open innovation.

To the section

The Information Access Capability

Collaborative Planning and Investment enabled by Societal Architecture supports governance transparency and service delivery through solutions that promote citizen, business, agency, and other stakeholder access to public information and data, balanced by needs for Government security and individual privacy.

Collaborative Planning and Investment solutions enabled by Societal Architecture should support a diversity of public and private access methods for Government public information, including multiple access points, the separation of transactional from analytical data, and data warehousing architecture.

Accessibility involves the ease with which users obtain information.

Information access and display must be sufficiently adaptable to a wide range of users and access methods, including formats accessible to those with sensory disabilities.

Figure 4.9 - Information Access driving digital transformation capacities
Figure 4.9 - Information Access driving digital transformation capacities

Data standardization, including a common vocabulary and data definitions are critical.

See also:

To the section

The Security and Privacy Capability

Collaborative Planning and Investment enabled by Societal Architecture helps to secure government information against unauthorized access.

Governments must be aware of security breaches and data compromise and the impact of these events. Appropriate security monitoring and planning, including an analysis of risks and contingencies and the implementation of appropriate contingency plans, must be completed to prevent unauthorized access to government information.

Additionally, Collaborative Planning helps all actors apply the principles of the prevailing privacy acts and incorporate them into architecture designs.

The Technology Adoption Capability

Collaborative Planning and Investment enabled by Societal Architecture helps all actors to select and implement proven market technologies. Systems should be decoupled to allow maximum flexibility. Incorporating new or proven technologies in a timely manner will help actors to cope with change.

To the section

Principles that are Realized by the CPIM Capabilities

The next figure uses of the ArchiMate capability model elements to present the rio and digital principles that are realized by the capabilities.

Figure 4.10 - Principles realized by the CPIM Capabilities
Figure 4.10 - Principles realized by the CPIM Capabilities

To the chapter


4.6 - Including Investment Decision Making in CPIM

In the context of the 2030 Agenda for Sustainable Development, also access to finance, and impact on material resources - the environment - are critical issues.

Finance for Development is a topic that is addressed in the Addis Ababa Action Agenda, and the environmental and social impact are addressed via the sustainable development goals and their targets.

Therefor, to CPIM we added collaborations for capital investments and operational expenses and income, to create a Collaborative Planning and Investment Methodology (CPIM).

To the chapter


4.7 - Implications for CPIM of General Requirements and Constraints

The figure below explains the importance of the General Principles for the CPIM.

Cognitive, material and financial means are accessed in the collaborations, and for those means we have included some overall requirements - these are negotiable - and constraints.

Figure 4.11 - Requirements and constraints affecting resources and capabilties for CPIM
Figure 4.11 - Requirements and constraints affecting resources and capabilties for CPIM

To the chapter


Chapter 5 - The Societal Architecture for the Techno Globe


5.1 - Societal Architecture: an Overview
5.2 - Transformation at Multiple Levels
5.3 - Transformation at the Pico level
5.4 - Transformation at the Micro level
5.5 - Transformation at the Meso level
5.6 - Transformation at the Macro level
5.7 - Why Societal Architecture?


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


5.1 - Societal Architecture: an Overview

The societal architecture is a reference architecture that recognizes multiple levels of scope and socio-technology in society and its transformation (SlideShare).

Everyone’s path is a composition of journey segments:

  • Segments as a curious student, in sports, as a loving mother or father are part of pico-journeys, which are displayed as the highest level in the figure to convey the centrality of the human beings in the social order and as citizen.
  • Segments while one is working in a business or organization. Here it is convenient to further distinguish the organizations in accordance with their mission:
    • private sector, business for profit, livelihood, non-profit, for sports, etc.: the micro level;
    • confederations protecting and representing members with similar interests with respect to the executive and legislative organs in a country, or local government unit: the meso level;
    • executive and legislative organs which set and enforce general norms for society as a whole, at levels of (geographic) scope: local over national to international

Given the common use of customer journey maps and in order to support Collaborative Planning (and Investment) at multiple levels in society we introduce terms journey map, macro journey, meso journey, micro journey and pico journey.

Figure 5.1 - Positioning pico, micro, meso and macro actors in a multi-level architecture
Figure 5.1 - Positioning pico, micro, meso and macro actors in a multi-level architecture

To the chapter


5.2 - Transformation at Multiple levels

The following sections generically characterizes actors at different levels in a modern society.

Development agendas such as Addis Ababa Action Agenda involve actors at multiple levels in society. A regulative cycle or collective regulative bundle describes one possible way to deal with (required) change by key actors and in key systems or constellations. The socio-technical level of the actors is depicted in the figure “Socio-technical Transition Pathways”.

The level (macro, meso, micro, or pico) of a principal will determine attributes of its interests (e.g., the resources for survival and growth that it must consume, produce or protect). A Principal is an entity that can own a claim to an object (such as to a piece of land, the right to harvest certain trees in a forest, a liability, the property rights of traditional or new knowledge) and be a party in a contract or agreement.

Also behavioural constraints are determined by the level. For instance:

  • within their jurisdictions, macro and meso-level actors should refrain from giving preferential treatment to any of their micro or pico-level “subjects”;
  • companies compete at the micro-level in their sector of industry;
  • persons compete in sports contests (in sports disciplines (meso-level)) or for job promotion (in the micro-context of an organization);
  • the institutional instruments that governments can use to promote or protect domestic industries, or attract foreign investors, are constrained by global trade agreements.

In what follows, for each socio-technical level and for the multi-level, we will address:

Extent and principals

Improved livelihood-centrism in knowledge conversions builds upon attitude changes and decisions by actors responsible at multiple levels of socio-technology and scope: macro, meso, micro and pico.

The interaction in a value-constellation of principals and entities of all four levels: pico, micro, meso and macro.

Level what used to be with societal architecture guidelines
Pico (person) little awareness of where the self fits in the whole be knowledgeable of hashtags for important aspects of life and adopt Household journeys for the #SDGs
Micro (organization) little awareness of how business success builds upon meso-level achievements distinguish between the cooperative and competitive aspects of business success and give both a balanced attention in Business competing & engaging in partner journeys - #b4sdgs
Meso (federation) in developing countries: little attention for this level give ‘‘fair’’ federations the attention and resources they deserve for Sector journeys - #isicWW & #cofogWW
Macro (society) little participation by stakeholders due to communicative hurdles overcome communicative hurdles by using the internet and social media also in a smart and disciplined way for Sustainable landscape, #MacroJourneys and #WWlgu

Domains & systems

What is the domain and what are typical interactions and systems at the different levels?

The ecosystem, including the natural, social and technical environment and the socio-cultural arrangements.

Improved livelihood-centrism in knowledge conversions builds upon these changes in communications:

Level what used to be with Wikiworx guidelines
Pico (person) post the casual, post much, read little, focus on the own reputation ‘‘no matters what’’ '’research before writing: Before writing and posting to a wide public, check recent contributions in your area of interest; cite your sources; and aim for genuine and reliable contributions, #tag to reach your target readers; engage in discussions with your readers
Micro (organization) marketing, marketing, marketing reduce the obtrusiveness of your marketing communications, e.g. by ensuring it appears alongside suitably tagged content or pages with closely related content. See the role ‘‘smart online advertiser’’ at Fair Glocal Partnership.
Meso (federation) Federations have been created ad hoc and coexist in a partly competitive mode; very wasteful… guideline: evolve towards “one federation/space per ISIC or CPC class”
Macro (society) Each agency has its own website and communications channels, without consideration of how the individual in need will find up-to-date information that is relevant to his or her situation now Explain the use of the ISIC/COFOG/CPC classifications alongside wiki functionality in finding and placing information; and apply it for all government partnership communications, as well as for supporting governmental initiatives.

Design

What are typical design or development methods? How is change initiated and decided?

Poverty reduction strategies.

See for instance: the Poverty-Wellbeing Shareweb.

Cases

Which cases illustrate change factors? What representative cases are there in the literature?

Several cases are included in Geels & Schot (2007).

Problems

Which approaches are used to identify problem messes?

  • (Economic) Growth Diagnostics
  • Benchmarking per level in combination with cross-level causal-chain analysis as illustrated in Goossenaerts (2007).

Outcomes / values

What outcomes are valued, consumed and produced? How are they measured?

Sustainable and equitable socio-economic growth by capable people in rural livelihoods. Chambers and Conway (1991) report on their search for ways in which capability, equity and sustainability can be combined so that in practice conflict is low and mutual support is high.

To the chapter


5.3 - Transformation at level Pico

Extent and principals

Humans are self-conscious, anticipatory, imaginative, creative beings. This means that they are not restricted to act in narrowly confined ways according to fixed rules of behaviour. They can invent new solutions—or they may not even see the obvious ones (Bossel, 1999, page 5.) Where people fulfil roles in economic activities, as public servants or as participants in institutions, specific skills, knowledge and attitudes are expected from them.

Persons as members of households and in the role of teachers, workers, engineers, managers, librarians, farmers, parents, public servants, politicians. For more details, see: pico-classification.

The target actors at the Pico level are all persons that might use and produce externalized knowledge during their life, education and work. The community of person-actors is very heterogeneous, with age, gender, resource endowment, education, health, kinship and family-relationships, employment and livelihood as some of the typical determinants. Yet, the Universal Declaration of Human Rights and the UN Convention on the Rights of the Child confirms the same rights for all human beings, young or aged, rich or poor.

The Actor Atlas lists and describes a range of pico-level actors (and roles).

Domains & systems

Typical interactions take place in the livelihood, the learning and/or work context of the person in which various systems are used.

In addition to the resource endowment, attitude, skills and knowledge matter.

Learning

In the Preface of atria.us, four broad competence areas are briefly explained: Communications & Teamwork, Knowledge Translation, Listening Attitude and Skills for Civic Participation.

These competences must be combined with specific knowledge, experience and physical capacities of people as they fulfil the roles of pico actors in the classes of economic activity listed in the International Standard Industrial Classification of All Economic Activities (ISIC).

Figure 5.2 - Lifeworld and enablers of pico journeys
Figure 5.2 - Lifeworld and enablers of pico journeys

Kolb; learning paths.

The article How companies learn your habits by Charles Duhigg (February 16, 2012, New York Times Magazine) explains and illustrates the importance of cue-routine-reward loops for people, and it explains how life-events, such as giving birth, make customers vulnerable to intervention by marketers.

The Max-Neef Model of Human-Scale Development: for a brief summary, see Max-Neef on Human Needs and Human-Scale Development(Rainforestinfo.org), or the full version as part of Human Scale Development - Conception, Application and Further Reflections (Manfred A. Max-Neef, with contributions from Antonio Elizalde, Martin Hopenhayn).

Maslow’s hierarchy of needs gives a holistic perspective on a person’s needs. These needs must be taken into consideration in change, education and training initiatives (Simons, Irwin and Drinnien, 1987).

  • Physiological Needs consist of needs for oxygen, food, water, and a relatively constant body temperature. They are the strongest needs because if a person were deprived of all needs, these would come first in the person’s search for satisfaction.
  • Safety Needs. When all physiological needs are satisfied and are no longer controlling thoughts and behaviours, the needs for security can become active. Adults have little awareness of their security needs except in times of emergency or periods of disorganization in the social structure (such as widespread rioting). Children often display the signs of insecurity and the need to be safe.
  • Needs of Love, Affection and Belongingness can emerge next. Maslow states that people seek to overcome feelings of loneliness and alienation. This involves both giving and receiving love, affection and the sense of belonging.
  • Needs for Esteem can become dominant next. These involve needs for both self-esteem and for the esteem a person gets from others. When these needs are satisfied, the person feels self-confident and valuable as a person in the world. When these needs are frustrated, the person feels inferior, weak, helpless and worthless.
  • Needs for Self-Actualization are activated if and only if all of the foregoing needs are satisfied. Maslow describes self-actualization as a person’s need to be and do that which the person was “born to do.” “A musician must make music, an artist must paint, and a poet must write.” These needs make themselves felt in signs of restlessness that cannot be attributed to the non-satisfaction of the foregoing needs

For a person in a high-tech facility, Yamada (2002) explains the issues.

The Person’s Context

The Sustainable Livelihoods Framework (Chambers and Conway, 1991) offers a comprehensive view of the assets and capacities a person needs to escape poverty on a sustainable basis, and of the interactions between the vulnerability context and the poverty of persons and households. Any person needs a critical mass of assets to cope with stresses and shocks, and to maintain and enhance capabilities.

For the person in a high-tech facility, Yamada (2002) explains the issues.

Several proposed education sector initiatives to help overcoming failures in meeting fundamental human rights are listed at (possible) education Initiatives.

Cases

The literature on psychology and pedagogy lists many cases and illustrates change factors and their drivers.

Problems

Which approaches are used to articulate problems?

Outcomes / values

What outcomes are valued and produced? How are they measured?

In methods of sustainable development it must be ascertained that even smallholders, poor and disadvantaged persons can interactively influence the joint generation of options, joint decision making and joint actions. This is inclusion.

The use of the mother tongue in education, and the availability of educational content are important enabling conditions for smallholders’ participation in socio-economic development. They are even fundamental human rights, as stated in Article 17 of the UN Convention on the Rights of the Child. Yet in many languages the offering of educational and other content is very limited, as can be seen for a range of languages.

Care of the self and the family. Personal health and wealth.

To the chapter


5.4 - Transformation at level Micro

Extent and principals

Firms and other organizations and the plants, land and service facilities they operate. More details at micro journey.

The Actor Atlas has a list of micro-level actors.

Figure 5.3 - Micro journeys
Figure 5.3 - Micro journeys

Domains & systems

Micro level entities exist in all industries and for all functions of government:

Design

What are typical design or development methods? How is change initiated and decided?

Business and organization development methods, which may or may not be influenced by the UN Global Compact Strategy 2021-2023.

Cases

Which cases illustrate change factors? What representative cases are there in the literature?

Of interest for a specific industry are the Communications on Progress (COP) in the international Global Compact database.

To the chapter


5.5 - Transformation at level Meso

Extent and principals

Sector, such as an industry or agro sector, a scientific or applied discipline, etc.

For more details see the Meso Classification, where industry or trade organizations may exist for each industry and each function of government.

Standards organizations; sector, engineering and science associations and comparable entities; specialized intergovernmental organizations such as FAO, WHO, ITU, etc.

Within a geographic territory, also a cooperative adhering to co-operative principles is considered a meso-level actor for its micro-level members.

The Actor Atlas has a list of Meso-level actors.

Figure 5.4 - Meso journeys
Figure 5.4 - Meso journeys

Domains & systems

Typical interactions focus at sector-governance, standard-setting and other sector-wide interactions in an industry or discipline, or among members in a community of practice.

Design

What are typical design or development methods? How is change initiated and decided, and how do innovations diffuse?

  • Methods of scientific research;
  • engineering design;
  • standards development;
  • sectoral Institutional Analysis and Design (Hess & Ostrom, 2007);
  • diffusion of innovations (Rogers, 1962);
  • the multi-level perspective on socio-technical transitions (Schot et al, 1994).

Cases

Some representative cases in the literature:

  • Hygienic transition in Dutch cities (Geels and Schot, 2007)
  • Photo Voltaic cells (Nagamatsu et al, 2006)
  • Intellectual Property Rights and Standardization in the case of GSM (Bekkers, et al, 2002)
  • Innovation-regulation interactions in medicine development (Mittra and Tait, 2012)

To the chapter


5.6 - Transformation at level Macro

Extent and principals

Landscape, with a local to global horizon.

Intergovernmental agencies, regional, national and local authorities.

Illustrations and further explanation at macro classification.

Figure 5.5 - Macro journeys
Figure 5.5 - Macro journeys
Order or stratum within the mandate (link to Ens wiki) Macro actors
Natural order Ethnic group, CGIAR, IPCC , …
Social order United Nations , Member State of the UN , Executive of a country , Legislature , Judiciary , Parliament , local government, …
Social order: Financial assets and liabilities Financial Stability Board (FSB), IMF, …
Social order: Intellectual assets (content) UNESCO , Internet Governance Forum, National Knowledge Commission, WIPO Standing Committee on Copyright and Related Rights, United Nations Statistics Division,…

Domains & systems

The domain consists of the socio-economic interactions in a territory. Those socio-economic interactions can be stratified into several orders, as done in the table (Principals) to clarify the existence of several macro-level actors and roles.

Design

What are typical design or development methods? How is change initiated and decided?

  • Regulatory Reform: Jacobs (2007)
  • Constitutive* Institutional Analysis and Design : (Hess and Ostrom,2007).

Cases

Which cases illustrate change factors? What representative cases are there in the literature?

Current:

Past:

  • Parliament in England: North (1990, pp 112-115) describes the creation of Parliament as an institutional response to the need of centralized fuedal rulers (the Tudors in England) to acquire additional revenue to survive in the face of the rising costs of warfare. Besides providing the beginning of representative government, the Parliament contributed to the reduction of rent-seeking behavior by financially hard-pressed Stuart monarchs, also it betokened increased security of property rights, and a more effective, impartial judicial system.
  • Limited liability by Law in New York State (Shiller, 2003): The limited liability laws that first appeared in New England in 1811 fostered public acceptance of corporate stocks. Though these laws diminished the freedom of making contracts, they turned out to be a good thing. With unlimited liability investors tended to overestimate the miniscule probability of loss beyond initial investment. The limited liability experiment dramatically increased the supply of capital for corporations.
  • TRIPS: (WTO, 1995)
  • Small-scale societies : For findings related to the link between inequality and institutions that regulate the inheritability of assets, see Acemoglu and James Robinson (2009) and Mulder et al (2009).

Problems

Which approaches are used to identify problem messes?

Worldometers and Knoema provide a number of statistics that articulate problems in the areas of environment, health, food, water, energy.

Historical comparison (North, 1990), comparative economics (Djankov, S. et al, 2003).

Country benchmarking: economy rankings support a more focussed analysis of causal chains and means to overcome macro-level problems, for instance Business Enabling Environment (BEE) by the World Bank.

To the chapter


5.7 - Why Societal Architecture?

North, Wallis and Weingast (2009) explain the difference between natural states and modern societies. Modern societies create open access to economic and political organizations, and by doing so they foster political and economic competition, and development.

In the modern society, the balance between open access resources and private property is a subtle one. For knowledge resources, this balance seems to be least understood. Also claims on land, sea and its use are a contentious area.

Vagueness regarding the allocation of resources, be it land, knowledge or material, induces individual risk considerations that hinder development.

By using a multi-level classification of the actors in a “landscape” in which we distinguish biotope, sociotope and technotope we can articulate and vary the rules of interaction and the claims on resources.

By visually representing the claims that exist on contested resources various actors can be allocated better understood and delineated claims on resources, which will be inputs to the construction of sustainable and equitable futures. This construction of a sustainable future must proceed at each of the four socio-technical levels where stakeholders develop or acquire capabilities and interact with resources as mapped or encountered in their journeys.

Both the classification and the visual representations are indispensable instruments in re-architecting the socio-technical fabric of the techno-globe, to enable more inclusive, equitable and sustainable development and clarify what it means to be a member of a global partnership for the #2030Agenda for Sustainable Development - #SDGs.

In the next chapter, we describe each CPIM phase in detail and propose modalities for performing it, taking into consideration the 2030 Agenda for Sustainable Development, the Addis Ababa Action Agenda and digital public goods.

To the chapter


Chapter 6 - A Societal Architecture Repository enabling CPIM Phases


6.1 - #CPIM01 - Identify and Validate
6.2 - #CPIM02 - Research and Leverage
6.3 - #CPIM03 - Define and Plan
6.4 - #CPIM04 - Invest and Execute
6.5 - #CPIM05 - Perform and Measure


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


6.1 - #CPIM01 - Identify and Validate

The purpose of this step is to identify and assess what needs to be achieved in a portfolio, programme, project or iteration, understand the major drivers for change, and then define, validate, and prioritize the operational realities of the mission and goals with leadership, stakeholders, and operational staff.

During this step, the leadership, stakeholder, and customer needs and the operational requirements are validated so that ultimately, all interested parties are working towards the same, well understood, validated outcome.

Initial performance metrics are created to begin focusing the measurement of success to be consistent across stakeholder groups. In this step, “leadership” can range in levels of scope from an executive leader over an international challenge to a functional leader who has identified steady state improvements that may include services, systems, or infrastructure. An additional purpose of this step is to identify and engage appropriate governance.

The key outcomes are:

(1) identified and validated needs for a portfolio, programme, project or iteration,

(2) an overarching set of performance metrics, and

(3) a determination of who (governance) will ultimately oversee and approve recommended changes to meet those needs.

At the various scopes, focus may be either:

To the chapter

Portfolio management concepts for CPIM01 - Identify and validate

A decision making engagement may be necessary to support a change or re-design decision for an operational process or work system. In that case the study is undertaken in the reflective activities as part of the adaptive cycle for the work system.

The study is divided into phases in accordance with the required competences and stakeholder involvement.

Figure 6.1 - Portfolio management concepts related to CPIM01 Identify & Validate
Figure 6.1 - Portfolio management concepts related to CPIM01 Identify & Validate

To CPIM01

Programme management concepts for CPIM01 - Identify and validate

Figure 6.2 shows the programme initiating phase concepts.

Figure 6.2 - Programme management concepts related to CPIM01 Identify & Validate
Figure 6.2 - Programme management concepts related to CPIM01 Identify & Validate

To CPIM01

Project management concepts for CPIM01 - Identify and validate

Figure 6.3 shows the project initiating phase concepts.

Figure 6.3 - Project management concepts related to CPIM01 Identify & Validate
Figure 6.3 - Project management concepts related to CPIM01 Identify & Validate

The planning activities that the design and analysis entity performs when it receives a problem statement from the management activity.

Synergies in portfolio, programme and project management initiating phases

Figures 6.4 and 6.3 show how projects and programmes can become components of a portfolio, and benefit from the portfolios resources.

Figure 6.4 - Projects and Programmes as portfolio components
Figure 6.4 - Projects and Programmes as portfolio components

When exploring options for reuse from portfolio to project, the identification of stakeholders and their needs is a promising area (Figure 6.3).

A Stakeholder Matrix is defined both for a portfolio and for a programme. It is where the critical stakeholders are identified and analysed and forms the basis for stakeholder management and communication activities to assure that stakeholders expectations are anticipated, managed appropriately and answered.

Guidelines:

  • Identify the portfolio or programme key stakeholders, analyse their expectations, attitude, level of interest and influence;
  • Devise appropriate communication and management strategies to achieve stakeholder involvement and contribution;
  • Monitor stakeholders’ reactions and re-strategise and manage accordingly;
  • A one-off exercise is not enough; repeat these steps as necessary;
  • As a stakeholder matrix can contain sensitive information, the portfolio or programme manager may ensure that not all information is publicly available, or available to the entire team, and all other stakeholders.

Content:

  • Overview of the portfolio stakeholders: name, organizational position, portfolio role
  • Influence / impact diagram
  • Per stakeholder:
    • Contact details
    • Influence in the organization and potential impact on the portfolio
    • Interests and expectations
    • Concerns

Where a portfolio has been defined for a public or sector strategy, with a global or national scope, projects or programmes involving stakeholders at national or local level, with related needs are likely to have partially overlapping stakeholder matrixes. On the other hand stakeholder matrices may contain sensitive information specific to an initiative.

If such commonalities are identified or discovered early, portfolio content can be leveraged in the programme or project content, and programme content can be leveraged in project content.

One avenue for leveraging of portfolio content is for projects and programmes with a “lower” level of scope as components of portfolios with a “higher” level of scope. An example is the 2030 Agenda which can be considered a planet-wide portfolio, with component portfolios per country, sector, and programmes and projects at lower levels of scopes such as municipalities, sector organizations per country, companies, schools and plenty of other organizations, and even households.

Communication plan

Figure 6.5 shows the societal context for portfolios, programmes and projects that involve the public sector. This context and the principles it underscores must be taken into consideration when following the guidelines below. This context also justifies attention to #tagcoding and #xy2wiki: provide and reuse pertinent and locally relevant content in the language of the interested parties.

Figure 6.5 - Project, Programme and Portfolio communication plans in context
Figure 6.5 - Project, Programme and Portfolio communication plans in context

Figure 6.6 shows the #tagcoding and #xy2wiki scope. #tagcoding and #xy2wiki are proposed to be part of any global, national and local Portfolio Handbook. #tagcoding in ubiquitous or national social platforms provides a low cost and easy way of meeting the digital capability principles included in Figure 6.5.

Figure 6.6 - #tagcoding and xy2wiki scope
Figure 6.6 - #tagcoding and xy2wiki scope

When the generic communication guidelines in the Portfolio Handbook are not sufficient, a specific Portfolio, Programme, or Project Communication Plan (European Commission, 2021 and 2022) can be created. One part of those communication plans is the selection of #tagcoding hashtags for the material dimensions that will be affected by the initiative. A #tagcoding handbook (Goossenaerts, 2022) can be helpful in such a task.

The Portfolio Communication Plan defines and documents the content, format, frequency, audience and expected results. It also describes the communication strategy for each stakeholder, based on their interests, expectations, and influences.

Guidelines:

  • Determine for each identified portfolio stakeholder group or individual what information needs to be communicated: this information may be related to the stakeholder activities (as classified and coded in the ISIC classification), or to specific functions of government (as classified and coded in the COFOG classification), or to products or services (as classified and coded in the CPC classification) ;
  • Define all artefacts to collect, analyse and distribute portfolio information and manage stakeholders’ expectations: these artefacts depend on the used communication channels, there are a few rules of thumb (for an open communications plan):
    • do not depend on free platforms to store the content that is being used: it is better to store in a reliable free-access repository where each content chunk can be retrieved via it’s own url, without pay-walls and without the need to register for the user;
    • use existing classifications to ensure that content can always be retrieved, or at least for a defined and sufficient period of time;
    • make use of several social media and platforms to push messages to engaged stakeholders;
    • tag messages with suitable #tagcoding hashtags, so that they can be retrieved on-demand, when interested parties need them;
  • Determine the frequency of the communication items: frequency matters when adopting an information push approach; with #tagcoding, stakeholders have the option to retrieve the tagged information when they need it (pull approach)
  • Decide on the format and media of the communication (e.g., reports, presentations, meetings, emails, calls) adapted to the intended audience;
  • Determine who will be responsible for each communication item and identify the expected result: demand from programmes and projects that they apply #tagcoding as recommended and applied in the portfolio.

Content:

  • Communication objectives: avoidance of information overload for all stakeholders, on-demand availability for a sufficiently long period of time;
  • Audience to be addressed: determine suitable #tagcoding hashtags for each audience, and communicate these as part of each message, during meetings with the interested parties, and in deliverables
  • Communication channels and media to be used: in the case of social media or platform use, and where multiple stakeholders and multiple results are intended, #tagcoding could be used to indicate the intended audience for the communications, of the portfolio and of its component programmes and projects.
  • Communication strategy per stakeholder: when using #tagcoding, less effort (and costs) can go towards reaching stakeholders, and more effort can be dedicated to tailoring the message to the skill levels of the audiences; also the authors of each message can use hashtag search to retrieve earlier messages with related content that had been shared before, and to ensure consistent content of the new message.

The Programme Communication Plan defines and documents the communication items content, format, frequency, the audience and expected results. It also defines the communication strategy for stakeholders, typically a subset of the portfolio stakeholders, based on their interests, expectations and influences.

If a Programme Communication Plan is used, ensure that there is no duplication of communication activities and no (unexplained) inconsistencies across the communication activities used by the projects and programmes of the portfolio (family) to which the programme belongs.

Guidelines:

  • Determine what information needs to be communicated and the purpose of this information for each identified stakeholder group or individual.
  • Align the communication needs of the programme with those of the portfolio and its other programmes and projects.
  • Using the portfolio communications plan, make a selection of the artefacts to collect, analyse and distribute information and manage stakeholders’ expectations.
  • Align the frequency and timing, the format and media of the communication items with those of the portfolio, and of other programmes and projects.
  • Establish who will be responsible for each communication item and describe the expected result.
  • Share the plan with the key portfolio stakeholders, and with past and future programmes and projects of the portfolio.
  • Revisit the plan on a regular basis, either to incorporate new stakeholders or to acknowledge the fluctuating attitude of existing stakeholders.

The (Project) Communications (Management) Plan helps to ensure that all project stakeholders have the information they need to perform their roles throughout the project. Planning and executing project communication activities is essential for project success.

The Plan defines and documents communication activities, their goals, content, format, frequency and audience. It also defines how to communicate project status and the assignment of activities to the various stakeholders and includes a communication strategy for each key stakeholder, based on their interests, expectations and influence in the project.

The Project Manager (PM) Prepares the Project Communication Plan, and the Business Manager (BM) provides input and assists in its creation.

Guidelines:

  • Review the guidelines set out in the Communications Management Plan template to get a better understanding of how to tailor and customise the Communication Management Plan.
  • Ensure that there is no duplication of communication activities described in other management plans such as the Quality Management Plan, the Risk Management Plan, etc.
  • If certain processes are already described in the Project Handbook (e.g. the escalation process), reference them to avoid duplication and simply document any changes.
  • Identify project stakeholder groups based on the Project Stakeholder Matrix.
  • When determining the strategy for each communication activity, consider the interests and influence of both internal and external organizations to the project, and the communication activities planned by portfolio and programme.
  • For each target group, determine what information needs to be communicated, and the purpose of the communication.
  • Define all artefacts (e.g. Project Reports) and other means to collect, analyse and distribute project information and manage stakeholders’ expectations.
  • Determine the frequency of the communication activities, their format and the media to be used for the communications (e.g. reports, presentations, meetings, emails, calls).
  • Determine who will be responsible for each communication activity and describe the expected results.
  • Ensure that the communication management plan is communicated to the project stakeholders.

To CPIM01

Initiation request

In contrast with programmes and projects, in the PM² Portfolio management guide there is no “portfolio initiation request”. A portfolio takes off with a “Management Framework Definition” in which first the portfolio structure, governance and processes are defined.

Programme Initiation Request

The Programme Initiation Request is the programme’s starting point and formalises its initiation. By creating a Programme Initiation Request, the programme initiator ensures that the current context/situation (i.e. problem, need or opportunity) and the programme’s objectives are formally captured and can be used as a basis for further exploration and elaboration.

This artefact is significantly different from a Project Initiation Request because of the emphasis towards the management of benefits and organizational change. Once high-level benefits are identified and described here, they may serve as input for the Programme Business Case.

Guidelines

  • The Appropriate Governance Body (AGB) usually nominates a person who is accountable to create the Programme Initiation Request. This person might later become the Programme Owner (PgO).
  • Note that the creation of this artefact may be delegated to a person in the business organization who is familiar with this domain and might later become the Programme Business Manager (PgBM).
  • The lifecycle of the Programme Initiation Request ends with the creation of the Programme Business Case and Programme Charter. All the information included in the Programme Initiation Request is copied over, updated and further clarified in these two documents, at which point the Programme Initiation Request becomes obsolete.

Input: A problem, a need or an opportunity expressed by the initiator.

Steps:

  1. Draft the Programme Initiation Request.
  2. Submit the Programme Initiation Request for approval to the Appropriate Governing Body (AGB).
  3. The Appropriate Governance Body (AGB) accepts the Programme Initiation Request and authorises to prepare a more elaborate Programme Business Case.
  4. The Appropriate Governance Body (AGB) assigns officially the Programme Owner (PgO).
Project Initiation Request

The Project Initiation Request is a project’s starting point and formalises its initiation. By creating a Project Initiation Request, the project initiator ensures that the current context/situation (i.e. problem, need or opportunity) and the project’s desired outcomes are formally captured and can be used as a basis for further exploration and elaboration.

The Project Initiation Request contains basic information about the estimated effort and cost of undertaking the project as well as the timeframe for its completion and the type of delivery. Specifically, the document describes the impact the project is expected to bring and summarises the success criteria against which it will be evaluated. Additionally, the Project Initiation Request outlines the project’s relevance to the organization’s strategic direction and highlights the key assumptions, constraints and risks as assessed at this stage.

Input

  • A problem, a need or an opportunity expressed by the initiator. Guidelines
  • Note that though anyone can initiate a Project Initiation Request, in many cases the Project Owner (PO) delegates its creation to the Business Manager (BM).

Guidelines

  • Know your audience: Depending on the project size and the organization’s approval process, approval can be informal (i.e. the Project Owner (PO) accepts it), or formal (i.e. an Appropriate Governance Body (AGB) reviews and approves it).
  • Ensure all the relevant information is included, but at this point limit details to high-level information—finer points will be added in the form of the Business Case and other Project artefacts.

Steps (for a project’s initiation)

  1. The Project Initiation Request is drafted.
  2. The Project Initiation Request is submitted for approval to the relevant Governing or Steering Level role.
  3. Once the Project Initiation Request is approved, the project is defined in more detail with a preliminary project scope description in the Business Case and further elaborated in the Project Charter.
  4. The Solution Provider (SP) assigns the Project Manager (PM) and the Project Core Team (PCT). The Project Manager (PM) is typically assigned after the Business Case is approved (or at the latest before the completion of the Project Charter), while the Project Core Team (PCT) is typically assigned before the Planning Kick-off Meeting.

The lifecycle of the Project Initiating Request ends with the creation of the Business Case and Project Charter. All the information included in the Project Initiation Request is copied over, updated and further elaborated in these two documents, which remain “live” until the end of the project.

To CPIM01

Business Case

The purpose of a Business Case is to capture the reasoning behind an initiative and to describe the initiative’s alignment with the strategic objectives expressed by an organization or a representative authority. It also provides justification for the investment in time and effort and sets out the budget expectations for soon-to-be delivered benefits.

The P2M methodology does not explicitly define the business case for a portfolio. For this reason we address it in some of the case studies.

Programme and project business cases are defined as below.

Programme Business Case

The Programme Business Case summarises the goals and benefits to be obtained by this programme. It considers the impacts of the programme in terms of organizational change, the expected achievements from the programme and allows upper management to decide on the programme’s viability.

Guidelines

  • provides decision-makers with the information they need to determine whether the programme is worth undertaking.
  • Is a living document and therefore, should be re-examined at critical programme milestones to validate that the expected benefits are still attainable, if the costs/schedule fall within the budget/timeline, and the programme is still relevant to the organization and should be continued.
  • For larger strategic programmes, the Programme Business Case may also include an assessment of impact and risks along with a more detailed cost-benefit analysis.

Input: Programme Initiation Request

Steps

  1. The Programme Business Manager (PgBM) drafts the Programme Business Case based on the information captured in the Programme Initiation Request. The main aspects to be analysed and presented are:
  • The programme’s areas to address and anticipated benefits stemming from the programme’s execution
  • If possible, a notion of the programme’s scope and the identification of key milestones
  • The programme’s positioning in the overall organizational strategy
  • A general cost per benefit, per identified area (see Step 1)
  • Synergies and interdependencies within the portfolio, other programmes and initiatives
  • High-level roadmap, including major milestones in regards to the delivery of benefits
  1. The Programme Owner (PgO) evaluates the Programme Business Case and decides to approve or reject it.
  2. The Programme Owner (PgO) sends the Programme Business Case to the Appropriate Governance Body (AGB) for further decision making.

To CPIM01

Project Business Case

The purpose of the Business Case is to capture the reasoning behind the project, to describe the project’s alignment with the organization’s strategic objectives, to provide a justification for the investment in time and effort, and to set out the budgetary needs. For larger strategic projects, the Business Case may also include an assessment of impact and risks along with a more detailed cost-benefit analysis.

The Business Case provides decision-makers with the information they need to determine whether the project is worth doing. The Business Case is a living document and therefore should be re-examined at critical project milestones to check that the expected benefits are still achievable, the costs/schedule fall within the budget/timeline, and the project is still relevant to the organization and should be continued.

Inputs: Project Initiation Request

Guidelines

  • Note that the form and depth of analysis required for this artefact depends on the level of investment required for the project.
  • Consider several solutions that fulfil this business need and recommend one of these.
  • Describe the overall approach to how the project will be executed (project strategy).
  • Identify measurable criteria that will be used to determine the success of the project.
  • For projects carried out under contract (e.g. as a result of a bid award), create the Business Case based on the Request for Proposal, the response to this request, and the contract itself.

Steps

  1. The Business Manager (BM) drafts the Business Case based on the information captured in the Project Initiation Request. The main project aspects to be analysed and presented are:
  • the project’s justification and impact
  • the project’s positioning in the overall organizational strategy
  • an assessment of Strengths, Weaknesses, Opportunities and Threats (SWOT Analysis) of several solutions, one of which is proposed for implementation
  • a cost benefit analysis, per identified solution, detailed to the extend required
  • synergies and interdependencies with other projects and initiatives
  • high-level project roadmap, including major milestones.
  1. The Project Owner (PO) evaluates the Business Case and decides to approve or reject it.
  2. The Project Owner (PO) sends the Business Case to the Appropriate Governance Body (AGB) if needed for corporate approval.

To CPIM01 - To the chapter

Charter

The Charter of an initiative is a required document that outlines the mandate of the initiative. It summarises the objectives to be achieved and documents the selected approach that address the “functional” areas implementing these goals. While specifying the scope and specific project selection, the Charter provides insight in the outcomes that are required to enable the delivery of the intended benefits in a portfolio, programme, project or iteration. Finally yet importantly, it also defines the initiative’s budget and governance structure.

The P2M methodology does not explicitly define the charter for a portfolio. For this reason we address it in some of the case studies.

Programme and project charters are defined as below.

Programme Charter

The Programme Charter is a required document that outlines the mandate of the programme. It summarises the objectives to be achieved and documents the selected approach that address the “functional” areas implementing these goals. While specifying the scope and specific project selection, the Programme Charter provides insight in the outcomes that are required to enable the delivery of the intended benefits in a programme roadmap. Finally yet importantly, it also defines the programme’s budget and governance structure.

Guidelines:

  • Ensure that input from all concerned programme stakeholders is considered.
  • Focus on the high-level programme structure and roadmap instead of presenting detailed information.
  • The roadmap divides the programme in stages, as intermediate steps to the final vision. Determine high-level capabilities for each stage, together with the intended benefits.
  • This document serves as a baseline evaluation document. The Programme Charter can be re-baselined, if necessary, but is not a document subject to change.

Input: Programme Initiation Request, Programme Business Case

Steps:

  1. The Programme Owner (PgO) appoints a Programme Manager (PgM). The latter role completes the Programme Steering Committee (PgSC), together with the already appointed Programme Business Manager (PgBM).
  2. The Programme Manager (PgM) starts to progress on the Programme Charter, based on the information contained in the Programme Initiation Request and Business Case.
  3. It is necessary to capture the programme’s governance, overall approach and programme structure.
  4. The Programme Business Manager (PgBM) supports the Programme Manager (PgM) to define the intermediate steps (stages) towards the delivery of the final vision by the end of the programme. The required outcomes are listed per stage together with the expected benefits.
  5. The Programme Owner (PO) sends the Programme Business Case and Charter to the Appropriate Governance Body (AGB) for approval, if needed.
  6. The Appropriate Governance Body (AGB) evaluates and accepts or rejects the Programme Charter.
Project Charter

The Project Charter builds on the Business Case and defines the project scope, high-level requirements and deliverables. It provides a basis for the more detailed project planning. It defines the project’s objectives (i.e. scope, time, cost, quality), high-level requirements, risks and constraints, as well as the project milestones and deliverable(s).

The charter is a key element of the project approval process (along with the Business Case). It includes the what, how and when fundamentals of the project and provides a baseline against which progress can be measured. Although the Project Charter can be initiated by the Business Manager (BM), it is ultimately the responsibility of the Project Manager (PM) to complete it and submit it for approval.

Input: Project Initiation Request, Project Business Case

Guidelines:

  • The Project Charter should be brief so that it can be sent to project stakeholders as soon as possible, and so that it is easy for them to review and understand.
  • Avoid presenting detailed requirements. Instead present high-level needs and features.
  • Detailed requirements may be captured in other artefacts (e.g. in a Requirements Document), or in an appendix to the Project Charter to be elaborated during the planning phase.
  • Ensure that input from all concerned project stakeholders is considered.
  • Ensure that once created, the Project Charter is updated and distributed as required.

Steps

  1. The Business Manager (BM) will first consult the main project stakeholders and takes part in drafting the Project Charter.
  2. The Project Manager (PM) is responsible for delivering the document.
  3. The main project stakeholders review the Project Charter and the Project Steering Committee (PSC) accepts it.
  4. The Project Owner (PO) sends the Business Case and Project Charter to the appropriate decision-making body for additional approval, if needed.
  5. The appropriate decision-making body evaluates and accepts or rejects the Project Charter.

As part of the business case or the project charter, the problem of the object system and the research questions of the study are formulated.

The design and analysis entity may represent the problem and research questions using a black box and assumptions.

In the black box representation the system that must be studied is represented as a box, with the relevant control-, and environmental and output variables.

If the variants to study have been identified already, the related decision tree may be included as well.

To CPIM01 - To the chapter


6.2 - #CPIM02 - Research and Leverage

The purpose of this step is to identify external organizations and service providers that may have already met, or are currently facing needs similar to the ones identified in #CPIM01 - Identify and validate, and then to analyse their experiences and results to determine if they can be applied and leveraged or if a partnership can be formed to address the needs together.

In alignment with “Shared First” principle, it is at this point that the planners consult both internal and external service catalogues for pre-existing services that are relevant to the current needs. In some instances, an entire business model, policy, technology solution, or service may be reusable to address the needs defined in #CPIM01 - Identify and validate. This is an important benefit in these cost-constrained, quickly evolving times.

Based on the research, leadership and stakeholders determine whether or not they will be able to leverage the experiences and results from other organizations in their projects, programmes or portfolios.

Target outcome: At the conclusion of this step, the architects, leadership, and stakeholders have a clear grasp on the experiences and results of other organizations (in the partnership), and the leadership and / or governance have determined whether or not they will and can leverage these experiences for their own needs. In some instances, another organization may be currently planning for similar needs and a partnership can be formed to collectively plan for these needs. The decision to leverage or not leverage has a significant impact on the planning activities in Define and plan. For instance, if the organization determines that it can leverage policies, models and systems from another organization in order to meet its own needs, then these policies, models and systems become a critical input to planning.

With the communications plan of a portfolio one can explicitly pursue the reuse in programmes and projects of planning artefacts, such as objectives, and models at the various layers (as supported by ArchiMate model elements): strategy, motivation, business, application, technology and physical, and implementation and migration.

Model building and the leverage hypothesis testing

The design and analysis entity acquires or builds the models that will be useful in answering the question whether prior work can be applied and leveraged in the own project or programme.

The leverage hypothesis can be tested by means of domain models.

Domain Model

Various types of conceptual models are used to look “inside” a system with an accuracy and level of detail such that values for all relevant concepts are intelligable or even computable.

Working with domain models during the research and leverage phase does not commit the approach or platforms to be used in the phases CPIM04 - Invest and Execute and CPIM05 - Perform and Measure.

Conceptual models that precede the development or deployment of computation specific models, had better include:

  • a domain model describing all the entities involved in the anticipated solution
  • event and process models describing the dynamics of those entities
  • and transition specifications, describing what changes of entities are for each type of event

When elaborating or harvesting these specifications, it may be necessary to add new assumptions. For instance because one cannot immediately consult the interested parties with knowledge of a specific event and its transition.

CIM: Design the Conceptual Model of the Operational Process

Early testing of the overall coherence of the domain and process models can be achieved by making a combined use of UML and BPMN models:

  • A UML Model to specify the entities and their possible configurations
  • A BPMN Model to specify the events, the flow and interactions of the entities
  • pseudo code and parameter bindings to specify the transitions that must be implemented for the identified events

When elaborating the specification, usually additional events will be identified.

It is important that the interested parties are consulted about what should happen (the transition) when such an “additional event” occurs.

Executable model, Verification and Experimentation

In a next step an executable model can be built and experiments can be run.

  • as a network of computational modules
  • the right variables and attributes are defined to control the flow of the process and to collect the required output data.
  • each variable is given its value according to what is provided by the case/variant. The computer model is updated according to these variables

It must be confirmed that the executable model correctly implements all the details specified in the conceptual model.

In (the current version of) this book we will not elaborate on building the executable model and on experimenting with it.

Yet, one should be aware that there are different kinds of validations:

  • Validation of a model by the interested parties.
  • Validation regarding the compliance with or reuse of (validated) models from the portfolio of which a programme or project is a part.
  • Validation that the behaviour or experiment parameters of the simulation model corresponds to those of the object system studied.

Simulation tools such as JaamSim, and BPMN tools such as Camunda allow to run experiments and summarize the results of a simulation or test.

Simulation is useful when one has to compare two or more situations/ options. For each option, the summary results would include the average values (for instance average waiting time) and the confidence interval.

For simulation tools and for operational systems (for instance a process execution engine), a Platform Specific Model is needed to run the simulation or solution.

Examples include, but are not limited to:

  • JaamSim (several versions)
  • Camunda
  • BPMN Tools

To CPIM02 - To the chapter


6.3 - #CPIM03 - Define and Plan

The purpose of this step is to develop the integrated plan for the adjustments to the work system that are necessary to meet the needs identified in Identify and validate, while taking into consideration the insights regarding reuse and the solution resulting from the Research and Leverage phase.

Recommended adjustments could be within any or all of the architecture domains: strategy, business, data, applications, infrastructure, and security.

The integrated plan, the project plan, defines what will be done, when it will be done, how much it will cost, how to measure success, and the significant risks to be considered. Additionally, the integrated plan includes a timeline highlighting what benefits will be achieved, when their completion can be expected, and how the benefits will be measured. It is during this step that analysis of current capabilities and environments results in recommended adjustments to meet the needs identified in Identify and validate phase.

Also during this step, the formal design and planning of the target capabilities and environment is performed. In addition to the integrated plan, the full complement of architecture, capital planning, security, records, budget, human capital, and performance compliance documents is developed based on analysis.

The end outcome is an integrated set of plans that can be considered and approved by leadership and governance.

Target outcome: At the end of this Step (which is also end of Organize and plan), leadership and stakeholders will possess an integrated set of plans and artefacts. This set of plans should be synthesized into discrete decision-making packages for leadership and governance that are appropriate given financial, political, and organizational constraints.

In (the current version of) this book we will not elaborate much on this phase as it is well-covered in project management literature and practice.

To the chapter


6.4 - #CPIM04 - Invest and Execute

The purpose of this step is to make the investment decision and implement the changes as defined in the integrated plan. Many groups participate in this step, however, it is important to note that these groups will need to work as a coordinated and collaborative team to achieve the primary purpose of this step: to successfully implement the planned changes within the scope set for a project or programme.

Target outcome: A decision is made concerning the investment in the changes that were planned in Define and plan. At the end of this step the recommendations for addressing the defined needs have been implemented. If the investment is not approved, the architect, leadership, and stakeholders return to previous steps to alter the recommendations and plans for future leadership consideration. It is important to reiterate that the integrated plans and the implementation could consist of a variety of changes to include, but not limited to, policy changes, organizational changes, technology changes, process changes, and skills changes.

In (the current version of) this book we will not elaborate on this phase as it is well-covered in project management literature and practice.

To the chapter


6.5 - #CPIM05 - Perform and measure

The mission is performed and measured at a plateau (target) with the new capabilities planned in Define and plan and implemented in #CPIM04a - Invest & #CPIM04b - Execute. Prior to the implementation, the mission was performed and measured at a “baseline” plateau. The purpose of this interaction is to operate the mission and measure performance outcomes against identified metrics.

Target Outcome: The new capabilities as planned in Define and plan and implemented in #CPIM04a - Invest & #CPIM04b - Execute will be operational. The key outcome of this step is measured performance outcomes against identified metrics.

In (the current version of) this book we will not elaborate on this phase as it is well-covered in project management literature and practice.

To the chapter


Part III - Models and Tools in Early Planning & Analysis


Chapter 7 - Models and Tools in Identify and Validate

Chapter 8 - Models and Tools in Research and Leverage - Define the Study

Chapter 9 - Conceptual Models and Tools in Research and Leverage


To Part I - II - III - IV - V - VI-Annexes - VII-References


Chapter 7 - Models and Tools in CPIM01 - Identify and validate


7.1 - Introduction
7.2 - The Decision-Making Context
7.3 - Problem Formulation
7.4 - Establish objectives
7.5 - Scope and level of detail
7.6 - For larger initiatives only
7.7 - Identification and Validation in Open Portfolios
7.8 - Identification and Validation in Programmes
7.9 - Identification and Validation in Projects
7.10 - Identification and Validation in Iterations
7.11 - Identification and Validation in the 2030 Agenda
7.12 - Identification and Validation for Library Services
7.13 - Identification and Validation at a Petrol Station
7.14 - Identification and Validation at the Harbour


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


7.1 - Introduction

Performance measures are often about people who receive service. Indicators are proxies for the well-being of whole populations, and necessarily matters of approximation and compromise. Performance measures are about a known group of people who get service and conditions for this group can be precisely measured.

As part of the first step, three activities must always be executed, these are:

  • object system problem formulation,
  • establishing project objectives/ research questions, and
  • determine the scope and level of detail.

Before introducing these steps, we present the concept of a decision frame as a means to unambiguously express both problems with, objectives for and decision options on operational processes (that realize services).

The chapter ends with a list of issues that must be addressed in addition for larger projects.


7.2 - The Decision Making Context

A Results Framework (USAID,2021a) is a portrayal of the development hypotheses through which a Mission expects to achieve the Goal of a Country (or local government unit) Development Cooperation Strategy (CDCS)(USAID,2021b), as part of a Macro journey at the national (or Local) Level of scope.

Visually, a Results Framework brings together several, often quite distinct, streams of results, which function synergistically to produce broad development changes. Thus, an economic growth result in a Results Framework might join with a health (#sdg3 - Ensure healthy lives and promote well-being for all at all ages) and an education (#sdg4 - Ensure inclusive and equitable quality education and promote life-long learning opportunities for all) results to realize CDCS Goal stated in citizen welfare terms.

One example of a macro level results framework is the 2030 Agenda Indicators.

Tversky & Kahneman (1981) use the term decision frame to refer to the decision-maker’s conception of the acts, outcomes and contingencies associated with a particular choice. The frame that a decision-maker adopts is controlled partly by the formulation of the problem and partly by the norms, habits and personal characteristics of the decision-maker.

Decision frames are particularly malleable in contexts where multiple and conflicting objectives are at stake, perceived and technical risks are not well aligned, and difficult tradeoffs must be made in order to implement a particular strategy ((Payne et al, 1992) cited by (Wilson and Bruskotter, 2009)).

Slovic (1995) moreover indicates that people’s preferences are often constructed in the process of elicitation.

Decision Frame (ISO FDIS 15704)

A decision frame describes a set of items that constrain the degrees of freedom for the decision-making on the work system operations (see Figure 1.3) as controlled by a decision centre (part of the management activity in Figure 1.4). This frame will not be modified by the decision. Its constituents typically are the result of a decision that has already been made (for instance in the governance activity). To avoid conflicts, a decision centre should be under the influence of only one decision frame.

The main items influencing the decision-making are:

  • the decision objective or set of objectives the process has to meet;
  • the decision variables enabling the decision-maker to know what may be acted on and under what constraints;
  • the decision criteria guiding the choice of the decision-making.

Decision objective

Objectives indicate which types of performances are targeted. These performances can be the production costs, the delivery lead-time, the level of quality, for example.

Objectives are needed everywhere and every time a decision is made. Global objectives refer to the entire system or supply chain and, according to the principle of coordination, are consistently detailed to give local objectives to all decision centres.

Decision variable

Decision variables are the items upon which a decision centre can make decisions that allow it to reach its objectives.

Decision constraint

Constraints are the limitations on possible values of variables. Decision constraints limit the freedom of a decision centre to select any arbitrary value for its decision variables.

Performance measure

A performance measure is an aggregated piece of information allowing the comparison of the performance of the system to the system’s objectives. A performance measure is defined by its name, a value domain or dimension and a procedure that describes how its value can be calculated.

Consistency

Performance measures should be consistent with objectives because it is necessary to compare performances targeted (objectives) and performances reached (measures). Performance measures should also be consistent with decision variables because those variables will have an effect on the performance monitored (controllability). The main issue is to ensure internal consistency inside a decision centre in terms of the triplet presented (see Figure 7.1). This consistency is ensured if the performance measures allow verification of the achievement of the objective and are influenced by actions on decision variables.

Figure 7.1: Consistency of the "Objectives, Variables, Performance Measures" triplet
Figure 7.1: Consistency of the “Objectives, Variables, Performance Measures” triplet

Decision Frame and Network Structure

The object system for which decision making is required can have a network structure. Haegele and Klink (1998) state that four basic network structures (mostly used in a IT networking context) can distinguish networks in supply chain relationships. These are tree, bus, star and ring networks. In both tree and star networks there is a central player (for instance the company dominating the supply chain), which initiates the supply chain initiatives and owns the supply chain information system. This governance activity of this central player provides the top-level decision frame that must be refined by the partners in the network.

The partners who are involved in a network usually have the objective to increase their competitiveness. This implies they have to become more effective/efficient in comparison with other networks (chains) that are supplying products/services that compete in any way (similar products, substitute products etc.).

Performance measures, to be appropriate, should cover such areas as those:

  • of critical concern to object system common goals and strategies;
  • of inter-influence and of common concern among the network partners;
  • and concerned by both internal partners and external customers.

A performance measurement method should be based on the process model of the object system, so measures can be derived from process performance. Any process consumes particular enterprise resources, performs the planned missions and functions, and then adds value to products that are delivered to end customers. The consumed resources, and planned functional operations or expected outcomes are the essential performance of processes. Time, labour, capital, power, facilities, and information are typically the resources that processes consume. Traditionally, they can be measured according to their planned functional operations. For example, purchasing process is mainly responsible for material replenishment, supply base management, etc. Thus it can be measured from such performance as material replenishment reliability and quality, and supplier-buyer relationship. Reliability in delivery and transportation, and flexibility in material supply, production, and order delivery have received more and more attention in performance measurement of supply chains. For each process and its sub-processes that need to be measured, the corresponding measures are identified and grouped into the processes and measures hierarchy as shown in Figure 7.2.

Figure 7.2: Decomposition in Performance Management
Figure 7.2: Decomposition in Performance Management

An Object System can be divided into a number of Core Processes. A core process refers to a series of planned activities for original suppliers and manufacturers till retailers that add value for the end customer. These core business processes, which are of essential importance to business objectives and strategies, are suggested to identify and confine the decision frame. The core processes identified can be further decomposed into sub-processes and activities to address their detailed performances. For example, the inbound logistics can be decomposed into such sub-processes as purchasing, transport, supply base management, etc. All these core processes and sub-processes compose the framework for a supply chain Performance Measurement System.

The Supply Chain Design Decomposition (SCDD), is a toolbox for the measurement and improvement of logistics performance in supply chains, which is the result of the application of axiomatic design to SCM (Schnetzler et al, 2004). This axiomatic design was developed at the Massachusetts Institute of Technology (MIT Boston) as a scientific approach for the generation and selection of good design solution for products, processes, and systems (Suh, 2001). Axiomatic design focuses on the identification of functional requirements and the selection of means for achieving them. Objectives are expressed as functional requirements (FRs) for a solution and the possible means as design parameters (DPs) (Engelhardt and Nordlund, 2000). By decomposing the design into several levels of objectives-means-combinations, a causal model of the design is created showing the connections of an objective and the corresponding solution. Axiomatic design has been successful applied to the design of many products, systems, and software as well as to development of manufacturing systems. Manufacturing System Design Decomposition (Cochran et al., 2001) offers a tool to separate objectives from the means to achieve them, to relate low-level activities and decisions to high-level goals and requirements, to understand the interrelationships among the different elements of a system design, and to effectively communicate this information across the organization.

The objective/means hierarchy is illustrated in Figure 7.3. This model is used in relation with the designed “The Process – performance Indicators – Value” network. The highest level of SCDD concerns strategic supply chain management and is set up according to the methodology of economic value added (EVA) as an appropriate representative of the success of the enterprise. EVA can be understood as net operating profit after taxes minus a capital charge, which depends on the total invested capital and the capital costs (Ehrbar, 1998).

Figure 7.3: Example of an Objective-Means Hierarchy
Figure 7.3: Example of an Objective-Means Hierarchy

In an advanced governance system (van Eijnatten and Goossenaerts, 2004) also the decision-object hierarchies for other objectives such as safety, health, security, environment friendliness, and disaster reduction will need to be defined. Safety and health objectives are expressed with respect to human capital. Security and disaster reduction objectives are expressed with respect to several kinds of capital, with action means in the realm of the social capital. Environment friendliness objectives are expressed with respect to natural capital stocks and flow (see also Rudd, 2004).

In the case of a network structure, a decision frame and all reflective activities (governance, management and analysis and design) may exist for the operations of each sub-system.

Classes of Systems with Analytically Computable Performance

In many change situations it is important to assess the value impact of the proposed change (a setting of a decision variable) on the performance of a system.

For certain classes of systems, for instance M/M/s queues with exponential inter-arrival time distribution and/or service time distribution, certain measures of performance can be analytically computed. These are steady-state average delay, steady state average waiting time, steady-state time-average number in queue, and steady-state time-average number in system (Law & Kelton, 2000, page 97).

The triplet of objectives, decision variables and performance measures for the class of queuing systems looks as follows:

  • Objectives: not specified
  • Decision Variables:
    • Service mechanism: the number of servers; does each server have its own queue, or is there one queue feeding all servers; the probability distribution of customers’ service times.
    • Queue discipline: the rule that the server uses to choose the next customer from the queue (if any) when the server completes the service of the current customer.
  • Performance Measures:
    • (steady-state) average delay
    • (steady state) average waiting time
    • (steady-state) time-average number in queue
    • (steady-state) time-average number in system
    • mean service time and service rate

The selection of values for decision variables only becomes meaningful when objectives are stated for a system. If a given object system can be modelled (approximated) by a member of a class of systems for which performance measures can be computed analytically, then design alternatives exist within the same class of systems, where different values have been set for the decision variables in the class of systems. For instance, the number of servers is increased to reduce average delay, or the queue discipline is modified.

When approximating or modeling real life object system operations by classes of systems with analytically computable performance measures, we meet limitations of several kinds:

  • the degrees of freedom in the design is limited in comparison to the options that the decision maker or designer has;
  • the number of performance measures that can be computed is limited, and may not include performance measures that are consistent with the values and objectives stated for the system;
  • for a given object system multiple objectives may be stated (multi-criteria decision making), and there exist decision variables with joint effects for multiple sources of value loss (erosion) (e.g., the study by Lee and Özer (2005) on the effects of misplacement, shrinkage and transaction errors on inventory policies).

In such cases simulation offers an alternative decision supporting technique. It allows the designer to evaluate systems w.r.t. a broad range of decision frames, in which fewer limitations exist for the values, the objectives, the decision variables and the performance measures.

Implications for Simulation

In the study of systems with analytically computable performance, it is common to present the decision frame once and for all, and to further work (= do mathematics) within that decision frame, without revisiting the assumptions that limit their applicability.

When studying the behaviour of operational systems by means of simulation, it is common to adopt the decision frames of well known classes of systems, such as for instance queuing systems or manufacturing systems, and to restrict evaluations to performances that are also analytically computable, or to restrict decision options to those studied analytically.

To really appreciate the value of modeling of operational processes it is important to first define the decision frame that matters for the system studied, and to formulate the problem that initiates the redesign effort, in terms of the decision frame.

Points of attention in the case materials

Open portfolios may emphasize objectives, decision variables and performance measures that are mandatory or recommended for programmes, projects and iterations that become part of the portfolio.

  • objectives: minimizing environmental impact, or minimizing emissions; maximize the use of shared models
  • decision variables: which portfolio models, or which of their content, to use
  • performance indicator: emission measures

Programmes, projects and iterations may then copy those objectives, decision variables and performance measures into their decision frames and elaborate their business case using them.

To the chapter


7.3 - Problem formulation

Every decision making engagement begins with a statement of the problem for some operational process or facility that delivers an eco-system, industry or government service.

A problem statement that is provided by the management entity or problem owner (client) is usually informed by immediate ambitions and context of the work-system but may be less aware of all the means that are available for solving the problem, and of constraints.

Very often though, the problem is stated as the absence of something, and the problem owner assumes that the presence of that something is the solution: in other words, the problem owner proposes a solution, or has jumped to a conclusion regarding the solution of his problem, without having done a proper analysis.

By focussing on objectives, performance measures and decision variables one can kick off the path to understanding the problem without such jumping to conclusions.

If a problem statement is prepared, it is important that the client understands and agrees with the formulation.

A problem for an operational process or facility is well understood when it is formulated w.r.t. a decision frame expressing objectives, performance measures and decision variables for the operational process or facility.

Modeling may help in the formulation of the problem.

It is moreover suggested that a set of assumptions is prepared and agreed upon with the client or the interested parties.

Ideally the “scientific” planner would like to have one model that represents and explains the entire system in its environment. Such a model does not exist, but models and data of parts or aspects of the system (the firm, supply, distribution and sales, consumers, competition and environment) are available.

If such models and data exist and are relevant to the scope of a decision problem, then it is important that they can be deployed early in the decision study.

The various layers of the ArchiMate framework support the use of models in the problem formulation.

The models may also be refined or improved. The decision study may require additional data.

Let us review the problem formulation at the levels of open portfolios, programmes, projects and iterations by expressing the decision frame for some typical situations.

Problem formulation in Open Portfolios (Macro and meso journeys)

For instance the problem of climate change caused by mankind.

At country level, not meeting a target defined with respect to 2030 Agenda Indicators signals a problem.

In an open portfolio the range of problems that should be addressed could be very wide, and problems of various facilities could be mutually enforcing.

In such a situation, different decision frames may coexist, one for each facility “l” providing an eco-system, industry or government service for a sociotope. This is depicted in figure 7.4.

Figure 7.4: Portfolio objectives pertaining to distinct result areas (or facilities)
Figure 7.4: Portfolio objectives pertaining to distinct result areas (or facilities)

Problem formulation in Programmes (Meso and micro journeys)

For instance the contribution of fossil fuels to climate change caused by mankind.

The contribution to carbon emissions by the use of private jets.

In the context of the “Open” 2030 Agenda which defines development goals for different areas of human activity, each of those areas could be the object system of a programme’s problem formulation.

Problem formulation in Projects (Micro and pico journeys)

The result framework could be formulated using a balanced scorecard of a similar framework.

Here we give some concrete examples that many may be familiar with. One of the purposes of this e-book is to encourage a similar way of working in meso and macro journeys.

1. Increase plant throughput by 20%

The plant management has been given the directive to increase throughput by 20%, for instance on the basis of a benchmark with competing plants.

The decision frame for the plant operations looks thus:

  1. Objective: increase plant throughput by 20 %
  2. Performance indicator: plant throughput
  3. Decision Variables: not specified

Note that no constraints (operational costs, project budget, on the solution …) are given. It is important that related assumptions are checked with the problem owner. The problem statement is too broad to immediately justify a decision making engagement.

2. Reduce Work in Progress (WIP) by 10%.

The decision frame for the plant operations looks thus:

  1. Objective: reduce WIP by 10 %
  2. Performance indicator: WIP during the operations
  3. Decision Variables: not specified

The problem statement is too broad to immediately justify a decision making engagement.

3. How many AGVs are required?

  1. Objective: not specified, but it can be assumed that a certain volume of jobs must be performed within a certain period of time
  2. Performance indicator: e.g., average waiting time, time-average in queue,..
  3. Decision Variables: the number of AGV’s

In the case that performances cannot be computed analytically (approximately), modeling is recommended.

4. What Schedule achieves best throughput?

  1. Objective: highest/best throughput
  2. Performance indicator: throughput
  3. Decision Variables: a number of available schedules (or scheduling algorithms)

In the case that performances cannot be computed analytically (approximately), modeling is recommended.

It is typical to have multiple dependencies among decision variables and performances. Smaller buffer sizes may not help higher throughput rates, though it may imply lower costs and WIP.

Problem formulation in iterations

As problem messes may be complex it is often irrealistic to achieve a solution in one step. By considering the various properties of the facility and dependencies among the decision variables a stepwise approach which may pass over several plateaus between the current situation and the intended future. Each iteration solves some sub-problems of the overall problem mess. As one progresses from one iteration to the next, additional insight into the facility and the operational processes may open up additional solution paths.

To the chapter


7.4 - Establish Objectives/ Research Questions

This step should be accomplished regardless of location of the analyst and client. The portfolio, programme or project objectives indicate the performance questions that are to be answered by the decision making engagement.

Objectives in Open Portfolios (Macro and meso journeys)

The sustainable development goals indicate possible objectives for a wide range of macro- and meso-level development portfolios.

Objectives in Programmes (Meso and micro journeys)

The sustainable development goals and benchmarking indicate possible objectives for a wide range of meso- and micro-level programmes.

Objectives in Projects (Micro and pico journeys)

Here we give some concrete examples that many may be familiar with. One of the purposes of this e-book is to encourage a similar way of working in meso and macro journeys, with a considerable sharing of objectives and research questions.

Typical objectives can be to verify the throughput time of a new manufacturing line, identify the bottleneck operations in a system, find the proper buffer capacities to attain certain levels of production, determine the best batch sizes and sequence for a multi-product manufacturing line, etc.

One should remember that the objective of a decision making engagement cannot be just to simulate the system(Ulgen et al., 1994), or to develop a system.

Besides answering performance questions about alternative designs of operational processes, there may be project objectives related to time scale, run speed or visual presentation (Mehta, 2000).

The result of project may also be to provide a training tool or an on-going scheduling tool. These study-objectives may affect the way the model should be created. For example, if there are no training purposes for the study deliverables, then simple animation may be sufficient. On the contrary, in case of training purposes animation may appear to be an important tool, 3-D detailed animation may be required.

After the objectives of the study have been finalized, they should be written and stated as part of the portfolio, programme, project or iteration documentation.

It is important for any team to remind itself of the original objectives when proceeding with the remaining steps and phases of a portfolio, programme, project or iteration.

To the chapter


7.5 - Scope and Level of Detail

The scope and level of detail determine what should be included in the model and how much detail should be modelled.

The model should have a minimum amount of detail required to achieve the objectives at the level of the initiative. At least enough to get confident answers for the specific questions from the study. In many cases, the availability of data and time, experience of the modeller, animation requirements, and expectations of the interested parties are more dominant factors in determining the level of detail than the specific issues to be addressed by the study.

In the portfolio-programme-project-iteration chain, the modeller should aim to reuse “less specific” lower level models that will satisfy the objectives of the study.

For example, for the information exchanges in a supply chain, the EDIFACT messages can serve as reusable “portfolio models”.

In another example, for the AGV (Automated Guided Vehicle) material handling study, the manufacturing cells that request the AGVs to drop and pick up parts may be modelled as black boxes. Each manufacturing cell can be described with one inter-arrival distribution for AGV pickup requests and another inter arrival distribution for AGV retrieval requests. On the other hand, in a more complex AGV study where there are synchronization issues among the manufacturing cells, one may need to describe in detail the schedule of operations at each cell (Ulgen et al., 1994).

In some cases, lack of time may force the modeller to build a less specific upper level model that satisfies only a subset of the original objectives of the study.

But don’t forget, more detail doesn’t necessarily mean more accuracy!

To the chapter


7.6 - For Larger Initiatives Only

For larger initiatives, additional activities are recommended:

  • Estimation of the required resources for the study,
  • performing a cost-benefit analysis, and
  • the creation of a planning chart.

This e-book doesn’t elaborate these topics in detail. Yet it conjectures that reusing models along the portfolio-programme-project-iteration chain, will contribute to substantial economies regarding the required resources, especially if these resources are “open”.

Seen in the perspective of a planet that must achieve the sustainable development goals, any paywalls that hamper the reuse of intellectual resources will harm the cost-benefit equations and complicate the planning of interested parties that should not be left behind.

Estimate the required resources needed to do the study and modeling

Estimating how long an initiative will take and which resources will be used for the study is an important step.

The detailed list of tasks to be performed in the study, the duration of each task, the resources to be used for each task and cost of each resource are needed in order to make a sound estimate of the resource requirements of the initiative. Level of detail and availability of data in the proper form are important factors in determining the time and type of resources required for the study. Availability of historical data from prior initiatives can increase the confidence in the estimates resource levels, timing and cost. A PERT analysis that gives the minimum and maximum duration for each task can be useful in estimating the total initiative time at different levels of confidence.

A special attention should be given to human requirements. Human requirements in a decision making engagement are due to:

  • interaction with people familiar in management of the system,
  • interaction with people familiar with the engineering details of the system,
  • modeller(s) familiar with the modeling tool to be used as well as experience with similar types of systems,
  • data collection required by the study.

Perform a Cost-Benefit analysis

This process needs not to be an extended formal process but it should be performed as a check-point in any study.

A simple cost-benefit calculation may also aid the modeller in determining the proper level of detail to include in the model.

For example, for an AGV study, it would be wasteful to spend $20,000 of additional modeling time to decide if faster AGVs are better for the system when the total incremental cost of the faster AGVs is less than $20,000. The team should consider the whole life-cycle of the system and all relevant cost components in the cost-benefit analysis. It is common to observe a cost-benefit ratio of one-hundred to one-thousand from a typical decision making engagement when one looks at the total benefits gained throughout the life of the system (Ulgen et al., 1994).

Create a planning chart of the proposed project

Modeling initiatives can easily get out of hand, especially if the rate of change in the scope of the project exceeds the rate at which the results are available to the interested parties.

A Gantt chart showing the tasks with milestone points can help control an initiative.

Figure 7.5 shows a Gantt chart for the major phases of a decision making project. Typical milestone events in a simulation project may include completion of the project specifications, CIM model results, input data collection and analysis, base model validation, base model final results, alternate model validation, alternate model final results and final report.

Figure 7.5: A Gantt chart showing the major phases of a decision making engagement
Figure 7.5: A Gantt chart showing the major phases of a decision making engagement

To the chapter


7.7 - Identification and Validation in Open Portfolios

The 2030 Agenda for Sustainable Development - #SDGs

As open portfolios don’t have a competitive or “self-enrichment” intention, the notion of Economic Added Value that is key in micro journeys is subordinate to the values that are depicted in Figure 7.6 and have been defined in the 2030 Sustainable Development Agenda.

Figure 7.6: Values of the 2030 Agenda
Figure 7.6: Values of the 2030 Agenda

In figure 7.7, the sustainable development goals are linked to the values. The Sustainable Development Goals are strategic objectives for the United Nations member states. Each goal has a number of targets for which also indicators have been defined and data are being collected.

Figure 7.7: Values and strategic objectives of the 2030 Agenda
Figure 7.7: Values and strategic objectives of the 2030 Agenda

The third component of the 2030 Agenda decision framework are the decision variables. These are not specified in the 2030 Agenda itself, but are addressed in the Addis Ababa Action Agenda and in the national action plans of the UN Member States and the private sector.

One way of describing the decision variables is via variations in the production and consumption of products and services, as classified in the Central Product Classification (CPC), and as produced and delivered by:

A myriad of problem statements can be created using this generic decision frame, and both government agencies, industry bodies, and private sector players can launch portfolios, programmes, projects and iterations to solve the identified problems.

Each interested party can activily work at one or a few problems, where each problem is addressed in a portfolio, programme, project or iteration by a dedicated consortium, network or community.

Figure 7.8: The decision frame of the 2030 Agenda
Figure 7.8: The decision frame of the 2030 Agenda

Figure 7.8 shows the decision frame of the 2030 Agenda, and figure 7.9 shows business, sociological, political and technological trends that should be considered in the planning.

Figure 7.9: Business,  sociological, political and technological trends shaping business/IT planning
Figure 7.9: Business, sociological, political and technological trends shaping business/IT planning

That there are many interested parties, many problems as well as many potential solutions, justifies an open communication strategy, for instance as proposed in the #tagcoding handbook and its translations.

It is clear that solving problem messes at this scale involves many parties that otherwise might freely select values and objectives serving either private or public interest, within the constraints of government regulations (and their resource endowments).

The question then rises for whom the decision frame is valid. Corporate objectives such as maximizing shareholder value reflect the believe that the public interest is best served by every individual pursueing private property growth in a free market. Free market then means a market that is not constrained by any but basic rules, such as specified in contracts.

Regarding the 2030 Agenda validation, its adoption at the UN General Assembly of 2015 indicates a willingness to invest across levels of government. Moreover during the 2030 Agenda’s preparation and in the Addis Ababa Action Agenda much attention was given to a Global Partnership that should engage National governments of all countries, Local authorities, International institutions, Business, Civil society organizations, Philanthropists, Social impact investors, Scientists and academics, People – all sitting at the table to go beyond aid to discuss a truly international framework of policies to achieve sustainable development.

EDIFACT

The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT is a subsidiary, intergovernmental body of the United Nations Economic Commission for Europe (UNECE) which serves as a focal point within the United Nations Economic and Social Council for trade facilitation recommendations and electronic business standards. It has global membership and its members are experts from intergovernmental organizations, individual countries’ authorities and also from the business community.

Its key areas of work include Trade Facilitation Recommendations. Over the past 40 years, the United Nations Economic Commission for Europe (UNECE) has developed and maintained a series of recommendations and standards for international trade. These reflect best practices in trade procedures and data and documentary requirements. They are used worldwide to simplify and harmonize international trade procedures and information flows.

Figure 7.10: The decision frame of UN/CEFACT
Figure 7.10: The decision frame of UN/CEFACT

The key open portfolio problem is to extend the standard offer to more sectors (index l in Figure 7.10).

7.8 - Identification and Validation in Programmes

Limit to programmes that are aware of open portfolio and intend to maximally reuse the resources provided (ref. Figures 7.8 and 7.9):

  • by including objectives, measures and indicators in their decision frames;
  • by adopting the standards in their analysis and solution design.
  • ….

To the chapter


7.9 - Identification and Validation in Projects

Limit to projects that are aware of open portfolio and intend to maximally reuse the resources provided (ref. Figures 7.8 and 7.9):

  • by including objectives, measures and indicators in their decision frames;
  • by adopting the standards in their analysis and solution design.
  • ….

To the chapter


7.10 - Identification and Validation in Iterations

Limit to iterations that are aware of open portfolio and intend to maximally reuse the resources provided (ref. Figures 7.8 and 7.9):

  • by including objectives, measures and indicators in their decision frames;
  • by adopting the standards in their analysis and solution design.
  • ….

To the chapter


7.11 - Identification and Validation in the 2030 Agenda

To the case overview - To the chapter


7.12 - Identification and Validation for Library Services

Library services globally must respond to new trends in development and technology.

The local public library must become an (internet-based) capability for all people (citizens), business, and government agencies (local authorities), to easily find and access printed or online content (both creative works and digital public goods) in their native, second or third language. This content will be of interest to their culture, recreation, learning or coping in a sustainable and inclusive manner with the livelihood challenges and opportunities they face.

In the creation of this capability, there is a role for:

  • all librarians, as well as for library patrons and many other library stakeholders.
  • providers of digital public goods

Figure 7.11 shows critical resources, e.g. “Library collection”, stakeholders, e.g. “Library patron”, alongside the pursued capability and possible courses of action (decision variables) for enhancing the library services.

Figure 7.11: Outcomes and Critical Resources for library Services
Figure 7.11: Outcomes and Critical Resources for library Services

Regarding the availability of local library services (performance measures), note that the #WWlgu pages of local governments include links to “local” open data provided by Knoema as well as links to LibWeb - Library Servers via WWW.

Table 7.1: Library scorecard
Table 7.1: Library scorecard

In the Nr. column these abbreviations are used for the objectives: F: Financial; I: Internal business processes; C: Customers; and L: Learning and growth.

To the case overview - To the chapter


7.13 - Identification and Validation at a Petrol Station

Problem Formulation

The decision frame is:

  • Objective: minimal number of customers driving on because there is no place in the queue area;
  • Performance indicator: number of customers driving on without being served;
  • Decision variable: the length of the queue area.

Assumptions that may need attention when agreeing the problem formulation include:

  • customers will not get fed up with waiting, for instance in a long queue
  • all customers that enter the queue will wait until they have been serviced
  • sales revenue will be higher when less customers drive on

There is no data about the cost of enlarging the queue area, nor about the revenue increases that could be gained.

Research Questions

  1. What is in the current situation the percentage of people that leave without being served?
  2. What is the average waiting time of served customers for different capacities of the queue area?
  3. What is the influence of the queue capacity on the percentage of cars leaving without being served?

Scope and Level of Detail

The pumps with service start and service end events.

The queue area with arrival, departure, and service start events.

The cars with the events matching the queue area and pump events.

The decision of the car to drive on when it finds the queue area full.

To the case overview - To the chapter


7.14 - Identification and Validation at the Harbour

Problem Formulation

The decision frame is:

  • Objective: reduce mean expected throughput time
  • Performance indicator: mean expected throughput time;
  • Decision variable: queueing discipline; resource allocation strategy

The problem is to evaluate the impact of the decision options on the mean expected throughput time.

Research Questions

  1. Does closing Dock1 to Big Ships and Dock2 to Small Ships improve the mean expected throughput time of ships at the harbour?
  2. Is it better to use FIFO rule instead of SPT rule?

Scope and Level of Detail

The docks with service start and service end events.

The queue with arrival, change queue and service start events.

The ships with the events matching the queue and dock events.

To the case overview - To the chapter


Chapter 8 - Research & Leverage (CPIM02a)


8.1 - Identifying external experiences
8.2 - Open portfolios as external experiences
8.3 - Scope and variables in programmes
8.4 - Scope and variables in Projects
8.5 - Scope and variables in Iterations
8.6 - #CPIM02a in Case 1 - 2030 Agenda
8.7 - #CPIM02a in Case 2 - Library services
8.8 - #CPIM02a in Case 3 - The Petrol Station Case
8.9 - #CPIM02a in Case 4 - The Harbour Case


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


Introduction

The activity black box and assumptions must be expressed. In most cases it is necessary to also list the decision options that will be evaluated (number of models and the techniques used to evaluate them). A decision tree is used to organize all the decision options and their order. If modeling or simulation is required, a modeling or simulation tool must be selected as well.


8.1 - Identifying external experiences for a work system

Given a problem formulation by means of a decision framework, and in reference to a results framework, the next step is to clarify the scope of the work system using a black box notation, and assumptions.

Black Box and Assumptions

To simulate the system we need input variables. There are two types of input variables:

  • Environmental variables: Variables we can’t modify and that are a result of the environment of the system.
  • Control variables: Variables we can control or change.

Using these variables, the running simulation and the behaviour of the system can be analyzed considering the output variables.

In this step, the problem and objectives of the decision making engagement are formulated as concretely as possible. The desired reliability and accuracy of the decision making engagement results should also be defined here.

  • Reliability is the confidence level at which the results should be displayed. Example: we would like to obtain the average throughput time with a confidence level of 95%.
  • Accuracy is the number of decimals at which we would like to display the results. Example: for time measures, we need to know if results will be displayed in hours, minutes, seconds, etc.

These steps must be performed:

  • Determine the environmental, control and output variables of a system in its black box representation (Figure 8.1).
  • List and finalize the assumptions. Which components of the real system will be excluded, included as a black box, included in moderate detail, or included in fine details is decided at this step.

It is important to keep a formal list of assumptions throughout the study, starting at the design phase, since the scope of work and the micro level assumptions to be made in model building will depend on them. These assumptions should be kept in mind all through the process and included in the final report. A trap which many modellers may fall into is waiting until the end of the study to record their assumptions; by then, they may have forgotten many of them and wasted a lot of time in inadvertently changing the scope of work throughout the process.

Figure 8.1: The Black Box Notation
Figure 8.1: The Black Box Notation

Regulative Cycle extended with Reference Models

The research & leverage is focussed at improving a work system under consideration.

Where research should lead to problem-solving or practical interventions (Goossenaerts et al., 2007), there is often a need for the process of multi-methodology, that is, combining together several methods in an intervention (Mingers, 2003). Originating in psychological practice, the regulative cycle (Van Strien, 1997) has been extensively applied also as a methodology of practice, geared towards the “interested” regulation of the behaviour of groups or organizations in the desired direction. Where principals are engaged with the operations and improvement of a work system such as a plant, a hospital or a service system, the cycle includes the following activities:

  • evaluation (of system operations with respect to an instrument or via benchmarking),
  • problem identification (selection from a problem mess),
  • diagnosis (of the problem situation – analysis),
  • plan of action (design), and
  • intervention (implementation).

This last step is again followed by evaluation to close the cycle.

In the evaluation activity it is convenient to have an instrument to compare the performance or structure of the work system. The reference fab methodology (Plieninger et al., 2001) uses a reference model for systematic target setting on high level performance indicators.

The model obtained from peer intelligence is translated into a site specific reference model with targets for the actual site work system. The translation considers factor costs, volumes and complexity of technologies.

Figure 8.2: Regulative cycle extended with Reference Models (Goossenaerts et al., 2007)
Figure 8.2: Regulative cycle extended with Reference Models (Goossenaerts et al., 2007)

Where open portfolios, programmes and projects involve digital components, some form of concertation of the regulative cycles is recommended. Model-based analysis and development (Berre et al, 2004-2007) and the sharing model repositories can help reduce common project risks (Goossenaerts, 2004). Where a trend to many-to-many relationships is observed (Elgarah et al, 2005), lock-in strategies by software vendors, and free-rider attitudes and prisoner’s dilemma by OEM and their customers may delay achieving solution flexibility, perpetual service-IT alignment, as well as affordable development and implementation costs. A complicating factor in deciding on investments in the digitally enabled constellations is the imitable nature of the standards, architectures, contracts and services that must be deployed. In economic theory, the relevant game is the public good game, a multi-player variant of the prisoner’s dilemma (Fehr and Schmidt, 1999).

In an open portfolio, the purpose of this step is to identify external organizations and service providers that may have already met, or are currently facing needs similar to the ones identified in #CPIM01 - Identify and validate, and then to analyse their experiences and results to determine if they can be applied and leveraged or if a partnership can be formed to address the needs together.

In alignment with “Shared First” principle, it is at this point that the planners consult both internal and external service catalogues for pre-existing services that are relevant to the current needs. In some instances, an entire business model, policy, technology solution, or service may be reusable to address the needs defined in #CPIM01 - Identify and validate – an important benefit in these cost-constrained, quickly evolving times.

Based on this analysis, leadership and stakeholders determine whether or not they will be able to leverage the experiences and results from other organizations in their projects, programmes or portfolios.

8.2 - Open Portfolios as external experiences

The 2030 Agenda for Sustainable Development - #SDGs

The 2030 Agenda decision framework and related performances are to serve as catalyst for sharing experiences and results among diverse partners.

In a sense they provide a decision framework.

Consider a current need, expressed as a gap with respect to a sustainable development goal or target for the system’s outcome.

When allocating the goals to sectors of industry and functions of government, and comparing performances of thoses sectors and functions in other countries or constellations with those of the problem owner, options for leveraging those experiences would often exist.

One way of describing the decision variables is via variations in the production and consumption of products and services, as classified in the Central Product Classification (CPC), and as produced and delivered by:

A myriad of problem statements can be created using this generic decision frame, and both government agencies and private sector players can launch portfolios, programmes, projects and iterations to solve the problems.

Each interested party can activily work at one or a few problems, while ensuring that effort is wisely divided over a feasible range of programmes, projects and iterations for a selection of economic activities and functions of government such that “landscape wide” progress can be guaranteed.

Figure 8.3: The black box of the 2030 Agenda
Figure 8.3: The black box of the 2030 Agenda

Figure 8.3 shows the black box of the 2030 Agenda.

That there are many interested parties, as well as many potential solutions, justifies an open communication strategy, for instance as proposed in the #tagcoding handbook and its translations.

It is clear that solving problems at this scale involves many parties that otherwise can freely select values and objectives serving either private or public interest, within the constraints of government regulations.

The question then rises for whom the decision frame is valid. Corporate objectives such as maximizing shareholder value reflect the believe that the public interest is best served by every individual pursueing private property growth in a free market. Free market then means a market that is not constrained by any but basic rules, such as specified in contracts.

Regarding the 2030 Agenda validation, its adoption at the UN General Assembly of 2015 indicates a willingness to invest across levels of government. Moreover during the 2030 Agenda’s preparation and in the Addis Ababa Action Agenda much attention was given to a Global Partnership that should engage National governments of all countries, Local authorities, International institutions, Business, Civil society organizations, Philanthropists, Social impact investors, Scientists and academics, People – all sitting at the table to go beyond aid to discuss a truly international framework of policies to achieve sustainable development.

The 2030 Agenda for sustainable development faces at least these three systemic challenges, for which the OECD has proposed Principles on Effective Public Investment across Levels of Government:

  • Co-ordination across governments and policy areas
    • 01 - Adopt an integrated, place-specific strategy
    • 02 - Co-ordinate across sub-national and national levels
    • 03 - Invest at the relevant scale
  • The strengthening of capacities for public investment and the promotion of learning
    • 04 - Understand impacts and risks
    • 05 - Engage stakeholders at every step
    • 06 - Include private actors and institutions
    • 07 - Build expertise in local partners
    • 08 - Focus on results, capture lessons from experience
  • Ensure sound framework conditions at all levels of governments
    • 09 - Develop a fiscal framework aligned with objectives
    • 10 - Insist on sound, transparent financial management
    • 11 - Promote strategic use of public procurement
    • 12 - Strive for consistent, quality regulation
Figure 8.4: Trickle down from open portfolio to programmes, projects and iterations
Figure 8.4: Trickle down from open portfolio to programmes, projects and iterations

The key open portfolio problem is to convince all the interested parties in investing towards the objectives of the 2030 Agenda.

EDIFACT

To enhance and facilitate international trade UN/CEFACT addresses these topics:

  • Code List Recommendations: Codified information is an integral part of data exchange in international business whether this is on paper documents or electronic data exchange. The United Nations Economic Commission for Europe (UNECE), through its UN Centre for Trade Facilitation and Electronic Business (UN/CEFACT) develops, maintains and publishes for free of charge a number of code lists used extensively in business transactions.
  • Standards ranging from general, supply chain management and transport and logistics to environment and covering sectors such as Agriculture, Travel and Tourism and Accounting and Audit. Key standards include:
    • UN/LOCODE: The “United Nations Code for Trade and Transport Locations” is commonly more known as “UN/LOCODE”. Currently, UN/LOCODE includes over 103,034 locations in 249 countries and territories. UN/LOCODE is used by most major shipping companies, by freight forwarders and in the manufacturing industry around the world. It is also applied by national governments and in trade related activities, such as statistics where it is used by the European Union, by the UPU for certain postal services, etc.
    • UN/EDIFACT: The United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) comprise a set of internationally agreed standards, directories, and guidelines for the electronic interchange of structured data, between independent computerized information systems.
    • BSP-RDM: The objective of this Buy-Ship-Pay Reference Data Model (BSP-RDM) is to describe the requirements for a generic Reference Data Model (RDM), generalizing the concepts of the Multi-Modal Transport Reference Data Model (MMT-RDM) and the Supply Chain Reference Data Model (SCRDM), leading to the development,publishing and improving the maintenance of a Business Standard, which can be applied by country and regional administrations and industries.
Figure 8.5: The black box of the UN/CEFACT standards
Figure 8.5: The black box of the UN/CEFACT standards

To the chapter


8.3 - Scope and variables in Programmes

Limit to programmes that are aware of open portfolio and intend to maximally reuse the resources provided (ref. Figure 8.3, 8.4 and 8.5):

  • by including objectives and indicators in their decision frames;
  • by adopting the standards in their analysis and solution design.
  • ….

To the chapter


8.4 - Scope and Variables in Projects

To the chapter


8.5 - Scope and Variables in Iterations

To the chapter


8.6 - Scope and Variables in the 2030 Agenda

To the case overview - To the chapter


8.7 - Scope and Variables of Library Services

A library is a large collection of books, and can refer to the place in which the collection is housed. Today, the term can refer to any collection, including digital sources, resources, and services. The collections can be of print, audio, and visual materials in numerous formats, including maps, prints, documents, microform (microfilm/microfiche), CDs, cassettes, videotapes, DVDs, video games, e-books, audiobooks and many other electronic resources.

In the International Standard Industrial Classification of All Economic Activities, Rev.4 the activities of libraries are included in #isic9101 - Library and archives activities, and include:

  • documentation and information activities of libraries of all kinds, reading, listening and viewing rooms, public archives providing service to the general public or to a special clientele, such as students, scientists, staff, members as well as operation of government archives:
    • organization of a collection, whether specialized or not
    • cataloguing collections
    • lending and storage of books, maps, periodicals, films, records, tapes, works of art etc.
    • retrieval activities in order to comply with information requests etc.
  • stock photo libraries and services
Figure 8.6: The black box of Library Services
Figure 8.6: The black box of Library Services

The work system pattern in figure 8.7 illustrates the wide range of control and environmental variables and indicators that may be considered in the transition of public library services.

Figure 8.7: The black box of Library Services
Figure 8.7: The black box of Library Services

To the case overview - To the chapter


8.8 - Scope and Variables in the Petrol Station Case

In this case, we assume no external experiences can be relied upon. We follow the steps explained in chapter 6.2.

The Black Box Representation

The input variables are:

  • Environmental variables:
    • the interarrival time of cars
    • the service time of cars
  • Control variables:
    • the queue length
    • (the number of pumps)

The output variables are:

  • the percentage of cars not served
  • the mean waiting time
Figure 8.8: Black-Box representation of the Petrol station example
Figure 8.8: Black-Box representation of the Petrol station example

Assumptions and Givens

No data collection is required, as some information is given on the interarrival times and service times.

G1. the interarrival time of cars is expo(4)

G2. the service time of cars is uniform(1,6)

A1. the business operates 24 hours per day; 7 days per week

A2. no defects of the pumps occur

List of assumptions must be maintained as the study (and the Modeling) proceeds, that is why it is convenient to put it in an annex. In real world projects, all assumptions must be approved by the problem owner.

Is Modeling needed?

System:

  • Single class system
  • No admission control
  • One queue (FIFO)
  • One server
  • in A/B/M/K/N notation: M/G/1/3 system

Are there results available for the M/G/1/3 system? NO!

Can we make any approximation?

Yes: M/M/1/3 system

The Number of Models

There are two models that must be evaluated for the problem owner:

  • the current model with queue length 3 (M/G/1/3; by Modeling)
  • the situation with longer queue length, e.g. 4, 5 or 6 (M/G/1/4; by Modeling)

In addition, for validating the simulation model, an approximate model will be evaluated by queuing theory, and its results will be compared to a simulation experiment with the same properties.

  • the approximate model with queue length 3, and exponentional service times (M/M/1/3; by queuing theory)
  • the approximate model with queue length 3, and exponentional service times (M/M/1/3; by Modeling)

To the case overview - To the chapter


8.9 - Scope and Variables in the Harbour Case

In this case, we assume no external experiences can be relied upon. We follow the steps explained in chapter 6.2.

The Black Box Representation

From the objective it is clear that the mean throughput time has to be determined. This is the output variable, which has to be delivered by the observer. In order to deliver this output variable the observer has to record some items within the simulated system.

At the same time attention must be paid to the output variable from the real system: “departing ships”. There are two control variables, namely the dock allocation strategy and the queue discipline. The environmental variables are the interarrival time, service time and the size of the ship.

Figure 8.9. The black-box description of the harbour case.
Figure 8.9. The black-box description of the harbour case.

The input variables are:

  • Environmental variables:
    • the interarrival time of ships
    • the service time of docks for ships
  • Control variables:
    • the queue discipline
    • dock allocation strategy

The output variables are:

  • the mean throughput time

Assumptions and Givens

No data collection is required, as some information is given on the interarrival times and service times.

G1 …Gn: …

A1. both docks operate 24 hours per day; 7 days per week A2. no maintenance of the docks is required.

List of assumptions must be maintained as the study (and the Modeling) proceeds, that is why it is convenient to put it in an annex.

Is Modeling needed?

Yes, because changing queues cannot be addressed in analytic models.

For validation purposes, and for determining the number of models, lets simplify as follows:

  • dock1 closed to Big ships and dock2 closed to Small ships
  • Use simply a FIFO rule instead of the SPT rule?

Then we obtain two separate queuing systems at dock 1 and dock 2 that behave like M/G/1 systems:

  • Dock 1, with Intearrival times expo(5.5) and Service time time Uniform(3,7)
  • Dock 2, with Intearrival times expo(6.7) and Service time Uniform(2,8)

The Number of Models

For the problem owner four models must be evaluated:

  • the current situation with both kinds of ships served at both docks and SPT;
  • Alternative 1: where ships must be served in the specialized dock, with SPT;
  • Alternative 2: where ships must be served in the specialized dock, with FIFO;
  • Alternative 3: with both kinds of ships served at both docks and FIFO as queue discipline.

For three of these models (current, Alternative 1 and 3) Modeling is required.

In addition, for validating the simulation model, Alternative 3 will be evaluated by queuing theory, and its results can be compared to a simulation experiment with the same properties.

Figure 8.10: The Decision Tree for the Harbour Case
Figure 8.10: The Decision Tree for the Harbour Case

To the case overview - To the chapter


Chapter 9 - Conceptual Models in Research and Leverage (CPIM02b)


9.1 - Introduction to Conceptual Models for Simulation
9.2 - Modeling a Simple Waiting Line Situation
9.3 - General Queuing Systems
9.4 - Performance Measures in Queuing Systems
9.5 - Conceptual Model of Petrol Station Operations
9.6 - The Harbour Case
9.7 - Conceptual Domain Models
9.8 - Conceptual Models in Open Portfolios
9.9 - Conceptual Models in Programmes
9.10 - Conceptual Models in Projects
9.11 - Conceptual Models in Iterations
9.12 - Conceptual Models for the 2030 Agenda
9.13 - Conceptual Models for Library services


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


9.1 - Introduction to the Conceptual Model for Simulation

The conceptual model aims at looking “inside” the black box in order to design aspects of the real system. The model should be accurate so that it is possible to represent all the concepts that may be involved in the digital part of the work system. This step is abstract, in the sense that it is independent of the software or programming language used.

The first part of this chapter is dedicated to the design of the conceptual model for discrete event systems. These conceptual models (Pels and Goossenaerts, 2007) are at the “computation independent model” (CIM) layer of the Model Driven Architecture Chapter 3.6 and in the Comprehensive Simulation Methodology.

Discrete Event Simulation (DES) concerns the simulation of a system as it evolves over time by a representation in which the state variable changes only at a discrete set of points in time. (In more mathematical terms, we might say that the system can change at only a countable number of points in time). These points in time are the ones at which an event occurs, where an event is defined as an instantaneous occurrence that may change the state of the system. Before such a model is implemented in a computer system using computer dependent languages, a conceptual model is build using the UML static structure diagram and a Petri net process model.

Although discrete event systems modeling could conceptually be done by hand calculations, the amount of data that must be stored and manipulated for most real-world systems dictates that discrete-event systems modeling is done in a modeling tool and simulations are done on a digital computer (Law and Kelton, 2000).

DES have been extensively applied by industrial engineers and management scientistse to model manufacturing systems and operational processes. It has now become invaluable in modeling service operations (e.g., banks, restaurants, fast food, emergency rooms), telecommunication networks, transportation systems, semiconductor production, and airline baggage handling systems: American Airlines, Taco Bell, Burger King, Intel, …

There is specialized software for each application area. Such softwares include JaamSim®, ProModel®, MedModel®, Comnet®, Service Model®, ExSpect and others (see Law&Kelton (2000, Chapter 3)). Each simulation environment uses its specific language to describe the modeled system in an executable format. Each language has its specific features that make it straightforward to model some system characteristics and sometimes require work-arounds to model other characteristics.

In this chapter we introduce a general conceptual modeling approach that enables to specify collaborations in a digitally empowered discrete dynamic system in a straightforward and at the same time precise way. This conceptual modeling approach uses Petri nets or BPMN to model the state changes of the system and UML static structure diagrams to specify tot possible states of the system. A logical and set theoretic language is used to specify the state changes in detail.

We use the example of an A/B/m/K/N queue system to illustrate the modeling steps, and to show how these components allow us to bring discrete event systems or transition systems into the decision loop of the manager of the industrial enterprise.

The essence of a simulation model is that the state changes of the system are modeled through time. Hence, it is important to consider how time-flow might be handled within the simulation. Time-slicing and next-event technique are illustrated.

The Basic Modeling/Simulation Methodology that is the de facto standard in handbooks, has some major weaknesses:

  1. It suggests that every modeling problem must be solved in a green field, and relies on extensive dedicated modeling for any problem.
  2. It does not distinguish between different kinds of (less scarce) skills that may be required for the different steps in decision making engagements.

In this section we illustrate ways to overcome these weaknesses in modeling and elaborate the CIM modeling step as part of more comprehensive simulation methodology.

To the chapter


9.2 - Modeling a Simple Waiting Line Situation

Petri Nets or BPMN

Figure 9.1 shows a Petri net for a simple waiting line situation, using the CPN-tools notation. We can read from this model that new clients arrive and have to wait until a server is available. If a client and a server are both available they are both put in the Served state. When the service ends the server is returned to the Free place and the client is put in state Served. From the perspective of a A/B/m/K/N queue system non of the parameters have been specified yet, except that in this model the queue capacity K and the population N are infinite.

We use the CPN-tools notation to specify the process structure as a BPMN in terms of places, transitions and arcs. Also we specify the types of the places (as label of the place) and the variable names (as label of the input arcs) that will be used in the transition specifications. Although CPN-Tools is quite well able to express all other details, we regard these as platform specific notations. For the Computation Independent Model we prefer UML as a well suited tool to specify the object classes that define the colors of the tokens. We use set theory and predicate logic to specify transitions. The following section shows how the UML static structure can add quite some detail.

Figure 9.1: Petri net for simple waiting line situation.
Figure 9.1: Petri net for simple waiting line situation.

UML static structure diagrams

The basic concepts in the Petri net terminology are tokens and places. In the UML static structure diagram in Figure 9.2 they are defined as the object classes Token and Place. The association Token-Place expresses the basic property that any token is at any point in time in exactly one place. A place can hold zero or more tokens. Since queues are a central concept in Discrete Event simulations and queues are modeled as places in Petri nets, Place has the derived attribute Length, First and Last, holding the number of tokens in the place, the one that arrived first and the one that arrived last.

In order to be able to select a first and last token from a place, Token has the attribute ArrTimeInPlace, that is supposed to be updated implicitly by the generic simulation mechanism that is assumed behind the conceptual model. The main object classes of this mechanism are Clock and Random. Clock has an attribute Time that holds the current system time at any moment and that is incremented implicitly. For the interpretation of the conceptual model it may be supposed that this time is incremented with a sufficiently small step so that any moment time when a time-dependent precondition of any transition becomes true, it occurs in the clock. The object Random represents the random generation mechanism that is used in simulations to generate stochastic values for parameters like arrival time and service time. For this purpose it has the attribute Seed to set the starting condition of the generator and the procedures Draw, Uniform, Negexp, Normal to generate different distributions. Every time one of the operations is executed, a new number is produced.

Figure 9.2: UML static structure diagram for simple waiting line simulation.
Figure 9.2: UML static structure diagram for simple waiting line simulation.

In Figure 9.1 we see that two types of tokens travel through the system: clients and servers. In the second row of the diagram we find these specified as classes Client and Server. The behaviour of a client is determined by his arrival time, service time and waiting time. These are modeled as the attributes ArrivalTime (distinct from ArrTimeInPlace), ServiceTime and WaitingTime. For the behaviour of a server it is important to know the end time of the current operation. This is represented in the attribute EndTime. An important performance indicator is the occupation degree. To enable to calculate this, Server has the attribute BusyTime. Whether a server is free or busy at any moment can be read from the place where it resides.

The behaviour of a model depends on the initial state. This is defined by specifying the objects that are initially in the system:

  • c1: a client with ServiceTime = 4, that will arrive at time 1. The initial value of WaitingTime is not relevant.
  • c2: a second client with ArrivalTime = 3 and ServiceTime = 5,
  • s1: a server with BusyTime = 0,
  • now: a clock; a simulation needs only one clock. The actual system time is denoted as now.Time,
  • r: a random generator. Some models required different random generators for independent series of random values. A random number between 0 and 1 is obtained with r.Random. A number from a Uniform distribution between 5 and 7 is obtained with r.Uniform(5, 7).

So far the UML diagram Figure 9.2 and the objects that are initially in the system define the state space of the model. The tokens in the initial state are specified in the lowest row in Figure 9.2. The Petri net specifies what are the transitions and on what combinations of tokens they operate. The typing of the places specifies the object class of the tokens that are in the place. Places can hold single tokens, like in Wait, or tuples (ordered sets) of tokens, like Served. The following section describes how transitions are specified.

Transitions

Transitions are specified by means of a Pre- and a Post-condition. The pre-condition tells under what conditions the transition must take place. The general Petri net condition that a token must be available in each input place is implicit and needs not to be specified. The variable names that label the input arcs are used in the pre-condition and refer to an arbitrary token from the corresponding input place. The transition fires when a set is found consisting of one token from each input place for which the pre-condition holds. In the pre-condition it is allowed to refer not only to the input objects (like in CPN), but to any object in the current state, including clock and random objects.

The post-condition must hold for the state of the system after the transition. The new state is specified with reference to the old state. The post-condition is a predicate that must hold for the new state and the implementation of the model is free to choose any state that satisfies this condition. However, in order to keep the specification as simple as possible we add a few rules:

  • Any variable that is not mentioned in the post-condition remains unchanged,
  • Where the <- operator is used, all variables in the right operand refer to the old state, while the left operand is the place that holds the token resulting from the right operand,
  • Where the := operator is used the left operand is a variable (instance of a certain class) that in the new state has the value resulting from the right operand, in which all variables refer to the old state,

In the pre- and post-condition we use OCL (Object Management Group, 2005) for expressing the conditions.

The following shows the transition specification that complements the Petri net and UML diagram of Figure 9.1 and Figure 9.2 into a complete conceptual model.

 1 Start
 2 c1.Place = NewClient  &
 3 c2.Place = NewClient  &  
 4 s1.Place = Free &
 5 s1.BusyTime = 0;
 6 
 7 Arrive
 8 Pre 	c.ArrivalTime = now.Time
 9 Post	Wait <- c;
10 
11 StartServe
12 Pre	c = Wait.First
13 Post	Serve <- (s, c)  &
14         s.EndTime := now.Time + c.ServiceTime     &
15         c.WaitingTime := now.Time - c.ArrivalTime   &
16         s.BusyTime := s.BusyTime + c.ServiceTime;
17 
18 EndServe
19 Pre	now.Time = s.EndTime
20 Post	Served <- c   &
21         Free <- s;
22 
23 Functions
24 NrServed = Served.Length;
25 AverageWait =  sum(c in Served: c.Waitingtime) / NrServed;
26 Occupation = s1.BusyTime / now.Time * 100;
27 EndTransitions

In this transition specification there is a block for each transition in the Petri net. There are three additional blocks: Start, Stop and Functions.

Start holds the pre-condition for the process as a whole. In this case it specifies the places of the initial tokens.

Stop specifies the condition for which the process ends. In this case stop is not included because the process stops by itself as the number of clients is limited (2).

Under Functions a number of functions is specified that can be used as shorthand in other expressions or to define the output variables of the system. Often these are aggregate functions, which means that they are calculated over a set of objects. The general format of such functions is

1 Functionname(range: expression).

In the function AverageWait this is applied with:

1 Functionname: sum
2 Range: c in Served (clients in place Served)
3 Expression: c.Waittime (waiting time of served client).

Other well known aggregate functions like average, minimum, maximum etc. are assumed to be predefined.

In this simple model it is easy to describe a trace of the model execution:

  1. at time 1 client c1 arrives, moves to Wait, is combined with s1 and moves to Serve.
  2. at time 3 client c2 arrives and moves to Wait,
  3. at time 5 client c1 finishes serving and is moved to Served. Server s1 moves to Free. Client 2 is combined with s1 and together they are moved to Serve,
  4. at time 10 client c2 finishes serving and is moved to Served. Server s1 moves to Free.

Since nothing else is going to happen, the simulation process ends here.

1 NrServed = 2,
2 AverageWait = 0,5,
3 Occupation = 90 (%).

Generating arrivals

In the example above all clients that act in the simulation are put in the NewClient place at initialisation time. In most system models clients will be generated during the process. The Petri net in Figure 9.3 shows the extension that does so.

Figure 9.3: Simple queuing system with client generator.
Figure 9.3: Simple queuing system with client generator.

There are several changes to our model.

Evidently, there is an additional arc from Arrive to NewClient. This means that transition Arrive must be respecified:

1 Arrive
2 Pre 	c.ArrivalTime = now.Time
3 Post	Wait <- c   &     
4         NewClient <- n   &
5         n.ArrivalTime := now.Time+r.Negexp(5)  &
6         n.ServiceTime := r.Uniform(3,6);

This means that every time a client arrives and is put in the wait queue, a new client is created and put in NewClient with new values for arrival time and service time. That n is a token of class Client (see Figure 9.2) is (implicitly) derived from the color of place NewClient. That a new token is created in Arrive is reflected in the naming of the incoming and outgoing arcs. Because we model operational processes, we assume conservation laws for the tokens and their (role-) naming. Hence, the incoming token will proceed to Wait. Moreover, the presence of an outgoing arc with a new name indicates the creation of a new token in Arrive. Note that these interpretations deviate from those in simulation tools, but are acceptable for operational processes and convenient for conceptual modeling.

This example shows that new tokens are created when a (role-) name is used for an ouput arc that does not correspond to an input role-name (variable name). The type of the token is defined by the type of the output place and the values of its attributes can be specified using the := operator.

Other changes are to the UML static structure diagram, and the specification of the initial state by declaring instances of classes Client and Server. In this case, there must be an initial client “ci” at place NewClient in place of the c1 and c2 (as in Figure 9.2). Hence the start transition must also be modified.

1 Start
2 ci.Place = NewClient  &
3 s1.Place = Free;

It is agreed that dynamically created tokens (such as those in the n-role in Figure 9.3) are not declared in the UML static structure diagram of the system model.

Another situation where conservation laws are relied upon to explain the meaning is when a transition has one incoming and two outgoing arcs with identical labels. In this case, the incoming token will move on either of the outgoing arcs. Conversely, two incoming and one outgoing arc with identical labels (e.g., c) indicates that the c-role token can come from either place connected through the incoming arcs.

Moving the clock

In the previous section we introduced the clock as an object class with attribute time and stated that in the conceptual model the advancing of the clock is “implicit” and thus needs not be specified explicitly in the conceptual model. It must however be understood how the clock mechanism is organised in a discrete event simulation.

An event is defined as an instantaneous occurrence where the state of the system changes. At the occurrence of an event the clock is set to the time of the event. After changing the state of the system according to the transition specification, the system must be able to determine the time of next event. It sets the clock to that time and handles that event etc. The simulation stops when no next event can be determined. This explains how the clock jumps in discrete steps from one event-time to the other. Essential for this mechanism is that at any time at least one next event-time must be known.

In a Petri net events are associated with transitions. The firing of a transitions is the same as an event. The class of events associated with a particular transition is called an event type. This means that in the model of Figure 9.1 there are three event types:

1 Arrival: the arrival of a client,
2 StartServe: the start of servicing a client
3 EndServe: the completion of servicing a client

By initialising the system with two clients with known arrival times in the NewClient place, the times of the two arrival events are defined: 1 and 3 time units. After initialisation the system can set the clock directly to the first of them: 1 time units.

Handling the arrival event according to transition Arrival means that the client is placed in place Wait. This transition enables the transition StartService, so a third event is scheduled at the same time: the StartService transition sets the EndTime of the server and so defines the fourth event: the EndService of the first client at time point 5. Now the system has two next events: the arrival of the second client at time 3 and the departure of the first client at time 5. Of all scheduled events the 2nd arrival comes first: the clock is set to 3 and the second client is moved to place Wait. Then the clock can be moved to the only remaining event: the EndService of c1 at time point 5.

Returning the server to place Free enables the StartService transition for the waiting c2, so this becomes the next event at the same time. Handling this event means assigning a value to the EndTime of the server and thus defining the time of a new EndService event at time 10. The clock is set to 10. Since the Wait place is empty there is no new event to be defined and thus the simulation stops.

It is easy to see that new event times are defined each time a token is put in a place that is input to a transition with a time dependent pre-condition. Transitions without a time related pre-condition can only occur at the same time as another transition. Therefore in some DES approaches only time related transitions are considered as event types. From this point of view the model in Figure 9.1 has only two event types: Arrival and EndService. The transitions StartService has no time in its pre-condition and thus can only occur in combination with an Arrival or an EndService. In the Petri Net approach however we must consider a simultaneous arrival and startservice as distinct events, because in the interpretation of the second transition the end state of the first transition is taken as old state. This means that a set of events that occur at the same point in time, is still ordered in time for the interpretation of their transition rules. This is assured by considering the subsequent event as to be defined by the preceding event. As long a time is defined as a high precision real, it is very unlikely that two time-related events occur at exactly the same point in time. If it might happen the sequence of handling is undefined and left to the implementation.

In the model of Figure 9.3 each arrival generates its next arrival. This means that as long as the server is busy there are always two future events defined: the next arrival and the next end service. If the server is free there is only the next arrival. This simulation will never end. To define an end to such a process a Stop transition can be added to the list of transitions. If the process had to run for 24 hours and the time unit is one minute, then stopping condition would be formulated as:

1 Stop
2 Pre  now.Time = 1440
3 Post …

The post condition can be used to handle some round-ups of output variables.

The time advancing method as described in this section is known as the next event technique. Another technique is known as the fixed increment time advance technique. Here the time is incremented in fixed steps and after each step all transitions are checked whether they should have fired in the past period. This technique is suitable for models that are based on differential equations, which means that the changing of certain variables is defined in terms of its time-derivative. This type of variables is not further treated here. More details are in Law&Kelton (2000, p. 93-94).

To the chapter


9.3 - General queuing systems

In this section we represent an A/B/m/K/N system using the Petri net notation, and explore how the system behaviour can be represented in suitable object classes constructs for the various places. The main purpose of this model is to convey insights on the dynamics in the queuing system, and how to observe this dynamics. We repeat the definitions of the notation:

  • A: Inter-arrival time distribution
  • B: Service time distribution
  • m: number of servers present
  • K: storage capacity of the queue. If K is omitted, then K is infinite.
  • N: finite population of customers (or closed queuing systems). It is the number of customers in the system, they never leave the system. If N is omitted the system is open, there is an infinite population of customers: the system is accessible to any customer from the outside world wishing to be served.

Some values for A and B:

  • M (Markovian): negative exponential distribution
  • G (general): not a known distribution
  • D (Deterministic): constant value.
Figure 9.4:  General Queuing System.
Figure 9.4: General Queuing System.

Figure 9.4 shows the general structure of a queuing system. Below we will show how the different parameters can be modelled.

The data structure needs some extensions:

  • The clients need a number in order to be able to recognize them,
  • Servers need a number to recognize them,
  • A queue with limited capacity is needed as specialisation of Place,
  • A place representing the fixed population, for which the same specialisation can be used.

Figure 9.5 shows the UML static structure for a general queuing system with m = 4 and N = 100.

Figure 9.5: UML Static Structure for general queuing system.
Figure 9.5: UML Static Structure for general queuing system.

The transition specifications for the general queuing system can be specified as follows:

 1 Transitions
 2 Start	c1.Place = New &
 3 Wait.k := 4  &
 4 Population.k := 100  &
 5 c1.Arrivaltime := r.NegExp(5);
 6 
 7 CreatePopulation
 8 Pre	c.Nr ? Population.k
 9 Post	Population <- c  &
10         New <- d  &
11         d.Nr := c.Nr + 1   &
12         d.ArrivalTime := c.ArrivalTime + r.NegExp(5)  &
13         d.TotalServiceTime := 0   &
14         d.TotalWaitingTime := 0   &
15         d.TimesServer := 0   &
16         d.TimesUnserved := 0;
17 
18 Arrive
19 Pre	c.ArrivalTime = now.Time
20 Post	If 	Wait.Length < Wait.k
21         Then	Wait <- c  
22         Else	Gone <- c   &
23                 c.TimesUnserved := c.TimesUnserved + 1;
24 
25 StartServe
26 Pre c = Wait.First
27 Post	Busy <- (c, s)  &
28         s.EndTime := now.Time + r.Uniform(3,6) &
29         s.BusyTime := s.BusyTime + s.EndTimenow.Time  &
30         c.TotalWaitTime :=  c.TotalWaitTime + now.Timec.ArrivalTime;
31 
32 EndServe
33 Pre	now.Time = s.EndTime
34 Post	Free <- s  &
35         Gone <- c &
36         c.TimesServed := c.TimesServed +1;
37 
38 Return
39 Post	If 	Population.Length = 0 
40         Then	c.ArrivalTime := now.Time + r.NegExp(5)
41         Else	c.ArrivalTime:=Population.Last.ArrivalTime+ r.NegExp(5);
42 Endtransitions

To the chapter


9.4 - Performance Measures in Queuing systems

The purpose of simulation is to study the behaviour and the performance of the system. Depending on the problem to be solved, we are interested in specific performance parameters of the system. Therefore we must carefully define these parameters. In the Computation Independent Model this can be done by specifying these parameters as functions of the system state. Thus the value of each performance parameter is defined at any point of time during the Modeling. In most cases we will be interested in these values in particular at the completion time of the process.

The measurement gives us a view on the system state and enables us to evaluate the performance of a given system. When we are dealing with a queuing system, the main purpose is to know the effectiveness of such a system.

Some performance measures can be expressed as discrete values. Examples are:

  • the total server idle time during the “experiment”
  • the maximal flow time
  • the number of entities not admitted

For other performance measures, aggregate values over certain sets of clients are used. This often requires that specific attributes are assigned to different token classes. Examples are:

  • The maximum time waiting in queue: for which you need to define the attribute “waiting time in queue” for each client,
  • Lengthq : Length of the queue (max, average) in order to evaluate the queue capacity (too small, large, or suitable). This requires a value of the queue length as encountered by each client,
  • The utilization of a machine: the proportion of time a machine is busy during the simulation: requires the cumulated service times,
  • The total server idle time: the proportion of time a machine is idle during the simulation,
  • The number of parts that finish being processed on a server and leave the system: requires that all relevant clients are collected in a specific end place.
  • The flowtime of parts that finish being processed on a server and leave: flowtime also called cycle time or througput time, for a part is the time that elapses between its arrival and its departure: requires values for e.g. arrival time, wait time and service time for each client.

Example: Consider the operation of a two teller bank where customers arrive for service. The queue has a capacity of 10. The performance indicators that must be computed are: the average percentage of idle time for all tellers (AvgPercIdleTime), the average waiting time of the admitted customers (AvgWaitingTime), and the percentage of customers not admitted (PercNotAdm).

Solution: For computing AvgPercIdleTime we assign class Teller the attribute BusyTime. Then the percentage is defined with the function:

1 AvgPercIdelTime = sum(s in Teller: now.Time – s.BusyTime) / 2 * 100

The average waiting time per customer requires that each customer has an attribute WaitingTime and that each served customer is kept in a place Served. The function then is defined as:

1 AvgWaitingTime = sum (c in Served: c.WaitingTime) / Served.Length

For computing PercNotAdm we must keep the not admitted customers in a place NotAdm and the served customers in a place Served. The function can then be defined as:

1 PercNotAdm = NotAdm.Length / (NotAdm.Length + Served.Length) x 100. 

To the chapter


9.5 - Conceptual Model of Petrol Station Operations

In this part we describe the example of a petrol station. The aim is to model and simulate a petrol station with one petrol pump on a traffic route (see Figure 9.6).

Three cars at most can wait for petrol filling at the petrol pump. The owner of the petrol station has the feeling that some potential clients are leaving the station because there is no place to wait for service. But he doesn’t know how far this assumption is true. So he would like to know what is the influence of the capacity size of the pump on the percentage of cars leaving without being served.

The cars in the queue follow a First In First Out Rule (FIFO).

Figure 9.6: A petrol station.
Figure 9.6: A petrol station.

The research questions are:

  • What is the percentage of people that leave without being served?
  • What is the average waiting time of served customers?

The experimental values for the arrival times and the service time for ten cars are given in Table 9.1.

Table 9.1: Arrivals and process time for ten cars.

Car number Inter Arrival time Service time
1 9 4
2 5 5
3 1 6
4 2 3
5 1 2
6 2 1
7 1 4
8 5 2
9 1 1
10 2 1

The system can be recognized as a G/G/1/3 system (G because no specification of a particular distribution on arrival and service times is given. The Petri net for this system can be derived from Figure 9.4 and is presented in Figure 9.7.

Figure 9.7: Petri net of the Petrol Station.
Figure 9.7: Petri net of the Petrol Station.
Figure 9.8: UML diagram for Petrol Station.
Figure 9.8: UML diagram for Petrol Station.

The UML diagram for the pump is shown in Figure 9.8. It is derived from the general queue diagram in Figure 9.5 by leaving out irrelevant details. The diagram does not show the initial cars, since it is unpractical to draw larger numbers of objects in data structure diagrams. A table is much more convenient form as shown below in the Start specification under Transitions. Note that in this table the inter arrival times from Table 9.1 have been transformed into arrival times.

1 Transitions
2 Start
3 Coming = 
Object ArrivalTime ServiceTime
c1 9 4
c2 14 5
c3 15 6
c4 17 3
c5 18 2
c6 20 1
c7 21 4
c8 26 2
c9 27 1
c10 29 1
 1 Arrive
 2 Pre	c.ArrivalTime = now.Time
 3 Post	If 	Wait.Length < Wait.k
 4         Then	Wait <- c 
 5         Else	DriveOn <- c;
 6 
 7 StartServe
 8 Pre	c = Wait.First;
 9 Post	Busy <- (c, p) &
10         p.EndTime := now.Time + c.ServiceTime &
11         p.BusyTime := p.BusyTime + p.EndTimenow.Time  &
12         c.WaitTime :=  now.Timec.ArrivalTime;
13 
14 EndServe
15 Pre	now.Time = p.EndTime
16 Post	Free <- p  ?
17         Served <- c;
18 
19 Function
20 PercUnServed = UnServed.Length/(Unserved.Length+Served.Length) *100; 
21 AvgWaitTime = sum (c in Served: c.WaitTime)/Served.Length;
22 EndTransitions

To the case overview - To the chapter


Hand Simulation

Using those variables we can now develop the Hand simulation (Table 9.2). In the columns we specify the different variables that make up the state. Each row represents an event. The columns specify the event time, the car that causes the event, the transition that fires, the end time of the pump, the content of the queue, the waiting time of the car (specified only once for each served car, so that the column can be summed) and finally the contents of places Busy, Free, Served and DriveOn.

Table 9.2: Hand simulation.

now. car Transition p.End- Wait c.Wait- Busy Free Served         DriveOn  
Time     Time     Time        
9 c1 arrive   c1     p1      
9 c1 startserve 13   0 (c1, p1)        
13 c1 endserve 13       p1 c1    
14 c2 arrive   c2     p1 c1    
14 c2 startserve 19   0 (c2, p1)   c1    
15 c3 arrive 19 c3   (c2, p1)   c1    
17 c4 arrive 19 c3, c4   (c2, p1)   c1    
18 c5 arrive 19 c3, c4, c5   (c2, p1)   c1    
19 c2 endserve 19 c3, c4, c5     p1 c1, c2    
19 c3 startserve 25 c4, c5 4 (c3, p1)   c1, c2    
20 c6 arrive 25 c4, c5, c6   (c3, p1)   c1, c2    
21 c7 arrive 25 c4, c5, c6   (c3, p1)   c1, c2 c7  
25 c3 endserve   c4, c5, c6     p1 c1, c2, c3 c7  
25 c4 startserve 28 c5, c6 8 (c4, p1)   c1, c2, c3 c7  
26 c8 arrive 28 c5, c6, c8   (c4, p1)   c1, c2, c3 c7  
27 c9 arrive 28 c5, c6, c8   (c4, p1)   c1, c2, c3 c7, c9  
28 c4 endserve 28 c5, c6, c8     p1 c1, c2, c3, c4 c7, c9  
28 c5 startserve 30 c6, c8 10 (c5, p1)   c1, c2, c3, c4 c7, c9  
29 c10 arrive 30 c6, c8, c10   (c5, p1)   c1, c2, c3, c4 c7, c9  
30 c5 endserve 30 c6, c8, c10     p1 c1, c2, c3, c4, c5 c7, c9  
30 c6 startserve 31 c8, c10 10 (c6, p1)   c1, c2, c3, c4, c5 c7, c9  
31 c6 endserve 31 c8, c10     p1 c1, c2, c3, c4, c5, c6 c7, c9  
31 c8 startserve 33 c10 5 (c8, p1)   c1, c2, c3, c4, c5, c6 c7, c9  
33 c8 endserve 33 c10     p1 c1, c2, c3, c4, c5, c6, c8 c7, c9  
33 c10 startserve 34   4 (c10, p1)   c1, c2, c3, c4, c5, c6, c8 c7, c9  
34 c10 endserve 34       p1 c1, c2, c3, c4, c5, c6, c8, c10 c7, c9  
1 Length (Served) = 8
2 Length (DriveOn) = 2
3 PercUnServed = 20%
4 sum(c in Served: c.WaitTime) = 41
5 AvgWaitTime = 5,125

Explanation of the table:

  • At time T= 9 the first car arrives. It goes directly to the pomp since the queue is empty and the pump free. C1.WaitingTime := 0. The endtime of the pump is set to 13.
  • At time T=13 the first car ends its serving and moves to place Served. The pump moves to Free.
  • At time T=14, a second car arrives in the system. At the same time it starts serving since the pump is free. Its waiting time is set to 0 and the end time of the pump is set to 19.
  • At T = 15, the third car arrives. Since the pump is not free, this third car has to wait.
  • Same thing for the next two cars arriving.
  • At T = 19 the second car has been completely fuelled. It moves to Served and the pump becomes free. This sets the conditions for the start of serving the third car, for which the waiting time is set tot 4.
  • At time T = 21, something new happens. The arriving seventh car finds the queue filled to its limit, so it moves to the Unserved place.
  • The same situation occurs at time T = 27.
  • At time t = 29 the last car arrives in the system and goes in the queue.
  • T = 30, 31, 33 and 34: endservice events that move a car to place Served.

If the output variables are calculated now we find:

  • Length (Served) = 8
  • Length (DriveOn) = 2

It is now possible to calculate some variables:

  • The percentage of cars leaving the system without being served is = 100.2/10 = 20%
  • The average waiting time in the system is = 41/8 = 5,125

Note that this Hand simulation is only intended for understanding the behaviour. We have too few cars to make any statistical conclusions about the behaviour of the system.

To the case overview - To the chapter


9.6 - The Harbour

A harbour can host two types of ships: Small and Big. Small ships arrive with inter arrival times exponentially distributed with a mean of 5,5 hours. Big ships arrive with inter arrival times exponentially distributed with a mean of 6,7 hours. There are two docks (dock1 and dock2) at this harbour where ships can be unloaded. Small ships are unloaded at dock1 with a service time uniformly distributed between 3 and 7. Big ships are unloaded at dock2 with a service time uniformly distributed between 2 and 8.

If dock1 is empty and there are Big ships waiting for dock2 then a Big ship can go to dock1 and is served with 1,5Uniform(2,8). If dock2 is empty and there are Small ships waiting for dock1 then a Small ship can go to dock2 and is served with 2Uniform(3,7).

For both docks the queue discipline is SPT (Shortest processing time first).

The management team of the harbour wonders if closing dock1 to Big ships and dock2 to Small ships would not improve the mean expected throughput time of ships at the harbour. Another question is if it is not better to use simply a FIFO rule (First In First Out) instead of the SPT rule? How can we help the management team to get answers to their questions?

The black box representation of this problem is shown in Figure 8.7.

Figure 9.9 shows a model of operational process in a Petri net model.

Figure 9.9: Petri net model of Harbour.
Figure 9.9: Petri net model of Harbour.
Figure 9.10: UML diagram of Harbour.
Figure 9.10: UML diagram of Harbour.

With the UML specification of Figure 9.10 the transitions of the model can be specified as below.

 1 Transitions
 2 Start 	s1.Place = NewSmall  &
 3         s2.Place = NewBig  &
 4         d1.Place = FreeSmall  &
 5         d2.Place = FreeBig;
 6 
 7 ArriveSmall
 8 Pre	s.ArrivalTime = now.Time;
 9 Post	If  	FreeBig.Length > 0 ? WaitSmall.Length = 0 
10         Then	WaitSmall <- s 
11         Else	WaitBig <- s  &
12                 s.ServiceTime := s.ServiceTime * 2
13         Endif
14         NewSmall <- n   &
15         n.ServiceTime := r.Uniform(3, 7)  &
16         n.ArrivalTime := now.Time+r.Negexp(5.5);
17 
18 StartSmall
19 Pre	t.ServiceTime = Min(s ? WaitSmall: s.ServiceTime)
20 Post	ServeSmall <- (t, d) &
21         d.EndTime := now.Time + t.ServiceTime  &
22         d.BusyTime := d.BusyTime + t.ServiceTime  &
23         t.WaitingTime := now.Time - t.ArrivalTime;
24 
25 EndSmall
26 Pre	now.Time = d.EndTime
27 Post	Served <- t _ &
28         FreeSmall <- d;
29 
30 ArriveBig
31 Pre	s.ArrivalTime = now.Time;
32 Post	If  	FreeSmall.Length > 0 ? WaitBig.Length = 0 
33         Then	WaitBig <- s
34         Else	WaitBig <- s  &
35         n.ServiceTime := n.ServiceTime * 1.5
36         Endif
37         NewBig <- n  &
38         n.ServiceTime := r.Uniform(2, 8)   &
39         n.ArrivalTime := now.Time+r.Negexp(6.7);
40 
41 StartBig
42 Pre	t.ServiceTime = Min(s ? WaitBig: s.ServiceTime)
43 Post	ServeBig <- (t, d) _ &
44         d.EndTime := now.Time + t.ServiceTime   &
45         d.BusyTime := d.BusyTime + t.ServiceTime   &
46         t.WaitingTime := now.Time - t.ArrivalTime;
47 
48 EndBig
49 Pre	now.Time = d.EndTime
50 Post	Served <- t   &    FreeBig <- d;
51 
52 Functions
53 MeanTPT = sum(c in Served: c.WaitingTime+c.ServiceTime)/Served.Length;
54 EndTransitions

This model does not specify a stop condition, since the run length has not yet been decided. It only models the SPT case with switching docks. This operational process has to be compared with alternatives:

  • First alternative: stop switching docks. This means that the Arrival processes are simplified.
  • Second alternative: change SPT into FIFO. This requires that Start processes are changed.

To the case overview - To the chapter


9.7 - Conceptual Domain Models

The formal approach to systems modeling (Van Hee, 1994) offers a sound theoretical basis for a much wider range of CIM models. In the approach the combined use of object and transition system specification techniques has been well established. Today, UML domain modeling techniques offer a standard for modeling the entities that occur in the universe of discourse associated with any service or information system. The possible states of a (work) system and (relevant parts of) its environment are represented by a(n infinite) set of object-diagrams (or token models), in which each object is instance of one or more classes. Any enterprise information system will include representations of those entities and of the business events.

A socio-economic event causes a change of the state-of-affairs. Socio-economic events are classified according to their level in the multi-level perspective. Landscape events include the enactment of a new rule, the occurrence of a disaster such as a storm or earthquake, or the discovery of a new law of nature. Examples of sector events are a financial meltdown, the enactment of a new industry standard, or the granting of a patent. Interactions among enterprises consist of business events. Finally, life events are punctuated events in the life of a person or another individual.

Where interactions among persons and businesses give rise to a conflict, the coping with the conflict in a court signifies an escalation of the “course of life or business events” to the landscape level.

Especially for frequent business events and life events, information systems have been deployed that computationally reflect the change of the state-of-affairs inherent to the event. The meaning of the event maps to a token model being transformed, for instance in its representation by data and content. That such computational reflection is less common or evident for sector and landscape events must not imply that domain models are not relevant for the corresponding levels. Commercial contracts, tax and value-added tax regulations determine patterns and constraints for commercial interactions that move and transform material, content and financial resources.

For centuries information systems have been embodied as document flows and archives. An increasing number of companies and agencies have – singly and severally – introduced information systems to support their own data processing and content requirements. After establishing a dominant position in the intra-enterprise dealing with content, computers and internet are now key to the re-engineering of business-to-business and business-to-government interactions (Aerts et al., 2004).

Commercial contracts, Incoterms and (value-added-)tax regulations are defined in reference to a number of common stakeholder types and situational entities engaged in the unfolding of a commercial transaction.

Why Meso-level CIM Models in a CPIM?

The ongoing digitization of the interactions among public and private sector entities calls for architecture specifications that capture the ontological and regulatory commonalities at the landscape and sector levels, and for the governance and management of the reuse relationships among the specifications.

In the past certain cross-enterprise commonalities had been captured in enterprise-wide (data) models (Scheer, 1989) that have become a thrust in ERP-system realization. Many reference models have been created in the proprietary domain.

In the multi-level perspective, architecture descriptions could exist at the micro, meso and macro levels. They are then called enterprise, sector and landscape models. Refinement and instantiation relationships could be established among the models at the different levels.

At each socio-technical level, and for each stakeholder, the architecture descriptions aid in articulating the functional requirements both for the operational processes and work systems. At the macro and meso level, the landscape and sector models allow for the pattern-based expression of regulations and other interaction patterns. Such expressions serve as unambiguous requirements that must be met by enterprise models at the micro level.

For the proof-of-concept in this book, architecture descriptions are elaborated for the socio-economic landscape, business, sectors and households.

How to correctly join business processes to micro-level domain data descriptions to drive solution implementations in a multi-level perspective has been the focus of Goossenaerts et al (2009) which elaborated the case of Value-Added-Tax implementation and regulation (Zegers, 2007).

Table 9.3 Stakeholders in the ERP-VAT value constellation

Actor (level) Description                                                    
VAT regulations (regulator) (macro) Value Added Tax rules are enacted in many countries. In the European Union, the member VAT rules are harmonized in accordance with a number of directives. VAT is a general consumption Tax which is indirect: the taxation takes place at the supplier of the consumer.
Tax authorities (meso) The Tax authorities are the executive body that implements the VAT regulations. It is responsible for collecting and remitting the tax payments. The Tax authorities prefer that companies can easily and accurately complete their Tax declarations, and that companies and citizens are willing to do so. They must cope with criminal attacks on the VAT system, such as the “Missing Trader intra-community” (MTIC) VAT fraud.
ERP users with exposure to complicated VAT situations (micro) These are firms that deploy ERP-systems in support of their business processes. If a firm exhibits several of the following aspects, it has a higher exposure to complicated VAT-situations: many establishments in different countries, supply to foreign clients, large number of clients, different types of establishments, distributive trade activities, the combination of supply of goods and services, large amount of different products, supply to own company in different countries.
VAT-ERP specialists (meso/micro) EDP-Auditors, Tax, VAT, ERP, business consultants.
ERP vendors (micro) Providers of specialised software for enterprise operations, including sales, purchasing and logistics.

Table 9.4 Stakeholder Objectives affected by a new VAT-ERP compliance regime

Actor Actor Objective affected (Balanced Score Card dimensions: F(inancial), I(nternal processes),                       
  C(ustomers) or L(earning and growth) over horizon                                    
  (S: strategic; T: tactical; and O: operational)                                                 
VAT regulations (regulator) C: non-ambiguity for the subjects; completeness; guarantee the public interests
  I: stay up-to-date with developments; continuous knowledge acquisition
  L: continuous evaluation of societal changes; achieve low complexity
Tax authorities (meso) F: efficient deployment of means; minimize VAT losses due to fraud
  C: improve the customer satisfaction; contribute to ease of meeting fiscal duties
  I: optimizing the use of ICT; efficiency and effectiveness; encourage collaboration with third parties; improving efficiency of mass processes
  L: working in the actual environment; improve the quality of service; strengthening the civil servant competences
ERP users with exposure to complicated VAT situations (micro) F: Return on Investment; reduce costs; increase turnover; reduce risks of fines and double taxes
  C: customer satisfaction
  I: compliancy of the systems that support the business processes, in particular of ERP systems; efficiency of the business processes
  L: employee productivity and efficient response to change
VAT-ERP specialists (meso/micro) F: increase turnover
  C: offer multi-disciplinary services; pro-activity; investment in sustainable customer relations
  L: continuous actualising of knowledge in the fiscal area
ERP vendors (micro) F: improve market value (S); increase turnover (T); reduce costs (O)
  C: meet requirements of (new) customers; proactive identification and meeting of customer demand (T); efficiency in meeting customer requirements (O)
  I: routinely responding to changes in the environment (S); improve tactical decision making (T); efficiency in process improvements (O)
  L: routinely absorbing of changes (S); ensure that employees take effective decisions (T); increase productivity (O)

In current institutional change practices, rule changes follow from governmental measures and give rise to a specific transition pathway in which textual descriptions are the main carriers of meaning. The reverse charge derogation to counter the MTIC VAT fraud illustrates the regime. In a consultation with stakeholders, the proposed measure is discussed and amended, leading to a “text-only” announcement of a new rule or a rule change with an effective date from which all enterprises must comply. ERP vendors can reflect the new rule in a new version of their system, or customers, supported by specialists in the affected areas and systems, must modify their customizations.

System users, their vendors, and consultants must cope with a variety of problems when responding to change. For instance, in the VAT-ERP regime, interviews with stakeholders, resulted in the problem-oriented interrelationships digraph model in Figure 9.11. The digraph shows dependencies among problems, including the horizon in which problems are manifest (strategic, tactical or operational) for the micro-level project activities (Zegers, 2007), as included in Goossenaerts et al (2009).

Figure 9.11: Problem Interdependencies in the VAT-ERP compliance regime
Figure 9.11: Problem Interdependencies in the VAT-ERP compliance regime

The factor landscape in Table 9.5 depicts factors and interdependencies in the VAT-ERP domain. Upperlevel stakeholders (macro and meso level) have choices to influence the exogenous factors of all sub-level principals (micro and pico). At each level ownership of assets gives rise to motives to improve the assets’ value-creating and risk-reducing effectiveness. Where such ownership is missing or unclear, there often is negligence of the asset (the prevalence of the collective action dilemma in the public good game (Fehr and Schmidt, 1999), (Markus et al, 2006).

Table 9.5 Factor Landscape: Meso-level Gaps with Micro-level Consequences

The contrast between stakeholders’ objectives and their group performance regarding compliance underscores the statement that the prevailing compliance regime is less effective than it could or should be. The elaboration of the solution direction has been guided by the vision of scaling up and out, enterprise architecture practices that are already effectively used within organizations.

The stakeholder observations are concerned with the prevalence of risks, as observed in the study by Zegers (2007), and a qualitative evaluation of the practices and their outcomes in reference to the scorecards of the stakeholders involved. It is in a context of dynamic cross-border value chains, complex information systems and frequent regulatory changes, that the prevailing compliance regime has gradually become problematic.

The practices that have served as a yardstick to compare the VAT-ERP compliance regime are those of companies that manage in enterprise architecture the models of their objectives, organization, processes, master data and transaction data, systems, ongoing projects etc. These companies are enabled to determine the area of impact of the change, and to plan for change implementations, while maximally reusing explicit requirements, information system artifacts and best practice patterns.

Yet, the majority of system stakeholders usually do not use an enterprise architecture approach.

This gap can be bridged by the use of a societal architecture meso-level conceptual models in a Collaborative Planning and Investment Methodology.

A societal architecture approach accelerates enterprise- and household-level evolution that is aligned to prescriptive or descriptive macro- and meso-level architecture descriptions. Those architecture descriptions could be focussed on implementing strategic agendas such as the 2030 Agenda, or global tax-cooperation.

On the right-hand side, figure 9.12 depicts for the customer the current compliance regime in which landscape models are only expressed using natural language and logic (AS IS). For the supplier a TO-BE compliance regime is depicted, with shared reference models at landscape and sector level that will simplify alignment at the firm level. The reuse illustrated in this book could be applied more broadly. Hence the reference in the figure to Performance Reference Model (PRM), Business Reference Model (BRM), Service Reference Model (SRM) and Data Reference Model (DRM) as employed in the Federal Enterprise Architecture Framework (FEAF).

Figure 9.12: Multi-level Domain-driven Project Environment
Figure 9.12: Multi-level Domain-driven Project Environment

Considering the factor dependencies depicted in Figure 9.11 and Table 9.5, and the public domain gap regarding meso-level models, we express the design requirements for the meso-level CIM models (Table 9.6). These requirements generalize the VAT-ERP bridge services (Zegers, 2007). R1 is met by positioning the models at the CIM layer in the Model Driven Information System Development. R2 is met by the functional focus of the models and their mutual relationships in an CPIM. R4, R3 and R5 are the focus of the following sections. In those sections we also make recommendations regarding the public or proprietary provision of several models.

Table 9.6: Design Requirements for meso-level models

ID Explanation
R1 The meso-level CIM models must be implementation independent: regulation-ICT compliance models should be applicable for multiple enterprise software packages, and for multiple regulatory requirements.
R2 The meso-level CIM models should be positioned between regulations and enterprise software systems: In this way it will function as a bridge. It will make regulations executable within enterprise software systems.
R3 The meso-level CIM models must be flexible: In the case of changes in the external environment, such as changes in regulations, it must be easy to extend the model so that it reflects the new requirements.
R4 The meso-level CIM models must be correct: regulations must be modelled according to the principles and behaviour prescribed in the regulations.
R5 The meso-level CIM models must add value for all stakeholders in the VAT-ERP sector: This increases the degree of acceptance and justifies the place of the models at the meso-level.

Reusable Domain models leveraging the Multi-level perspective

This chapter demonstrates how the multi-level perspective merges with model driven information system development in the regulative cycles walked through by VAT-ERP stakeholders for their work systems.

Among micro-level CIM models, there exist commonalities that are based upon the existence of the enterprises in the same sector and the same landscape, where they are subject to the same rules, and interact with the same external parties.

Using the VAT-ERP compliance case, it is demonstrated how reusable models have the potential to simplify - improve - (model-driven) ERP system development at the micro level. Where regulatory change is expressed as a δCIM with respect to a current CIM model, as illustrated by the UK MTIC changes for VAT rules, the induced micro-level response becomes straightforward, as briefly illustrated for ERP system changes.

Landscape properties and rules are elaborated to the level of detail that is required for explaining the VAT-ERP scenario. Super-level models allow for many more refinements than those presented in this chapter. The utility of partial models is much broader than only for ensuring VAT-ERP compliance. Each level-step down, represents the gradual narrowing of perspective and the progressive articulation of constraints. Sometimes the explanatory text gives an indication of the model breadth, in order to complement the depth that is pursued for the VAT-ERP case.

Landscape Entity and Interaction Models

The landscape entity model describes for the market the kinds of principals, and the Rights, Responsibilities and Restrictions (RRR) (Oosterom et al, 2006) that these principals have with respect to the goods and entities (institution objects) (Figure 9.13) that matter in socio-economic interactions (Figure 9.15). An InstitutionObject instance is anything that can be the object of an RRR. As sub-classes of InstitutionObject, the classes Thing, Type and Phylos support the distinction between the ontogenic, typogenic and phylogenic lifecycles (Goossenaerts, 2000). An instance of Type refers to the specification of similar objects, such as the VAT return format used in Belgium during the year 2008, or cars with the same brand and type. An instance of Phylos represents the family of objects with similar types, such as the family of cars, or the family of VAT returns used within the EU since its establishment. Phylos are the focal point in regulations enacted by an agency. A Type is the focus of the productive or repetitive activities of a company or organization. For example, the (document) type VAT return is defined by the VAT authorities, for use by anyone who must do VAT accounting.

Figure 9.13: The Landscape (Entity) Model
Figure 9.13: The Landscape (Entity) Model

Regulations and Contracts specify mutual entitlements between the contracting parties. They specify requirements regarding the socio-economic interactions affecting the bundles of RRR instances with respect to institution objects. In the case that the socio-economic interactions are supported by ICT (ICT-reliance), the clauses of contracts and regulations become pertinent also to the requirements for the information systems. For a thorough grasp of the eco-system structure and dynamics (behavior) it is helpful to recognize ontological stratification. Ontological stratification is the partitioning of (conceptualization of) a system’s environment into several disjoint spaces (or strata) according to the identity criteria used to conceptualize the entities in these spaces, and according to the possible behaviors of these entities. The joint use of ontological strata has been demonstrated in a study on openness in agent systems (Abramov et al, 2005). Reflecting the long-accepted distinctions between material, information and financial flows in commerce, we adopt the three strata: material, content (data, concept, information) and financial. Figure 9.14 partitions the asset (types) into material, content and money, and for each partition it also defines segments that can contain the asset.

Figure 9.14: Material, Content and Money Ontological Strata in the Commercial Landscape
Figure 9.14: Material, Content and Money Ontological Strata in the Commercial Landscape

The landscape interaction model (Figure 9.15) applies UML use case notation to depict the activities in which companies and statutory authorities engage. Regulations are enacted as part of the ‘commercial law’ in the Regulative Commerce activity (lower part of the figure). Not in the model are the (constitutive) landscape contracts and administrative prescriptions that prescribe who is entitled to regulate and how such regulation is performed. The VAT Regulator exists in each EU country to ensure compliance of VAT regulations with the EU directives. The documents involved in the activities are depicted as actors with a prefix ‘Doc’, a choice that is supported by the actant concept of Actor Network Theory (Callon, 1986).

The upper part of the figure depicts the scope of the commercial law. This consists of micro-level interactions that typically involve the exchange and carriage of goods and the performance of services. For the Tax authorities the invoice (line) is the evidence of an elemental economic event in which an entitlement to VAT has been created. The economic events involve exchanges and carriages of material, content and money. Usually, as in the case where material goods are transported by a third party, the fulfillment of the economic event will involve more than two parties. The Incoterms offer a set of standard options to separate the duties in cross border transactions.

Figure 9.15: Socio-economic Activity in the Landscape Interaction Model
Figure 9.15: Socio-economic Activity in the Landscape Interaction Model

Each actor in the interaction model is bound to a class that specifies the required structure of the objects and subjects that must fill it (Table 9.7). A doc-actor (actant) must have a specification that is derived from subclasses in the InstitutionObject branch in the landscape entity model. A subject actor is bound to an instance of the Principal branch. Also server actors are possible.

For each activity we can provide an informal description (Table 9.8) and a progression of invariants and pre- and post-conditions involving the instances bound to the actants in the activity. It is also possible to define activity diagrams or BPMN models with for each actant a swim lane.

A principal’s economic activity must comply with the RRR instances that it has for the institution objects involved in the activity. RRR instances determine constraints for the activities. For instance, a right to sell comes with a responsibility to charge VAT. The landscape entity model as a whole describes in a generic manner the transaction context for an (un-limited) number of activity (business use case) occurrences.

Table 9.7: Binding the Landscape Models

ACTOR (ROLE NAME) CLASS CONSTRUCT ADDITIONAL CONDITION                                                    
Doc:: Commercial Law Contract An accumulation of rules that prescribe commercial behaviour; these are prescriptions that are (assumed to be) known by the principals within the scope, and here is assumed to include the VAT regulations, a.o. Because rules are partial, contradictions could arise.
Tax Authorities Agency The executive body of a country performing VAT Collection as its statutory duty, this is within the scope set by the commercial rules.
CA::Elemental Economic Event Economic Event An economic event that cannot be decomposed anymore; it involves two parties, one of which must be a company and have a VAT registration.
Doc::Invoice Invoice A document that gives evidence of the one or more economic events, linked via inv_line[i], that involve at least two companies; it is an input to the collect_VAT activity.
Act:: Company Company A principal that takes part in commercial interactions and has a VAT registration.
Act:: Principal Principal Any consumer or customer. If the customer itself is a company, then it must also perform VAT accounting.

Table 9.8: Informal activity descriptions

ACTIVITY ACTIVITY DESCRIPTION                                                    
Regulate Commerce Updating of the commercial regulations in accordance to new directives and/ or other emerging requirements
Collect VAT The periodic collection of VAT, it must be performed in compliance to all prescriptions for the activity.
Elemental Economic Event Any event, such as supply of goods or delivery of services that can be the object of an invoice line. It is an abstract event for which a wide range of extensions exist, as indicated by the (parameterized) extension points service[tose] and supply[tosu], with values in the enumeration types TypeOfService, resp. TypeOfSupply.
VAT accounting The accounting of VAT on the basis of sent and received invoices by a VAT-registered company.

The landscape interaction model demonstrates the common footprint of regulations at the macro level. In what follows, refinements of the landscape interaction model show more realistic patterns of aggregate economic events and the unambiguous representation of VAT rules as progressive constraints.

Partial models for International Commerce

Value exchanges and carriage (VEC) form an important, more complex part of the commercial activity in the landscape. Complexity results from the involvement of multiple parties, with a varying allocation of RRR instances during the transaction. Figure 9.16 shows how transactions according to specific Incoterms2000 are composed of elemental economic events that are described in invoice lines.

Figure 9.16: International Value Exchange and Carriage
Figure 9.16: International Value Exchange and Carriage

Table 9.9: Binding International Value Exchange and Carriage to the Landscape Domain Models (in addition to those in table 9.7).

ACTOR/ACTANT BINDING ADDITIONAL CONDITION                                                    
Statistics Office, Customs Agency These are executive bodies performing their statutory duties within the scope set by the commercial rules.
Doc:: SAD C88.1-8 SAD C88, a sub-class of Document The single administrative document that is linked to an economic event that is border-crossing; different sheets are intended for the different parties involved in the economic event
Principal (buyer, seller, carrier) Principal in a specific country any party selling, buying or carrying goods or services (this party could be established in a EU country or outside it)
Sales Contract, SSN, ECSI, B/L SWB AWB All sub-classes of Document See the text for the role of these documents.

Table 9.10: Informal activity descriptions (in addition to those in table 9.7).

ACTIVITY ACTIVITY DESCRIPTION                                                    
Import/Export Clearance, Import/Export Statistics Collection Business use cases (scenarios) in the portfolio of the linked principal; it must be performed in compliance to all prescriptions for the activity, and be restricted to those institution objects for which sufficient RRR’s are owned by the principal
CA::VEC, CA::VEC-EXW, VEC stands for value exchange and carriage, it is an abstract use case for cross-border (usually composite) economic events. An extensions exist for each of the Incoterms2000. For instance VEC-EXW is the elaboration of VEC in accordance with the EXW Incoterm; it involves a chain of economic events among parties as identified by the Incoterm, and as implied by the arrangements for payment, transportation and insurance. The latter are not in the model.
CA::EEE Selling An elemental economic activity between a seller and a buyer
CA::VEC A-B Carrying, CA::Forwarding,
CA::Port and Container base operations Some of the additional transactions that can be part of an EXW international commercial transaction.

In international trade, the buyer, seller and carrier must consider commercial and official requirements, leading to commercial and official documentation to complete and provide. On the commercial side, the sales contract, the Invoice, the Export Cargo Shipping Instruction (ECSI), the Standard Shipping Note (SSN), the Bill of Lading (B/L; alternatively the Sea Waybill (SWB) or the Air Waybill (AWB)) are completed and provided as indicated in Figure 9.17. Regarding the official requirement our treatment is restricted to the Single Administration Document (SAD, Customs Form C88), the Customs declaration document for export, imports and goods transiting the EU. The International Commercial Terms (International Chamber of Commerce (ICC), 1999) specify a number of standard trade terms for frequently used patterns of international value exchange and carriage (transactions).

Figure 9.17: International Value Exchange and Carriage
Figure 9.17: International Value Exchange and Carriage

In Goossenaerts et al (2009) further partial models are provided for the VAT case.

9.8 - Conceptual Models in Open Portfolios

To the chapter


9.9 - Conceptual Models in Programmes

To the chapter


9.10 - Conceptual Models in Projects

To the chapter


9.11 - Conceptual Models in Iterations

To the chapter


9.12 - Conceptual Models and the 2030 Agenda

To the case overview - To the chapter


9.13 - Conceptual Models and Library Services

Figure 9.18: Library Services Context
Figure 9.18: Library Services Context

Table 9.11: Stakeholder goals and supporting business processes

Stakeholder Goal with Identifier Supporting Business Process
Guest G1: KnowLibraryServices Publish Library Services
  G2: BecomeMember Membership Registration
Member M1: HoldMediaObject Title Lending & Return
  M2: BeNextForObject Title Reservation
  M3: EndMembership Membership Registration
Clerk Cl1: Maintain Library State Validity Register State Changes
  Cl2: Satisfy Next Guest Service Desk Operations
Librarian L1: Add/Remove Media MediaSelection
  L2: Add/Remove Title Title Acquisition & Removal
  L3: Know BSC Scores Monitoring & Evaluation
Figure 9.19: A domain model for library stakeholders and media products
Figure 9.19: A domain model for library stakeholders and media products

To the case overview - To the chapter


Part IV - Societal Architecture Benefits Beyond Research & Leverage


Chapter 10 - Benefits in Research and Leverage - Executable Model and Experimentation (CPIM02c&d)

Chapter 11 - Benefits in Define and Plan (CPIM03)

Chapter 12 - Benefits in Invest and Execute (CPIM04)

Chapter 13 - Benefits in Perform and Measure (CPIM05)


To Part I - II - III - IV - V - VI-Annexes - VII-References


Chapter 10 - Benefits in Research and Leverage - Executable Model and Experimentation


10.1 - Evaluation of the Research & Leverage Phase
10.2 - Where could you go wrong
10.3 - Statistical Inference
10.4 - Executable Model, Experimentation and open portfolios
10.5 - Executable Model and Experimentation in Programmes
10.6 - Executable Model and Experimentation in Projects
10.7 - Executable Model and Experimentation in Iterations


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


10.1 - Evaluation of the Research & Leverage Phase

Explain your results and how you answered the research questions of the decision making engagement. Give your recommendations/advise. Make a self-evaluation of your results.

On completion of the research and leverage phase, a number of tasks may need to be done, e.g.,

  • Complete documentation
  • Communication of results
  • Recommendations regarding the implementation

Deliverables of a decision making engagement may include deliverables in report and file form as well as deliverables such as model-specific or generic Modeling training, and customized user interfaces for model input and output. Deliverables in report or file form include the project specifications, the final report, conceptual model, Modeling and animation model and experiment files for different models, raw data collection files, detailed model output files, customized input and output user interfaces, user manual, and maintenance manual.

Documentation is necessary for numerous reasons. If the simulation model is going to be used again by the same or different analysts, it may be necessary to understand how the simulation model operates. This will enlarge confidence in the simulation model so that the client can make decisions based on the analysis. Also, if the model is to be modified, this can be greatly facilitated by adequate documentation.

The result of all the analyses should be reported clearly and concisely. This will enable the client to review the final formulation, the alternatives that were addressed, the criterion by which the alternative systems were compared, the results of the experiments, and analyst recommendations, if any. (Banks and al., 2000).

It is also useful, at the end of a simulation project, to review the overall project process and perhaps refine the process before starting the next project. (Mehta, 2000). The Modeling analyst acts as a reporter rather than an advocate. The report prepared stands on its merits, and is just additional information that the client uses to make a decision. If the client has been involved throughout the study period, and the Modeling analyst has followed all the steps rigorously, then the likelihood of a successful implementation is increased.

Certainly modeling, executable models and simulation are not panacea. Realistic executable models may require long computer programs of some complexity. There are special-purpose simulation languages and packaged systems available to ease this task, but it is still rarely simple. Consequently, producing useful results from a computer simulation and experimentation can turn out to be a surprisingly time-consuming process. In one way, therefore, computer simulation and experimentation should be regarded as a last resort to be used if all else fails (Pidd, 1998).

Yet even when it will be time-consuming and there may be alternative approaches, there are certain advantages in employing a simulation or experimentation approach and it may be the only way of tackling some problems and engaging multiple stakeholders in such a way that they really understand the implications of certain decision alternatives.


Cost Aspects

Advantages of simulation and experimentation:

  • Relative low costs: although Modeling can be time-consuming and therefore expensive in terms of skilled manpower, real experiments may also turn out to be expensive-particularly if something goes wrong! So Modeling lets you test every aspect of a proposed change or addition without committing resources to their acquisition. This is critical because once the hard decisions have been made, the bricks have been laid or the material-handling systems have been installed, changes and corrections can be extremely expensive. Modeling is a wise investment since a typical cost of a decision making engagement is substantially less than 1% of the total amount being expended for the implementation of a design or redesign. Since the cost of a change or modification to a system after installation is so great, Modeling is a wise investment.
  • Safety constraints: One of the objectives of decision making engagement may be to estimate the effect of extreme conditions, and to do this in real life may be dangerous or even illegal. An airport authority may take some persuading to allow a doubling of the flights per day even if they do wish to know the capacity of the airport. Simulated aircraft cause little damage when they turn out of fuel in the Modeling sky.

Disadvantages:

  • Time Consuming and Expensive: Other alternative analytical methods must be considered before starting a decision making engagement because Modeling consumes a lot of time (and money). Skimping on resources for Modeling and analysis may result in a simulation model and/or analysis that is not sufficient to the task.

Time Aspects

Advantages of simulation and experimentation:

  • Time saving: Admittedly, it takes a significant amount of time to produce working computer programs for simulation models. However, once these are written then an attractive opportunity presents itself. Namely, it is possible to simulate weeks, months or even years in seconds of computer time. Hence a whole range of policies may be properly compared. Moreover, by compressing or expanding time Modeling allows you to speed up or to slow down phenomena so that you can thoroughly investigate them. It can save a lot of time to apply Modeling to determine the effect of implementation of a change in a certain decision variable in the production process.
  • Replication and explore possibilities: Unfortunately, the real world is rarely kind enough to allow precise replication of an experiment. One of the skills employed by physical scientists is the design of experiments which are repeatable by other scientists. This is rarely possible in management science. Modelings are precisely repeatable; you can explore new policies, operating procedures, or methods without the expense and disruption of experimenting with the real system. Modifications are incorporated in the model, and you observe the effects of those changes on the computer rather than the real system. You could even investigate the effect of a change in working hours on the throughput time because of changes in legislation.

Disadvantages

  • Model building requires special training: it is an art that is learned over time and through experience. Furthermore if two models of the same system are constructed by two different individuals, they may have similarities, but it is highly unlikely that they will be the same.
  • No appropriate Modeling software: Unfortunately, the Modeling software does not always incorporate all the functions that Modeling analysts need during the study. The limitations of the software are often recognized in a later stage in the project. At that moment it is fairly impossible to go back to the beginning and start all over. In most cases, assumptions must be made to validate the model. However, they can affect the Modelings outcome, so be aware of your assumptions.

Team and organization aspects

Advantages of simulation and experimentation:

  • Training the team: system models can provide excellent training when designed for that purpose. Used in this manner, the team provides decision inputs to the simulation model as it progresses. The team, and individual members of the team, can learn by their mistakes, and learn to operate better. This is much less expensive and less disruptive than on-the-job learning.
  • Building consensus: Using Modeling to present design changes creates an objective opinion. You avoid having inferences made when you approve or disapprove of designs because you simply select the designs and modifications that provided the most desirable results, whether it be increasing production or reducing the waiting time for service. In addition, it is much easier to accept reliable simulation results, which have been modelled, tested, validated, and visually represented, instead of one person’s opinion of the results that will occur from a proposed design.

Disadvantages

  • Modeling may be used inappropriately: people may still insist on applying Modeling in some cases when an analytical solution is possible or even preferable. This is particularly true in the Modeling of some waiting lines where closed-form queuing models are available, at least for long-run evaluation.
  • Lack of communication between the Modeling analysts and the management: If only Modeling is used, the management only communicates with the Modeling analysts in beginning and at the end of the decision making engagement. The effect of this approach can result in an incomprehensible Modeling report by the management of the organization. The Modeling project must be incorporated in the organization is self, and must not be seen as a stand-alone procedure.
  • Lack of Modeling knowledge: Modeling is not an easy exercise; it requires specific knowledge of math, statistics and computer science. Due to these entry barriers not everyone can be involved in the project. As a consequence, Modeling analysts do not have good understanding about the surrounding organization or the project management side of the project. Without this information, building and Modeling of the model can develop as a project it self with no respect to the overall management objectives.

Insight aspects

Advantages of simulation and experimentation:

  • Understand why? Managers often want to know why certain phenomena occur in real systems. With Modeling, you determine the answer to the “why” questions by reconstructing the scene and taking a microscopic examination of the system to determine why the phenomenon occurs. You cannot accomplish this with a real system because you cannot see or control it in its entirety.
  • Identify constraints: Production bottlenecks give manufacturers headaches. It is easy to forget that bottlenecks are an effect rather than a cause. However, by using Modeling to perform bottleneck analysis, you can discover the cause of the delays in work-in-process, information, materials, or other processes.
  • Visualize the plan: Taking your designs beyond CAD drawings by using the animation features offered by many Modeling packages allows you to see your facility or organization actually running. Depending on the software used, you may be able to view your operations from various angles and levels of magnification, even 3-D. This allows you to detect design flaws that appear credible when seen just on paper on in a 2-D CAD drawing.
  • Prepare for change: We all know that the future will bring change. Answering the “what-if” questions is useful for both designing new systems and redesigning existing systems. Interacting with all those involved in a project during the problem-formulation stage gives you an idea of the scenarios that are of interest. Then you construct the model so that it answers the questions pertaining to those scenarios. What if an AGV is removed from service for an extended period of time? What if the demand for service increases by 10 percent? What if…?

Disadvantages

  • simulation results may be difficult to interpret: since most Modeling outputs are essentially random variables (they are usually based on random inputs), it may be hard to determine whether an observation is a result of system interrelationships or randomness. Therefore is it difficult to generalize results.
  • It is difficult to produce exact results: Because many systems are affected by uncontrollable and random inputs, many system models involve random or stochastic input components, causing their output to be random too. For example, a model of a distribution center would have arrivals, departures, and lot sizes arising randomly according to particular probability distributions, which will propagate through the model’s logic to cause output performance we measures like throughput and cycle times to be random as well. So running a stochastic Modeling once is like performing a random physical experiment once, or watching the distribution center for one day – you’ll probably see something different next time, even if you don’t change anything yourself. In many Modelings as the time frame becomes longer (like months instead of a day), most results averaged over the run will tend to settle down and become less variable, but it can be hard to determine how long is “long enough” for this to happen.
  • Wrong or no performance indicators: On what grounds, can be decided whether it is a good decision to implement a certain Modeling outcome? Is throughput time the only important factor? What will be the effect on the other product flows if we implement this decision? It is clear that people need well-defined performance indicators to make the correct trade-off. Management wants to avoid local optimizations and in the end, the Modeling project must benefit the organization as a whole.

To the chapter


10.2 Where could you go wrong?

Based on (Sadowsky and Grabau, 2000).

Tackling the wrong problem

Sometimes, the biggest mistake is made at the outset of a decision making engagement. If your organization or client has picked the wrong problem to explore with Modeling, you might be put at a high risk of failure before you have made your first mouse click!

One of the interesting places where this occurs is when simulation and experimentation are used to prove what’s already known or decided, or about which there already is a wide consensus. In some firms, thresholds of capital acquisition require a decision making engagement, though it might be initiated well after first commitments to a particular course of action have been made.

Because of the animation that accompanies most simulation and experimentation studies, another danger presents itself when identifying candidate projects. Certainly, many problems require detailed modeling, simulation or experimentation; however, other problems can be readily solved using other tools, such as queuing analysis, optimisation, simple spreadsheet calculations, or a questionaire. If something simpler than simulation and experimentation can provide the same quality of results, then avoid the cost of the decision making engagement and use the appropriate tool.

The most common types of misguided simulation and experimentation studies are those where the scope is too ambitious or ill-defined. It’s difficult to figure out where the boundaries should be in a complex system, since often it seems that everything could be an important factor of performance or outcome. You must work hard early in a project to discover what to exclude from the study; while it’s hard to say “no”, it can be critically important to be willing to do so.

Working on the Right problem at the wrong time…

You may think carefully about when to start a simulation or experimentation project and whether to put the brakes on, even if you’ve established momentum. If the designers of the system/process are still considering widely differing ideas, or are brainstorming for how to solve some of the fundamental problems in the system, then it may be premature to perform more than a rudimentary analysis.

It’s more difficult to identify timing problems once a project is under way. If there are regular and significant changes to the nature of the project, you’ll feel the effects since you’ll have to rework your model. It’s hard to know whether or when you should pause the modeling work to let the project team do some preliminary design.

There is also danger when a simulation or experimentation is started too late to be successful.

Missing the Warning signs of the “Data Woes”

According to Ricki Ingalls, manufacturing strategy manager for Compaq Computer, “it’s the data management that takes up most of the time… getting the data, running it, and then analysing it”.

Three situations: you can have too little, too much, or just the right amount… and still find yourself in trouble:

  • Too little data: Most often, if there are problems with data, it’s a lack of information. Service times, yield probabilities, defect rates, rework percentages, and many other important aspects of a system’s dynamics may not be collected for other business purposes. Because getting this data can be very time-consuming, it’s critical to establish your data needs as early in a study as possible and to immediately assess whether the data exists.
  • Too much data: In your search for data, you may find the opposite problem, that there’s far too much of it. While the particular information you need may exist, even perhaps electronically in a database or spreadsheet, you may spend days trying to locate it among all the other data that’s with it. In this circumstance, it’s imperative to find help from someone who is knowledgeable about the data and whom you can educate about your exact needs.
  • Just the right amount but what does it mean? When you look at the data, be sure to understand what it really means! What you think of when you say cycle times, for instance, may be very different from the data that’s stored in a cycle-time table, which might include waiting time, breakdown times, and other properties that should be modelled separately.

Letting the window of opportunity close

The greatest and most widely discussed risk of failure with simulation and experimentation is that you won’t finish the job on time. There are myriad reasons why simulation and experimentation projects are late in delivering results. Four particular pitfalls are listed here.

  1. Getting lost in Detail: The art of Modeling involves assessing what level of detail is required to support the project’s goals. It’s tough to do this right, though, because often you can’t tell whether the detail is needed until you’ve developed it; and once the work is done, it’s hard to justify removing it if it’s unimportant. Whenever possible, err on the side of keeping the model simple, unless you have the luxury of significant slack in your schedule. Sometimes the need for additional model fidelity is driven by a desire for more realistic animations. The quality of the animation can indeed be very important in effectively communicating project recommendations.
  2. Leaving Analysis for the End: In the traditional view, projects suffer from too strong a focus on the model (and perhaps the animation), so that after the inevitable delays and problems, there is no time left to run scenarios. Instead the analyst is faced with a presentation, deadline that’s firm and little time to experiment, analyze, or think.
  3. Having too much fun with Animation: Animation holds a similar attraction in Modeling studies than using PowerPoint for a presentation! With the mouse in-hand, you can easily fall into the trap of adjusting, tweaking, and enhancing the animation far beyond what’s needed, just because of its entrancing nature.

Testing at the end of the Project

As with analysis, verification of the models must be performed throughout a project. Because it’s even more tedious and uninteresting than the simulation and experimentation, it’s easy to leave testing for late in the project. Think about a test plan early in the project and revise it as you progress.

To the chapter


10.3 - Statistical Inference

To be completed.


10.4 - Executable Model, Experimentation and open portfolios

An earlier version of the proposed approach for the derivation of executable models was included in A Multi-level Model-driven Project Environment (MMPE) which facilitates systematic society-wide reuse of the architecture descriptions models (Goossenaerts et al., 2009).

Building upon a formal approach to domain modeling, we emphasize specific model-resources at different levels and explain their impact on change projects and the risks involved.

The elaboration of model dependencies that are cross-phase in the regulative cycle (van Strien, 1997), one such cycle could be the TOGAF Architecture Development Method, cross-level in multi-level planning, and cross-layer in the Enterprise Architecture is an original contribution of our work. The allocation of models to the public and proprietary domains is intended to induce fair and concerted growth-focused attitudes (Goossenaerts, 2007).


10.5 - Executable Model and Experimentation in Programmes

For a study on e-maintenance by original equipment manufacturers, see Goossenaerts et al. (2007).

To the chapter


10.6 - Executable Model and Experimentation in Projects

This situation is typically present in ICT projects.

Some form of simulation and experimentation is achieved by injecting process flow explanations and elements of participative simulation (Goossenaerts and Pelletier, 2002), wireframes and mock-ups in workshops and presentations.


10.7 - Executable Model and Experimentation in Iterations

Some form of simulation and experimentation is achieved by explaining process flows and using screenshots with proposed changes for user tasks where change is planned.


Chapter 11 - Benefits in Define and plan (CPIM03)


This chapter is due for a later version, especially also with reference to portfolio, programme, project and iteration definition and planning in Chapters 2 and 4. Depending on the level of the defining and planning, at play are a different mix of digital principles (Chapter 1):

and capabilities (Chapter 4):


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)

Chapter 12 - Invest and Execute (CPIM04)


This chapter is only an early draft.

12.1 - Joint Implementation by Various Actors and Stakeholders
12.2 - Returns of Collaboration in Portfolios and Programmes
12.3 - Returns of Collaboration in the Semiotic CPIM Phases
12.4 - Invest and Execute for the 2030 Agenda for Sustainable Development
12.5 - Invest and Execute for Library Services


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


12.1 - Joint implementation by various actors and stakeholders

In this chapter we describe the tools and resources for implementing the 2030 Agenda for Sustainable Development. In this chapter we elaborate the “Societal Architecture customized views” for each stakeholder group with a focus on the reusable input the Societal Architecture provides for their Invest and Execute activities.

An earlier version of the proposed approach was included in A Multi-level Model-driven Project Environment (MMPE) facilitates systematic society-wide reuse of the architecture descriptions models. Building upon a formal approach to system modeling, we emphasize specific model-resources at different levels and explain their impact on change projects and the risks involved (Goossenaerts et al, 2008).

The elaboration of model dependencies that are cross-phase in the regulative cycle, one such cycle could be the TOGAF Architecture Development Method, cross-level in MLP, and cross-layer in the Enterprise Architecture is an original contribution of our work. The allocation of models to the public and proprietary domains is intended to induce fair and concerted growth-focused attitudes (Goossenaerts, 2007).

Stakeholders to consider:

12.2 - Returns of Collaboration in Portfolios and Programmes

The need for investment from the global to local macro level is clearly expressed in the finance-related Sustainable Development Targets and article 34 on capacities of the Addis Ababa Action Agenda.

  • 17.1 Strengthen domestic resource mobilization, including through international support to developing countries, to improve domestic capacity for tax and other revenue collection (#sdt171)
  • 17.2 Developed countries to implement fully their official development assistance commitments, including the commitment by many developed countries to achieve the target of 0.7 per cent ODA/GNI to developing countries and 0.15 to 0.20 per cent of ODA/GNI to least developed countries; ODA providers are encouraged to consider setting a target to provide at least 0.20 per cent of ODA/GNI to least developed countries (#sdt172)
  • 17.3 Mobilize additional financial resources for developing countries from multiple sources (#sdt173)
  • 17.4 Assist developing countries in attaining long-term debt sustainability through coordinated policies aimed at fostering debt financing, debt relief and debt restructuring, as appropriate, and address the external debt of highly indebted poor countries to reduce debt distress (#sdt174)
  • 17.5 Adopt and implement investment promotion regimes for least developed countries (#sdt175)

Addis Ababa Action Agenda, Art. 34 “#aaaa34 - Capacities of municipalities and other local authorities”

  • We further acknowledge that expenditures and investments in sustainable development are being devolved to the subnational level, which often lacks adequate technical and technological capacity, financing and support (#aaaa34_1)
  • We therefore commit to scaling up international cooperation to strengthen capacities of municipalities and other local authorities. We will support cities and local authorities of developing countries, particularly in least developed countries and small island developing States, in implementing resilient and environmentally sound infrastructure, including energy, transport, water and sanitation, and sustainable and resilient buildings using local materials (#aaaa34_2)
  • We will strive to support local governments in their efforts to mobilize revenues as appropriate (#aaaa34_3)
  • We will enhance inclusive and sustainable urbanization and strengthen economic, social and environmental links between urban, peri-urban and rural areas by strengthening national and regional development planning, within the context of national sustainable development strategies (#aaaa34_4)
  • We will work to strengthen debt management, and where appropriate to establish or strengthen municipal bond markets, to help subnational authorities to finance necessary investments (#aaaa34_5)
  • We will also promote lending from financial institutions and development banks, along with risk mitigation mechanisms, such as the Multilateral Investment Guarantee Agency, while managing currency risk (#aaaa34_6)
  • In these efforts, we will encourage the participation of local communities in decisions affecting their communities, such as in improving drinking water and sanitation management (#aaaa34_7)
  • By 2020, we will increase the number of cities and human settlements adopting and implementing integrated policies and plans towards inclusion, resource efficiency, mitigation and adaptation to climate change and resilience to disasters (#aaaa34_8)
  • We will develop and implement holistic disaster risk management at all levels in line with the Sendai Framework (#aaaa34_9)
  • In this regard, we will support national and local capacity for prevention, adaptation and mitigation of external shocks and risk management (#aaaa34_10)

Shifting Investments

Considering that in the international development landscape a lot of investments are allocated to (expensive) knowledge work that is focused on the semiotic flows (see Figure 4.7 in Reuse of Knowledge Assets in Decision Support Studies) the intended impact of the Societal Architecture is threefold as depicted in Figure 12.1:

  • To reduce the cost of semiotic flows;
  • To enhance the investment in material solutions; and
  • Harness a much wider pool of people and capacities to make sense of the information and contribute to (material) solutions.
Figure 12.1 - Shifting Investments in Collaborative Planning and Investment
Figure 12.1 - Shifting Investments in Collaborative Planning and Investment

The goal of harnessing a much wider pool of people and capacities to make sense of the information and contribute to (material) solutions is moreover served by #tagcoding and #xy2wiki as depicted in Figure 12.2 that also clarifies the related building up of capabilities.

Figure 12.2 - #xy2wiki, #tagcoding and the harnessing of a much wider pool of people and capacities
Figure 12.2 - #xy2wiki, #tagcoding and the harnessing of a much wider pool of people and capacities

To the chapter


12.2 - Returns of Collaboration in Portfolios and Programmes

Landscape models for public-private monitoring, review and validation and sectoral partial models that are aligned with the Sustainable Development Goals and open domain models.

Reduced risks of stranded resources.

Identifying commonalities across countries, municipalities and languages as illustrated in Invest and Execute for Library Services.

To the chapter


12.3 - Returns of Collaboration in the Semiotic Phases

For the scope of semiotic phases, see Chapter 4.3 Reuse of Knowledge Assets in Decision Support Studies.

Content in this chapter will be based on Knowledge conversion


12.4 - Invest and Execute for the 2030 Agenda

Content in this chapter will be based on Initiative Management - Be collaborative - #dp9

To the case overview - To the chapter


12.5 - Invest and Execute for Library Services

It is important that each town (k) in each country (j) of the world has a local public library (j,k) journey towards providing #cpc8451 - Library services in the languages spoken in the town.

Each language has an ISO-639 code, and this code is used to distinguish the (online) library activities, for instance #cpc8451hi for library services providing content in Hindi.

Depending on the current status of the library services in a language or town, priority initiatives can be selected from below tasks:

Figure 12.3 shows some constraints for beneficiaries and systems that have to be taken into consideration.

Figure 12.3 - Budget and cost-benefit constraints for xy2jk library services
Figure 12.3 - Budget and cost-benefit constraints for xy2jk library services

To the case overview - To the chapter


Chapter 13 - Perform and Measure (CPIM05)


This chapter must still be written. This area of work is well covered in operations management and by the work of international organizations and national statistics organizations.

Emphasis on general Principles for collaborative performance and measurement in the 2030 Agenda Partnership and the role of National Statistics Organizations.

13.1 - Performance and Joint Measurement for the various Actors and Stakeholders
13.2 - Returns of Collaboration in Operations and Measurement
13.3 - Perform and Measure in the 2030 Agenda Portfolio
13.4 - Perform and Measure in Programmes
13.5 - Perform and Measure in Projects
13.6 - Perform and Measure for the 2030 Agenda
13.7 - Perform and Measure for Library Services


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


13.1 - Performance and Joint Measurement for the Various Actors and Stakeholders

In this chapter we describe the “Societal Architecture customized views” for Joint performance and measurement for each stakeholder group with reference to the reusable input the Societal Architecture provided for their Identify and validate, Research and leverage, and Define and plan activities.

An earlier version of the proposed approach was included in A Multi-level Model-driven Project Environment (MMPE) which facilitates systematic society-wide reuse of the architecture descriptions models (Goossenaerts et al., 2009). Building upon a formal approach to domain modeling, we emphasize specific model-resources at different levels and explain their impact on change projects and the risks involved.

The elaboration of model dependencies that are cross-phase in the regulative cycle (van Strien, 1997), one such cycle could be the TOGAF Architecture Development Method, cross-level in multi-level planning, and cross-layer in the Enterprise Architecture is an original contribution of our work. The allocation of models to the public and proprietary domains is intended to induce fair and concerted growth-focused attitudes (Goossenaerts, 2007).

To the chapter


13.2 - Returns of Collaboration in Operations and Measurement

What are the benefits of cross-level collaboration in operations and measurement?


13.3 - Perform and Measure in Open Portfolios

This chapter will source from work on the 2030 Agenda Review Framework.

Figure 13.1 - National follow up and review
Figure 13.1 - National follow up and review

13.4 - Perform and Measure in Programmes

To the chapter


13.5 - Perform and Measure in Projects

This chapter will source from work on the UN Global Compact Strategy 2021-2023 and the UN Global Compact’s reporting framework.

Over 66,000 Communications on Progress (COP) are available from the international Global Compact database.

To the chapter


13.6 - Perform and Measure for the 2030 Agenda

See Perform and Measure in Open Portfolios.

To the case overview - To the chapter


13.7 - Perform and Measure for Library Services

To the case overview - To the chapter


Part V - Agents and Global Portfolios


Chapter 14 - Agents in a Techno Globe

Chapter 15 - The Global Tax Portfolio

Chapter 16 - The Global Content Portfolio


To Part I - II - III - IV - V - VI-Annexes - VII-References


Chapter 14 - Agents


14.1 - Raising Awareness for Sustainable Development
14.2 - About the Agent Template
14.3 - Citizens and Households
14.4 - Global Partnership
14.5 - National Government
14.6 - Local Authorities
14.7 - Schools
14.8 - UN Country Teams
14.9 - Publishers and Right Holders
14.10 - Libraries
14.11 - Aid Organizations
14.12 - Firms


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


14.1 - Raising Awareness for Sustainable Development

One of the first concerns in the communication plans of open portfolios and the programmes, projects and iterations they enable is the raising of awareness.

Awareness-raising activities aim to increase the engagement of citizens and local communities in order to promote their sense of ownership of the 2030 Agenda and their participation in the achievement of the SDGs at local level.

The raising of awareness is about:

  • letting people know about the existence of the SDGs and its targets,
  • empowering people to participate in the achievement in their daily lives of localised targets,
  • empowering people to hold to account their governments and businesses for their localised development performance.

The raising of awareness is part of a localization process of taking into account subnational and local contexts in the achievement of the 2030 Agenda. Beyond the awareness the localizing will also involve the setting of local goals and targets, determining the local means of implementation and using indicators to measure and monitor local progress.

Supporting Principles

Awareness-raising campaigns should be carried out at international, national and subnational levels, and those campaigns should be mutually enforcing in order to emphasize local spaces “of everyone” (lifeworlds) as the ultimate sites of delivery and development.

National and subnational governments, civil society organizations, the private sector, academia and individual citizens should all be involved in the end-to-end partner journeys for the local implementation of the SDGs.

Supporting principles (#rio or Digital capability Principles - #dp):

  • #rio04 - Environmental protection as integral part: In order to achieve sustainable development, environmental protection shall constitute an integral part of the development process and cannot be considered in isolation from it.
  • #rio06 - Special priority for the least developed, most vulnerable: The special situation and needs of developing countries, particularly the least developed and those most environmentally vulnerable, shall be given special priority. International actions in the field of environment and development should also address the interests and needs of all countries.
  • #rio07 - Common but differentiated responsibilities: States shall cooperate in a spirit of global partnership to conserve, protect and restore the health and integrity of the Earth’s ecosystem. In view of the different contributions to global environmental degradation, States have common but differentiated responsibilities. The developed countries acknowledge the responsibility that they bear in the international pursuit to sustainable development in view of the pressures their societies place on the global environment and of the technologies and financial resources they command.
  • #rio09 - Cooperate to strengthen endogenous capacity-building: States should cooperate to strengthen endogenous capacity-building for sustainable development by improving scientific understanding through exchanges of scientific and technological knowledge, and by enhancing the development, adaptation, diffusion and transfer of technologies, including new and innovative technologies.
  • #rio10 - Participation of all concerned citizens: Environmental issues are best handled with participation of all concerned citizens, at the relevant level. At the national level, each individual shall have appropriate access to information concerning the environment that is held by public authorities, including information on hazardous materials and activities in their communities, and the opportunity to participate in decision-making processes. States shall facilitate and encourage public awareness and participation by making information widely available. Effective access to judicial and administrative proceedings, including redress and remedy, shall be provided.
  • #rio20 - The full participation of women is essential: Women have a vital role in environmental management and development. Their full participation is therefore essential to achieve sustainable development.
  • #rio21 - Mobilize the creativity, ideals and courage of the youth: The creativity, ideals and courage of the youth of the world should be mobilized to forge a global partnership in order to achieve sustainable development and ensure a better future for all.
  • #rio22 - Indigenous people and local communities have a vital role: Indigenous people and their communities and other local communities have a vital role in environmental management and development because of their knowledge and traditional practices. States should recognize and duly support their identity, culture and interests and enable their effective participation in the achievement of sustainable development.
  • #dp9 - Be collaborative.

The agent information is shared in a template that is introduced next.

To the chapter


14.2 - About the agent template

In digital media, the agent template would look as in the figure below in which a number of tab-structures contain a large set of content that is consulted and modified as new initiatives develop and deliver.

Figure 14.1: The Citizen's agent template wiki-page
Figure 14.1: The Citizen’s agent template wiki-page

Online open shared agent descriptions support the society-wide reuse of the architecture descriptions. Building upon a formal approach to system modeling, we emphasize specific model-resources at different levels and (will) explain their impact on change projects and the risks involved.

Contextual factors

The availability of a societal architecture - preferably as part of a society repository - will impact the amount of work that must be invested in extending agent descriptions as a portfolio, programme or project is launched.

In a societal architecture described in accordance with the ArchiMate framework:

  • agents (for the portfolio that will aim for a service solution) are included in the motivation extension. The rationale for their involvement will often be related to their role in the Business collaboration that must be supported by the service solution;
  • hands-on users (of the products for which requirements are collected and shared) are addressed as part of the active structure aspect:

To the chapter - to the introduction on agents


14.3 - Citizens and households

For background and examples, see Household journeys for the #SDGs.

For innovation matters, see citizen (template).

To the chapter


14.4 - Global Partnership

For background, see Global Partnership.

For innovation matters, see Global Partnership (template).

To the chapter - to Joint implementation - to the introduction on agents


14.5 - National Government

For background, see National government.

For innovation matters, see National government.

In a contemporary national government one must distinguish different classes of public legal entities in accordance with their leading of governance, management or analysis & design processes.

To the chapter


14.6 - Local Authorities

For background, see Local Authorities.

For innovation matters, see Local Authorities (template).

To the chapter - to Joint implementation - to the introduction on agents


14.7 - Schools

For background, see School.

For innovation matters, see School (template).

To the chapter


14.8 - UN Country Teams

For background and tasks, see UN Country Team.

For innovation matters, see UN Country Team (template).

To the chapter


14.9 - Publishers and right holders

For background, see Reproduction rights organizations.

For innovation matters, see Publishers and right holders (template).

To the chapter - to Joint implementation - to the introduction on agents


14.10 - Libraries

For background, see Library.

For innovation matters, see Towards a #2030library and the global partnership online agent template where Figure 14.2 can be found.

Figure 14.2: Capabilities for the #SDGs enabled by libraries
Figure 14.2: Capabilities for the #SDGs enabled by libraries

To the chapter - to Joint implementation - to the introduction on agents


14.11 - Aid and international organizations

For background on International Organizations, see United Nations.

For background on aid Organizations, see aid organizations.

For innovation matters in international organizations, see Towards an Agenda 2030 United Nations Development System and Figure 14.3.

Figure 14.3: Gaps of the United Nations Development System
Figure 14.3: Gaps of the United Nations Development System

For innovation matters in aid organizations, see the Aid organization template of which a screenshot is included in figure 14.4.

Figure 14.4: The Aid Organization's agent template wiki-page
Figure 14.4: The Aid Organization’s agent template wiki-page

14.12 - Firms

For background, see Firm and other micro-level entities.

For innovation matters, see firm (template).

To the chapter - to Joint implementation - to the introduction on agents


Chapter 15 - The Global Tax Portfolio


15.1 - The Purpose of the Portfolio
15.2 - The Stakeholders
15.3 - Mandated Constraints
15.4 - Naming Conventions and Terminology
15.5 - Relevant Facts and Assumptions
15.6 - The Scope of the Work
15.7 - Domain Data Model and Data Dictionary
15.8 - The Scope of the Products
15.9 - Functional Requirements
15.10 - Non-Functional Requirements
15.11 - Portfolio Issues


To Part I (Chapter 1 - 2 - 3) _ II (4 - 5 - 6) _ III (7 - 8 - 9) _ IV (10 - 11 - 12 - 13) _ V (14 - 15) _ VI (Annexes) _ VII (References)


Introductory Remarks

For an ICT initiative of significant size, that seizes all potential benefits of an information exchange architecture (as part of a Societal Architecture) it is recommended that a business requirements document be created as part of the portfolio communications plan.

In this example we apply chapters of the Volère template.

Explanations for the completion of each section can be found at the template pages. In this chapter the sections are applied at different levels in the chain from portfolio to programme, project or iteration.


15.1 - The Purpose of the Portfolio

To the chapter

15.1a - The User Business and Background of the Portfolio Effort

Inefficiencies in the international tax landscape, dominated by thousands of bilateral treaties, have been described by Thuronyi (2001):

“It has become apparent, however, that the bilateral nature of this treaty network involves inherent flaws which have become more serious as the network has grown. The treaty network has become cumbersome and inflexible and, in many instances, has spawned opportunities for tax avoidance.”

The perspective of national tax administrations is covered in great detail in Borja et al (eds, 2020).

Slowly, the international community is adopting multilateral elements in international treaties. One example of these is the Two-Pillar Solution to Address the Tax Challenges of the Digitalisation of the Economy.

These as well as other changes to the international tax landscape over the last ten years, make it timely to consider what implications these developments may have for the way international tax rules are administered by national tax administrations.

While international tax policy design has resulted in many common and co-ordinated rules, the tax administration framework is still more inward looking.

In the international corporate tax landscape there is a need for simple, collaborative, and digital administration of common rules and an international tax information exchange architecture.

National tax administrations and corporations must improve timeliness through real-time data availability and incorporating compliance by design.

The changing tax landscape matters also for developing countries and for the UN initiatives in this area. Witness of this is the recent resolution on the Promotion of inclusive and effective international tax cooperation at the United Nations. The topics of this resolution and the immediate intended deliverable are shown in Figure 15.1.

Figure 15.1: Topics in the international tax cooperation resolution
Figure 15.1: Topics in the international tax cooperation resolution

In a report to the G7 Finance Ministers and Central Bank Governors, the OECD (2022) upon request of the German G7 Presidency, has focussed on the further strengthening of international tax-cooperation, and recommendations for further action.

This report aims to assist developing countries in implementing the Two-Pillar Solution and builds upon a set of recommendations from the report Tax Co-operation for the 21st Century, OECD Report for the G7 Finance Ministers and Central Bank Governors.

Seen from the perspective of the CPIM, the ArchiMate implementation and migration viewpoint may look as in the figure below.

Figure 15.2: The Global tax portfolio
Figure 15.2: The Global tax portfolio

A wide range of taxes exist already as can be seen in enumeration 5153 - Duty or tax or fee type name code in the next figure.

Figure 15.3: The tax landscape as represented using EDIFACT data-elements
Figure 15.3: The tax landscape as represented using EDIFACT data-elements

The Two-Pillar solution does especially target MNE’s, yet we also include other businesses and households in the viewpoint because there are some impacts for them as well. At the same time the approach can be illustrated for all parties, and prepare also for the communication to them.

Figure 15.4: Global Tax programmes for MNE's
Figure 15.4: Global Tax programmes for MNE’s

To the section

15.1b - Goals of the Global Tax Stewart

The Global Anti-Base Erosion Rules (GloBE) are a key component of a plan to ensure that large multinational enterprise pay a minimum level of tax on the income arising in each of the jurisdictions where they operate.

GloBE can be seen as one programme in the global tax portfolio, one that targets at MNE’s.

More specifically, the GloBE Rules provide for a co-ordinated system of taxation that imposes a top-up tax on profits arising in a jurisdiction whenever the effective tax rate, determined on a jurisdictional basis, is below the minimum rate.

Broader target: #sdt171

Figure 15.5: Goals of the global tax adminstration steward
Figure 15.5: Goals of the global tax adminstration steward

To the section

15.1c - Goals of a Domestic Tax Administration Programme

Modify the domestic tax rules, filing procedures, systems and processes such that tax administration can fill its role in the Two-Pillar solution and align processes and filing requirements with international resources. Thus making compliance easy and low risk for all taxpayers, from natural persons to MNE’s.

Figure 15.6: Goals of a Domestic Tax Administration
Figure 15.6: Goals of a Domestic Tax Administration

To the section

15.1d - Goals of the MNE tax director tax compliance programme

Implement the new rules for compliance with tax rules, filing procedures, systems and processes such that tax administrations of all branches are supported in their tax interactions with the national jurisdictions where they operate, and the mother organization complies with and benefits from international standards in the area.

Figure 15.7: Goals of the MNE tax director tax compliance
Figure 15.7: Goals of the MNE tax director tax compliance

To the section

15.1e - Goals of the MNE branch tax division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework. Contribute national reports on transactions and to the MNE tax division.

See also Figure 15.7.

15.1f - Goals of a business tax division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework.

See also Figure 15.7.

15.1g - Goals of an income tax payer

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework.

See also Figure 15.7.

To the section - To the chapter


15.2 - The Stakeholders

To the chapter

15.2a. The Client

The tax administrations of over 135 jurisdictions which joined the ground breaking plan to update key elements of the international tax system which is no longer fit for purpose in a globalised and digitalised economy.

15.2b. The Customer

Tax administrations, MNE’s whose tax filing and payments are affected by the Global Anti-Base Erosion Rules, and all taxpayers.

15.2c. Other Stakeholders

At the “distributed” portfolio and programme level role or department names are used rather than person names.

Stakeholder 1: MNE central tax team

Field name Description
Stakeholder Name MNE central tax team
Stakeholder Class Sponsor
Stakeholder Role Oversee the compliance with the GloBE rules
Stakeholder Rationale Key impacted stakeholder
Involvement Estimate when and how much time the stakeholder should be involved in the requirements debate
Classes of knowledge  

Stakeholder 2: MNE country-level tax department

Field name Description
Stakeholder Name MNE country-level tax department
Stakeholder Class Sponsor and Functional beneficiary
Stakeholder Role Interacting with National tax-administration, compliance with national tax rules
Stakeholder Rationale What involvement does the stakeholder have in the requirements debate?
Involvement Estimate when and how much time the stakeholder should be involved in the requirements debate
Classes of knowledge Business constraints, Technical constraints, Functionality, Non-Functional requirements

Stakeholder 3: Country tax administrations

Field name Description
Stakeholder Name Tax administration(j)
Stakeholder Class Sponsor, Consultant and Functional Beneficiary
Stakeholder Role Alignment of national tax rules with (multi-lateral and remaining bi-lateral) treaties; fill the role of business manager, or membership of the business implementation group
Stakeholder Rationale What involvement does the stakeholder have in the requirements debate?
Involvement Gap analysis, (multi-year) roadmap and implmentation
Classes of knowledge Goals, Business constraints, Technical constraints, Functionality, Non-Functional requirements, Portfolio Issues

15.2d. The Hands-On Users of the Product

User 1: Tax Inspector

Field name Description
User name/category Tax inspector(J)
User role Active role in defined projects and iterations
Subject matter experience Master
Technological experience Current systems that must evolve
Other user characteristics Some aversion of innovation
Priority Key in each participating country
User participation Each country must choose champions to play key roles in clarifying business and functional requirements for the country
Non-functional requirements Domestically used languages
Portfolio Issues Give attention to continuing education and user documentation that keeps up with portfolio progress at the international and domestic levels

User 2: MNE Tax Director

(to be completed)

User 3: MNE Country(j) Tax Director

(to be completed)

Distinguish between small and big businesses.

(to be completed)

User 5: Household(n) in Country(j) Taxpayer Function

Distinguish between poor and rich households.

(to be completed)

15.2e. Personas

Fraudsters as well as people and companies, including MNE’s, that want to avoid paying their fair share of taxes are negative stakeholders that must be taken into consideration.

15.2f. Priorities Assigned to Users

Requirements of households, poor households in particular, must always have the highest priority as they have the least capabilities to compensate for poorly designed solutions.

15.2h. Maintenance Users and Service Technicians

(to be completed)

To the section - To the chapter


15.3 Mandated Constraints

At the portfolio level it is meaningful to list solution constraints, recommended implementation environments, off-the-shelf software and partner or collaborative applications made available publicly, or in the portfolio, schedule and enterprise constraints.

Anticipated workplace environment, schedule, budget and enterprise constraints should typically be elaborated at the programme or project level.

Figure 15.8: EIRA's simplified technical view - infrastructure
Figure 15.8: EIRA’s simplified technical view - infrastructure

Contemporary digital solutions eco-systems involve an extensive technology stack as is illustrated by the simplified technical view - infrastructure and technical view - application of the 3rd version of the European Interoperability Reference Architecture (EIRA) (currently in its 5th version).

Figure 15.9: EIRA's simplified technical view - application
Figure 15.9: EIRA’s simplified technical view - application

To the section - To the chapter


15.4. Naming Conventions and Terminology

To the chapter

15.4a - Glossary of All Terms, Including Acronyms, Used by Stakeholders involved in the Portfolio

At the portfolio level this chapter should include all the terms of the (multi- and bi-lateral) treaties with which alignment is pursued.

This glossary is best provided online.

It should also include the names of technical reference materials such as, for instance, those of the EDIFACT standard, the Open PM² Methods, and the European Interoperability Reference Architecture (EIRA):

To the section

15.4b - Abbreviations

Acronym Meaning
APAs Advance Pricing Agreements
ATAF African Tax Administration Forum
BEPS Base Erosion and Profit Shifting
CRS Common Reporting Standard
FTA Forum on Tax Administration
G20 Group of 20
G7 Group of 7
GVS Government Verification Service
ICAP International Compliance Assurance Programme
IMF International Monetary Fund
IT Information Technology
MAP Mutual Agreement Procedure
MNE Multinational Enterprise Group
OECD Organization for Economic Co-operation and Development
PAYE Pay As You Earn
TADAT Tax Administration Diagnostic Assessment Tool
TIWB Tax Inspectors Without Borders
UNDP United Nations Development Programme
VAT Value Added Tax
WBG World Bank Group
CE Constituent Entity
ETR Effective Tax Rate
GloBE Global Anti-Base Erosion
IFRS International Financial Reporting Standards
JV Joint Venture
MNE Multinational enterprise
UPE Ultimate Parent Entity

15.4c - Forms and Templates

Forms used to report events or file taxes.

Templates for frequently used communications.

To the section - To the chapter


15.5 - Relevant Facts and Assumptions

The reasoning that is made here is that the portfolio provides a conceptual model of a wide range of facts and business rules as captured in a sufficiently expressive conceptual domain model.

Because this document is intended as “portfolio requirements”, those facts and business rules are expressed in the following chapters.

The programmes and projects seeking support from the portfolio would then list those conceptual domain models as their initial relevant facts and business rules, and they would add facts and business rules that are specific to their scope of work.

To the chapter


15.6 - The Scope of the Work

The typical topics in this chapter include:

To the chapter

15.6a - The Current Situation

Differentiate it for the various portfolio stakeholders.

To the section - To the chapter

15.6a.1 - The Current Situation for the Global Tax Stewart
Figure 15.10: The current corporate tax landscape
Figure 15.10: The current corporate tax landscape

To the current situation

15.6a.2 - The Current Situation for the Domestic Tax Administration

Modify the domestic tax rules, filing procedures, systems and processes such that tax administration can fill its role in the Two-Pillar solution and align processes and filing requirements with international resources. Thus making compliance easy and low risk for all taxpayers, from natural persons to MNE’s.

Figure 15.11: The current situation for a Domestic Tax Administration
Figure 15.11: The current situation for a Domestic Tax Administration

To the current situation

15.6a.3 - The Current Situation for the MNE tax director

Implement the new rules for compliance with tax rules, filing procedures, systems and processes such that tax administrations of all branches are supported in their tax interactions with the national jurisdictions where they operate, and the mother organization complies with and benefits from international standards in the area.

To the current situation -

15.6a.4 - The Current Situation the MNE branch tax division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework. Contribute national reports on transactions and to the MNE tax division

15.6a.5 - The Current Situation for the Business Tax Division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework.

15.6a.6 - The Current Situation for an income tax payer

The income tax payer is confronted with multiple changes due to new sources of income, for instance as user of a digital platform, and the stacking of policies, including new taxes and tax deduction possibilities.

To the current situation - To the section - To the chapter

15.6b - The Context of the Work

In a global tax portfolio the focus in the context of the work is on a collaboration that involves taxes.

Here we consider one specific case, that of a Digital Platform Operator, and a taxpayer who is both employee and an income earning user of a digital platform.

Figure 15.12: The context of the work for a digital platform operator
Figure 15.12: The context of the work for a digital platform operator

The Pay-As-You-Earn or PAYE collaboration involving employer, employee and the tax administration is an important and easy-to-collect tax item. Its claim on the resources of the tax administration is limited, especially if the filing of declarations by employees is restricted to those who have significant other income or are entitled to significant special deductions, or both. A simple PAYE does not complicate the employer’s payroll administration. Compliance checks can focus on the employer, rather than on individual employees. Non-consolidation with other income is more acceptable if other income is also subject to withholding tax.

A new international cooperation Digital platform direct withholding (j)* extends the PAYE cooperation to income earned through digital platforms. This extension is possible once third parties, such as digital platform operators, and tax administrations have a common understanding of the identity of an individual or entity.

Information reporting flows can be improved, creating opportunities to apply the PAYE principles to this area. A holistic, technology-driven approach to tax compliance by design, can reduce the tax gap and the administrative costs of compliance for all parties involved. It can also increase tax certainty for taxpayers. For example, the verification of the identity of a user renting accommodation through a digital platform through a portal, the tax administration with taxing rights over the user could at the same time instruct the platform on the appropriate rate of withholding to be applied to the rental income generated by the user and to remit these taxes directly to the tax administration.

In the area of digital content creation, for instance on platforms such as OnlyFans, privacy is one of the important requirements. Content creators may not like that the source of their income is automatically disclosed to tax-administrations. Also as one creator may be active at different platforms, and given the proliferation of platforms, consolidation of the income is not evident.

Such requirements could be addressed in international treaties in which the payment processor is made responsible for distribution of a paid amount to the various rightholders.

In Figure 15.13 it is assumed that there is a 10% value added tax obligation to the country of residence for platform provider and content creator, and a 10% digital service tax obligation to the country where the service is consumed or purchased. In the example it is also assumed that the platform provider charges a 20% processing fee which includes the payment processing.

Figure 15.13: Imagining a multilateral treaty covering both value added (VAT) and digital services tax (DST)
Figure 15.13: Imagining a multilateral treaty covering both value added (VAT) and digital services tax (DST)

In summary, each payment generates a range of tax obligations. When there is an international treaty, these obligations could be handled by the payment processor which can also guarantee the usual confidentiality and privacy requirements. The payment processor can also generate monthly or quarterly VAT forms for the productive parties. Parties can use these forms in their VAT filing.

Figure 15.14: Pay-As-You-Earn in Digital Services (PAYED)
Figure 15.14: Pay-As-You-Earn in Digital Services (PAYED)

Similar to the Pillar Two GloBE Income Inclusion Rule which imposes top-up tax on a parent entity in respect of the low taxed income of a constituent entity, the tax that would be due to non-cooperating jurisdictions becomes due to the tax administrations in the cooperating jurisdictions. This situation is explained in Figure 15.15.

Figure 15.15: Non-cooperating jurisdictions in Pay-As-You-Earn in Digital Services (PAYED)
Figure 15.15: Non-cooperating jurisdictions in Pay-As-You-Earn in Digital Services (PAYED)

Another situation is the transfer of VAT for a VAT liable entity that is consuming digital services. This situation is explained in Figure 15.16.

Figure 15.16: VAT transfer in Pay-As-You-Earn in Digital Services (PAYED)
Figure 15.16: VAT transfer in Pay-As-You-Earn in Digital Services (PAYED)

To the section - To the chapter

15.6c - Work Partitioning: Business Events

To the chapter - To the section

In the PAYED collaboration only a few business events must be transformed to progress on the various courses of action depicted in Figure 15.13.

Figure 15.17: The Pay-As-You-Earn in Digital Services (PAYED) business events
Figure 15.17: The Pay-As-You-Earn in Digital Services (PAYED) business events

Whereas the figure provides a visual overview of the business events, it is recommended to provide a heading for each business event (type) within the scope of the portfolio and to provide meaningful details, including for instance the non-functional requirements (e.g. frequency) and issues (for instance that the fiscal periods (business event: end/start of fiscal period) are not aligned accross countries).

The effective money flows are depicted in Figure 15.18.

Figure 15.18: Money flows in Pay-As-You-Earn in Digital Services (PAYED)
Figure 15.18: Money flows in Pay-As-You-Earn in Digital Services (PAYED)

For each business event a template is completed.

Field name Description
Business event name The name(s) of the business event
Business object The business object that is involved in the occurrence of the business event
Product & interface The (business) product for, and/or the business interface via, which the business event will imply a need to perform
Initiating actor The (business) actor that will initiate the business event
Non-functional requirements List non-functional requirements that are specific and important for the business event, tag them as one or more of the listed types of non-functional requirements
Issues List issues that are specific and important for the business event, tag them as one or more of the listed types of issues

To the section - To the chapter

15.6c.1 - Tax administration registration
Field name Description
Business event name Tax administration registration
Business object The registration will follow upon the signing up of the country to the multilateral tax convention
Product & interface The instrument of joining the convention should include the details of the tax-administration that will collect the taxes that will be due under this convention
Initiating actor The government executive that deposits the instrument of joining the convention
Non-functional requirements The number of occurrences of this event is limited to the number of countries in the world
Issues For an actual real world example, check the website on the Inclusive Framework on Base Erosion and Profit Shifting

To the work partioning - To the section - To the chapter

15.6c.2 - Bank account registration
Field name Description
Business event name Bank account registration
Business object A bank account is needed for every agent who participates in the digital services economy.
Product & interface An agent usually has a bank account in the jurisdiction of residence or incorporation. Some jurisdictions require that one declares the ownership of accounts in other countries. It is assumed that a cooperative jurisdiction requires the bank to know the owner of the account. An agent may have multiple bank-accounts in multiple jurisdictions.
Initiating actor The agent who will participate in the digital services economy.
Business rules The account used for a payment will determine where the digital service tax of a purchase is due. If the jurisdiction is not cooperating under the convention the tax will be transferred to the cooperating jurisdiction(s) involved in the transaction. If a transaction involves only (accounts in) non-cooperating jurisdictions, then the tax is due to a global fund for the development of the least developed countries.
Non-functional requirements Globally there are billions of bank accounts with thousands of banks, and usually a bankaccount is owned for several years, even for the rest of the life of the registered owner. Banking activities meet strict security requirements. This makes banks or payment processors suitable partners in meeting additional requirements such as those of the PAYED collaboration.
Issues Note that the PAYED collaboration is a proposed collaboration. It is not implemented by any bank or payment processor. It is used as an illustration of a portfolio level functional requirements specification.

To the work partioning - To the section - To the chapter

15.6c.3 - Producer registration
Field name Description
Business event name Producer or Content Creator registration
Business object The registration of a “platform account” will enable the agent to receive payments for the content shared via the platform.
Product & interface The “platform account” should include details such as jurisdiction of residence, VAT or Tax Identification Number, and the bank account where payments are due, or that will be used for payments. It will also provide support for uploading content, and for performing certain interactions with subscribers.
Initiating actor The producer or content creator
Business rules The account used for receiving (and performing) payments will determine where the digital service and value added taxes are due. It could be a requirement that jurisdiction of residence is the same as that of the bank account used in the registration. The registration may involve the uploading of an identification document and the validation of the bank account.
Non-functional requirements The PAYED collaboration does not require disclosure of the platform or the services to the tax authorities where taxes are due.
Issues There are a large number of digital platforms where content creators could earn income from subscribers or in other digital value chains. For instance YouTube, Patreon, OnlyFans, LeanPub, Adsense, Facebook, LinkedIn. Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification.

To the work partioning - To the section - To the chapter

15.6c.4 - Private consumer registration
Field name Description
Business event name Private consumer registration
Business object The registration of a “platform account” will enable the consumer to buy digital services from the creators on the platform.
Product & interface The “platform account” should include details such as jurisdiction of residence, and the payment instrument that will be used for payments. It will also provide support for accessing content, and for performing certain interactions with creators.
Initiating actor The private consumer
Business rules The jurisdiction of the payment instrument (or linked account) will determine where the digital service taxes are due. It could be a requirement that jurisdiction of residence is the same as that of the payment instrument. The registration may involve the uploading of an identification document and a first payment which will validate the payment instrument.
Non-functional requirements The PAYED collaboration does not require disclosure of the platform or the services to the tax authorities where digital service taxes are due.
Issues There are a large number of digital platforms where private consumers could pay for digital services. For instance (add free) YouTube, Patreon, OnlyFans, LeanPub, Adwords, Facebook, LinkedIn. Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification.

To the work partioning - To the section - To the chapter

15.6c.5 - VAT liable consumer registration
Business event name VAT liable consumer registration
Business object The registration of a “platform account” will enable the VAT liable consumer to buy digital services from the creators on the platform.
Product & interface The “platform account” should include details such as jurisdiction of incorporation, VAT or Tax Identification Number, and the payment instrument that will be used for payments. It will also provide support for accessing content, and for performing certain interactions with creators.
Initiating actor The VAT liable consumer
Business rules The jurisdiction of the payment instrument (or linked account) should be the same as the issuer of the VAT or Tax Identification Number. These will determine where the digital service taxes are due, and if transfer of VAT is allowed. It could be a requirement that jurisdiction of incorporation is the same as that of the payment instrument. The registration may involve the uploading of VAT number so it can be verified and a first payment which will validate the payment instrument.
Non-functional requirements The PAYED collaboration does not require disclosure of the platform or the services to the tax authorities where digital service taxes are due.
Issues There are a large number of digital platforms where VAT liable consumer could pay for digital services. For instance (add free) YouTube, Patreon, OnlyFans, LeanPub, Adwords, Facebook, LinkedIn, but also hosting and cloud services. Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification.

To the work partioning - To the section - To the chapter

15.6c.6 - Digital Service Payment
Field name Description
Business event name Digital service payment
Business object A payment message combining features of the EDIFACT COPAYM (Contributions for payment) and PAYORD (Payment order message) messages
Product & interface The payment message supported by the digital platform and the payment processor should include all details that are relevant for the taxation and earnings in accordance with the multi-lateral convention
Initiating actor The buyer
Business rules The jurisdiction of the payment instrument (or linked account) should be the same as the issuer of the VAT or Tax Identification Number. These will determine where the digital service taxes are due, and if transfer of VAT is allowed. It could be a requirement that jurisdiction of incorporation is the same as that of the payment instrument. The registration may involve the uploading of VAT number so it can be verified and a first payment which will validate the payment instrument.
Non-functional requirements The number of payments to be processed will be quite large
Issues There are a large number of digital platforms where VAT liable consumer could pay for digital services. For instance (add free) YouTube, Patreon, OnlyFans, LeanPub, Adwords, Facebook, LinkedIn, but also hosting and cloud services. Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification.

To the work partioning - To the section - To the chapter

15.6c.7 - Periodic tax transfer
Field name Description
Business event name Periodic tax transfer
Business object An anonymized transaction list of the past period determines the amounts that must be paid to each tax administration.
Product & interface Each Payment Processor maintains for each tax administration a periodic anonymized transaction list that specifies the amounts that are due to it. The total of the list is transferred following each period, which could be a week, a month or a day.
Initiating actor The payment processor
Business rules The period chosen, and the details that must be included in the anonymized transaction list
Non-functional requirements The payment processor is preferred for this task to ensure the confidentiality; A periodic consolidation is preferred in order to avoid a large number of small payments to the tax administration account.
Issues Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification

To the work partioning - To the section - To the chapter

15.6c.8 - Prefilled tax declaration
Field name Description
Business event name Prefilled tax declaration
Business object Each participating tax administration can periodically, typically prior to the moment the tax declaration is due, use the received taxes for a person to complete the related items in the tax declaration.
Product & interface Each tax administration maintains the tax payments that are made on behalf of its constituents.
Initiating actor The participating tax administration
Business rules The period chosen, and the details that must be included in the personalized list of tax payments that however does not include the confidential details of the transactions for which the taxes are due
Non-functional requirements This service by the tax administration simplifies the tax filing for its constituents, for a tax item that could otherwise be very cumbersome.
Issues Note that the PAYED collaboration is a proposed collaboration. It is not implemented by platform. It is used as an illustration of a portfolio level functional requirements specification

To the work partioning - To the section - To the chapter


15.6d - Specifying the Business Use Cases (BUC)

Business Events trigger business use cases.

In a full specification of a completely new business use case, all fields in below table may be considered and descriptions provided.

So it is generally recommended to create a heading and complete a template for each (series of) business event(s). If much content has been captured in Archimate viewpoint diagrams, BPMN collaboration diagrams and UML class diagrams, then it not all that content should be repeated.

Field name Description
BUC Name The name of the BUC.
Category One of these options: core, supporting or management.
Trigger The business event(s) that initiate(s) the execution of the business use case.
Goals The “end state” that must be achieved following the initiation of the Use case. Reference can be made to performance indicators.
Primary Actor Who/what is the essential business actor or application component in the successful execution of the work.
Other Actors Who/what else is acting in this BUC? Besides referring to business actors and application components, you may refer to business roles and application functions.
Pre-conditions What conditions must be satisfied for this BUC to be triggered?
Post-conditions Successful the state after the successful execution of the BUC; and Alternative possible other states after the BUC completes.
Workflow-basic The expected or normal flow of events, if possible with annotation indicating service-requirements or automation possibilities. This flow could be described as a business process.
Alternative Workflows The possible alternative flows of events.
Business rules  
Business objects The business objects that are used by the BUC.
Non-functional requirements Description of, or references to relevant non-functional requirements.
Portfolio Issues Description of, or references to relevant portfolio, programme or project issues.

Quite often the readers of the business requirements document or the portfolio communications plan will not be novices in the area, and therefore the analysts may skip the textual explanation of some parts. Moreover, as many aspects of the specification are also included in the (semi-) formal domain and process models, the author may prefer not to repeat all clauses that are included in the models and their conventions.

If you are in the business of “decision making for society” and you haven’t learned yet how to read process and domain models, consider the old adage that exists in many languages: “A picture is worth a thousand words”. It means that complex and sometimes multiple ideas can be conveyed by a single still image, which conveys its meaning or essence more effectively than a mere verbal description.

ArchiMate, BPMN and UML models incorporate the know how of a generation of data, information, process and business analysis experts and professionals.

What I learned over many years of communication about complex problems is that these models, when used in a smart way, convey meaning and essence more effectively then tens of thousands of words.

So, if you are in the business of “decision making for society”, learning the language of these models will very much improve your ability to understand problems and to imagine and communicate about possible solutions. This then will contribute to better decisions about the way forward.

Nowadays, introductory texts and courses about ArchiMate, BPMN and UML models are abundant. With Archi for ArchiMate and Modelio for BPMN and UML excellent and stable open source tools are available for practicing these modeling techniques. One topic that is less covered in literature is the integration between BPMN process models and UML domain models. Early treatment of this topic can be found in the Specification of Information Systems lecture notes at the Eindhoven University of Technology (Aalst, Wil van der, et al, 2002) for which I wrote the chapter about “integrating information and process modeling” (Goossenaerts, 2002).

The scope of the domain model is determined by the collaboration described in Figure 15.19. This BPMN collaboration model expresses the key message exchanges between the various participants in the Pay-As-You-Earn Digital (PAYED) collaboration. Whereas in the figures 15.12 to 15.18 ArchiMate conventions were used to explain and illustrate possible tax domain decisions, we now move to the joint use of BPMN and UML to functionaly describe or specify the information exchanges and business processes that would realize or implement those decisions.

Figure 15.19: The Pay-As-You-Earn in Digital Services Collaboration in BPMN
Figure 15.19: The Pay-As-You-Earn in Digital Services Collaboration in BPMN

In Modelio 5.1 the participants and messages in this BPMN collaboration diagram can be linked to repectively process diagrams and data types. Each participants process diagram may be used to describe its business processes. As this is not the main focus at the portfolio level these processes are not elaborated here for now. In stead we move on to the domain models and (part of) the data dictionary.

To the section - To the chapter


15.7 - Domain Models and Data Dictionary

In the domain model we build upon a number of EDIFACT segments, as depicted in Figure 15.20 to capture information about:

  • parties as modelled in Figure 3.7 Classes of agents Chapter 3.5.2
  • collaborations in Sociotope and Technotope as modelled in Figure 3.8 Possible Collaboration Chapter 3.5.3
Figure 15.20: Some relevant EDIFACT Segments
Figure 15.20: Some relevant EDIFACT Segments

Note that the EDIFACT segments can be applied in a much wider range of interactions as already covered by the EDIFACT messages. Moreover, their variability as reflected in the enumerations, supports the application in a very wide range of new situations, as will be illustrated for one very particular case, the PAYED collaboration. The reader is encouraged to explore the use cases he or she is familiar with, by using the techniques illustrated here.

To the chapter

15.7a - Conceptual Domain Model

The conceptual domain model is one of the key assets that a portfolio can share to the participating parties. For the Global Tax Portfolio, it would typically include the classes of agents, the range of possible collaborations, and the tax name codes that are within the portfolio’s scope (See EDIFACT enumeration 5153, depicted in Figure 15.3 of section 15.1a - The User Business and Background of the Portfolio).

To the section - To the chapter


15.7b - Domain Data Model

The domain data model is based on the Conceptual Domain Model and is an area where international standards are required.

EDIFACT and the tax initiatives of the OECD pay attention to such standards.

It is recommended that the portfolio provide these standards as shared specifications and and as shared models in open source tools.

A header and a table for each relevant domain object, possibly to be supplemented with a UML model of the object and its relations to other key domain objects.

Field name Description
Name The name of the business object
Description The meaning of the BO; relevant characteristics
Business Rules What rules govern the creation, maintenance and access classification of the business object
Actors The actors that are interacting with the business object
Non-functional requirements Description of, or references to relevant non-functional requirements.
Portfolio Issues Description of, or references to relevant portfolio, programme or project issues.

To the section - To the chapter


15.7c - Data Dictionary

A list as part of the chapter, or as a separate excel, or a report based on the UML model.

A lot of content can be included in the models that are published in open source tools, so that they are available to all professionals that could be involved in the programmes, projects and iterations of the portfolio.

For examples, see Ag Data Commons: Data Dictionary - Examples.

To the section - To the chapter


15.8 - The Scope of the Product

To the chapter

15.8a - Product Boundary

A use case diagram identifies the boundaries between the users (actors) and the product you are about to build (this is sometimes called “the system”).

You arrive at the product boundary by inspecting each business use case and determining, together with the appropriate stakeholders, which part of the business use case should be automated (or satisfied by some sort of product) and which part must be done by the user.

This task must take into account:

There is a Product Use Case for each part of the business use case that must be automated.

The parts of the business use case that must be done by users must be addressed in the training and user documentation (Issue – Training and User Documentation ) by means of narratives and illustrations that explain the sequence of user and system tasks.

15.8b - Product Use Case Table

A table of all the Product Use Cases that must be developed or modified in the portfolio, programme, project or iteration.

15.8c - Individual Product Use Cases (PUC’s)

Usually product use cases are explained in more detail in a use case template, or in a UML Use Case diagram. Quite often they are fully specified in a dedicated document.

Include references if available.

The key benefit of having these use cases documented in modeling tool such as Modelio 5.1 is that changes in one of the aspects, for instance the information flows, are easily reflected in all views in which those changes have an impact. Moreover, the entire model can be navigated on the basis of dependencies between aspects.

The Modelio 5.1 use case diagram is illustrated in Annex 11 - The integration of process and information modeling in Modelio 5.1.

To the section - To the chapter


15.9 - Functional Requirements

Functional requirements are the fundamental or essential subject matter of the product. They describe what the product has to do or what processing actions it is to take.

In the CPIM approach, as a major share of functional requirements has been incorporated in the description of the context of the work, the business use cases, the data model and the product use cases, the focus in this chapter is on functional requirements that haven’t been captured yet in the previous specifications.

For each functional requirement a heading and a table, with as possible content at least:

  • a number #FR001,…
  • a name or title,
  • a priority (MOSCOW)
  • a description (with source and fit criterion)
  • references to the impacted business events, business use cases, data elements and product use cases.

Notice that business events, business use cases, data elements and product use cases will also include references to the functional requirements that must be considered during their design and implementation.

Further detail about a specific requirement can be supplemented in function of the “debate around the requirement”, and the degree to which the requirement will be met following the different iterations.

To the chapter


15.10 - Non-Functional Requirements

For each non-functional requirement a heading and a table, with at least for example:

  • a number #NFR01,…
  • a name or title,
  • a type - see Annex 2 - Types of Non Functional Requirements for possibilities
  • a description (with source and fit criterion)
  • references to the impacted business events, business use cases, data elements and product use cases.

Notice that business events, business use cases, data elements and product use cases will also include references to or information about the non-functional requirements that must be considered during their design and implementation.

One set of NFRs that is very relevant at the portfolio level are the Usability and Humanity Requirements which include the interface languages of a system.

It should be easy to add new languages to an interface that is intended to the public.

There exist specific interface design patterns that centralize the terms used in the interface in one or more tables that include internal codes and map these to terms in the languages for which the interface has been adapted. Such a pattern is illustrated in the elements as illustrated in Figure 15.21.

Figure 15.21: A design pattern for a multilingual interface
Figure 15.21: A design pattern for a multilingual interface

To the chapter


15.11 - Portfolio Issues

For each portfolio issue a heading and a table, with at least:

  • for example, a number PI 01,…
  • a name or title,
  • a type - see Annex 3 - Types of Issues in Portfolios, Programmes, Projects and Iterations for possibilities
  • a description
  • references to the impacted business events, business use cases, data elements and product use cases: those parts of the requirements specification will also include references to the issues that must be considered during their design and implementation.

Further detail can be supplemented in function of the type and impact of the issue and the degree to which the issue will be resolved in programmes, projects or iterations.

A minimal set of issues would include:

  • PI 01 – Training and User Documentation
  • PI 02 - Step-by-step migration plan

To the chapter


Part VI - Annexes


Annex 1 - Stakeholder Classes

Annex 2 - Types of Non Functional Requirements

Annex 3 - Types of Issues in Portfolios, Programmes, Projects and Iterations

Annex 4 - EDIFACT Message Directory

Annex 5 - EDIFACT Segment Directory

Annex 6 - EDIFACT Composite Data Elements

Annex 7 - EDIFACT Data Element Directory

Annex 8 - Roles and Deliverables in the Open PM² Methods

Annex 9 - Concepts, Viewpoints and Views of the European Interoperability Reference Architecture

Annex 10 - UML Models for some EDIFACT Segments

Annex 11 - The Integration of Process and Information Modeling in Modelio 5.1


To Part I - II - III - IV - V - VI-Annexes - VII-References


To Chapter 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 - Annexes


Annex 1 - Stakeholder Classes

Stakeholder Class Definition Examples  
Interfacing Technology - OWA (Operational Work Area) Any system within the Operational Work Area (software, hardware or mechanical) that must have a defined interface with the eventual solution Existing software, hardware or machines  
Interfacing Technology - CBE (Containing Business Environment) Any system within the Containing Business Environment that must have a defined interface with the eventual solution Existing software, hardware or machines, that can be accessed via networks including the internet  
Interfacing Technology - WE (Wider Environment) Any system within the Wider Environment that must have a defined interface with the eventual solution Existing software, hardware or machines, typically accessed via the internet or wide area networks  
Normal Operator/User Someone who uses the product to do work or to accomplish some purpose A citizen using Parliament Watch to ask a question to a politician, a moderator, a politician answering a question, …  
Maintenance Operator Someone who keeps the product operational according to agreed requirements    
Operational Support Helps the users to make effective use of the product help desk, trainer, coach/mentor  
Functional Beneficiary Does not have direct, hands-on contact with the product but benefits from the fact that it exists user of reports, programme manager,…  
Internal Consultant A person inside the organisation who provides knowledge and expertise necessary to quantify technical and business constraints future ideas specialist, data modeller, process analyst  
Sponsor The link between a project and the rest of the organisation. Helps to resolve problems and make decisions Sponsor, project champion  
External Consultant A person outside the organisation who provides knowledge and expertise necessary to quantify technical and business constraints auditor, legal specialist, inspector,…  
Negative Stakeholder A person or organisation who does not want the project to succeed competitor, hacker, …  
Team Member A person who is dedicated to working on the project project manager, business analyst, tester, systems architect  

Annex 2 - Types Non Functional Requirements

For examples and clarification of each type of non-functional requirement, see: Volere template

  1. Look and Feel Requirements
    • 10a. Appearance Requirements
    • 10b. Style Requirements
  2. Usability and Humanity Requirements
    • 11a. Ease of Use Requirements
    • 11b. Personalization and Internationalization Requirements
    • 11c. Learning Requirements
    • 11d. Understandability and Politeness Requirements
    • 11e. Accessibility Requirements
  3. Performance Requirements
    • 12a. Speed and Latency Requirements
    • 12b. Safety-Critical Requirements
    • 12c. Precision or Accuracy Requirements
    • 12d. Reliability and Availability Requirements
    • 12e. Robustness or Fault-Tolerance Requirements
    • 12f. Capacity Requirements
    • 12g. Scalability or Extensibility Requirements
    • 12h. Longevity Requirements
  4. Operational and Environmental Requirements
    • 13a. Expected Physical Environment
    • 13b. Wider Environment Requirements
    • 13c. Requirements for Interfacing with Adjacent Systems
    • 13d. Productization Requirements
    • 13e. Release Requirements
  5. Maintainability and Support Requirements
    • 14a. Maintenance Requirements
    • 14b. Supportability Requirements
    • 14c. Adaptability Requirements
  6. Security Requirements
    • 15a. Access Requirements
    • 15b. Integrity Requirements
    • 15c. Privacy Requirements
    • 15d. Audit Requirements
    • 15e. Immunity Requirements
  7. Cultural Requirements
    • 16a. Cultural Requirements
  8. Compliance Requirements
    • 17a. Legal Compliance Requirements
    • 17b. Standards Compliance Requirements

To table of annexes


Annex 3 - Types of Issues in Portfolios, Programmes, Projects and Iterations

For examples and clarification of each type of issue, see the Volere template.

  1. Open Issues
  2. Off-the-Shelf Solutions
    • 19a. Ready-Made Products
    • 19b. Reusable Components
    • 19c. Products That Can Be Copied
  3. New Problems
    • 20a. Effects on the Current Environment
    • 20b. Effects on the Installed Systems
    • 20c. Potential User Problems
    • 20d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
    • 20e. Follow-Up Problems
  4. Tasks
    • 21a. Portfolio Planning
    • 21b. Planning of the Development Phases
  5. Migration to the New Product
    • 22a. Requirements for Migration to the New Product
    • 22b. Data That Has to Be Modified or Translated for the New System
  6. Risks
  7. Costs
  8. User Documentation and Training
    • 25a. User Documentation Requirements
    • 25b. Training Requirements
  9. Waiting Room
  10. Ideas for Solutions

To table of annexes

Annex 4 - EDIFACT Message Directory

  • APERAK Application error and acknowledgement message
  • AUTHOR Authorization message
  • BALANC Balance message
  • BANSTA Banking status message
  • BAPLIE Bayplan/stowage plan occupied and empty locations message
  • BERMAN Berth management message
  • BMISRM Bulk marine inspection summary report message
  • BOPBNK Bank transactions and portfolio transactions report message
  • BOPCUS Balance of payment customer transaction report message
  • BOPDIR Direct balance of payment declaration message
  • BOPINF Balance of payment information from customer message
  • BUSCRD Business credit report message
  • CALINF Vessel call information message
  • CASINT Request for legal administration action in civil proceedings message
  • CASRES Legal administration response in civil proceedings message
  • CHACCO Chart of accounts message
  • CLASET Classification information set message
  • CNTCND Contractual conditions message
  • COACSU Commercial account summary message
  • COARRI Container discharge/loading report message
  • CODECO Container gate-in/gate-out report message
  • CODENO Permit expiration/clearance ready notice message
  • COEDOR Transport equipment stock and profile report message
  • COHAOR Container special handling order message
  • COLREQ Request for a documentary collection message
  • COMDIS Commercial dispute message
  • CONAPW Advice on pending works message
  • CONDPV Direct payment valuation message
  • CONDRA Drawing administration message
  • CONDRO Drawing organisation message
  • CONEST Establishment of contract message
  • CONITT Invitation to tender message
  • CONPVA Payment valuation message
  • CONQVA Quantity valuation message
  • CONRPW Response of pending works message
  • CONTEN Tender message
  • CONWQD Work item quantity determination message
  • COPARN Container announcement message
  • COPAYM Contributions for payment
  • COPINO Container pre-notification message
  • COPRAR Container discharge/loading order message
  • COREOR Container release order message
  • COSTCO Container stuffing/stripping confirmation message
  • COSTOR Container stuffing/stripping order message
  • CREADV Credit advice message
  • CREEXT Extended credit advice message
  • CREMUL Multiple credit advice message
  • CUSCAR Customs cargo report message
  • CUSDEC Customs declaration message
  • CUSEXP Customs express consignment declaration message
  • CUSPED Periodic customs declaration message
  • CUSREP Customs conveyance report message
  • CUSRES Customs response message
  • DAPLOS Data Plot Sheet
  • EBADV Debit advice message
  • DEBMUL Multiple debit advice message
  • DEBREC Debts recovery message
  • DELFOR Delivery schedule message
  • DELJIT Delivery just in time message
  • DESADV Despatch advice message
  • DESTIM Equipment damage and repair estimate message
  • DGRECA Dangerous goods recapitulation message
  • DIRDEB Direct debit message
  • DIRDEF Directory definition message
  • DMRDEF Data maintenance request definition message
  • DMSTAT Data maintenance status report/query message
  • DOCADV Documentary credit advice message
  • DOCAMA Advice of an amendment of a documentary credit message
  • DOCAMI Documentary credit amendment information message
  • DOCAMR Request for an amendment of a documentary credit message
  • DOCAPP Documentary credit application message
  • DOCARE Response to an amendment of a documentary credit message
  • DOCINF Documentary credit issuance information message
  • ENTREC Accounting entries message
  • FINCAN Financial cancellation message
  • FINPAY Multiple interbank funds transfer message
  • FINSTA Financial statement of an account message
  • GENRAL General purpose message
  • GESMES Generic statistical message
  • GOVCBR Government Cross Border Regulatory message
  • HANMOV Cargo/goods handling and movement message
  • ICASRP Insurance claim assessment and reporting message
  • ICSOLI Insurance claim solicitor’s instruction message
  • IFCSUM Forwarding and consolidation summary message
  • IFTCCA Forwarding and transport shipment charge calculation message
  • IFTDGN Dangerous goods notification message
  • IFTFCC International transport freight costs and other charges message
  • IFTICL Cargo insurance claims message
  • IFTMAN Arrival notice message
  • IFTMBC Booking confirmation message
  • IFTMBF Firm booking message
  • IFTMBP Provisional booking message
  • IFTMCA Consignment advice message
  • IFTMCS Instruction contract status message
  • IFTMIN Instruction message
  • IFTRIN Forwarding and transport rate information message
  • IFTSAI Forwarding and transport schedule and availability information message
  • IFTSTA International multimodal status report message
  • IFTSTQ International multimodal status request message
  • IMPDEF EDI implementation guide definition message
  • INFCON Infrastructure condition message
  • INFENT Enterprise accounting information message
  • INSDES Instruction to despatch message
  • INSPRE Insurance premium message
  • INSREQ Inspection request message
  • INSRPT Inspection report message
  • INVOIC Invoice message
  • INVRPT Inventory report message
  • IPPOAD Insurance policy administration message
  • IPPOMO Motor insurance policy message
  • ISENDS Intermediary system enablement or disablement message
  • ITRRPT In transit report detail message
  • JAPRES Job application result message
  • JINFDE Job information demand message
  • JOBAPP Job application proposal message
  • JOBCON Job order confirmation message
  • JOBMOD Job order modification message
  • JOBOFF Job order message
  • JUPREQ Justified payment request message
  • LEDGER Ledger message
  • LREACT Life reinsurance activity message
  • LRECLM Life reinsurance claims message
  • MEDPID Person identification message
  • MEDPRE Medical prescription message
  • MEDREQ Medical service request message
  • MEDRPT Medical service report message
  • MEDRUC Medical resource usage and cost message
  • MEQPOS Means of transport and equipment position message
  • MOVINS Stowage instruction message
  • MSCONS Metered services consumption report message
  • ORDCHG Purchase order change request message
  • ORDERS Purchase order message
  • ORDRSP Purchase order response message
  • OSTENQ Order status enquiry message
  • OSTRPT Order status report message
  • PARTIN Party information message
  • PAXLST Passenger list message
  • PAYDUC Payroll deductions advice message
  • PAYEXT Extended payment order message
  • PAYMUL Multiple payment order message
  • PAYORD Payment order message
  • PRICAT Price/sales catalogue message
  • PRIHIS Pricing history message
  • PROCST Project cost reporting message
  • PRODAT Product data message
  • PRODEX Product exchange reconciliation message
  • PROINQ Product inquiry message
  • PROSRV Product service message
  • PROTAP Project tasks planning message
  • PRPAID Insurance premium payment message
  • QALITY Quality data message
  • QUOTES Quote message
  • RDRMES Raw data reporting message
  • REBORD Reinsurance bordereau message
  • RECADV Receiving advice message
  • RECALC Reinsurance calculation message
  • RECECO Credit risk cover message
  • RECLAM Reinsurance claims message
  • RECORD Reinsurance core data message
  • REGENT Registration of enterprise message
  • RELIST Reinsured objects list message
  • REMADV Remittance advice message
  • REPREM Reinsurance premium message
  • REQDOC Request for document message
  • REQOTE Request for quote message
  • RESETT Reinsurance settlement message
  • RESMSG Reservation message
  • RETACC Reinsurance technical account message
  • RETANN Announcement for returns message
  • RETINS Instruction for returns message
  • RPCALL Repair call message* SAFHAZ Safety and hazard data message
  • SANCRT International movement of goods governmental regulatory message
  • SLSFCT Sales forecast message
  • SLSRPT Sales data report message
  • SOCADE Social administration message
  • SSIMOD Modification of identity details message
  • SSRECH Worker’s insurance history message
  • SSREGW Notification of registration of a worker message
  • STATAC Statement of account message
  • STLRPT Settlement transaction reporting message
  • SUPCOT Superannuation contributions advice message
  • SUPMAN Superannuation maintenance message
  • SUPRES Supplier response message
  • TANSTA Tank status report message
  • TAXCON Tax control message
  • TPFREP Terminal performance message
  • UTILMD Utilities master data message
  • UTILTS Utilities time series message
  • VATDEC Value added tax message
  • VERMAS Verified gross mass message
  • VESDEP Vessel departure message
  • WASDIS Waste disposal information message
  • WKGRDC Work grant decision message
  • WKGRRE Work grant request message

To table of annexes


Annex 5 - EDIFACT Segment Directory

  • ADR - Address
  • AGR - Agreement identification
  • AJT - Adjustment details
  • ALC - Allowance or charge
  • ALI - Additional information
  • APP - Applicability
  • APR - Additional price information
  • ARD - Monetary amount function
  • ARR - Array information
  • ASI - Array structure identification
  • ATT - Attribute
  • AUT - Authentication result
  • BAS - Basis
  • BGM - Beginning of message
  • BII - Structure identification
  • BUS - Business function
  • CAV - Characteristic value
  • CCD - Credit cover details
  • CCI - Characteristic/class id
  • CDI - Physical or logical state
  • CDS - Code set identification
  • CDV - Code value definition
  • CED - Computer environment details
  • CIN - Clinical information
  • CLA - Clause identification
  • CLI - Clinical intervention
  • CMP - Composite data element identification
  • CNI - Consignment information
  • CNT - Control total
  • COD - Component details
  • COM - Communication contact
  • COT - Contribution details
  • CPI - Charge payment instructions
  • CPS - Consignment packing sequence
  • CPT - Account identification
  • CST - Customs status of goods
  • CTA - Contact information
  • CUX - Currencies
  • DAM - Damage
  • DFN - Definition function
  • DGS - Dangerous goods
  • DII - Directory identification
  • DIM - Dimensions
  • DLI - Document line identification
  • DLM - Delivery limitations
  • DMS - Document/message summary
  • DOC - Document/message details
  • DRD - Data representation details
  • DSG - Dosage administration
  • DSI - Data set identification
  • DTM - Date/time/period
  • EDT - Editing details
  • EFI - External file link identification
  • ELM - Simple data element details
  • ELU - Data element usage details
  • ELV - Element value definition
  • EMP - Employment details
  • EQA - Attached equipment
  • EQD - Equipment details
  • EQN - Number of units
  • ERC - Application error information
  • ERP - Error point details
  • EVE - Event
  • FCA - Financial charges allocation
  • FII - Financial institution information
  • FNS - Footnote set
  • FNT - Footnote
  • FOR - Formula
  • FSQ - Formula sequence
  • FTX - Free text
  • GDS - Nature of cargo
  • GEI - Processing information
  • GID - Goods item details
  • GIN - Goods identity number
  • GIR - Related identification numbers
  • GOR - Governmental requirements
  • GPO - Geographical position
  • GRU - Segment group usage details
  • HAN - Handling instructions
  • HYN - Hierarchy information
  • ICD - Insurance cover description
  • IDE - Identity
  • IFD - Information detail
  • IHC - Person characteristic
  • IMD - Item description
  • IND - Index details
  • INP - Parties and instruction
  • INV - Inventory management related details
  • IRQ - Information required
  • LAN - Language
  • LIN - Line item
  • LOC - Place/location identification
  • MEA - Measurements
  • MEM - Membership details
  • MKS - Market/sales channel information
  • MOA - Monetary amount
  • MSG - Message type identification
  • MTD - Maintenance operation details
  • NAD - Name and address
  • NAT - Nationality
  • PAC - Package
  • PAI - Payment instructions
  • PAS - Attendance
  • PCC - Premium calculation component details
  • PCD - Percentage details
  • PCI - Package identification
  • PDI - Person demographic information
  • PER - Period related details
  • PGI - Product group information
  • PIA - Additional product id
  • PNA - Party identification
  • POC - Purpose of conveyance call
  • PRC - Process identification
  • PRI - Price details
  • PRV - Proviso details
  • PSD - Physical sample description
  • PTY - Priority
  • PYT - Payment terms
  • QRS - Query and response
  • QTY - Quantity
  • QUA - Qualification
  • QVR - Quantity variances
  • RCS - Requirements and conditions
  • REL - Relationship
  • RFF - Reference
  • RJL - Accounting journal identification
  • RNG - Range details
  • ROD - Risk object type
  • RSL - Result
  • RTE - Rate details
  • SAL - Remuneration type identification
  • SCC - Scheduling conditions
  • SCD - Structure component definition
  • SEG - Segment identification
  • SEL - Seal number
  • SEQ - Sequence details
  • SFI - Safety information
  • SGP - Split goods placement
  • SGU - Segment usage details
  • SPR - Organisation classification details
  • SPS - Sampling parameters for summary statistics
  • STA - Statistics
  • STC - Statistical concept
  • STG - Stages
  • STS - Status
  • TAX - Duty/tax/fee details
  • TCC - Charge/rate calculations
  • TDT - Transport information
  • TEM - Test method
  • TMD - Transport movement details
  • TMP - Temperature
  • TOD - Terms of delivery or transport
  • TPL - Transport placement
  • TRU - Technical rules
  • TSR - Transport service requirements
  • VLI - Value list identification

To table of annexes


Annex 6 - EDIFACT Composite Data Elements

  • C001 Transport means
  • C002 Document/message name
  • C003 Power type
  • C004 Event category
  • C008 Monetary amount function detail
  • C009 Information category
  • C010 Information type
  • C011 Information detail
  • C012 Processing indicator
  • C019 Payment terms
  • C030 Event type
  • C040 Carrier
  • C042 Nationality details
  • C045 Bill level identification
  • C049 Remuneration type identification
  • C056 Contact details
  • C058 Name and address
  • C059 Street
  • C063 Event identification
  • C076 Communication contact
  • C077 File identification
  • C078 Account holder identification
  • C079 Computer environment identification
  • C080 Party name
  • C082 Party identification details
  • C085 Marital status details
  • C088 Institution identification
  • C090 Address details
  • C099 File details
  • C100 Terms of delivery or transport
  • C101 Religion details
  • C106 Document/message identification
  • C107 Text reference
  • C108 Text literal
  • C128 Rate details
  • C138 Price multiplier information
  • C174 Value/range
  • C186 Quantity details
  • C200 Charge
  • C202 Package type
  • C203 Rate/tariff class
  • C205 Hazard code
  • C206 Identification number
  • C208 Identity number range
  • C210 Marks & labels
  • C211 Dimensions
  • C212 Item number identification
  • C213 Number and type of packages
  • C214 Special services identification
  • C215 Seal issuer
  • C218 Hazardous material
  • C219 Movement type
  • C220 Mode of transport
  • C222 Transport identification
  • C223 Dangerous goods shipment flashpoint
  • C224 Equipment size and type
  • C229 Charge category
  • C231 Method of payment
  • C232 Government action
  • C233 Service
  • C234 UNDG information
  • C235 Hazard identification placard details
  • C236 Dangerous goods label
  • C237 Equipment identification
  • C239 Temperature setting
  • C240 Characteristic description
  • C241 Duty/tax/fee type
  • C242 Process type and description
  • C243 Duty/tax/fee detail
  • C244 Test method
  • C246 Customs identity codes
  • C270 Control
  • C272 Item characteristic
  • C273 Item description
  • C279 Quantity difference information
  • C280 Range
  • C286 Sequence information
  • C288 Product group
  • C289 Tunnel Restriction
  • C290 Transport service
  • C329 Pattern description
  • C330 Insurance cover type
  • C331 Insurance cover details
  • C332 Sales channel identification
  • C333 Information request
  • C401 Excess transportation information
  • C402 Package type identification
  • C501 Percentage details
  • C502 Measurement details
  • C503 Document/message details
  • C504 Currency details
  • C506 Reference
  • C507 Date/time/period
  • C508 Language details
  • C509 Price information
  • C512 Size details
  • C514 Sample location details
  • C515 Test reason
  • C516 Monetary amount
  • C517 Location identification
  • C519 Related location one identification
  • C521 Business function
  • C522 Instruction
  • C523 Number of unit details
  • C524 Handling instructions
  • C525 Purpose of conveyance call
  • C526 Frequency details
  • C527 Statistical details
  • C528 Commodity/rate detail
  • C531 Packaging details
  • C532 Returnable package details
  • C533 Duty/tax/fee account detail
  • C534 Payment instruction details
  • C536 Contract and carriage condition
  • C537 Transport priority
  • C543 Agreement type identification
  • C545 Index identification
  • C546 Index value
  • C549 Monetary amount function
  • C550 Requirement/condition identification
  • C551 Bank operation
  • C552 Allowance/charge information
  • C553 Related location two identification
  • C554 Rate/tariff class detail
  • C555 Status
  • C556 Status reason
  • C564 Physical or logical state information
  • C585 Priority details
  • C593 Account identification
  • C595 Accounting journal identification
  • C596 Accounting entry type details
  • C601 Status category
  • C701 Error point details
  • C702 Code set identification
  • C703 Nature of cargo
  • C709 Message identifier
  • C770 Array cell details
  • C778 Position identification
  • C779 Array structure identification
  • C780 Value list identification
  • C782 Data set identification
  • C783 Footnote set identification
  • C784 Footnote identification
  • C785 Statistical concept identification
  • C786 Structure component identification
  • C811 Question details
  • C812 Response details
  • C814 Safety section
  • C815 Additional safety information
  • C816 Name component details
  • C817 Address usage
  • C818 Person inherited characteristic details
  • C819 Country subdivision details
  • C820 Premium calculation component
  • C821 Type of damage
  • C822 Damage area
  • C823 Type of unit/component
  • C824 Component material
  • C825 Damage severity
  • C826 Action
  • C827 Type of marking
  • C828 Clinical intervention details
  • C829 Sub-line information
  • C830 Process identification details
  • C831 Result details
  • C836 Clinical information details
  • C837 Certainty details
  • C838 Dosage details
  • C839 Attendee category
  • C840 Attendance admission details
  • C841 Attendance discharge details
  • C844 Organisation classification detail
  • C848 Measurement unit details
  • C849 Parties to instruction
  • C850 Status of instruction
  • C851 Risk object type
  • C852 Risk object sub-type
  • C853 Error segment point details
  • C878 Charge/allowance account
  • C889 Characteristic value
  • C901 Application error detail
  • C941 Relationship
  • C942 Membership category
  • C944 Membership status
  • C945 Membership level
  • C948 Employment category
  • C950 Qualification classification
  • C951 Occupation
  • C953 Contribution type
  • C955 Attribute type
  • C956 Attribute detail
  • C960 Reason for change
  • C961 Formula complexity
  • C970 Clause name
  • C971 Proviso type
  • C972 Proviso calculation
  • C973 Applicability type
  • C974 Basis type
  • C977 Period detail

To table of annexes


Annex 7 - EDIFACT Data Element Directory

  • 1000 - Document name
  • 1001 - Document name code
  • 1003 - Message type code
  • 1004 - Document identifier
  • 1049 - Message section code
  • 1050 - Sequence position identifier
  • 1052 - Message item identifier
  • 1054 - Message sub-item identifier
  • 1056 - Version identifier
  • 1058 - Release identifier
  • 1060 - Revision identifier
  • 1073 - Document line action code
  • 1082 - Line item identifier
  • 1131 - Code list identification code
  • 1145 - Traveller reference identifier
  • 1146 - Account name
  • 1147 - Account identifier
  • 1148 - Account abbreviated name
  • 1153 - Reference code qualifier
  • 1154 - Reference identifier
  • 1156 - Document line identifier
  • 1159 - Sequence identifier source code
  • 1170 - Accounting journal name
  • 1171 - Accounting journal identifier
  • 1218 - Document originals required quantity
  • 1220 - Document copies required quantity
  • 1222 - Configuration level number
  • 1225 - Message function code
  • 1227 - Calculation sequence code
  • 1228 - Action description
  • 1229 - Action code
  • 1230 - Allowance or charge identifier
  • 1312 - Consignment load sequence identifier
  • 1366 - Document source description
  • 1373 - Document status code
  • 1476 - Controlling agency identifier
  • 1490 - Consolidation item number
  • 1496 - Goods item number
  • 1501 - Computer environment details code qualifier
  • 1502 - Data format description
  • 1503 - Data format description code
  • 1505 - Value list type code
  • 1507 - Designated class code
  • 1508 - File name
  • 1510 - Computer environment name
  • 1511 - Computer environment name code
  • 1514 - Value list name
  • 1516 - File format name
  • 1518 - Value list identifier
  • 1520 - Data set identifier
  • 1523 - Message implementation identification code
  • 2000 - Date
  • 2002 - Time
  • 2005 - Date or time or period function code qualifier
  • 2009 - Terms time relation code
  • 2013 - Frequency code
  • 2015 - Despatch pattern code
  • 2017 - Despatch pattern timing code
  • 2018 - Age
  • 2023 - Period type code qualifier
  • 2029 - Time zone identifier
  • 2031 - Time variation quantity
  • 2116 - Time zone difference quantity
  • 2118 - Period detail description
  • 2119 - Period detail description code
  • 2148 - Date variation number
  • 2151 - Period type code
  • 2152 - Period count quantity
  • 2155 - Charge period type code
  • 2156 - Check-in time
  • 2160 - Days of week set identifier
  • 2162 - Journey leg duration quantity
  • 2164 - Millisecond time
  • 2379 - Date or time or period format code
  • 2380 - Date or time or period text
  • 2475 - Event time reference code
  • 3005 - Maintenance operation operator code
  • 3009 - Maintenance operation payer code
  • 3035 - Party function code qualifier
  • 3036 - Party name
  • 3039 - Party identifier
  • 3042 - Street and number or post office box identifier
  • 3045 - Party name format code
  • 3055 - Code list responsible agency code
  • 3077 - Test medium code
  • 3079 - Organisation classification code
  • 3082 - Organisational class name
  • 3083 - Organisational class name code
  • 3124 - Name and address description
  • 3126 - Carrier name
  • 3127 - Carrier identifier
  • 3131 - Address type code
  • 3139 - Contact function code
  • 3148 - Communication address identifier
  • 3153 - Communication medium type code
  • 3155 - Communication means type code
  • 3164 - City name
  • 3192 - Account holder name
  • 3194 - Account holder identifier
  • 3197 - Agent identifier
  • 3207 - Country identifier
  • 3222 - First related location name
  • 3223 - First related location identifier
  • 3224 - Location name
  • 3225 - Location identifier
  • 3227 - Location function code qualifier
  • 3228 - Country subdivision name
  • 3229 - Country subdivision identifier
  • 3232 - Second related location name
  • 3233 - Second related location identifier
  • 3236 - Sample location description
  • 3237 - Sample location description code
  • 3239 - Country of origin identifier
  • 3251 - Postal identification code
  • 3279 - Geographic area code
  • 3285 - Instruction receiving party identifier
  • 3286 - Address component description
  • 3289 - Person characteristic code qualifier
  • 3292 - Nationality name
  • 3293 - Nationality name code
  • 3295 - Name original alphabet code
  • 3299 - Address purpose code
  • 3301 - Enacting party identifier
  • 3310 - Inherited characteristic description
  • 3311 - Inherited characteristic description code
  • 3397 - Name status code
  • 3398 - Name component description
  • 3401 - Name component usage code
  • 3403 - Name type code
  • 3405 - Name component type code qualifier
  • 3412 - Contact name
  • 3413 - Contact identifier
  • 3432 - Institution name
  • 3433 - Institution name code
  • 3434 - Institution branch identifier
  • 3436 - Institution branch location name
  • 3446 - Party tax identifier
  • 3449 - Bank identifier
  • 3452 - Language name
  • 3453 - Language name code
  • 3455 - Language code qualifier
  • 3457 - Originator type code
  • 3459 - Frequent traveller identifier
  • 3460 - Given name
  • 3463 - Gate identifier
  • 3465 - In-house identifier
  • 3475 - Address status code
  • 3477 - Address format code
  • 3478 - Marital status description
  • 3479 - Marital status description code
  • 3480 - Person job title
  • 3482 - Religion name
  • 3483 - Religion name code
  • 3493 - Nationality code qualifier
  • 3496 - Sales channel identifier
  • 3499 - Gender code
  • 3500 - Family name
  • 3503 - Access authorisation identifier
  • 3504 - Given name title description
  • 3507 - Benefit coverage constituents code
  • 4009 - Option code
  • 4017 - Delivery plan commitment level code
  • 4018 - Related information description
  • 4022 - Business description
  • 4025 - Business function code
  • 4027 - Business function type code qualifier
  • 4035 - Priority type code qualifier
  • 4036 - Priority description
  • 4037 - Priority description code
  • 4038 - Additional safety information description
  • 4039 - Additional safety information description code
  • 4043 - Trade class code
  • 4044 - Safety section name
  • 4046 - Safety section number
  • 4048 - Certainty description
  • 4049 - Certainty description code
  • 4051 - Characteristic relevance code
  • 4052 - Delivery or transport terms description
  • 4053 - Delivery or transport terms description code
  • 4055 - Delivery or transport terms function code
  • 4056 - Question description
  • 4057 - Question description code
  • 4059 - Clause code qualifier
  • 4065 - Contract and carriage condition code
  • 4068 - Clause name
  • 4069 - Clause name code
  • 4071 - Proviso code qualifier
  • 4072 - Proviso type description
  • 4073 - Proviso type description code
  • 4074 - Proviso calculation description
  • 4075 - Proviso calculation description code
  • 4078 - Handling instruction description
  • 4079 - Handling instruction description code
  • 4148 - Information category description
  • 4149 - Information category description code
  • 4150 - Information detail description
  • 4151 - Information detail description code
  • 4153 - Information details code qualifier
  • 4183 - Special condition code
  • 4184 - Special requirement description
  • 4187 - Special requirement type code
  • 4215 - Transport charges payment method code
  • 4219 - Transport service priority code
  • 4221 - Discrepancy nature identification code
  • 4233 - Marking instructions code
  • 4237 - Payment arrangement code
  • 4276 - Payment terms description
  • 4277 - Payment terms description identifier
  • 4279 - Payment terms type code qualifier
  • 4294 - Change reason description
  • 4295 - Change reason description code
  • 4343 - Response type code
  • 4344 - Response description
  • 4345 - Response description code
  • 4347 - Product identifier code qualifier
  • 4383 - Bank operation code
  • 4400 - Instruction description
  • 4401 - Instruction description code
  • 4403 - Instruction type code qualifier
  • 4404 - Status description
  • 4405 - Status description code
  • 4407 - Sample process step code
  • 4415 - Test method identifier
  • 4416 - Test description
  • 4419 - Test administration method code
  • 4424 - Test reason name
  • 4425 - Test reason name code
  • 4431 - Payment guarantee means code
  • 4435 - Payment channel code
  • 4437 - Account type code qualifier
  • 4439 - Payment conditions code
  • 4440 - Free text
  • 4441 - Free text description code
  • 4447 - Free text format code
  • 4451 - Text subject code qualifier
  • 4453 - Free text function code
  • 4455 - Back order arrangement type code
  • 4457 - Substitution condition code
  • 4461 - Payment means code
  • 4463 - Intra-company payment indicator code
  • 4465 - Adjustment reason description code
  • 4467 - Payment method code
  • 4469 - Payment purpose code
  • 4471 - Settlement means code
  • 4472 - Information type
  • 4473 - Information type code
  • 4474 - Accounting entry type name
  • 4475 - Accounting entry type name code
  • 4487 - Financial transaction type code
  • 4493 - Delivery instruction code
  • 4494 - Insurance cover description
  • 4495 - Insurance cover description code
  • 4497 - Insurance cover type code
  • 4499 - Inventory movement reason code
  • 4501 - Inventory movement direction code
  • 4503 - Inventory balance method code
  • 4505 - Credit cover request type code
  • 4507 - Credit cover response type code
  • 4509 - Credit cover response reason code
  • 4510 - Requested information description
  • 4511 - Requested information description code
  • 4513 - Maintenance operation code
  • 4517 - Seal condition code
  • 4519 - Definition identifier
  • 4521 - Premium calculation component identifier
  • 4522 - Premium calculation component value category identifier
  • 4525 - Seal type code
  • 5004 - Monetary amount
  • 5006 - Monetary amount function description
  • 5007 - Monetary amount function description code
  • 5013 - Index code qualifier
  • 5025 - Monetary amount type code qualifier
  • 5027 - Index type identifier
  • 5030 - Index text
  • 5039 - Index representation code
  • 5047 - Contribution code qualifier
  • 5048 - Contribution type description
  • 5049 - Contribution type description code
  • 5104 - Monetary amount function detail description
  • 5105 - Monetary amount function detail description code
  • 5118 - Price amount
  • 5125 - Price code qualifier
  • 5152 - Duty or tax or fee type name
  • 5153 - Duty or tax or fee type name code
  • 5160 - Total monetary amount
  • 5189 - Allowance or charge identification code
  • 5213 - Sub-line item price change operation code
  • 5237 - Charge category code
  • 5242 - Rate or tariff class description
  • 5243 - Rate or tariff class description code
  • 5245 - Percentage type code qualifier
  • 5249 - Percentage basis identification code
  • 5261 - Charge unit code
  • 5263 - Rate type identifier
  • 5267 - Service type code
  • 5273 - Duty or tax or fee rate basis code
  • 5275 - Supplementary rate or tariff code
  • 5278 - Duty or tax or fee rate
  • 5279 - Duty or tax or fee rate code
  • 5283 - Duty or tax or fee function code qualifier
  • 5284 - Unit price basis quantity
  • 5286 - Duty or tax or fee assessment basis quantity
  • 5289 - Duty or tax or fee account code
  • 5305 - Duty or tax or fee category code
  • 5307 - Tax or duty or fee payment due date code
  • 5314 - Remuneration type name
  • 5315 - Remuneration type name code
  • 5375 - Price type code
  • 5377 - Price change type code
  • 5379 - Product group type code
  • 5387 - Price specification code
  • 5388 - Product group name
  • 5389 - Product group name code
  • 5393 - Price multiplier type code qualifier
  • 5394 - Price multiplier rate
  • 5402 - Currency exchange rate
  • 5419 - Rate type code qualifier
  • 5420 - Unit price basis rate
  • 5463 - Allowance or charge code qualifier
  • 5479 - Relation code
  • 5482 - Percentage
  • 5495 - Sub-line indicator code
  • 5501 - Rate plan code
  • 6000 - Latitude degree
  • 6002 - Longitude degree
  • 6008 - Height measure
  • 6029 - Geographical position code qualifier
  • 6060 - Quantity
  • 6063 - Quantity type code qualifier
  • 6064 - Variance quantity
  • 6066 - Control total quantity
  • 6069 - Control total type code qualifier
  • 6071 - Frequency code qualifier
  • 6072 - Frequency rate
  • 6074 - Confidence percent
  • 6077 - Result representation code
  • 6079 - Result normalcy code
  • 6082 - Dosage description
  • 6083 - Dosage description identifier
  • 6085 - Dosage administration code qualifier
  • 6087 - Result value type code qualifier
  • 6096 - Altitude
  • 6113 - Length type code
  • 6140 - Width measure
  • 6145 - Dimension type code qualifier
  • 6152 - Range maximum quantity
  • 6154 - Non-discrete measurement name
  • 6155 - Non-discrete measurement name code
  • 6162 - Range minimum quantity
  • 6167 - Range type code qualifier
  • 6168 - Length measure
  • 6173 - Size type code qualifier
  • 6174 - Size measure
  • 6176 - Occurrences maximum number
  • 6178 - Edit field length measure
  • 6182 - Diameter measure
  • 6245 - Temperature type code qualifier
  • 6246 - Temperature degree
  • 6311 - Measurement purpose code qualifier
  • 6313 - Measured attribute code
  • 6314 - Measure
  • 6321 - Measurement significance code
  • 6331 - Statistic type code qualifier
  • 6341 - Exchange rate currency market identifier
  • 6343 - Currency type code qualifier
  • 6345 - Currency identification code
  • 6347 - Currency usage code qualifier
  • 6348 - Currency rate
  • 6350 - Units quantity
  • 6353 - Unit type code qualifier
  • 6410 - Measurement unit name
  • 6411 - Measurement unit code
  • 6412 - Clinical information description
  • 6413 - Clinical information description identifier
  • 6415 - Clinical information type code qualifier
  • 6426 - Process stages quantity
  • 6428 - Process stages actual quantity
  • 6432 - Significant digits quantity
  • 6434 - Statistical concept identifier
  • 7001 - Physical or logical state type code qualifier
  • 7006 - Physical or logical state description
  • 7007 - Physical or logical state description code
  • 7008 - Item description
  • 7009 - Item description code
  • 7011 - Item availability code
  • 7036 - Characteristic description
  • 7037 - Characteristic description code
  • 7039 - Sample selection method code
  • 7040 - Power type description
  • 7041 - Power type code
  • 7045 - Sample state code
  • 7047 - Sample direction code
  • 7059 - Class type code
  • 7064 - Type of packages
  • 7065 - Package type description code
  • 7073 - Packaging terms and conditions code
  • 7075 - Packaging level code
  • 7077 - Description format code
  • 7081 - Item characteristic code
  • 7083 - Configuration operation code
  • 7085 - Cargo type classification code
  • 7088 - Dangerous goods flashpoint description
  • 7102 - Shipping marks description
  • 7106 - Shipment flashpoint degree
  • 7110 - Characteristic value description
  • 7111 - Characteristic value description code
  • 7124 - United Nations Dangerous Goods (UNDG) identifier
  • 7130 - Customer shipment authorisation identifier
  • 7133 - Product details type code qualifier
  • 7134 - Product name
  • 7135 - Product identifier
  • 7139 - Product characteristic identification code
  • 7140 - Item identifier
  • 7143 - Item type identification code
  • 7160 - Special service description
  • 7161 - Special service description code
  • 7164 - Hierarchical structure level identifier
  • 7166 - Hierarchical structure parent identifier
  • 7168 - Level number
  • 7171 - Hierarchical structure relationship code
  • 7173 - Hierarchy object code qualifier
  • 7175 - Rule part identifier
  • 7176 - Risk object sub-type description
  • 7177 - Risk object sub-type description identifier
  • 7179 - Risk object type identifier
  • 7186 - Process type description
  • 7187 - Process type description code
  • 7188 - Test method revision identifier
  • 7190 - Process description
  • 7191 - Process description code
  • 7224 - Package quantity
  • 7233 - Packaging related description code
  • 7240 - Item total quantity
  • 7273 - Service requirement code
  • 7293 - Sector area identification code qualifier
  • 7294 - Requirement or condition description
  • 7295 - Requirement or condition description identifier
  • 7297 - Set type code qualifier
  • 7299 - Requirement designator code
  • 7357 - Commodity identification code
  • 7361 - Customs goods identifier
  • 7364 - Processing indicator description
  • 7365 - Processing indicator description code
  • 7383 - Surface or layer code
  • 7402 - Object identifier
  • 7405 - Object identification code qualifier
  • 7418 - Hazardous material category name
  • 7419 - Hazardous material category name code
  • 7429 - Indexing structure code qualifier
  • 7431 - Agreement type code qualifier
  • 7433 - Agreement type description code
  • 7434 - Agreement type description
  • 7436 - Level one identifier
  • 7438 - Level two identifier
  • 7440 - Level three identifier
  • 7442 - Level four identifier
  • 7444 - Level five identifier
  • 7446 - Level six identifier
  • 7449 - Membership type code qualifier
  • 7450 - Membership category description
  • 7451 - Membership category description code
  • 7452 - Membership status description
  • 7453 - Membership status description code
  • 7455 - Membership level code qualifier
  • 7456 - Membership level description
  • 7457 - Membership level description code
  • 7458 - Attendee category description
  • 7459 - Attendee category description code
  • 7491 - Inventory type code
  • 7493 - Damage details code qualifier
  • 7495 - Object type code qualifier
  • 7497 - Structure component function code qualifier
  • 7500 - Damage type description
  • 7501 - Damage type description code
  • 7502 - Damage area description
  • 7503 - Damage area description code
  • 7504 - Unit or component type description
  • 7505 - Unit or component type description code
  • 7506 - Component material description
  • 7507 - Component material description code
  • 7508 - Damage severity description
  • 7509 - Damage severity description code
  • 7511 - Marking type code
  • 7512 - Structure component identifier
  • 7515 - Structure type code
  • 7517 - Benefit and coverage code
  • 8015 - Traffic restriction code
  • 8017 - Traffic restriction application code
  • 8022 - Freight and other charges description
  • 8023 - Freight and other charges description identifier
  • 8024 - Conveyance call purpose description
  • 8025 - Conveyance call purpose description code
  • 8028 - Means of transport journey identifier
  • 8035 - Traffic restriction type code qualifier
  • 8051 - Transport stage code qualifier
  • 8053 - Equipment type code qualifier
  • 8066 - Transport mode name
  • 8067 - Transport mode name code
  • 8077 - Equipment supplier code
  • 8078 - Additional hazard classification identifier
  • 8092 - Hazard code version identifier
  • 8101 - Transit direction indicator code
  • 8126 - Transport emergency card identifier
  • 8154 - Equipment size and type description
  • 8155 - Equipment size and type description code
  • 8158 - Orange hazard placard upper part identifier
  • 8169 - Full or empty indicator code
  • 8178 - Transport means description
  • 8179 - Transport means description code
  • 8186 - Orange hazard placard lower part identifier
  • 8211 - Hazardous cargo transport authorisation code
  • 8212 - Transport means identification name
  • 8213 - Transport means identification name identifier
  • 8215 - Transport means change indicator code
  • 8216 - Journey stops quantity
  • 8219 - Traveller accompanied by infant indicator code
  • 8246 - Dangerous goods marking identifier
  • 8249 - Equipment status code
  • 8255 - Packing instruction type code
  • 8260 - Equipment identifier
  • 8273 - Dangerous goods regulations code
  • 8275 - Container or package contents indicator code
  • 8281 - Transport means ownership indicator code
  • 8323 - Transport movement code
  • 8332 - Equipment plan description
  • 8334 - Movement type description
  • 8335 - Movement type description code
  • 8339 - Packaging danger level code
  • 8341 - Haulage arrangements code
  • 8351 - Hazard identification code
  • 8364 - Emergency procedure for ships identifier
  • 8393 - Returnable package load contents code
  • 8395 - Returnable package freight payment responsibility code
  • 8410 - Hazard medical first aid guide identifier
  • 8453 - Transport means nationality code
  • 8457 - Excess transportation reason code
  • 8459 - Excess transportation responsibility code
  • 8461 - Tunnel Restriction Code
  • 8462 - Transport service identification code
  • 8463 - Transport service name
  • 8464 - Transport service description
  • 9003 - Employment details code qualifier
  • 9004 - Employment category description
  • 9005 - Employment category description code
  • 9006 - Qualification classification description
  • 9007 - Qualification classification description code
  • 9008 - Occupation description
  • 9009 - Occupation description code
  • 9012 - Status reason description
  • 9013 - Status reason description code
  • 9015 - Status category code
  • 9017 - Attribute function code qualifier
  • 9018 - Attribute description
  • 9019 - Attribute description code
  • 9020 - Attribute type description
  • 9021 - Attribute type description code
  • 9023 - Definition function code
  • 9025 - Definition extent code
  • 9026 - Edit mask format identifier
  • 9029 - Value definition code qualifier
  • 9031 - Edit mask representation code
  • 9035 - Qualification application area code
  • 9037 - Qualification type code qualifier
  • 9038 - Facility type description
  • 9039 - Facility type description code
  • 9040 - Reservation identifier
  • 9043 - Reservation identifier code qualifier
  • 9045 - Basis code qualifier
  • 9046 - Basis type description
  • 9047 - Basis type description code
  • 9048 - Applicability type description
  • 9049 - Applicability type description code
  • 9051 - Applicability code qualifier
  • 9141 - Relationship type code qualifier
  • 9142 - Relationship description
  • 9143 - Relationship description code
  • 9146 - Composite data element tag identifier
  • 9148 - Directory status identifier
  • 9150 - Simple data element tag identifier
  • 9153 - Simple data element character representation code
  • 9156 - Simple data element maximum length measure
  • 9158 - Simple data element minimum length measure
  • 9161 - Code set indicator code
  • 9162 - Data element tag identifier
  • 9164 - Group identifier
  • 9166 - Segment tag identifier
  • 9169 - Data representation type code
  • 9170 - Event type description
  • 9171 - Event type description code
  • 9172 - Event
  • 9173 - Event description code
  • 9175 - Data element usage type code
  • 9213 - Duty regime type code
  • 9280 - Validation result text
  • 9282 - Validation key identifier
  • 9285 - Validation criteria code
  • 9302 - Sealing party name
  • 9303 - Sealing party name code
  • 9308 - Transport unit seal identifier
  • 9321 - Application error code
  • 9353 - Government procedure code
  • 9411 - Government involvement code
  • 9415 - Government agency identification code
  • 9417 - Government action code
  • 9419 - Service layer code
  • 9421 - Process stage code qualifier
  • 9422 - Value text
  • 9424 - Array cell data description
  • 9426 - Code value text
  • 9428 - Array cell structure identifier
  • 9430 - Footnote set identifier
  • 9432 - Footnote identifier
  • 9434 - Code name
  • 9436 - Clinical intervention description
  • 9437 - Clinical intervention description code
  • 9441 - Clinical intervention type code qualifier
  • 9443 - Attendance type code qualifier
  • 9444 - Admission type description
  • 9445 - Admission type description code
  • 9446 - Discharge type description
  • 9447 - Discharge type description code
  • 9448 - File generation command name
  • 9450 - File compression technique name
  • 9453 - Code value source code
  • 9501 - Formula type code qualifier
  • 9502 - Formula name
  • 9505 - Formula complexity code
  • 9507 - Formula sequence code qualifier
  • 9509 - Formula sequence operand code
  • 9510 - Formula sequence name
  • 9601 - Information category code
  • 9605 - Data code qualifier
  • 9607 - Yes or no indicator code
  • 9619 - Adjustment category code
  • 9620 - Policy limitation identifier
  • 9623 - Diagnosis type code
  • 9625 - Related cause code
  • 9627 - Admission source code
  • 9629 - Procedure modification code
  • 9631 - Invoice type code
  • 9635 - Event details code qualifier
  • 9636 - Event category description
  • 9637 - Event category description code
  • 9639 - Diagnosis category code
  • 9641 - Service basis code qualifier
  • 9643 - Supporting evidence type code qualifier
  • 9645 - Payer responsibility level code
  • 9647 - Cavity zone code
  • 9649 - Processing information code qualifier

To table of annexes


Annex 8 - Roles and Deliverables in the Open PM² Methods

Below figures give an overview of the deliverables and roles in the Open Project Management Methodology (PM²) series by the European Commission Centre of Excellence in Project Management (European Commission, 2021 and 2022):

  • PM² Project Management Methodology - Guide 3.0.1.
  • PM² Programme Management - Guide 1.0
  • PM² Portfolio Management 1.5
Figure A8.1 - Portfolio management deliverables
Figure A8.1 - Portfolio management deliverables
Figure A8.2 - Programme management deliverables
Figure A8.2 - Programme management deliverables
Figure A8.3 - Project management deliverables
Figure A8.3 - Project management deliverables
Figure A8.4 - Portfolio management roles
Figure A8.4 - Portfolio management roles
Figure A8.5 - Programme management roles
Figure A8.5 - Programme management roles
Figure A8.6 - Project management roles
Figure A8.6 - Project management roles

To table of annexes


Annex 9 - Concepts, Viewpoints and Views of the European Interoperability Reference Architecture

The European Interoperability Reference Architecture (EIRA©) is a reference architecture that is focused on the interoperability of digital public services, each of which may have its own level of scope and (enterprise) architecture.

It is composed of the most salient Architecture Building Blocks (ABBs) (model elements) needed to promote cross-border and cross-sector interactions between public administrations.

Its current release is EIRA_v5_0_0.

It has the viewpoints and views shown in Figure A9.1.

Figure A9.1 - EIRA viewpoints and views
Figure A9.1 - EIRA viewpoints and views

Figure A9.2 shows the EIRA Legal view.

Figure A9.2 - EIRA Legal view
Figure A9.2 - EIRA Legal view

To table of annexes


Annex 10 - UML Models for some EDIFACT Segments

Figure A10.1 shows the content of the EDIFACT ADR - Address segment.

Figure A10.1 - The EDIFACT ADR - Address Segment
Figure A10.1 - The EDIFACT ADR - Address Segment

Figure A10.2 shows the content of the EDIFACT NAD - Name and address segment.

Figure A10.2 - The EDIFACT NAD - Name and address Segment
Figure A10.2 - The EDIFACT NAD - Name and address Segment

Figure A10.3 shows the content of the EDIFACT PNA - Party identification segment.

Figure A10.3 - The EDIFACT PNA - Party identification Segment
Figure A10.3 - The EDIFACT PNA - Party identification Segment

Figure A10.4 shows the content of the EDIFACT MOA - Monetary amount segment.

Figure A10.4 - The EDIFACT MOA - Monetary amount Segment
Figure A10.4 - The EDIFACT MOA - Monetary amount Segment

Figure A10.5 shows the content of the EDIFACT TAX segment.

Figure A10.5 - The EDIFACT TAX Segment
Figure A10.5 - The EDIFACT TAX Segment

Figure A10.6 shows the content of the EDIFACT FII - Financial institution information segment.

Figure A10.6 - The EDIFACT FII - Financial institution information Segment
Figure A10.6 - The EDIFACT FII - Financial institution information Segment

Figure A10.7 shows the content of the EDIFACT RFF - Reference segment.

Figure A10.7 - The EDIFACT RFF - Reference Segment
Figure A10.7 - The EDIFACT RFF - Reference Segment

To table of annexes


Annex 11 - The Integration of Process and Information Modeling in Modelio 5.1

Modelio 5.1 is an open source modeling tool that supports the integration between BPMN process models and UML information models in a specification that is at the level of the “Computation Independent Model” (see chapter 3.6 - Models and Model Layers). The utility of such an integration has been described in Goossenaerts (2002) using UML and Hierarchical Petri-Nets. Unhappily, up to now, I don’t know of introductory texts explaining a similar integration between process models expressed in BPMN and information models expressed using UML class diagrams.

Annex 11.1 Modelio 5.1 Basics

This annex briefly explains how Modelio 5.1 supports the integration specification.

The diagrams supported in Modelio 5.1’s UML and BPMN Modeler Module are depicted in Figure A11.1

Figure A11.1 - Diagrams in Modelio 5.1's UML and BPMN Modeler Module
Figure A11.1 - Diagrams in Modelio 5.1’s UML and BPMN Modeler Module

For an integration specification at the conceptual level, we need:

  • BPMN Collaboration diagram
  • BPMN Process diagrams
  • Class diagrams
  • Use Case diagrams

Figure A11.2 illustrates a simple collaboration involving three participants, and four kinds of message flows.

Figure A11.2 - The BPMN Collaboration diagram in Modelio 5.1
Figure A11.2 - The BPMN Collaboration diagram in Modelio 5.1

Figure A11.3 shows the facilities for creating a BPMN process model. These are comparable with most BPMN process modeling tools.

Figure A11.3 - The BPMN Process diagram in Modelio 5.1
Figure A11.3 - The BPMN Process diagram in Modelio 5.1

Figure A11.4 shows the facilities for creating a UML Class Diagram. These are comparable with those of several other UML modeling tools.

Figure A11.4 - The UML Class diagram in Modelio 5.1
Figure A11.4 - The UML Class diagram in Modelio 5.1

Use a UML Class diagram to model the statical aspects of an information system.

Use a BPMN Collaboration diagram and process diagrams to model the dynamics of a system.

Annex 11.2 Support for the Integration Specification

In this annex, we address the integration specification connecting both models as supported in Modelio 5.1. An integration specification consists of linking messages and object stores of the process model to a data-types or a class in the information model. In the specification each task in the process model can also be linked to a use-case or to an operation of a class or data-type.

Figure A11.5 shows the collaboration of a library. The exchanges are shown as information flows, but may also involve the borrowed books for instance.

Figure A11.5 - The public library collaboration
Figure A11.5 - The public library collaboration

Figure A11.6 shows the domain model for the potential patrons of a library. This model shows a lot of options regarding several information fields, such as the identification document, or the way in which the address or contact information is composed.

Figure A11.6 - The public library domain - patrons
Figure A11.6 - The public library domain - patrons

Figure A11.7 shows the data that the library wants to include in the registration form. The registration form conveys specific choices regarding address, identification documents that may be checked to confirm autenticity of the patron data, etc.

Figure A11.7 - The public library domain - registration form
Figure A11.7 - The public library domain - registration form

Figure A11.8 shows the binding of the information flow “Registration” to a message which in its turn is bound to the RegistrationForm defined in Figure A11.7.

Figure A11.8 - The public library collaboration "with registration form"
Figure A11.8 - The public library collaboration “with registration form”

Figure A11.9 shows a Use Case diagram in which the handling of the registration, online or at the desk, is linked to information items “completedForm” and “memberList”, which in their turn are bound to the data types “RegistrationForm” and “Members” that are defined in Figure A11.7.

Figure A11.9 - The Use Case diagram  "with registration form"
Figure A11.9 - The Use Case diagram “with registration form”

The further elaboration of the case follows the common steps. To appreciate the support of Modelio 5.1 for the integration specification, it is recommended to get your hands on the tool and check a few introductory videos to get acquainted with the interface.

To table of annexes

Part VII - References


To Part I - II - III - IV - V - VI-Annexes - VII-References


Aalst, W. van der, Wagner, G. & Goossenaerts, J. (2002) Specification of Information Systems, Lecture Notes. Technische Universiteit Eindhoven, Faculteit Technologie Management.

Abramov, V.A., J.B.M. Goossenaerts, P. De Wilde, L. Correia (2005) Ontological stratification in an ecology of infohabitants, in: E. Arai, J. Goossenaerts, F. Kimura, K. Shirase (eds) Knowledge and Skill Chains in Engineering and Manufacturing: Information Infrastructure in the Era of Global Communications, Springer pp. 101-109.

Acemoglu, Daron and James Robinson (2009) Foundations of societal inequality. Science, 326(5953):678–679, October 2009; http://www.sciencemag.org/cgi/content/summary/326/5953/678

Ackoff, R.L. (1970) A Concept of Corporate Planning, Wiley-Interscience, 1970.

Adair, John (2009) Effective Decision Making - The Essential Guide to Thinking for Management Success (Revised edition).

Aerts, A.T.M., J.B.M. Goossenaerts, D.K. Hammer, J.C. Wortmann (2004) Architectures in context: on the evolution of business, application software, and ICT platform architectures. Information & Management 41 (6) (2004) 781-794.

Alter, S (2003) 18 reasons why IT-reliant work-systems should replace the “IT-artifact” as the core subject matter of the IS field. Communications of the Association for Information Systems, Vol. 12, 2003, pp. 366-395.

Ambler, S.W., J. Nalbone, M. Vizdos (2005) Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall, Englewood Cliffs, NJ.

Banks, J. (2000) Introduction to Simulation. Proceedings of the winter simulation conference, J.A. Joines, R. R. Barton, K. Kang, and P.A. Fishwick, eds. Pages 9-16.

Banks, J., J.S. Carson II, B. L. Nelson and D. M. Nicol (2001) Discrete-event system simulation. Third edition. Prentice-Hall, ISBN 0-13-088702-1.

Bassogly, N., T. Daim, O. Kerimoglu (2007) Organizational adoption of enterprise resource planning systems: a conceptual framework. Journal of High Technology Management Research 18, p. 73-97.

Bekkers, R., B. Verspagen, & Smits, J. (2002) Intellectual Property Rights and Standardization: the case of GSM. Telecommunications Policy, 26 (3/4).

Bellamy Foster, John & Brett Clark (2009) The Paradox of Wealth: Capitalism and Ecological Destruction, Monthly Review, 61(6). url

Bernard, S.A. (2004) An Introduction to Enterprise Architecture EA3, Authorhouse, Bloomington, IN.

Berre, A.-J., B. Elvesæter, B. Nordmoen, J. Oldevik, O. Sims, C. Sluman, A. Solberg, S. Tyndale-Biscoe, B. Wood, J. Ø. Aagedal (2007) COMET – Component and Model-based development Methodology; Methodology Handbook.

Bertrand, J.W.M. and Fransoo, J.C. (2002) Modeling and Simulation – Operations Management research methodologies using quantitative techniques, Int. J. of Operations & Production Management, Vol. 22, no. 2.

Bertsimas, D., Freund, R.M. (2000) Data, Models, and Decisions: The Fundamentals of Management Science, South-Western College Publishing, Thomson Learning.

Borja, D., J. F. Redondo Sánchez, A. Seco, S. Velazquez, R. Zambrano eds. (2020) ICT as a Strategic Tool to Leapfrog the Efficiency of Tax Administrations, Inter-American Center of Tax Administrations-CIAT, Panama City, ISBN: 978-9962-722-07-6.

Bossel, H. (1999) Indicators for Sustainable Development: Theory, Method, Applications. The International Institute for Sustainable Development (IISD). URL

Bostrom, R.P. and J.S. Heinen (1977) MIS Problems and Failures: A Socio-Technical Perspective. PART I: The Causes. MIS Quarterly, 1(3), December 1997, pp. 17-32.

Bota-Genoulaz, V. , P.-A. Millet, B. Grabot (2005) A survey on the recent research literature on ERP systems, Computers in Industry 56 (6) pp. 510-522.

Calon, M. (1986) The Sociology of an Actor-Network: The Case of the Electric Vehicle. In Calon, M., J. Law and A. Rip (1986) Mapping the Dynamics of Science and Technology - Sociology of Science in the Real World. The McMillan Press Ltd. pp. 19-34.

Chambers R. and Gordon R. Conway (1991) Sustainable rural livelihoods: practical concepts for the 21st century. Institute of Development Studies, url.

Cochran, D.S., Arinez, J.F., Duda, J.W., & Linck, J. (2001) A decomposition approach for manufacturing system design. Journal of Manufacturing Systems, 20 (6).

European Commission, Council of the European Union, Directorate-General for Informatics (2021) PM² Programme management : guide 1.0, Publications Office of the European Union, https://data.europa.eu/doi/10.2799/193169

European Commission, Council of the European Union, Directorate-General for Informatics, General Secretariat of the Council (2022) PM² Portfolio management guide 1.5, Publications Office of the European Union, https://data.europa.eu/doi/10.2799/311760

European Commission, Directorate-General for Informatics (2021) The PM²-Agile guide 3.0.1, Publications Office of the European Union, https://data.europa.eu/doi/10.2799/162784

European Commission, Directorate-General for Informatics (2021) PM² Project management methodology : guide 3.0.1, Publications Office of the European Union, https://data.europa.eu/doi/10.2799/08869

Dick, J., Chard, J. (2003) Requirements-driven and Model-driven Development: Combining the Benefits of Systems Engineering, Telelogic White Paper, www.telelogic.com.

Djankov, S., Glaeser, E., La Porta, R., Lopez-de-Silanes, F., Shleifer, A. (2003) The New Comparative Economics. Journal of Comparative Economics 31, pp. 595-619.

Dulong de Rosnay, M. & Stalder, F. (2020) Digital commons. Internet Policy Review, 9(4). https://doi.org/10.14763/2020.4.1530

Educational Business Articles (2022) The Change Management Process: Linking the Steps to Successful Change. Accessed December 1, 2022. url

Eijnatten, F.M. van, & Goossenaerts, J.B.M. (2004) Towards human-profile based operations in advanced factory governance systems: Contemporary challenges for socio-technical systems design? In: Arai, E., & Arai, T. (Eds.), Proceedings of the 5th International Conference on Machine Automation ICMA 2004: Mechatronics for safety, security, and dependability in new era (pp. 529-534). Osaka, Japan: Osaka University Press.

Ehrbar, Al. (1998) EVA economic value added – the real key to creating wealth, Wiley, New York.

Elgarah, W., N. Falaleeva, C.S. Saunders, V. Ilie, J.T. Shim and J.F. Courtney (2005) Data Exchange in InterorganizationalRelationships: Review Through Multiple Conceptual Le nses. The DATA BASE for Advances in Information Systems – Winter 2005, 36(1) pp. 8 – 29.

Engelhardt, F. and Nordlund, M. (2000) Strategic planning based on axiomatic design, Proceedings of ICAD2000 – 1st International Conference on Axiomatic Design, Cambridge MA, June 21-23, 2000, pp. 26-34.

Feez, S. (2007) Montessori’s mediation of meaning: a social semiotic perspective. Ph.D. thesis, University of Sydney. URL

Fehr, E., K.M. Schmidt (1999) A theory of fairness, competition and cooperation, The Quarterly Journal of Economics 114 (3) pp. 817-868.

Fishwick, Paul A. (1994) Simulation Model Design and Execution. Prentice Hall.

Frischmann, Brett M. (2005) An Economic Theory of Infrastructure and Commons Management. Minnesota Law Review, Vol. 89, pp. 917-1030. Available at SSRN

Geels, F.W. & J. Schot (2007) Typology of sociotechnical transition pathways. Research Policy 36, pp. 399-417.

Gogg, T.J., and J.R.A. Mott (1996) Improve quality & productivity with Simulation. Third edition, JMI Consulting Group, USA, ISBN 1-882229-03-7.

Goossenaerts, J.B.M. (2000) Industrial Semiosis - towards a Foundation for Deploying the Ubiquitous Information Infrastructure, Computers in Industry 43 (2) pp. 189-201.

Goossenaerts, J.B.M. (2002) Integrating Information and Process Modeling. Part IV (page 317-378) of Aalst, W. van der, Wagner, G. & Goossenaerts, J. (2002) Specification of Information Systems, Lecture Notes. Eindhoven Univ. of Technology. Available at ResearchGate.

Goossenaerts, J.B.M. (2004) Interoperability in the Model Accelerated Society, in: P. Cunningham and M. Cunningham, eAdoption and the Knowledge Economy: Issues, Applications, Case Studies. IOS Press Amsterdam, pp. 225-232.

Goossenaerts, J. (2007) Institutions for Pro-Growth Conduct in the Knowledge Economy, (SSRN url)

Goossenaerts, J.B.M., M. Dreverman, J.M. Smits, P.W.H.M. van Exel (2009a) Plant Lifecycle Data Standards in the Process Industry: Diagnosis and Resolution of Collective Action Failure. Available at SSRN: url

Goossenaerts, J. and C. Pelletier (2002) Ontological Commitment for Participative Simulation. In: Arisawa, H., Kambayashi, Y., Kumar, V., Mayr, H.C., Hunt, I. (eds) Conceptual Modeling for New Information Systems Technologies. ER 2001. Lecture Notes in Computer Science, vol 2465. Springer, Berlin, Heidelberg. https://doi.org/10.1007/3-540-46140-X_11

Goossenaerts, J., F. Possel-Dölken, K. Popplewell (2007a) Vision, Trends, Gaps and a Broad Road Map for Future Engineering. International Journal of e-Collaboration 3(4) pp. 1-20

Goossenaerts, Jan, Robbert Van Leijsen, Arjan Gelderblom (2007b) Perspectives on the e-Maintenance Transition. Research Gate url.

Goossenaerts, J.B.M., A.T.M. Zegers, J.M. Smits (2009b) A Multi-Level Model-Driven Regime for Value-Added Tax Compliance in ERP Systems, Computers in Industry, Volume 60, Issue 9, December 2009, pp. 709-727.

Griep, P.A.M. and Flapper, S.D.P. (1987) Discrete Simulatie (met een inleiding in SIMULA), Academic Service.

Guizzardi, G. and G. Wagner (2012) Tutorial: Conceptual simulation modeling with Onto-UML. Proceedings of the 2012 Winter Simulation Conference, DOI: 10.1109/WSC.2012.6465328.

Haegele, T., Klink, J. (1998) Das Added-Value-Network Konzept (The Added Value Network Concept); Fraunhofer Institute for Manufacturing Engineering and Automation (IPA), Stuttgart.

Hee, K.M. van (1994) Information Systems Engineering: A Formal Approach, Cambridge University Press, Cambridge.

Her Majesty Revenue & Customs (2007) Regulatory Impact Assessment; VAT: Reverse charge accounting for businesses trading in mobile phones and computer chips.

Hess C. and E. Ostrom (2007) Understanding Knowledge as a Commons: From Theory to Practice. The MIT Press.

Hoekstra, R., J.P. Smits, K. Boone, W. van Everdingen, F. Mawire, B. Buck, A. Beutling and K. Kriege (2014) Reporting on sustainable development at national, company and product levels: The potential for alignment of measurement systems in a post-2015 world. Report by Statistics Netherlands, Global Reporting Initiative and The Sustainability Consortium url

International Chamber of Commerce (ICC) (1999) Incoterms2000 Transport Obligations, Costs and Risks, ICC publication No. 614., ICC Publishing, Paris, France.

ISO/FDIS 15704: Industrial automation systems — Requirements for enterprise-reference architectures and methodologies

Jacobs, S (2007) How Broad-based Reforms Succeed in Changing the Business Environment: The Strategic Use of Drivers of Change, Jacobs & Associates, Washington DC.

Kapczynski, A., Krikorian, G. (Eds.) (2010) Access to knowledge in the age of intellectual property. Zone Books.

Kaplan R.S., D. P. Norton (1993) The Balanced Scorecard - Measures that Drive Performance. Harvard Business Review, January/February 1993.

Kelton, W.D., R.P. Sadowski. D.A. Sadowski (1998) Simulation with JaamSim. 1998. Companies. ISBN 0-07-027509-2.

Law A.M. and W. D. Kelton (2000) Simulation, Modelling and Analysis. Third edition. McGraw-Hill series. ISBN 0-07-059292-6.

Lee, Hau L. and Özer, Ö. (2005) Unlocking the value of RFID, Graduate School of Business, Stanford University.

Lyytinen, K., M. Newman (2008) Explaining Information System Change as a Punctuated Socio-Technical Change, European Journal of Information Systems 17, pp. 589–613.

Markus, L.M., C.S. Steinfield, R.T. Wigand, G. Minton (2006) Industry-wide information systems standardization as collective action: the case of the U.S. Residential Mortgage Industry, MIS Quarterly 30 (Special Issue, August), pp. 439-465.

Mehta, A. (2000) Smart Modeling – Basic methodology and advanced tools. Proceedings of the winter simulation conference, J.A. Joines, R. R. Barton, K. Kang, and P.A. Fishwick, eds. pp. 241 – 245.

Miller, J., J. Mukerji (eds.) (2003) MDA Guide Version 1.0.1, OMG, Object Management Group.

Mingers, J. (2003) A classification of the philosophical assumptions of management science methods. Journal of the Operational Research Society, 54, pp. 559-570

Mittra, J., Tait, J. (2012) Analysing stratified medicine business models and value systems: innovation-regulation interactions. New Biotechnology, March issue.

Mulder, Monique B., Samuel Bowles, Tom Hertz, Adrian Bell, Jan Beise, Greg Clark, Ila Fazzio, Michael Gurven, Kim Hill, Paul L. Hooper, William Irons, Hillard Kaplan, Donna Leonetti, Bobbi Low, Frank Marlowe, Richard McElreath, Suresh Naidu, David Nolin, Patrizio Piraino, Rob Quinlan, Eric Schniter, Rebecca Sear, Mary Shenk, Eric A. Smith, Christopher von Rueden, and Polly Wiessner (2009) Intergenerational wealth transmission and the dynamics of inequality in small-scale societies. Science, 326(5953):682–688, October 2009.

Nagamatsu, A., C. Watanabe, K.L. Shum (2006) Diffusion trajectory of self-propagating innovations interacting with institutions – incorporation of multi-factors learning function to model PV diffusion in Japan. Energy Policy, 34, pp. 411-421.

Nonaka, I., Konno, N. (1998) The Concept of “Ba”: Building a Foundation for Knowledge Creation, California Management Review 40(3) pp.40-54.

Nonaka, I., Toyama, R., Konno, N. (2000) SECI, ba and leadership: a unified model of dynamic knowledge creation. Long Range Planning 33 (1) pp. 5–34.

North, D.C. (1990) Institutions, Institutional Change and Economic Performance. Cambridge. Cambridge University Press.

North, Wallis and Weingast (2009) Violence and Social Orders - A Conceptual Framework for Interpreting Recorded Human History, Cambridge University Press.

Object Management Group (OMG) (2005) OCL 2.0 Specification. OMG document ptc/2005-06-06.

OECD (2022) Tax Co-operation for the 21st Century: OECD Report for the G7 Finance Ministers and Central Bank Governors, May 2022, Germany, OECD, Paris, url.

Oosterom, P. van, C. Lemmen, T. Ingvarsson, P. van der Molen, H. Ploeger, W. Quak, J. Stoter, J. Zevenbergen (2006) The core cadastral domain model. Computers, Environment and Urban Systems 30 (2006) pp. 627-660.

Op den Kamp, M.J.M. (2004) Ontwikkeling van een multi-inzetbaar model bij Kappa Packaging, Graduation thesis, Eindhoven University of Technology, Dept. of Technology Management.

Ostrom, E. (1999) Institutional rational choice: an assessment of the IAD framework. In: P. Sabatier, Editor, Theories of the Policy Process, Westview Press, Boulder, Colorado, pp. 35–71.

Payne, J. W., J. R. Bettman & E. J. Johnson (1992) Behavioral decision research: A constructive processing perspective. Annual Review of Psychology, Vol. 43, pp. 87–132.

Pels, H. J. and J. Goossenaerts (2007) A conceptual modeling technique for discrete event simulation of operational processes. In: Olhager J. and F. Persson (eds.) Advances in Production Management Systems, IFIP vol. 246, Springer.

Pidd, M. (1998) Computer simulation in management science. 4th edition. John Wiley & Sons. ISBN 0-471-97931-7.

Plieninger, Ralf, Urs Muller, Hans Ehm, and Werner Reczek (2001) Cost Reduction using Systematic Target Setting of the Reference Fab Methodology, Proceedings of the 2001 IEEE/SEMI Advanced Semiconductor Manufacturing Conference, IEEE, pp. 17-20.

Public-Private Infrastructure Advisory Facility (PPIAF) (2014) Unsolicited Proposals – An Exception to Public Initiation of Infrastructure PPPs - An Analysis of Global Trends and Lessons Learned. url

Reed, Nick and Ihnen, Bernd (2021) Design Principles for Business Capability Maps (Part 1), Bizzdesign Blog

Robinson, S. (2011) Choosing the right model: Conceptual modeling for simulation. Proceedings of the 2011 Winter Simulation Conference, DOI: 10.1109/WSC.2011.6147862.

Robyn S. Wilson and Jeremy T. Bruskotter (2009) Assessing the Impact of Decision Frame and Existing Attitudes on Support for Wolf Restoration in the United States, Human Dimensions of Wildlife, Vol. 14 pp. 353-365.

Rogers, E.M. (1962) Diffusion of Innovations, The Free Press.

Rudd, M.A. (2004) An institutional framework for designing and monitoring ecosystem-based fisheries management policy experiments, Ecological Economics, Volume 48, Issue 1, pp. 109-124.

Sadowsky D.A., and M.R. Grabau (2000) Tips for a successful practice of Simulation. Proceedings of the winter Simulation conference, J.A. Joines, R. R. Barton, K. Kang, and P.A. Fishwick, eds. Pages 26 – 31.

Scheer, A.-W. (1989) Enterprise-Wide Data Modeling – Information Systems in Industry, Springer-Verlag, Berlin.

Schnetzler, M., Sennheiser, A. and Weidemann, M. (2004) Supply Chain Strategies for Business Success, in Cunningham, P. and Cunningham, M. eAdoptation and the Knowledge Economy: Issues, Applications, Case Studies, IOS Press Amsterdam, 2004, pp. 1231-1238.

Schot, J., R. Hoogma, B. Elzen (1994) Strategies for shifting technological systems: the case of the automobile system, Futures 26 (10) pp. 1060–1076.

Simons, Janet A., Irwin, Donald B. and Drinnien, Beverly A. (1987) Psychology - The Search for Understanding.

Slovic, Paul (1995) The Construction of Preference, American Psychologist, Vol. 50, no. 5, pp. 364-371.

Shiller, Robert J. (2003) The New Financial Order – Risk in the 21st Century. Princeton University Press, Princeton and Oxford.

Strien, P.J. van (1997) Towards a Methodology of Psychological Practice, the Regulative Cycle, Theory and Psychology 7 (5) pp. 683-700.

Suh, N.P. (2001) Axiomatic design – Advances and applications, New York (etc.), Oxford University Press.

Thuronyi, V. (2001) International Tax Cooperation and a Multilateral Treat, 26 Brooklyn Journal of International Law 26(4). url

Trienekens, Jos J. M., Rob J. Kusters, Ben Rendering and Kees Stokla (2005) Business-oriented process improvement: practices and experiences at Thales Naval The Netherlands (TNNL), Information and Software Technology, Volume 47, Issue 2, pp. 67-79.

Tversky, Amos and Daniel Kahneman (1981) The Framing of Decisions and the Psychology of Choice, Science, New Series, Vol. 211, No. 4481, pp. 453-458.

Ulgen, O.M., J. J. Black, B. Johnsonbaugh and R. Klungle (1994a) Simulation methodology in practice – Part I: Planning for the study. International Journal of Industrial Engineering, Vol 1, Number 2, pp. 119–128.

Ulgen, O.M., J. J. Black, B. Johnsonbaugh and R. Klungle (1994b) Simulation methodology in practice – Part II: Selling the results. International Journal of Industrial Engineering, Vol 1, Number 2, pp. 129–137.

United Nations Economic Commission for Europe (UNECE) (2019) Generic Activity Model for Statistical Organisations - GAMSO (Version 1.2, January 2019) url

USAID website (2021a) Results Framework (RF), url (accessed April 24,2021)

USAID website (2021b) Country Development Cooperation Strategies (CDCS), url (accessed April 24,2021)

Virkkunen, J. and K. Kuutti (2000) Understanding organizational learning by focusing on “activity systems”. Accounting, Management and Information Technologies, vol. 10, no. 4, pp. 291-319.

Warmer, J. and A. Kleppe (1999) The Object Constraint Language: precise modeling with UML, Addison-Wesley.

Watson, E.E., H. Schneider (1998) Using ERP in Education, Communications of the Association for Information Systems.

Whitten, J.L, L.D. Bentley and K.C. Dittman (2004) Systems Analysis and Design Methods, 6th edition, McGraw Hill, Irwin, Boston.

Williams, T.J., Bernus, B., Brosvic, J., Chen, D., Doumeingts, G., Nemes, L., Nevins, J.L., Vallespir, B., Vlietstra, J., and Zoetekouw, D. (1994) Architectures for integrating manufacturing activities and enterprises, Computers in Industry, 24, (2-3).

World Bank Group (2014) Public-private partnerships: reference guide version 2.0 (English). Washington, D.C. : World Bank Group. url.

WTO (1995) TRIPS, Agreement on Trade-Related Aspects of Intellectual Property Rights (pdf).

Yamada, S. (2002) Challenges in Dealing with Human Factors Issues in Manufacturing Activities. In: Arisawa, H., Kambayashi, Y., Kumar, V., Mayr, H.C., Hunt, I. (eds) Conceptual Modeling for New Information Systems Technologies. ER 2001. Lecture Notes in Computer Science, vol 2465. Springer, Berlin, Heidelberg. https://doi.org/10.1007/3-540-46140-X_2

Zachman, J.A. (1987) A framework for information systems architecture. IBM Systems Journal 26 (3) pp. 276-292.

Zegers, A.T.M (2007) Omzetbelastingwetgeving en ERP systemen – een overbrugbare kloof? Unpublished master’s thesis, Eindhoven University of Technology, the Netherlands. * * *

About the author

The author
The author

Jan Goossenaerts is a social media entrepreneur and a business and architecture consultant specialized in aligning ICT and communications solutions to organizational and societal needs. In 2012 he founded Wikinetix which became a finalist in the 2012 Social Media Leadership Awards. In order to catalyse further the instructive and productive use of the internet and social media he invented #tagcoding and launched the Actor Atlas and the #xy2wiki programme.

Mastodon: @jagoo@mastodon.social

Twitter: @collaboratewiki and @ActorAtlas (Actor Atlas)

LinkedIn: Jan Goossenaerts

ORCID: Jan Goossenaerts