MAP for Digital Transformation – Laboratory of Architectural and Technological Governance

Methodology, Architecture and Practice (MAP) for Digital Transformation is a series of blogpost about #DigitalTransformation.

This blogpost is about a Laboratory of Architectural and Technological Governance of “Smart Everything”

1 Why the laboratory is created (what is the reason for this?)

The Laboratory of Architectural and Technological Governance of Smart Everything (LATGOSE) is created for systematic and integrated execution of a national programme “Smart Everything”.

The Laboratory is aimed at solving real-life issues which are important for people, business and the state. Thus the Laboratory will compliment typical activities such as AR/VR, AI, blockchain, communication infrastructure, data centres, etc.

The Laboratory is considered as a medium-term endeavour.

2 Mission (which problem is solved and for whom?)

The mission statement of the Laboratory is "Making the world easier” by offering a coherent set of smart solutions of issues which are important for people, business and the state.

Such issues are complex because of their multidisciplinary nature as a mixture of economic, social, technological, legislative and environmental aspects. Solutions for such issues must be smart – in other words, such solutions must be being able to achieve their goals in a sustainable (with maintaining stability) way.

We believe that such solutions are digital sociotechnical systems, which are built with primary use of
  • common architectural and technological approaches;
  • potentials of information and communication technologies, and
  • modern IT tools.

3 Problem landscape

The variety of domains to be addressed by the Laboratory is outlined by the national programme of Smart Everything. Typical system domains are around people, business and the state.

4 Vision (description of the results)

People and businesses will be able to easily find a practical solution for a wide range of their real-life issues and apply such a solution (with some support from the state) with the use of to pre-arranged documents, methods, scenarios. It is expected that 80% of such issues will be covered by practical solutions in 3 years.

The Laboratory strategical direction is the implementation of the digital agenda (as it is defined by the national programme “Smart Everything”) to ensure inclusive and sustainable economic growth of the economy at any scale. This involves stimulating and supporting new digital initiatives and projects with the extensive use of information and communication technologies, new business processes and the creation of digital assets based on public and equal cooperation: municipal governments, small and medium-sized businesses and active citizens.

The wide involvement of small and medium-sized businesses with the regulatory and supervisory functions of local government is expected.

Initially, there will be a few pilot areas to build an initial version of the digital sociotechnical systems to be cloned and adapted to other clients.

5 Stakeholders

Primary beneficiaries:
  • People,
  • Businesses,
  • The state.

Secondary beneficiaries:
  • Public organizations,
  • Political parties,
  • Associations of people,
  • Companies providing local services,
  • Companies that develop digital solutions.

6 Informal description of the digital sociotechnical system

1 The person is in the centre of the attention of the digital sociotechnical system.

2 Typical usage of the digital sociotechnical system follows this pattern:
  1. A person formulates an issue that he / she wants to solve;
  2. The system offers several practical solutions to the issue;
  3. The person chooses a practical solution;
  4. The system helps the person to follow the chosen practical solution, i.e. indicates which documents on which templates should be prepared, forms requests to governmental agencies or other organizations, monitors the execution of a practical solution, etc.
  5. Later system will help the person in his subsequent activities related to this issue.

3 The selected architectural and technological decisions guarantee that digital sociotechnical systems are clonable and adaptable to local realities.

4 The selected architectural and technological decisions guarantee the coordination and integrationn of the digital sociotechnical system with systems implemented centrally at the state level.

5 Digital sociotechnical systems are complex digital constructions. The figure below outlines a reference architecture for only one systems domain – Smart Cities.

7 The Laboratory is a pilot factory of digital sociotechnical systems

The main activity of the Laboratory is
  • systemic building,
  • practical use,
  • continuous improvement and
  • dissemination
of the Digital Toolbox for Digital Transformation as the primary mean of constructing digital sociotechnical systems for specific conditions.

The Digital Toolbox for Digital Transformation allows to:
  • Decompose a "big" problem into an organized set of "small" problems;
  • Select an available solution for each " small" problem or create such a solution;
  • Assemble the “big” solution from the "small" solutions.

The Laboratory functions in the follow way:
  1. The Laboratory receives an order to solve a problem related to the mission of the Laboratory.
  2. The Laboratory analyses the order, conducts necessary surveys and proposes a variant of the digital sociotechnical system for the client (or an extension of the already existing system).
  3. If the proposal requires the development of some new components (i.e. solutions for "small" problems) then the Laboratory prepares the specifications, selects implementors from start-ups and partners and conducts architectural control of the work.
  4. The Laboratory synthesizes the solution for the ordered problem.
  5. The Laboratory works with the client to implement this solution.
  6. The Laboratory organizes support of the solution.

