MAP for Digital Transformation example – Constructing multiple Smart Cities by an ecosystem of start-ups

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

1 Context

At the beginning of October 2018, the www.africup.tn conference took place in Tunisia. The conference was focused on how to help start-ups. Currently, start-ups are the main “source” of jobs in many countries, especially, on the African continent, because traditional companies don’t create new jobs any more.

The conference has been attended by ministers, investors, start-up leaders and other persons and organizations. During the conference, a law for helping start-ups has been adopted (“Loi Startup Act” https://www.ilboursa.com/marches/tunisie-la-loi-startup-act-entre-officiellement-en-vigueur_14957).

The general mood at the conference can be described in the following words: if you can do something right, good and successful for people and countries, there will always be some money for it. Therefore, the conference had a plenary discussion on one of the key problems of Smart Cities of the continent – smart water management. 

2 What is Smart City?

Understanding “a city” as any geographically located population (metropolis, town, village, island, etc.), a Smart City is a city that makes the world easier for citizens, business and government by providing solutions to their problems.

These problems are complex because of their multidisciplinary nature as a mixture of economic, social, technological, legal, environmental and ethical aspects. Solutions to such problems must be aligned and balanced against each other to allow Smart Cities reaching their goals in a sustainable (with preserving stability) manner. 

3 Complexity of Smart Cities

The urban nature of cites naturally leads to a high level of complexity because of the need to control interacting flows of energy, water, waste, transport, food, etc. Each of these flows needs to maintain a balance, to be capable to handle peak loads, to be prepared for quick elimination of consequences of emergency situations (resilience), etc. The figure below shows some of the relationship between the elements of a city. 

Cities are characterized by unpredictable growth, a wide variation in public opinion on priorities, concentration of conflicts and policies.

Each city is unique and all cities have a lot in common.

In the world there are about 4,5 thousand cities with a population of more than 150,000 people.

Construction of a Smart City is not a one-off event but a portfolio of projects with common and evolving purposes.

Making the entire city "smart" cannot be done by a start-up or a mega IT-company (remember General Electric, which tried to make a universal IoT platform alone https://tbri.com/blog/predix-is-looking-for-a-new-owner/ and failed).

Thus, construction of Smart Cities is a systemic problem that can only be solved systemically with

• involvement of all stakeholders (due to the social orientation of the cities); 
• proper coordination (for the construction cost of all "Smart Cities"); 
• broad cooperation (to use the opportunities within the cities), and 
• digital technologies (for ease of information processing and cloning of digital components). 

4 Systems approach to Smart Cities

In the year 2017, the IEC (www.iec.ch) was created a Systems Committee on Smart Cities. This committee considers a Smart City as a sustainable digital system, which consists of several types of systems: socio-technical, information, cyber-physical, computing, etc.

The usual pattern for defining multiple similar systems is to standardize their reference architecture which will be “adapted” to local conditions by mixing common and specific elements. Based on the reference architecture, various technical committees develop product standards that are used to create various elements. Thanks to the systems approach, such elements form a common and extensible digital platform. At the same time, each Smart City uses its own copy of platform with its own specific elements as shown in figure below.

Knowing that many participants will be involved in construction of Smart Cities, the Systems Committee prepares also a description of the methodology which is used to develop the reference architecture. At present, the Smart Cities Reference Architecture Methodology (SCRAM) is already in the process of consultation (IEC TS 63188 ED1) with countries which participate in the Systems Committee.

The SCRAM helps different people in similar situations to find similar solutions or suggest innovations. Therefore, the use of this methodology and the availability of the reference architecture will enable a particular city to quickly carry out its architectural works and determine that common solutions can be used and what specific solutions to be developed.

The SCRAM also allows to integrate together a lot of existing works for Smart Cities done by ISO, ITU and many other organisations and consortia. 

5 Smart Cities Reference Architecture (SCRA)

The SCRA is built in accordingly with a well-known practice (see ISO / IEC / IEEE 42010): an architecture is described by a consistent set of models that reflects this architecture from different views. Currently, the SCRA uses about 10 views and about 60 models which are defined by the SCRAM. The nomenclature of models and views can be extended because the SCRAM allows to define extra views and extra models as needed. The basic requirement is that all models must be aligned.

It is important that such models describe not only technical aspects, but also reflect social and managerial aspects such as:

• Public discussion (crowdsourcing). 
• Public rating (priority and importance). For example, to choose between "important, difficult and long" vs. "maybe relevant, easy and fast”. 
• A tree of goals for a specific planning cycle. 
• Unified lifecycle models for various elements. 

The figure below shows one of the models of the SCRA - the first level capabilities. The green marker indicates the water management area.

The figure below shows another model that describes the SCRA from a different view as a set of components of a digital platform. Again, a green marker indicates the components that are needed to begin implementing water management.

Note that many of such models are not only a description of the SCRA but also components of the digital platform (see https://improving-bpm-systems.blogspot.com/2018/04/betterarchitecting-with-digital-model. html). Therefore, the SCRA is also part of the reference implementation of Smart Cities. 

6 The implementation of Smart Cities

All the "boxes" in the picture above are functional elements and they are still rather complex. Therefore, additional architectural works are required to decompose a complex functional element into a set of simple functional elements that can be implemented by start-ups. As shown in the figure below, the functional elements (in the left part of the figure) are implemented by start-ups as digital modules (in the right part of the figure) to be used within or on top of the digital platform. Processes for decomposition, supervision and assembly are carried out by the Laboratory of Architectural and Technical Governance (see https://improving-bpm-systems.blogspot.com/2018/09/map/for-digital-transformation.html).

The Laboratory establishes some general rules (including a software factory) and start-ups follow these rules thus forming an ecosystem. Of course, traditional software companies may also participate in such an ecosystem. 

7 Is it a new market?

This modular approach to construct multiple Smart Cities can create a new market for digital modules and services. Any digital module can be financed on the basis of equity participation by investors, the government, start-ups and, even, citizens. The acquisition and use of digital modules by some cities may be organized under various compensation agreements, including “pay as you go”. For such a market, it is possible to introduce its own currency. 

8 Conclusion

Thus a fully transparent and decentralized scheme is formed for the collective construction of solutions for some wicked problems. To launch this scheme, a "place" (in geographically and broader senses) in which a nexus of four following power-streams will happen is necessary:

• Social (awareness of the situation of a critical mass of society). 
• Technological (availability of digital solutions and architectures). 
• Implementational (real construction in "live", materialization). 
• Financial (transparency who pays, why pays, who benefits) . 

Due to the dynamic nature of this nexus there is no need to theorize endlessly about it and his power-streams - the time for talks is over and some practical work must be started to launch this schema and manage the evolution of this nexus.

Smart Cities is the obvious "place" to launch this schema because a city is the beginning of everything and for everything. At the moment, it seems that Tunisia is, potentially, a geopolitical “place” to launch this scheme with an obvious extension to Africa and the Arab world (and, possibly, the Muslim world).

Note that “Smart Cities” is only an example and such a scheme can be applied for “Digital Healthcare”, “Smart Buildings and Dwellings”, “Smart Manufacturing”, “Digital Legislation” and “Digital Government”.


Thanks,
AS

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.


Thanks,
AS

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.

Overview

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

T1

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

T2

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

T3

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

T5

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

T6

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.

Thanks,

AS

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/blogs/post-platform-enterprise-pattern-faster-and-cheaper-inter-enterprise-ecosystem-business

WHY

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

HOW

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	Examples	Reason(s)	Supporting means
Data (see the DIKW pattern)	hashes, cryptographic keys	Security	common immutable storage
Information (see the DIKW pattern)	business objects	Interoperability, e.g. in interfaces	common immutable storage
Facts	audit trails, signed documents, agreed goals, demonstrated KPIs, inputs & outputs of inter-enterprise transaction	Traceability	common immutable storage
Events	some facts important for business	synchronization of work	common event queue
Rules	agreed business logic	regulation of work	common decision mechanism
Activities	agreed procedures, agreed SLAs, agreed protocols	automation	common scripts in domain-specific languages
Processes	agreed testing methods	coordination of work	common coordination mechanism
KPI calculations	agreed formulas and results of calculations	common view on performance	common dashboard
Intelligence	agreed algorithms and results	common view on planning	common prediction mechanism
Improvements	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
Finances	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. 

WHAT

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!

Conclusion

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

Thanks,
AS