Enterprise patterns: Anna Karenina

Working with reference architectures, I met the new for me pattern or principle called “Anna Karenina”. The name of the principle derives from Leo Tolstoy's 1877 novel “Anna Karenina”, which begins: “All happy families are alike; each unhappy family is unhappy in its own way”.

From https://en.wikipedia.org/wiki/Anna_Karenina_principle

The “Anna Karenina” principle states that a deficiency in any one of a number of factors dooms an endeavour to failure. Consequently, a successful endeavour (subject to this principle) is one for which every possible deficiency has been avoided.

So, during creation of a system it is necessary to

• find out a set of essential (positive and negative) factors (analysis), also known as a must-have list;
• separate these architectural concerns which is also a pattern (architecting);
• assemble all together as a stable system (synthesis).

If a reference architecture follows these two patterns then systems compliant to this reference architecture will have real changes to become good, right and successful. Certainly this justify extra efforts for developing reference architectures.

Thanks,

AS

It is time for #CBDC (Central Bank Digital Currency) reference architecture

1 Executive summary

CBDC implementation is a daunting task and its the most difficult feature is legality through CBDC life cycle. Let us architect CBDC as commonly agreed reference architecture which is available to everyone to move forward further (via improving the entire global economic position) and faster (via innovations).

Although there are some attempts to outline CBDC architectures these attempts are still missing good methodology practices.

2   Introduction

Leading financial and economic organisations as the BIS, WEF and FATF define CBDC as digital representation of cash, bearer financial asset and legal tender. In other words CBDC is “money M0 in digital form”.

For several reasons, the interest for CBDC has considerably increased during the year 2020 – there are a lot of papers, some central banks develop CBDC requirements, some central banks announced (sometimes mistakenly) that they are already implemented CBDC and some banks invite professional community to develop CBDC solutions. International financial organisations also actively participate and publish their requirements (e.g. the BIS at a WEF conference on July 2020 requested systemic stability for the Financial Market Infrastructure).

As everyone knows that Digital Transformation (DT) removes many of artificial and natural barriers. DT of money is about moving physical cash (the most basic and popular form of money) into digital space. Such digital representation of cash or digital cash or CBDC will have almost the same functionality as physical cash without barriers of physical representation.

Digital cash (which is done correctly) reduces many of existing barriers: everyone may execute legally and free-of-charge digital payments domestically and internationally. This is a huge difference with the current situation when a lot of people have no bank accounts and each cross-border payment costs approximately $ 35 (another estimation is 7-10% of remittance amount).

Digital cash is an enabler for frictionless, instantaneous, unconditional transfer with legal finality of value between any two parties; anytime, anywhere, without censorship. This will enable DT of financial market and investment practices. Lesser barriers in time, distance, legality, etc. improve the entire global economic position of all of the earths peoples.

The representation of money (physical or digital) is irrelevant, the sole characteristic required of any money based medium of exchange, is to achieve global unconditional settlement with legal finality, or legal tender based absolute cancellation of a payment obligation. Any digital bearer asset which is accepted by the community, to satisfy both of the two functions: a medium of exchange and a unit of account; with guaranteed unconditional settlement and achieve legal finality is Cash or Legal Tender. 

3 Why reference architecture

The FinTech and crypto communities already admitted that CBDC is not easy. Many people said that CBDC will take years to implement because of CBDC implementation complexity. Some systemic factors of complexity are listed below:

• Each country is different.
• There are many similarities between countries.
• Even Central Banks are confused with CBDC (see LBCOIN case).
• National CBDC is legal only in its own country.
• CBDC must be legal in each of its action.
• Least changes in legislation (see Russian Parliament “DUMA” case).
• To enable cross-border payments via CBDC an additional mechanism will be necessary.
• A systemic approach is needed to guarantee stability of operations (BIS said this at a WEF conference on July 2020).
• CBDC must enable innovations.
• CBDC must enable public-private partnership.
• CBDC must prevent the Wirecard case ([1] and [2]).
• etc.

Thus it is mandatory to develop about 200 rather similar CBDC implementations which possess the same emerging features. This is the case for the pattern “reference architecture”. This pattern is about two principal steps and the optional third one:

1. developing an agreed abstract (or imaginary) architecture which guarantees desired emerging features and
2. using such a reference architecture as a template for solution architecture of each CBDC implementation.
3. making a reference implementation.