Digital Transformation of existing applications and business practices, related to the national program “Smart Everything” has the following specifics:
  • The solution architecture implies the mandatory use of information systems, or subsystems for new solutions, or tool platforms, or other digital media using information and communication technologies;
  • The solution architecture involves reengineering business processes to take advantage of primacy of the digital representation of the objects used in the business processes;
  • The solution architecture implies the standardization of many IT components and business practices, as well as the availability of various documents in public access.

The Laboratory will work on the basis of business processes and architecture governance which are already regulated, are well documented and have been tested in practice. Also, the following good business practices will be used:
  • development of initiatives, implementation and support of digital projects;
  • project and portfolio management;
  • development of effective mechanisms for the implementation of projects and accumulated competencies, and
  • support dialogue between stakeholders to promote good practices in the digital domain.

8 Strategic plan of the Laboratory

  1. Creation of the initial version of the Digital Toolbox for Digital Transformation.
  2. Implementation of several digital sociotechnical systems at a few pilot clients.
  3. Expanding the quantity and quality of implementation of digital sociotechnical systems.
  4. Deepening and expanding the functionality of the Digital Toolbox for Digital Transformation.

The figure below shows the life cycle complexly of the Laboratory and its products.

9 Top level functions of the Laboratory

Gradual creation and development of the Digital Toolbox for Digital Transformation, which consists of:
  • system of ontologies (or formal terminologies);
  • common methodology for the development of digital systems in the scope of “Smart Everything”;
  • reference digital sociotechnical system (common digital platforms, off-the-shelf IT products and a set of platform-based agile solutions);
  • common practices of governance, management and operations of digital sociotechnical systems;

Adapting digital sociotechnical systems to the realities of particular clients.
Creation of specifications for a new component within the common digital platform which can be implemented by start-ups or partners.
Building local teams for supporting of digital sociotechnical systems.
Enriching digital sociotechnical systems based on the experience of their implementation.
Supporting digital sociotechnical systems for various clients.
Dissemination of Laboratory experience.

10 Structure of the Laboratory

Office of the Chief Architect
  • Architectural group
  • Methodological group
  • Digital sociotechnical systems group
  • Group of new technologies
  • Architecture supervision group

Project office
  • Groups by branches of economy
  • Digitalization of territorial
  • Digitalization of social
  • Digitalization of lawmaking
  • Digitalization of public authorities

Training group
  • Consulting centre
  • Media Group
Service group

11 Other topics for which detail description can be provided on demand