A reference architecture is universally valid within a particular problem space or subject field. A reference architecture is technology-neutral. An important driving factor for the creation of a reference architecture is to improve the effectiveness of creating products, product lines and product portfolios by

• managing synergy (e.g. to agree on a common infrastructure),
• providing guidance, e.g. architecture principles and good practices,
• providing an architecture baseline and an architecture blueprint, and
• capturing and sharing (architectural) patterns.

In this short article it is not possible to cover all the complexity of the CBDC reference architecture. Therefore, only factor “CBDC must be legal in each of its action” will be discussed below. 

4 CBDC must be legal in each of its action

Each CBDC implementation must implement all legal features of cash and guarantee integrity of CBDC through its life cycle. CBDC life cycle is rather simple and only the difficult part is payments:

1) Emission by the Central Bank or an operator on behalf of the Central Bank

2) Participation in payments between buyers and sellers

3) Recuperation CBDC by the Central Bank by taxation process and potential reuse of CBDC.

The status CBDC as “legal tender” implies that CBDC payments are protected by the State to take place with sufficient certainty to satisfy the needs of buyer sand sellers. Buyers must be protected by ensuring that payment employing CBDC may not be refused. Sellers will accept CBDC for its value only if they can be certain that it will, in turn, be accepted from them for the same value.

There are many national laws and other governmental instructions which regulate the current practices of cash usage. It is not necessary to know all of laws and instructions but the current practices must be carefully reproduced or reengineered in the digital space.

In the CBDC retail scenario, everyone may have one or many “heaps” of cash. To pay some cash, a payer must collect the necessary amount of cash from all his/her heaps of cash and pass this heap of cash to a payee. The latter validates this heap of cash and, usually, accepts it. The payment is done with its legal finality. Thus in digital space all of such actions may be explicit (because easy to check and guarantee legality of each action) and be executed as one transaction “all or nothing”.

In the CBDC wholesale scenario, if CBDC is guaranteed being legal then RTGS for CBDC is not much different from the CBDC retail scenario described in the previous paragraph. Of course, it must be remembered that such RTGS takes place in the same country (national CBDC is legal only in its own country) and CBDC is not mixed with commercial bank money which are not legal tender (please note that IMF’s synthetic CBDC and Swedish e-krona are such mixtures). More interesting, if CBDC wholesale can be carried out without the Central Bank then there is no need for RTGS for CBDC. It is a very useful simplification for the national financial market infrastructure.

In the CBDC cross-border payments scenario, an additional Universal CBDC (U-CBDC) must be internationally (or regionally) created and legalised. Let us consider that nation AAA CBDC (CBDC-AAA) must used to pay in nation BBB CBDC (CBDC-BBB). The price of the payment is expressed in U-CBDC and agreed by payer and payee. Then the sequence of actions is the following:

1. Payer asks the country AAA Central Bank (CB-AAA) to buy agreed amount of U-CBDC.
2. The CB-AAA buy on a free market that U-CBDC with CBDC-AAA.
3. Payer transfers that U-CBDC to payee.
4. Payee asks the country BBB Central Bank (CB-BBB) to sell on a free market that U-CBDC for CBDC-BBB.

All these actions must be legal and the whole sequence must be “all or nothing”, ideally, as requested by BIS DvP 1 model.

And, another big challenge in the CBDC cross-border case will be the BIS principles and CPSS-IOSCO principles for financial market infrastructures[3]. For example:

“Principle 1: Legal basis

An FMI should have a well-founded, clear, transparent, and enforceable legal basis for each material aspect of its activities in all relevant jurisdictions.” 

5 Examples of weak methodology

Reading of dozens various articles about CDBC, several cases of “broken logic” were identified. These cases are analysed below from international practices for developing reference architectures. Good, right and successful reference architectures must be based on an agreed set of concepts, stakeholders, stakeholder’s concerns, use cases, requirements, desired characteristics of potential solutions, architecture principles (decisions) for potential solutions, etc. Some of them belong to the problem space (which is solution-independent) and some of them belong to the solution space (which defines a set of potential solutions).

Usually, reference architectures are technology-neutral to promote innovations. Reference architectures make all the decisions explicit and explainable.

The IMF[4] is one of the first financial institutions which actively leads CBDC discussions. However, their logic is not always faultless. An example. The IMF impose in solution architectures the mandatory involvement of private companies, however, this architecture decision for potential solutions (from the solution space) is not explicitly justified and linked with the CBDC problem space description. Thus this architecture decision is like "putting a chariot before the horse".

Another example. IMF's synthetic CBDC (sCBDC) “ is a liability of private firms—the sCBDC issuers—rather than of the central bank”. Thus sCBDC is not legal tender and it can’t be compared with CBDC. Such kind of error could occur because of the absence of well-developed CBDC reference architecture.

Germany, federal finance ministry published a very good report[5]. However, their architecture decision for potential solutions to fix “distributed ledger technology (DLT) or blockchain technology” for CBDC is not logical. Because the solution space may have several possible solutions, such fixing is an artificial and unexplainable self-limitation. It stopped innovations. A better logic would be keeping the CBDC reference architecture technology-neutral.

Lithuania Central Bank “The LBCOIN is very similar to what is known as a central bank digital currency, said Jurgilas, putting Lithuania at the forefront of development of a fiat digital currencies.” [6]

However, their LBCOIN is not a legal tender hence not CBDC thus LBCOIN is , maximum, a stablecoin. Such an error can be found via a CBDC reference architecture.

Former CFTC Commissioner[7]: “Bowen made it very clear that even though the federal reserve chairman is a big believer that the government should develop this digital currency, bringing in multiple stakeholders will give a diverse perspective on its development and could give a better result to the overall project.”

Careful identification of stakeholders is a mandatory step for developing a good reference architecture.

Russian parliament Duma[8]: After 2 years of delays have approved as a law something strange which is not necessary aligned with FATF standards.

Careful check of all international requirements is a mandatory step for developing a good reference architecture.

ITU-T Focus Group Digital Currency group Digital Fiat Currency report[9] is the most comprehensive documentation about CBDC reference architectures. For the year 2019 is was perfect, however, several points are slightly different in the year 2020. Namely, terminology about CBDC.

This reference architecture doesn’t provide enough information about the problem space thus some of architecture decisions are not traced from use needs. It seems that the majority of architecture decisions are grew bottom-up which is not usual practice for developing reference architectures. As the result, this reference architecture is more an overview of existing approaches (e.g. retail CBDC, wholesale CBDC and cross-border payments CBDC are different) and technology-driven as confirmed by some considerations below:

“Another operational case in point for such smart contracts include DLT-based liquidity management facilities, which would enable bilateral transaction netting.”

“DFC using DLT architecture will be as much successful as the maturity of the ecosystem that is ready to embrace its full potential.”

This reference architecture looks like technology architecture. 

6 Conclusion

Because of the world-wide importance of money, there is a serious demand for a commonly agreed CBDC reference architecture. This reference architecture must be created with good methodology practices.