Digital sociotechnical system:
  • emergent characteristics,
  • architectural principles,
  • architecture,
  • technologies,
  • reference solution architecture,
  • expected results,
  • required resources,
  • examples of (experience Canton Geneva, India's experience in ICT for the creation of "smart cities").

The roadmap.

The staffing plan of the Laboratory.

Budget of the laboratory for the first year.

Logistics services required for the successful operation of the Laboratory.



Better architecting with – value viewpoint

This blogpost is an example view based on the value viewpoint described in the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW also it illustrates the blogpost http://egov-tm.blogspot.com/2018/07/blog-post.html

The IEC System Committee (SyC) “Electrotechnical aspects of Smart Cities” has the following scope.

To foster the development of standards in the field of electrotechnology to help with the integration, interoperability and effectiveness of city systems.

Note 1 This will be done:
  • by promoting the collaboration and systems thinking between IEC/TCs, the SyCs and other SDOs in relation to city system standards; 
  • by undertaking systems analysis to understand the needs for standards and assess new work item proposals (NWIPs) related to city systems; 
  • by developing systems standards where needed and by providing recommendations to existing SyCs, TCs/SCs and other SDOs. 

Note 2: Overall common city goals include, for example, sustainable development, efficiency, resilience, safety and support for citizens' engagement and participation. However, individual city will follow its own approach.

Note 3: “Cities” refers to any geographically located population.


Staring from this scope, the SyC Smart Cities have derived the following governance details.


Problem space specifics which are derived from the general knowledge of Smart Cities domain are the following. 

All Smart City programmes and projects pursue many common goals including sustainable development, better efficiency, resilience, safety and wider support for citizen’s engagement and participation. However, each individual city tends to follow its own approach in Smart Cities programmes and projects. It is not surprising that the numerous technology activists are very vocal on various Smart Cities forums even though city systems cannot be reduced to just big data and IoT (see https://www.forbes.com/sites/federicoguerrini/2016/09/19/engaging-citizens-or-just-managing-them-smart-city-lessons-from-china/#52b675c2dab0 ). 

It seems that around Smart Cities there are many wonderful information and communication technologies, high levels of enthusiasm from software vendors, strong support from top leadership, obvious benefits for a significant amount of the planet’s population and no shortage of funding. But, there is a huge demand for a common understanding. 

The current implementation practices of Smart Cities are rather disjointed, namely: 
  • Smart Cities programmes and projects are, primarily, local initiatives; 
  • Smart Cities programmes and projects are considered as technology projects; 
  • numerous Smart Cities interest groups are, primarily, clubs; 
  • efforts for the development of a common vision are insufficient, and 
  • typical financing patterns do not promote a common vision, namely the government is funding (to some extent) some cities, which engage technological companies, and the government is funding some technological companies, which engage cities. 
As a result, there is no agreed basis for efficient and effective cooperation and coordination between different Smart Cities programmes and projects. There is a lot of duplication of work, developed solutions are not reusable, and the same mistakes are repeated. 

A look on the number of cities with in different population categories indicates the imperative of bringing standardization in this complex paradigm of cities which are systems of systems leveraging networks of networks to bring operational efficiency, sustainability & resilience in the city infrastructure to improve its citizens’ quality of life. 

City systems are multi-disciplinary and multi-technologies thus city systems must be carefully architected allow all technologies working together. 

Mission statement which outlines what the SyC Smart Cities is doing (see scope) for whom (see cope and problem space specifics) and how is the following: 

Systemically develop together with IEC/TCs, SyCs, other SDOs a coherent and highly useful set of city system standards for implementing any city system. 

Here is clarification of what is meant by the words of this mission statement: 
  • “systemically develop” – use the IEC Systems Approach; 
  • “set of city system standards” – a comprehensive collection of 
  • “together with” – organisations which have to use this set of city system standards can easily understand it and master it; 
  • “coherent” – all standards for city systems must be compatible and developed under the same guidance; 
  • “highly useful” – organisations which are working and using city systems must be included as stakeholders; 
  • “any city system” – the set of city system standards must flexible and extensible to be useful for all types of city. 
A correspondence table T1


Stakeholders and their estimated concerns are the following. 

Citizens are primary beneficiaries however they will profit this “set of city system standards”” indirectly. It will be for smart city architecture teams to collect the citizens’ concerns and treat them systematically in accordance with the “set of city system standards””. Below is an example of citizens’ concerns (which will be referred further as “Full city system functionality”): 
  1. Adequate water supply. 
  2. Assured electricity supply. 
  3. Sanitation, including solid waste management. 
  4. Efficient urban mobility and public transport. 
  5. Affordable housing, especially for the poor. 
  6. Robust IT connectivity and digitalisation. 
  7. Good governance and citizen participation. 
  8. Sustainable environment. 
  9. Safety and security of citizens, particularly women, children and the elderly. 
  10. Affordable healthcare for everyone. 
  11. Modern education for children and adults. 
  12. Attractive for business. 

City governance organs are responsible for prioritisation of city systems improvement activities. 

City governance organs’ expected concerns are the following: 
  1. Methods to understand needs of city systems stakeholders. 
  2. Methods to estimate complexity and cost for implementation of Smart Cities programmes and projects. 
  3. Good business practices and world-class knowledge in Smart Cities to properly manage and execute Smart Cities programmes and projects. 
  4. Enabling collaboration and coordination with other Smart Cities programmes and projects to improve the quality, share cost, reduce time-to-value and manage associated risks. 

Smart City architecture teams are responsible for adoption and tailoring this “set of standards” to the unique needs of the particular city. 

Smart City architecture teams’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Quickly mastered “set of city system standards””. 
  3. Easy to use supporting tools. 
  4. Wide usage of this “set of city system standards””.
Standards development groups (IEC/TCs, SyCs and other SDOs) are responsible for formal definition of some functional elements and their interfaces which are outlined by this “set of city system standards”. Also, this “set of instruments” provides enough information on how define interfaces as APIs and how to describe functional elements. 

Standards development groups expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Vendors are responsible for implementing some functional elements and their interfaces. 

Vendors’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Investors are responsible for taking informed decisions about their investments in city systems infrastructure. At the moment cities are missing out on significant investments that should be available to them because of: a) the potential to mitigate huge potential economic losses from disasters, b) the growing popularity of sustainable investments which pushes many investment and pension funds to leave the fossil-fuel industry and to look for another investment-safe industry and c) the high risks of existing city bonds. 

This “set of city system standards” can be used to benchmark various Smart Cities related works. Also, applying this “set of instruments” brings good business practices and world-class knowledge in Smart Cities programmes and projects. 

Investors’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Stakeholders’ requirements (except citizens’ ones) as a systematised set of all concerns of all stakeholders are the following: 
  1. Full city system functionality. 
  2. Quickly understandable “set of city system standards”. 
  3. Quickly mastered “set of city system standards”. 
  4. Easy to use supporting tools. 
  5. This “set of instruments” must help stakeholders to estimate, plan, manage and execute Smart Cities programmes and projects. 
  6. Ability to share experience, collaborate and coordinate among Smart Cities programmes and projects which use this “set of city system standards”. 
  7. Wide usage of this “set of city system standards”. 