This ITU initiate has been recently relaunched as “Digital Currency Global Initiative” (https://www.itu.int/en/ITU-T/extcoop/dcgi/Pages/default.aspx) – hope they will use good methodology practices.

7 Additional resources

Publicly available documents.

https://samarin.biz/pubs/CBDC-Interoperability.pdf

https://samarin.biz/pubs/CBDC-Legal-Finality.pdf

https://samarin.biz/pubs/CBDC-Privacy.pdf

https://samarin.biz/pubs/CBDC-Resilience.pdf

https://samarin.biz/pubs/CBDC-Universal-Access.pdf

https://samarin.biz/pubs/CBDC-Security.pdf

https://samarin.biz/pubs/CBDC-Legality.pdf

https://samarin.biz/pubs/CBDC-Financial-Inclusion.pdf

Thanks,
AS


[1] https://www.coindesk.com/from-enron-to-wirecard-how-blockchain-tech-could-have-helped

[2] https://www.linkedin.com/posts/wassim-jarkas_from-enron-to-wirecard-how-blockchain-tech-activity-6693044727941488640-UPxs

[3] https://www.bis.org/cpmi/publ/d101a.pdf

[4] https://www.coindesk.com/private-sector-could-bring-value-to-future-cbdc-launches-says-imf-official

[5] https://www.bundesfinanzministerium.de/Content/DE/Downloads/Finanzmarktpolitik/2020-07-08-fintechrat-digitaler-euro.pdf?__blob=publicationFile&v=3

[6] https://www.reuters.com/article/us-eu-cryptocurrency-lithuania/lithuania-dabbles-in-https://cryptodaily.co.uk/crypto-coin-as-central-banks-look-for-ways-to-fend-off-facebook-idUSKBN2431RF

[7] https://cryptodaily.co.uk/2020/07/former-cftc-us-cbdc

[8] https://www.rbc.ru/crypto/news/5f16c6379a794732b6dd31e7

[9] https://www.itu.int/en/ITU-T/focusgroups/dfc/Pages/default.aspx

Better architecting with - standard viewpoints and model-types

1 Smart Cities Reference Architecture Methodology

The IEC System Committee “Smart Cities” is mandated to develop the Smart Cities Reference Architecture (SCRA) which is a template for various Smart Cities solution architectures.  Although there are many reference architectures for Smart Cities, those architecture have been developed under different and unknown methodologies. This made practically impossible to use them together and to adjust them to the needs of a particular city system.

To address this problem the IEC System Committee “Smart Cities” had decided to develop Smart Cities Reference Architecture Methodology (SCRAM) as an international normative document IEC SRD 63188. The SCRAM provides the logic how to build the SCRA and how to tailor the SCRAM and SCRA. The ability to tailor is very critical.

• Cities, as places where people live and work, are very important for our civilisation.
• All cities are different.
• Smart City is a city which makes the world easier for citizen, society, business and government.
• In Smart Cities projects 50% – 70% of work is about IT, i.e. digital.
• Smart City is a city which is rebuilt as a digital system (Digital Transformation is critical).
• Digital systems can be done well, be adaptable and easy repeated (this is the main secret of Digital Transformation), but such emergent characteristics have to be purposefully created.
• If a common methodology for building Smart Cities as digital repeatable systems is used, then all Smart Cities are the 70% same (an estimation).
• Coordinated and cooperated building together Smart Cities as digital repeatable systems leads to substantial gains in cost, speed and quality of their implementations.
• An export version of the Smart Cities implementation is created automatically.

Considering that Smart Cities will be digital repeatable systems, it has been understood that a platform is necessary. The SCRA outlines the Common Smart Cities Digital Repeatable Platform. Because of the complexity in Smart Cities, this platform is actually a complex of platforms (See the illustration below, which is slightly different from the various version in https://improving-bpm-systems.blogspot.com/2019/03/better-architecting-with-solution.html). For each platform, the SCRA lists its own components and essential capabilities for each component.

To describe such complexity, the SCRAM provides 11 viewpoints and 107 model-kinds. Additional, the Smart Cities Implementation Manual is anticipated for continual improvement and collecting knowledge about the SCRAM and SCRA.

2 Example of tailoring

A country NNN decided to introduce a country-wide ICT reference architecture for all Smart Cities projects. The country wanted to reuse the SCRAM and SCRA for the NNN-ICT RA. There are two fundamental requirements:

1. The NNN-ICT RA must include communication infrastructure which is not defined in the SCRAM and SCRA.
2. The NNN-ICT RA must be detailed enough as a Reference solution architecture.

A recommended tailoring is below. For Reference architecture, consider the following:

• Describe the requirements for NNN-ICT RA by covering the SCRAM model-types 7.2-7.15; maybe in a free format.
• Outline NNN-ICT RA via the SCRAM model-types 7.16-7.30; use SCRA whenever possible.
• List of platforms to be provided at the beginning via the SCRAM model-type 7.43.
• Provide a view of the Universal platform via SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for this platform).
• Provide a view of the Urban Platform via the SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for this platform).
• Provide a view for each vertical platform, e.g. transportation, gas, water, energy, waste etc. via the SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for these platforms).
• For each SCRAM model-types 7.31-7.42 develop implementation materials, i.e. how different teams must provide various information, e.g. model processes, data, etc.
• Provide any additional views and models, especially for communication infrastructure.

For Reference solution architecture, consider the following:

• Provide view for the SCRAM CROSSCUTTING ASPECTS ENGINEERING viewpoint.
• Provide view for the SCRAM RISK MANAGEMENT viewpoint.
• Provide view for the SCRAM SOFTWARE FACTORY viewpoint.
• For each component of the Universal platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the Universal Platform, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• For each component of the Urban platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the Urban platform, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• For each component of the vertical platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the vertical platforms, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• Provide any additional views and models.

3 SCRAM viewpoints and model-kinds

3.1 VALUE viewpoint

The value viewpoint describes the problem space in terms of expected value for the stakeholders by providing some ideas about potential overall solutions (called system-solutions to distinguish them from solutions on top of a platform). The value viewpoint comprises the following model-types:

• Problem space overview (see 7.2)
• Problem space terminology (see 7.3)
• Problem space specifics nomenclature (see 7.4)
• Problem space classifications nomenclature (see 7.5)
• Stakeholders nomenclature (see 7.6)
• Stakeholders’ concerns nomenclature (see 7.7)
• Dependencies between generic system stakeholders, stakeholders, stakeholders’ concerns and categories of concerns (see 7.8)
• High-level requirements nomenclature (see 7.9)
• High-level stories nomenclature (see 7.10)
• High-level use cases nomenclature (see 7.11)
• Problem space coverage by the high-level use cases (see 7.12)
• The mission statement (see 7.13)
• The vision statement (see 7.14)
• The strategic goals nomenclature (see 7.15)

3.2 BIG PICTURE viewpoint

The big picture viewpoint outlines the solution space and describes potential system-solutions as a set of high-level elements. The big picture viewpoint comprises the following model-types:

• Solution space boundaries (see 7.16)
• Solution space terminology (see 7.17)
• Solution space constraints nomenclature (see 7.18)
• Solution space classifications nomenclature (see 7.19)
• Solution space essential emergent characteristics nomenclature (see 7.20)
• Dependency matrix between problem space essential high-level requirements and solution space constraints vs. solution space essential emergent characteristics (see 7.21)
• Solution space architecture principles nomenclature (see 7.22)
• Dependency matrix between solution space essential emergent characteristics vs. solution space architecture principles (see 7.23)
• High-level illustrative diagrams (see 7.24)
• High-level business map (see 7.25)
• Beneficiaries’ journeys nomenclature (see 7.26)
• High-level reference capability map (see 7.27)
• High-level process map (see 7.28)
• High-level architecture (see 7.29)

3.3 SYSTEM-SOLUTION ENGINEERING viewpoint

The system-solution engineering viewpoint describes the system-solution as sets of artefacts such as capabilities, processes, service, functions, data, information, etc. This viewpoint explains how the system-solution delivers value to its beneficiaries as well as how the system-solution actually runs itself. The model-types of the system-solution engineering viewpoint are applied to any potential system-solution as the whole and some of its elements. The engineering viewpoint comprises the following model-types:

• Capability map (see 7.30)
• Low-level use cases nomenclature (see 7.31)
• Function map (see 7.32)
• Partners nomenclature (see 7.33)
• Process map (see 7.35)
• Services nomenclature (see 7.34)
• Decisions nomenclature (see 7.36)
• Events nomenclature (see 7.37)
• Data schemas nomenclature (see 7.38)
• Information flows nomenclature (see 7.39)
• Document/content classifications nomenclature (see 7.40)
• Key performance indicators nomenclature (see 7.41)
• Reports nomenclature (see 7.42)
• Standards and norms nomenclature (see 7.43)

3.4 PLATFORM ENGINEERING viewpoint

The platform engineering viewpoint covers a platform. A potential system-solutions may contain more than one platform. The platform viewpoint comprises the following model-types:

• Platforms nomenclature (see 7.44)
• Platform overview (see 7.45)
• Platform terminology (see 7.46)
• Platform components nomenclature (see 7.47)
• Platform solutions nomenclature (see 7.48)
• Platform software factory configuration (see 7.49)
• Platform governance, management and operations manual (see 7.50)

3.5 PLATFORM COMPONENT ENGINEERING viewpoint

The platform component engineering viewpoint covers a component of a platform. The platform component viewpoint comprises the following model-types:

• Platform component overview (see 7.51)
• Platform component terminology (see 7.52)
• Platform component capability map (see 7.53)
• Platform component function map (see 7.54)
• Platform component process map (see 7.55)
• Platform component business specifications (see 7.56)
• Platform component information specifications (see 7.57)
• Platform component application specifications (see 7.58)
• Platform component data specifications (see 7.59)
• Platform component infrastructure specifications (see 7.60)
• Platform component security specifications (see 7.61)
• Platform component services and APIs nomenclature (see 7.62)
• Platform component software factory configuration (see 7.63)
• Platform component management and operations manual (see 7.64)

3.6 SOLUTION ENGINEERING viewpoint

The solution engineering viewpoint covers various artefacts of the particular solution. The solution engineering viewpoint comprises the following model-types:

• Solution overview (see 7.65)
• Solution terminology (see 7.66)
• Solution capability map (see 7.67)
• Solution function map (see 7.68)
• Solution process map (see 7.69)
• Solution business specifications (see 7.70)
• Solution information specifications (see 7.71)
• Solution application specifications (see 7.72)
• Solution data specifications (see 7.73)
• Solution infrastructure specifications (see 7.74)
• Solution security specifications (see 7.75)
• Solution services and APIs nomenclature (see 7.76)
• Solution software factory configuration (see 7.77)
• Solution management and operations manual (see 7.78)

3.7 CROSSCUTTING ASPECTS ENGINEERING viewpoint

The crosscutting aspects engineering viewpoint specifies engineering practices for several essential emergent characteristics of the system-solution. The crosscutting aspects viewpoint comprises the following model-types:

• Interoperability aspect (see 7.79)
• Security aspect (see 7.80)
• Privacy aspect (see 7.81)
• Safety aspect (see 7.82)
• Reliability and resilience aspect (see 7.83)
• Low cost of operations and time-to-market aspect (see 7.84)
• Self-reference aspect (see 7.85)

3.8 CORPORATE viewpoint

The corporate viewpoint specifies various governance and management setup of the system-solution. The corporate viewpoint comprises the following model-types:

• Organisational structure (see 7.86)
• Governance structure (see 7.87)
• Project management (see 7.88)
• Corporate manual (see 7.89)
• Independent evaluation (see 7.90)
• Ethics, integrity and ani-corruption (see 7.91)
• Environment and health (see 7.92)

3.9 RISK MANAGEMENT viewpoint

The risk management viewpoint specifies necessary governance practices. The risk management viewpoint comprises the following model-types:

• Risk management aspect (see 7.93)
• Compliance management aspect (see 7.94)
• Regulatory management aspect (see 7.95)
• Crime prevention and detection (see 7.96)
• Auditing (see 7.97)
• Independent investigation (see 7.98)
• Crisis management (see 7.99)

3.10 SOFTWARE FACTORY viewpoint

The software factory viewpoint specifies BizDevOps practices. The whole logic of the software factory is quickly create a simple but complete solution, validate it and gradually enrich it. The implementation viewpoint comprises the following model-types:

• Software factory overview (see 7.100)
• Prototyping practices (see 7.101)
• Engineering practices (see 7.102)
• Assembling practices (see 7.103)
• Testing practices (see 7.104)
• Deployment practices (see 7.105)
• Monitoring practices (see 7.106)

3.11 STANDARDS viewpoint

The standards viewpoint specifies existing and future standards applicable for the system-solution. This viewpoint comprises the following model-types:

• Existing standards nomenclature (see 7.107)
• Potential standards nomenclature (see 7.108)

4 Conclusion

The logic behind the SCRAM and its viewpoints/model-types may be used for other digital domains, such as: Digital Healthcare, Smart Homes, Smart Building, argotech, fintech, edutech, etc.

Thanks,
AS


This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW

Better architecting with - explicit #security

1 Addressing crosscutting aspects by-design

Various crosscutting aspects (also known as non-functional or quality characteristics) of systems are, actually, dependant on all the system elements and relationships between them. For example, the security design principle “weakest link” is saying that “in designing security for a system, focus should be put on the weakest components of the overall system” (see Goldratt E.M., Cox J. The Goal: A Process of Ongoing Improvement, Second Revised Edition, 1992).