Additional requirements are the following: 
  1. Addressing city system quality characteristics such as: interoperability, safety, security (including confidentiality, integrity and availability), privacy, resilience, simplicity, low cost of operation, short time-to-value, combining diversity and uniformity, s-referential 
  2. Covering the whole life cycle of city systems. 
  3. Widespread and transformative use of data and technology. 
Vision statement which outlines a solution space in accordance with the mission statement and satisfies the citizens’ requirements, other stakeholders’ requirements and additional requirements is the following. 

Transparently developed a set of city system instruments including a detailed Smart Cities Reference Architecture which are easily adaptable for unique needs of any city system. 

Here is clarification of what is meant by the words of this vision statement: 
  • “transparently developed” – thus everyone can understand the logic of our work, validate our work and bend or reply some parts of our work if necessary. 
  • “set of city system instruments” – a coherent collection of various types of tool such as methodological, domain-specific, informational, software-intensive, standard and informative 
  • “Smart Cities Reference Architecture” – commonly-agreed architecture which all smart cities can use as a template for solution architecture of their city systems because the key decisions taken in the Smart Cities Reference Architecture will guarantee that future city systems (built in accordance with this Smart Cities Reference Architecture) will possess the required essential characteristics, e.g. security and privacy, by design. 
  • “detailed” – it is necessary to provide enough scope and enough decomposition of Smart Cities Reference Architecture to reach a level of details which is suitable for effective standardisation of city systems – functional blocks may be implementable as black-boxes and interfaces between them must be not too complex. 
  • “easy adaptable” – although there are a lot of communalities between cities, each city always has its own unique features. Thus city systems may use many of common system elements and easily intermix them with their own system elements. 
  • “unique needs of any city system” – the set of instruments must flexible and extensible to be useful for all types of city. 
A correspondence table T2


Strategic goals which are mandatory to achieve the vision statement are the following:
  1. Commonly-agreed multidisciplinary concept system to enable all the stakeholders use the same “language”; 
  2. Commonly-agreed Smart Cities Reference Architecture Methodology (SCRAM) to make transparent and understandable how the Smart Cities Reference Architecture (SCRA) has been developed and can be used; 
  3. Commonly-agreed SCRA to serve as a tailorable template for implementing any city systems; 
  4. Guiding materials on how to tailor the SCRAM and SCRA to easily address unique needs of any city system; 
  5. Mapping of existing and potential standards to the SCRA to quickly navigate in standards pertinent for city systems; 
  6. Additional instruments to simplify adoption of the SCRAM and SCRA, and 
  7. Achieve that practically all Smart Cities programmes and projects use the SCRAM and SCRA. 

A correspondence table T3