The understanding of emergent nature of crosscutting aspects led to raising of requirements for addressing them “by-design”. The most noticeable example of “privacy by-design” is the General Data Protection Regulations (GDPR) from the European Union (see https://eur-lex.europa.eu/eli/reg/2016/679/oj ). The concept “a system characteristic by-design” may be defined as “taking into account the characteristic throughout the system entire lifecycle processes (e.g. architecting, engineering, construction, operating, etc.) as an essential emergent characteristic of the system”.

2 Security Risk Architecture Model (SRAM)

To “estimate” a relative value of a non-functional or quality characteristic of a system at any stage of the system life cycle, it is necessary to “spread” such characteristic over the system elements and relationships between them. Figure below shows, that by knowing:

1. the security-related paraments, i.e. threats, attacks and vulnerabilities (see oval “Security”) for each least granular system elements;
2. relationships between the system elements (see oval “Architecture”), i.e.
   • how a set of least granular elements forms a service,
   • how services are used in business processes,
   • how business processes contribute into results,
   • how results reflect goals,
   • how goals are important for the system;
3. adverse impact which is produced by problems with each system element;

it is possible to objectively evaluate system risks (see oval “Risk management”).

Considering that relationships between system elements are static or dynamic then the structure and behaviour of security will be covered. The same can be done for all crosscutting aspects: security, privacy, safety, reliability, resilience, performance, value, income, expenses and other emergent characteristics.

3 Enhancement practices

There are internal and external enhancement practices for each crosscutting aspect. The internal enhancements practices comprise various certifications and industry agreements which are aspect-specific and element-specific. The external enhancement practices depend on the treatment of an element as:

• “white-box” with fully internal visibility and testability – some simulation, inspection and compliance external enhancement methods can be used;
• “black-box” with no internal visibility and testability – use external enhancement points for data/information inputs and outputs, and external enhancement controls for leaks detection;
• “grey-box” with partial internal visibility and testability – combining two previous options.

Typically, external enhancement methods are based on explicit relationships between elements (e.g. information flows). External enhancement points are based on digital archives and technologies similar to Security Information and Event Management (SIEM) tools. External enhancement controls are monitoring tools with some AI logic, for example, Data Loss Protection (DLP) tools.

For each relationship between elements, use external enhancement points for data/information flow starts and ends, and external enhancement controls for data/information transit.

The static relationships are expressed by any structural connection between elements, but dynamic relationships are expressed only by events (ECA and EPN techniques), processes (BPM techniques) and information flows (IFD techniques).

For example, a process model formally identifies all necessary enterprise enhancement points, methods and controls. (see figure below)

1. Add all external enhancement points.
2. Add all external enhancement controls for 4 activities which are “black-boxes”.
3. Add all external enhancement methods for 2 activities which are “white-boxes” and the process as the whole.
4. Add all the events and mitigation processes for some of them.

Thus, an explicit description of system elements and relationships between them provides a nomenclature of external enhancement practices, controls, points, and methods to be added to the system. Then they have to be linked to the risk management practices. All the information risk-related information sourced from various crosscutting aspects must be collected and treated together (see figure below).

1. Enterprise business functions should be enriched to generate the risk-related information.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business information.
3. Some business processes need to be updated to embed risk-related activities.
4. A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.

Additional security-related techniques are mentioned in https://improving-bpm-systems.blogspot.com/2014/04/ideas-for-bpmshift-delenda-est-vendor.html

4 Conclusion

Crosscutting aspects are desired emergent characteristics of a system. They must be addressed systemically.

Thanks,

AS


This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW

Better architecting with - solution artefacts

1 Introduction

Although the global success of software is unquestionable (“software is eating the world”, everyone wants to use agile, etc.), last year the agile guru and “father” of microservices Martin Fowler was talking "why are we struggling" (see https://martinfowler.com/articles/agile-aus-2018.html ). He pointed at three problems:

1. Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
2. Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
3. Organize around products.

Let us see how architecture addresses these three points (please, note that the word “architecture” has not been used in this speech).

The point 1 is actually well-known for architecture – no organisation is using only one framework and a framework “as is”. It is always a mixture of several frameworks which have been “massaged” to handle the real and unique needs of an organisation. To overcome this problem, the serious of blogs “Better Architecting With” (BAW) https://improving-bpm-systems.blogspot.com/search/label/%23BAW introduces a different approach – architecture description (remember ISO/IEC/IEEE 42010) which is a set of views and models, these models are aligned, and some models are, also, parts of system-of-interest. Thus teams may use views and models as they want.

There is already a standard set of model-types (e.g. I use 100+ of them) and there are some methods to generate (sometimes semi-automatic) some models from existing models. Processes are not fixed, but there is a natural order of dependencies between model-types. So, the teams may have a lot of freedom by using standard methods and model-types.

The item 3 is also well-known for architecture – the entity (product, solution, system, etc.) life cycle is more important than projects at various stages of such life cycle (see https://improving-bpm-systems.blogspot.com/2018/01/better-architecting-with-explicit.html ). So, there is a clear separation of duties:

• Use architecture to define the units-of-work to be done and some dependencies between them.
• Use agile to schedule and monitor execution of such units-of-work.

The item 2 is, actually, about being able to build that kind of adaptive software including refactoring – ‘I always loved Mary Poppendieck's phrase, "A late change in requirements is a competitive advantage." But to do that you need software that's designed in a way that's able to react to that kind of change. Refactoring is central to this because refactoring is a disciplined way of making changes.’

It seems that the guru is “self-locked” in the software domain in accordance with the well-known observation “if all you have is a hammer than everything looks like a nail”. Software has its artefacts (classes, packages, interfaces, schemas, services, applications, platforms, etc.), however solutions are, also, built from a different set of artefacts (which use software artefacts, of course). 

2 Solution artefacts

Architecturally, solutions consist of solution artefacts such as:

• events,
• processes,
• UI forms,
• roles,
• rules,
• KPIs,
• audit-trails,
• reports,
• automation scripts,
• data structures,
• documents,
• IoT devices,
• etc.

Also, architecturally, each of these artefacts may have several facets:

• specific management tool, e.g. Business Process Management (BPM)-suite tool;
• templates, e.g. process templates;
• instances, e.g. process instances;
• APIs (or interfaces) to all functionality, and
• patterns used by templates, e.g. workflow patterns.

Obviously, the specific management tools for these solution artefacts are needed only once for all the solutions within the whole computing environment, i.e. enterprise-wide. Also, templates, patterns and APIs are shared between many solutions. So, each unit-of-functionality that is used by more than one solution must be put aside and organised for sharing.

Logically, all the units-of-functionality to be shared should form an enterprise-wide platform (this is a type of software artefacts) and some units-of-functionality may become microservices (this is a type of software artefacts). 

3 Platforms and microservices orientation

The logic behind platforms is rather straightforward – instead of developing traditional applications which contain a lot of duplicating functionally, all common functionality is collected into a platform and solutions which are built on top of that platform possess only unique functionality. See figure below.

Planform is designed on the following principles:

• The platform simplifies the use of its platform components and ensures interaction between them. Thus, the platform frees up resources to focus on solving unique problems.
• New solutions are implemented outside the platform using rapid development techniques (agile methodology) and platform existing functionality.
• The planning of new solutions is coordinated within the scope of the platform to minimize duplication of efforts in solving the same problems.
• Successful new (thus innovative) solutions are gradually included in the platform for their wide use.
• Constant improvement of the platform is achieved through transparency, feedback, results of use and systematic evaluation of existing platform components.
• All interactions inside and outside the platform use the standardized interfaces (API methodology).
• The platform provides for several interchangeable options for some platform components.
• The platform offers not only a rich functionality, but also a methodology for developing various solutions based on it.
• The platform is built gradually by increasing its functionality horizontally and vertically.

The platform-enabled agile solutions orientation implies common engineering practices for solutions created on top of the platform. Any solution which is built on such a platform must contain only functionality which is not implemented in the platform (see Figure below).

4 Smart cities reference architecture case

Let us illustrate platforms, solutions and solution artefacts with the Smart Cities Reference Architecture Methodology which is under development in the IEC System Committee “Smart Cities”. Some of the goals of this methodology are to guarantee that 

1. all the common functionality is developed once and used by many Smart Cities and
2. individual Smart City can easily developed their own unique solutions (including replacing some platform functionality).

The analysis of Smart Cities functionality demonstrated that minimum 3 platforms are necessary: universal, urban-generic and urban-specific (see Figure below).

Another option is to split the urban-specific platform into 14 platforms.

To facilitate the isolation of solution artefacts, a reference application architecture for solutions is proposed (see figure below).

Then all the various facets (tools, APIs, patterns, templates and instances) are mapped to the platforms and solutions (see figure below).

5 Typology of solutions

The reference application architecture for solutions can be further elaborated by adding a typology (classification) of solutions. This means that there are some types of solution and each type is formed around a predominant solution artefact, namely:

• event centric,
• data-entry centric,
• document/content centric,
• data or/and information flow centric,
• data or/and information visualisation,
• IoT-device centric,
• short-running operations (or activity-based),
• long-running operations (or process-based),
• etc.

For each of these types of solution it is possible to propose a reference architecture. For example, a process-based solution reference architecture is illustrated in figure below. (Note that each activity in this process is surrounded by microservices with pre- and post-automation strips.)

However, a real solution, usually, combines some of those types.

Thus, solutions are delivered in accordance with the following generis procedure:

1. Minimal architecting to understand the type (or a mixture of types) of a solution.
2. Collecting use cases to define capabilities of the solution.
3. Quick prototyping to outline functions, APIs, and solutions artefacts.
4. Conducting gap analysis to determine what is missing in the platform(s).
5. Developing missing functionality as microservices to close the gap.
6. Assembling newly created and existing microservices to deliver the solution.

And, don’t forget the versioning for everything.

Thanks,
AS

This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW

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