Solution space constraints which limit potential solutions to reflect some nuances of the mission statement, the strategic goals and take into account the problem space specifics are the following:
  1. Adopting and adapting the IEC Systems Approach (see Annex A); 
  2. Although the IEC SyC Smart Cities responsibility is only about electrotechnical aspects of Smart Cities, the SCRA cover city systems as the whole. Then the extracted system elements will be sorted among various SDOs depending of the nature of those system elements. 
  3. Working together with the pertinent stakeholders, including IEC/TCs, SyCs, other SDOs, cities, and various bodies of knowledge implies that alignment of existing knowledge must be enforced; 
  4. Digital presentation of everything (applying the digital “twins” concept) because of digital transformation necessity, and 
  5. Making some digital models explicit, formal, machine-readable and machine executable thus creating some system elements which are good for description and execution (see “Towards software-defined organisations” https://www.slideshare.net/samarin/towards-softwaredefined-organisations ). 
Emergent characteristics of the solution space which address the strategic goals and the solution space constraints are the following:
  1. Friendliness: The set of instruments must explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her concerns and change his/her personal, professional and social life for the better 
  2. Systematic: The set of instruments provides a common approach for architecting city systems, so different people in similar situations find similar solutions or propose innovations. 
  3. Efficient: The set of instruments help stakeholders, programmes and projects to collaborate and coordinate their efforts via common agreements (i.e. standards) on various system elements (e.g. services, interfaces, data, etc.), common vision, common tools, common products, etc. 
  4. Flows handling: Cities are self-referential systems of flows ( see http://www.academia.edu/15717758/Conceptualising_the_Urban_System_as_a_System_of_Flows ) and, those flows are flows of entities of various types: digital, physical, living, social, political, legal, etc. If no flows then a city is dead. 
  5. Multidimensionality: Those flows co-exist and interrelate in the several dimensions: spatial, temporal, cybernetical, technological, etc. 
  6. Unpredictability of growth: Smart Cities are organically-grown and must be scalable. (What do you see in 70 million people moving to cities every year?) 
  7. Technology absorption: Because of the technology progress, many various (and unknown right now) intellectual devices (or “Things” from the IoT) and digital technologies will progressively automate, improve and drastically change various aspects of Smart Cities functioning including planning, execution, monitoring, prediction, optimisation of flows. 
  8. Synergetic: Intellectual devices, digital applications and digital services must work synergistically in several dimensions. 
  9. Holistic: Various aspects of the Smart Cities functioning (e.g. level of security, environmental impact, etc.) must be integrally (i.e. including all the available data, information and knowledge) anticipated, monitored, analysed, controlled, alerted and acted on. 
  10. Trustworthiness: High level of trustworthiness (includes security, privacy, safety, reliability, and resilience) is mandatory by design and by default. 
  11. Digital: For a man-made object, a digital twin comes first. For a nature-made object, a digital twin comes second. 
  12. Sufficient granularity: The SCRAM and SCRA must provide the level of granularity low enough for efficient implementation of city systems and high enough for standardisation purposes.

A correspondence table T5


Architectural principles of solution space which shape the proposed solutions to deliver the emergent characteristics of the solution space are the following:
  1. Explicit systems architecting and engineering is only a way to achieve essential characteristics of Smart City implementations. 
  2. Smart City as a System of Digital Interrelated Flows (SoDIF) which implies total digitalisation and intensive use of intellectual devices from the IoT. 
  3. Separation of concerns is very critical to reduce the complexity of Smart City implementations. 
  4. SoDIF is an assembly to be very adaptive and flexible. 
  5. SoDIF is constructed and operating on the basis of explicit and machine-executable digital contracts ( see “Digital-contract-as-a-process enables business in the digital world” http://improving-bpm-systems.blogspot.com/2016/07/digital-contract-as-process-enables.html ) between people, services, applications, devices and organisations. 
  6. Time and place must be integrated to handle flows properly. 
  7. Ontology is a must because the Smart Cities domain covers many, historically, disjoint subject fields. 
  8. Architecture description is based on the ISO/IEC/IEEE 42010; thus the SCRAM comprises a coherent set of viewpoints, model-types and artefact-types; the SCRA comprises a similar set of views, models and artefacts. 
  9. Alignment of views and models must be carried out systematically to preserve the conceptual integrity of the SCRA and tailored architecture. 
  10. Digital models must be used whenever is possible (see “Better architecting with – digital models” http://improving-bpm-systems.blogspot.com/2018/04/better-architecting-with-digital-model.html ). 
  11. Methods of the SCRAM are based on the following considerations: a) There is an extensible set of formal and semi-formal methods for creating some model-types from other model-types. b) Those methods are defined to facilitate their usage without high-level of creativity. c) Those methods are based on existing bodies of knowledge. 
  12. Processes of the SCRAM, if applicable, are borrowed from ISO/IEC 15288. And the SCRAM have three levels of coordination: a) between viewpoints; b) between model-types, and c) within some model-types. 
  13. Tailoring flow of the SCRA to unique needs of city systems (to be carried out by Smart Cities architecture teams) is the following: a) Copy the SCRA to the city Solution Architecture (SA). b) Select part of this SA to be tailored. c) Tailor this part of this SA by applying the SCRAM. d) Validate that all parts of this SA are aligned. e) Proceed to the item b) if necessary. 
  14. Derived reference architectures Potentially, a Smart Cities architecture team can use the SRCAM and SCRA to create their own reference architecture, for example, for a particular country. However, it is recommended to follow the SCRA and SCRAM to be able to use all benefits of the standardisation. 
  15. Maximum flexibility allows a reasonable variety of tools and techniques to be potentially selected for Smart Cities implementation. 
  16. Everything may be changed by design and by default thus imposing less limitations for Smart Cities implementation. 
  17. Governance & Management practices of the SCRAM are borrowed, if applicable, from existing bodies of knowledge, including, Quality management, CoBIT and IT4IT. An architecture group must provide the following four groups of service: a) Architecture Delivery services. b) Architecture Guidance services. c) Innovation & Optimisation services. d) Maintenance services. 

A correspondence table T6

Dynamic analysis of relationships

The graphical presentation mentioned above can be used for analysis of relationships between various artefacts. Selection of an artefact (it is in red) highlights all upstream artefacts in green and all downstream artefacts in blue.



Post-platform enterprise pattern: EEYORE

Post-platform enterprise pattern: Enterprise-Enterprise Yet Open Robotic Environment (EEYORE)

With thanks to John Morris (@JohnHMorris) and Michael Poulin (@m3poulin) for their valuable comments.

An updated version of the article is available at https://bpm.com/bpm-today/blogs/1292-post-platform-enterprise-pattern-faster-and-cheaper-inter-enterprise-ecosystem-business


In the modern business world, the vast majority of work is done by joint efforts of two or many enterprises. Inter-enterprise “working together” is a norm right now. It may have different longevity: one-off or sporadic or permanent (as B2B partnership). Can such “working together” be used systemically? For example, a modern enterprise is trying to get competitive advantage by
  1. perfecting, digitizing and innovating its core-business capabilities, and 
  2. using the best “other” enterprises for provisioning “other” capabilities needed to achieve the particular goal (even its mission); note that, those “other” capabilities for the enterprise point of view are the core-business capabilities from “other” enterprises point of view. 

In other words, an enterprise may combine its own “internal” capabilities with “external” capabilities obtained from other enterprises to achieve the particular goal.

Thus every enterprise involved is carrying out only its core-business capabilities! This is a big difference with the current situation in which some of enterprise’s capabilities (i.e. core-business) must compete in the world-wide market and some of enterprise’s capabilities (supporting) have no competitor at all.

The economist Ronald Coase - said that “Firms exist when the transaction cost of doing something within the firm, even with all its overhead, is lower than cost of doing things through a marketplace of free agents”. At present, an enterprise possesses core-business capabilities and supporting capabilities. Historically, the cost of intra-enterprise transactions is lower than the cost of inter-enterprise transactions. At the digital age the costs of inter-enterprise transactions are constantly dropping as digital technology develops (the so-called "API economy" is a good example of this). Of course, the cost contracting out versus direct management is only one of many factors such as risks, time lag, security, etc. to be taken into account.

Thus, the famous classic representation of an enterprise may be redrawn as shown in the illustration below. Note: Also logistics, marketing and sales may be considered as non core-business capabilities and be provided by “other” enterprises.

Ability of several enterprises to work together with maximum synergy and minimum overhead (thus much better than a classic enterprise) is critically important. Potential list of common activities to achieve that is not long but daunting:
  • formally define a work to be done ; 
  • find the best other enterprises for this work to be done; 
  • contract selected other enterprises; 
  • activate and configure a trusted working environment for all participating enterprises; 
  • carry out the work with secured sharing some data and information among participating enterprises and 
  • complete all contracts related to this work to be one. 
Certainly if modern digital technologies are properly architected together then they can enable this new way of working by making it more efficient and more effective that the current way of working.

Explicit, formal, machine-readable and machine-executable processes can act as a neutral and natural referee for coordinating inter-enterprise work. A potential implementation is an BPM-suite tool. A target is to position a BPM-suite tool as an independent and trusted 3rd party (a referee or a coordinator) to execute legally-bound processes for 2 or more mutually non-trusted parties. See http://improving-bpm-systems.blogspot.com/2016/07/digital-contract-as-process-enables.html

Of course, when many enterprises contribute into some common work, records management must be centralized (i.e. accepted by all the participants) and suitable for digital way of working. A digital archive with good availability and integrity can act as an escrow for some transactions and documents. Potential implementation is the blockchain technology.

An example of such a “disaggregation” of a classic enterprise – https://news.cgtn.com/news/35636a4e33637a6333566d54/share_p.html


Working together for the same goal requires sharing some things (business and technical artefacts) and, probably, some agreed means. Such a sharing is lesser for cooperation (different enterprise for different activities) and greater for collaboration (different enterprises for same activities).

Imagine that 10 enterprises have decided to work together. Shall each of them implement business processes required for this engagement? Add complex EDI infrastructure for communicating between processes from different enterprise? Keep everything within each enterprise? It looks a bit difficult. If something that must be shared is done once for everyone then everyone will gain. Thus some processes related to this engagement may be implemented once at an independent provider and linked to existing processes in each enterprise.

WHAT to share
Supporting means
Data (see the DIKW pattern)
hashes, cryptographic keys
common immutable storage
Information (see the DIKW pattern)
business objects
Interoperability, e.g. in interfaces
common immutable storage
audit trails, signed documents, agreed goals, demonstrated KPIs, inputs & outputs of inter-enterprise transaction
common immutable storage
some facts important for business
synchronization of work
common event queue
agreed business logic
regulation of work
common decision mechanism
agreed procedures, agreed SLAs, agreed protocols
common scripts in domain-specific languages
agreed testing methods
coordination of work
common coordination mechanism
KPI calculations
agreed formulas and results of calculations
common view on performance
common dashboard
agreed algorithms and results
common view on planning
common prediction mechanism
some proposals for better working
better joint performance
common set of digital models and agreed scenarios
Estimations of uncertainty which are evolving along the time
participants opinions on some factors
non-biased corporate security for all the enterprises involved
common immutable storage
Estimations of risk which are evolving along processes
participants opinions on adverse impacts
non-biased corporate security for all the enterprises involved
common immutable storage
payment mechanism
minimizing transactions with banks
own local currency

Things, which are shared in the particular case, must be a) architected together and b) digital (explicit, formal, machine-readable and machine executable) to achieve desired values of the important emergent characteristics such as:
  • the transactional cost for inter-enterprise transactions, 
  • risks, 
  • time lag, 
  • security, 
  • manageability, 
  • etc. 


New application architecture for inter-enterprise agile engagements can be built on the following pillars:
  • Immutable common digital archive (FACTS) to store all versions of all the artefacts. 
  • Microservices (ACTIONS), potentially in a serverless computing environment (because a digital archive is used as a common immutable storage). Please note that microservices are normal services (according to OASIS) except that one unit-of-functionality is one-unit-of-deployment is one-unit-of-execution. 
  • Machine-executable processes (COORDINATION). 
These pillars perfectly work together (in a robotic way without high level of creativity) – process templates define the granularity and interfaces for microservices and digital archive keeps all the artifacts (of course, they must be versioned). Process instances define validity of various facts.
See also http://improving-bpm-systems.blogspot.com/2018/06/architecting-modern-digital-systems.html

Some hurdles – processes modelling

Modelling of inter-enterprise processes is not easy because such processes are distributed (each of them may be executed in its own computing environment) and they communicated by exchanging of messages thus it is necessary to handle exceptions in communicating processes. Good modelling styles and process patterns will help.

Some hurdles – process execution

Some BPM-suite tools are already connected to the blockchain which is used as a common immutable storage.

1) Ultimus can use blockchain as a data storage - "Ultimus uses Tierion to create an audit trail for business processes and prove the integrity and timestamp of documents." See https://medium.com/tierion/ultimus-integrates-tierion-for-blockchain-digital-process-automation-f8331d76216a

2) Bonita can use blockchain – https://www.youtube.com/watch?v=lkwvko2Uy24

3) ConsenSys uses Camunda BPM-suite to use blockchain as a data storage, creating new users and executing smart-contracts https://www.youtube.com/watch?v=oww8zMzxvZA&feature=youtu.be
Some hurdles – process execution as a smart contract

One of the option to bring process to existing blockchain implementations is to implement a BPMN-like interpreter as a smart contract in the blockchain technology.

Some hurdles – blockchain mentality

People from the blockchain domain follow the “if you have a hammer then everything is a nail” negative pattern. https://blog.apla.io/report-of-the-egaas-team-556e5e4717bd

See http://ipe-lab.com/publication/223/?sphrase_id=41 as a case of the blockchain for control of third-party services. This an attempt to change a group of processes (from a few B2B partners) into a blockchain application. On the bottom picture (TO-BE), actual processes from the top picture (AS-IS) were lost. And, “Erroneous behaviour is judged by voting among all participants”, not by thorough analysis!


This pattern opens new perspective for the traditional Business Process Management which becomes also Inter-Enterprise Ecosystem Business. In other words, processes will expand outside enterprises to enable faster and cheaper “working together” for enterprises. 

And a quote from Alberto Manuel‏ (@AlbertoManuel) "Architecting expanded Value chain in the era of digital ecosystems and shared capabilities."



Architecting modern digital systems #entarch #bizarch #apparch #bpm #security #microservice

Mini-course at VFU

1 Title

Architecting modern digital systems

2 The problem to be addressed

At present, there are many IT-related methodologies, technologies, tools and schools of thoughts which overlap and contradict each other. The best practices are actually the best only in particular situations. Often decisions about software-intensive solutions are taken on the in-complete and subjective base. All of this tremendously complicates the modern digital systems thus reducing their potential effectiveness and efficiency. 

3 Objectives

The purpose of this course is to provide the basic knowledge and experience necessary to better understand how to deal with the increasing complexity of the information technologies to obtain the synergy between business needs and IT potentials. 

4 The approach

The course is based on the practical use of Enterprise Architecture (EA) which a methodology and practice for architecting solutions. EA provides an overarching guideline for understanding a “problem space” and take necessary decision about the “solution space” to deliver which addresses the problem. 

5 Learning outcomes

The trainees will
  • learn a systematic approach for architecting digital solutions; 
  • learn about some modern information technologies; 
  • learn how those technologies are working together for a systematic architecting, design, implementation, operations and evolution of digital systems; 
  • carry out a practical architecting exercise. 

6 Target audience

Bachelor and master level students specialising in IT. 

7 Requested knowledge

General knowledge of IS/IT. General programming experience. 

8 Layout of the teaching

Teaching will be given as six 1.5-hour lectures. The first 4 lectures will be about presenting some methodologies and technologies. Then the students will be asked to architect a solution based on a practical situation. The last session will be about presenting the student’s solution and wrapping up this mini-course. 


Better architecting with – digital models

1 The expression “all models are wrong” is wrong

"All models are wrong" is a well-known aphorism from statistics (attributed statistician to George Box, 1976), which has been used in other disciplines. A modern book on system engineering claims that "The map is not the territory, the menu can’t be eaten, the drawings do not fly, the source code does not store the values of its variables during execution". Let's analyse these statements.

The territory existed before its map. A map is an informational (or digital right now) "twin" of the territory. Since the territory is a natural (made by nature) object, its digital "twin" (made by man) is secondary and approximative.

The menu is the chef's plan and, at the same time, the informational (or digital right now) "twin" of kitchen services. Kitchen services are planned ahead for the several good reasons: discuss them with all the involved persons, organize work, optimize costs and reduce risks. Thus the menu (as a planning tool) helps in achieving the result, but it is not mandatory to provide services. In this case, the informational (or digital right now) "twin" may appear before the physical "twin".

It is clear that the drawings do not fly, but there is no flight without them. Those drawings is a necessary "part" of the aircraft to be manufactured according to these drawings. It is clear that the drawings, in themselves, are not a sufficient "part" of the aircraft because there is a long way from the drawing to the working copy. However, we can consider that the drawings are informational (or digital right now) "ancestors" of aircrafts. In this case, the informational (or digital right now) "twin" is necessarily created before its physical "twin".

Well, finally, the computer program and its source code. What is the relationship between them? There is no program without its source code. The source code can be expressed in several views - in high-level language and in the language of machine instructions (i.e. assembler). This is common but not necessary, because the source code can be interpreted directly without being translated into machine instructions. Wait, this looks rather familiar.

Wow, this is the genetic code for a bionic program! The genetic code does not have all the details, but it determines (albeit partially) the future bionic system. Of course, any bionic system is an adaptive system with a complex "bootstrap" procedure. While modern software systems must be highly-dependable.

So, in ther digital world we copy the mother nature – we create a piece of digital genetic code (in some programming languages) and from it we create a program with the help of the digital environment. Thus, the source code is the main part of the program. Both they are digital artefacts. In this case, there is only an informational (or digital right now) "twin". Well then, it is not a "twin" but an "original"! And this is a digital model.

Physical form
Digital form
1. Territory
2. Menu (probably)
3. Drawings (mandatory)
4. Program (inevitable)
2. Meal
3 Plane
1. Map

2 Obliterating differences between architecture and its description in the digital world

For the digital world, we must slightly adjust some of the provisions of ISO/IEC/IEEE 42010 Systems and software engineering - Architecture description. This standard clearly separates the architecture of the system and the description of the architecture. In accordance with this standard, the architecture description consists of models. But in the digital world, models can be also elements of the system-of-interest.

The usage of digital models:
  1. simplifies the choice of elements and system-of-interest options, 
  2. allows making predictions about the behaviour of the system-of-interest and 
  3. replaces the system-of-interest itself, for example, for training purposes. 

Such digital models are machine-readable and machine-executable. For example, a business process is not only an illustration, but also a piece of the source code of the system-of-interest. This increases the importance of Domain-Specific Languages (DSLs) through which some elements of the system-of-interest can be defined in business terms. For example, BPMN is a DSL. (As many years ago with the advent of SGML and HTML people began to say: the program becomes a document, in a document becomes a program.) Also, the appearance of the machine-executed elements of the system-of-interest in the early stages of its life cycle allows us to speak about the emergence of the BizDevOps culture as a natural up-stream extension of the DevOps culture.

The logic of the architecture viewpoints changes. Now, they are designed to systematically create model-types, some of which will be digital, i.e. machine-executable elements and/or machine-readable elements (or nomenclatures, for example, a list of all roles). Architecture viewpoints become some kind of aqueduct columns that support the logic of creating digital systems.

Fragment of the longest (132 km) Roman aqueduct, Tunisia.
(by the way, some parts of this structure are still working and used by local people)

Relationships between models also change. Previously, it was considered that models and views were created solely for stakeholders and, often, different models were created by different people thus models must be permanently aligned, e.g. by a chief architect. With the digital models, there is a lot of interest in semi-automatic and automatic creation of some models from already existing models. For example, if there is a functional map of the organization, then you can automatically offer the initial version of the organizational structure.

It is observed that the difference between the system-of-interest and its architecture description is disappearing in two directions:
  • Some elements of the system-of-interest can be used instead of some architecture description models. 
  •  Some architecture description models became the system elements. 

Ideally, the whole system description should be automatically generated from the existing system elements. This reminds us the “literate programming” from prof. Knuth – see https://www-cs-faculty.stanford.edu/~knuth/lp.html

It is clear that for each type of systems some of its digital models are system-forming elements. Imagine a directed and non-cyclic graph of dependencies between nodes as models and let us assign to its edges measure of the complexity of the "transition" between nodes. Then the models from which one can easily create the majority of other models are system-forming models.

All this is partially described in the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW