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

Smart Cities from the systems point of view

Thanks,
AS

Systems-level standardisation (example of smart cities)

Overall common city goals include, for example, sustainable development, efficiency, resilience, safety and support for citizen’s engagement and participation. However, an individual city will follow its own approach in smart cities programmes and projects.

The current implementation practices of smart cities are rather disjoint, namely:

• smart cities projects are, primarily, local initiatives
• smart cities projects are considered as technology projects
• numerous smart cities interest groups are, primarily, clubs
• efforts for development of common vision are insufficient
• typical financing patterns are: the government is budgeting (to some extent) some cities which engage technological companies and the government is budgeting some technological companies (China’s approach) 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. They carry out a lot of duplication of work, developed solutions are not reusable, the same mistakes are repeated.

To address such negative phenomena, the IEC came up with a new approach to standardisation – the systems-level standardisation which provides the context for the traditional product-level standardisation. The systems-level standardisation is aim to achieve synergy between uniformity (availability of standard products) and diversity (ability to combine standard and proprietary products).

The systems-level standardisation (which is carried out by the IEC Systems Committee “Smart Cities”) will offer to smart cities programmes and projects commonly agreed and fully traceable deliverables, namely:

• reference model (ideally, as an ontology), 
• reference architecture of a smart city as a system,
• typical use cases (how various actors interact with the smart city as a system); and 
• set of existing and new standards for implementation of various capabilities of smart cities. 

The openness of those deliverables allows easily adjust the reference architecture to an individual city and re-use already available standard elements.

The smart cities vision can be illustrated by the following figure.

(CUBE means Common Urban Business Execution)


Being equipped by those deliverables, various smart cities programmes and projects can carry out efficient and effective cooperation and coordination among them thus

• decreasing the total cost of smart cities programmes and projects, 
• reduce the lead time; and
• increase the quality of implementations.

At present, there are 4 Systems Committees (SyC):

1. Smart Energy
2. Active Assisted Living
3. Low Voltage Direct Current
4. Electrotechnical aspects of Smart Cities

And one System Evaluation Group (SEG):

1. Smart Manufacturing

The IEC system-level standardisation is based on the IEC Systems Approach.

Thanks,
AS

Smart-Home as a System-of-Systems reference architecture

This article uses the systems approach to define a reference architecture for the smart-home system domain. It is a continuation of the “Thing-as-a-System reference architecture for #IoT” article ( see https://www.linkedin.com/pulse/thing-as-a-system-reference-architecture-iot-alexander-samarin or http://improving-bpm-systems.blogspot.ch/2016/11/thing-as-system-reference-architecture.html ).

1 Basic concepts

The systems approach is a holistic approach to understanding a system and its discrete parts in the context of their behaviour and their relationships to one another and to their environment.

System domain is a subject field to which the systems approach is applied.

Examples are Smart-Energy, Smart-Home, Smart-Cities and Active Assisted Living (i.e. supporting people of any age with a temporary or permanent disability or impairment). The IoT is considered as a system domain as well.

Functional domain is a set of functions for fulfilment of top-level unit-of-purpose of a particular system.

Networking actors are people, digital services, digital applications and systems interacting over digital networks, primarily, the Internet.

Cyber-Physical System (CPS) is a system (comprises physical and digital discrete parts) that can interact with the physical world and networking actors.

Examples of CPS include autonomous automobile systems, process control systems, robotics systems, automatic pilot avionics, data acquisition and control systems for particle detectors at CERN, etc.

Thing is an intellectual (to some extend) cyber-physical device.

Thing as a System (TaaSy) is accessible, programmable and collaborative via digital services Thing which is considered as an CPS system. See [ref1].

Final-beneficiary is a person or an organisation served by a particular system domain (e.g. person who lives in a smart-home).

Wikipedia defines the “smart-home” concept or “home-automation” concept (also known as domotics or domotica) as the residential extension of building automation and involves the control and automation of lighting, ventilation, air conditioning, and security, as well as home appliances such as washer/dryers, ovens or refrigerators/freezers that use WiFi for remote monitoring.

Unfortunately, this definition has a few drawbacks, namely:

• it does not emphasize that all the cyber-physical devices within a particular home must work together as a system to achieve synergy and guarantee a good level of security and other desirable outcomes;
• home is place where one lives permanently, especially as a member of a family or household (thus final-beneficiaries for homes and buildings are different);
• other factors must be considered, e.g. political, socio-cultural, legal, etc.;
• smart-home systems is a class of cyber-physical systems.

Chapter 3 offers another definition of the smart-home concept to overcome these drawbacks.

2 Requirements for any smart-home implementation as a cyber-physical system

Some requirements (as an example) for any smart-home implementation:

1. Home-related internal activities can be progressively automated by intellectual cyber-physical devices.
2. Many various intellectual cyber-physical devices can be used synergistically at the same time.
3. Many various intellectual cyber-physical devices can be used synergistically at the same time and in the same place.
4. Some final-beneficiary can add new intellectual cyber-physical devices, digital applications and digital services.
5. Some functions of the intellectual cyber-physical device may be used at the smart-home scale, for example, a stereo could be used to broadcast an alert.
6. Various aspects of the smart-home functioning (e.g. level of security, environmental impact, comfort, etc.) must be integrally (i.e. including all the available information) monitored, analysed, controlled, alerted and acted on.
7. High level of trustworthiness (includes security, privacy, safety, reliability, and resilience) of any smart-home implementation.

3 System-forming considerations for any smart-home implementation

Note: The highlighted texts below are the essence of system-forming considerations.

The guiding motif of the smart-home system domain is that all the intellectual cyber-physical devices within a particular smart-home implementation must work together as a system. Explicit systems architecting and engineering is only a way to achieve security and operational excellence of smart-home implementations. In other words, the role of any smart-home implementation is to make a “forest” from individual “trees” (i.e. intellectual cyber-physical devices).

The key architectural decision about the smart-home reference architecture is that two primary concerns, namely, IoT (i.e. intellectual cyber-physical devices ) and smart-home, are separated. Because each intellectual cyber-physical device is, actually, a cyber-physical system then the smart-home is a digital system which includes many Thing-as-a-System (TaaSy) and is aimed for improving functioning of people’s home as a system.

Thus, it is possible to consider Smart-Home as a System of Systems (SHaaSoS). The SHaaSoS primary parts are:

• final-beneficiaries;
• other people involved in the smart-home lifecycle;
• various TaaSy, and
• various digital services and digital applications.

Technically, the SHaaSoS is a smart composition of various, even non-existing yet, TaaSy. The SHaaSoS as a composition environment must be also very adaptive, flexible and secure, for example:

• recognise some functionality of TaaSy as essential for the whole system;
• allow different functional domains to cooperate: for example, healthcare domains may use video surveillance functionality from the security domain;
• isolate, at the same, various functional domains, subsystems and TaaSy, and
• integrate everything via explicit and machine-executable processes.

Any SHaaSoS may interact with many external (relatively to a particular smart-home system) networking actors.

Considering that many TaaSy may be added to and removed from the SHaaSoS, the later must be able to control the lifecycles of all its TaaSy. This is something likes configuration management in ITIL.

To reinforce the security, each TaaSy must follow its well-defined contracts that are executed by the SHaaSoS ( see “Digital-contract-as-a-process enables business in the digital world” http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ). For example, a TaaSy fridge will have several internal & external digital contracts at the same time:

• with people who live in a particular home;
• with a producer of this fridge;
• with a service company for maintenance of this fridge;
• with some online shops to order various food, and 
• with the SHaaSoS of a particular home to achieve common goals of energy consumption, to inform about available food, etc.

The fulfilment of some of those digital contracts may require the usage of the Internet. Thus, the TaaSy fridge must be able to “demonstrate” to an in-house Internet router that the TaaSy fridge has rights to exchange data with some external digital services. Any data exchange with other digital services will be prohibited by the in-house router.

Any SHaaSoS itself follows its own digital contracts with people who live in a particular home. Please note, that any SHaaSoS is a bit “more” complex than a major-domo (or castellan, concierge, chamberlain, seneschal, mayor of the palace, maître d'hôtel, head butler and chief steward), because any SHaaSoS has its own contracts with its producer and its supporting services.

In smart home systems it is mandatory to consider the 3D geometry of any smart home because some functions are location-dependent (e.g. the same room); also some TaaSy may be mobile. Another very important factor is the time, because something must occur at a particular time, after some time, etc. The both factors, time and place must be integrated.

Potentially, each the behaviour of each final-beneficiaries must be planned, monitored and anticipated because some functions may operate differently when final-beneficiaries are in groups or individual. Imagine that each final-beneficiary has a trajectory in place x time space and those trajectories may intersect.

4 Mapping between requirements and system-forming considerations

	Explicit architecting	Two primary concerns	SHaaSoS	Composition environment	TaaSy lifecycle	Digital contract	Time and place integration
Progressive automation		X	X		X
Time factor	X	X	X	X			X
Place factor	X	X	X	X			X
Easy to install		X		X	X
Reuse of functionality	X		X	X	X		X
Holistic view	X	X	X		X	X	X
Trustworthiness	X	X	X		X	X	X

5 Essential views of Reference Architecture (RA)

5.1 Systemic viewpoint

The SHaaSoS systemic groups (or subsystems) are the following:

• TaaSy bay to connect the SHaaSoS and various TaaSy;
• Supporting group to provide functionality shared within a digital system (e.g. logging, monitoring, data handling, collaboration, process management, decision management, analytics, etc.);
• Primary group to provide core business functionality;
• Coordination group to execute digital contracts between various networking actors, TaaSy and SHaaSoS itself;
• Managerial group to reconfigure the SHaaSoS, and
• Operational group to maintain the proper functioning of the SHaaSoS. 

5.2 Functional viewpoint

The smart-home system domain has the following functional domains: security, food & cooking, health, communication, comfort, entertainment, cleaning and maintenance.

Each of those functional domains brings its own TaaSy and usually contributes to some systemic groups.

5.3 Operational patterns viewpoint

Two followings operational patterns are mainly used by the SHaaSoS:

Observe, Orient, Decide, Act (OODA) ( see https://en.wikipedia.org/wiki/OODA_loop ). This pattern is used to detect important events to be reacted with some actions (actually, initiated processes). It is illustrated in the “Event-processing viewpoint”.

Coordination, Event Streams, Analytics, Rules (CESAR). This pattern is used after the OODA pattern because a process (initiated by the OODA) must coordinate some activities, continuously monitor the current situation, make some predictions via analytical tools, and select the best next actions in accordance to existing rules.

5.4 Event-processing viewpoint

A very good presentation of this viewpoint can be found in http://www.slideshare.net/JanThielscher/successful-iot-projects-a-few-lessons that, actually, shows the pattern OODA.

5.5 Application architecture viewpoint

Application architecture of any SHaaSoS follows the platform pattern ( see http://improving-bpm-systems.blogspot.ch/search/label/%23platform ).

Such a platform comprises TaaSy bay and supporting functionality as well as a layer with SHaaSoS-specific functionality.

Solutions which are built on top of this platform are from the following functional domains: operational domain, managerial domain, primary domain and coordination domain. Those solutions use common patterns, tools, services available in the platform. Preferably, those solutions are assembled from microservices ( see http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html ).

This architecture is optimised for flexibility (separation of functionality into units-of-deployment), diversity (each SHaaSoS is different), uniformity (to avoid reinventing the wheel) and security (explicit and machine-executable processes).

5.6 Processes (flow of control) viewpoint

Potential processes in the coordination group are the following:

• Adding a digital contract to the repository of digital contracts
• Validation of a digital contract
• Execution (running) of a digital contract
• Control (including monitoring) of a running digital contract
• Execution of individual activities within a running digital contract
• Suspension of a digital contract
• Resuming of a suspended digital contract
• Termination (cancellation) of a running digital contract
• Archiving of a digital contract
• Removing a digital contract from the repository of digital contracts

5.7 Services viewpoint

All functionality is available as digital services and microservices. All of them have APIs which are developed under the same guidelines (a reference to be provided).

6 Conclusion

To achieve this, data formats and APIs must be flexible enough to be able to add more and more complex TaaSy. Thus, standardization of data formats and APIs must be based on the following practices:

• system domain ontologies,
• reusable compact data-structures also known as micro-formats,
• common modelling guidelines for business entities, 
• common modelling guidelines for services, and
• strict versioning. 

7 ANNEX Functions of home (as an example)

The article ( http://oer.nios.ac.in/wiki/index.php/Functions_of_a_Home ) provides a good list of functions of home:

1. Protective - Home gives us protection from outside heat and cold, sun, wind, rain, etc. It also gives protection to small children and old people who need special care.
2. Economic - Your home facilitates income generating activities like pickle or papad making or any other similar activity. Families also save money by staying together and sharing everything available. The money thus saved can be more effectively utilized elsewhere.
3. Religious - A home provides a place for a number of religious activities. You celebrate various festivals while staying in a home.
4. Educative - A home is the centre of family life. A child’s basic education starts from the home, which helps in the development of personality.
5. Social - A home facilitates meeting with other people and promotes social interaction.
6. Affectional - Home is a place where all family members stay together with love and affection.
7. Status-giving - You enjoy a particular status in the society if you are staying in a home.

A good source of home internal activities to be potentially automated comes from roles of staff who are working for rich people. Normal people would like that, such services will be carried out by appliances or robots or B2B partners.

The best source of internal home activities is - https://www.family-tree.co.uk/news-and-views/royal-household-staff-records-now-online.

A reigning UK monarch typically had 1,000 staff in the royal household. The biggest department was the Lord Chamberlain’s department, which had on average 700 staff and was responsible for the ceremonial and social life of the Court. Traditionally, employees in this department included the ‘above stairs’ servants such as pages, craftsmen, chaplains, physicians, musicians, watermen and Yeomen of the Guard. There is also a number of fabulous occupation titles listed among the royal household staff:

• Chocolate Maker to the Queen
• Yeoman of the Mouth to Her Majesty Queen Mary in the Pantry
• Necessary Woman to the Corridor and Entrance Hall
• Keeper of the Lions in the Tower
• Moletaker
• Master of the Game of Cock Fighting
• Groom of the Removing Wardrobe
• Groom of the Stole
• Strewer of Herbs
• Laundress of the Body Linen

8 ANNEX Influencing factors (as an example) to be considered by the smart home system domain

Housing preferences change

The “concept of dwelling” is going to be changed as general housing preferences among customers, designers and real estate managers, including lifestyle/activity changes and spatial changes

• internal spatial organisation
• space saving
• flexibility in between

Environmental trends change

• “Energy-Saving” will increase due to home automation and energy monitoring and controlling. 
• “Material-Saving” will increase due to the reduction in number of device.
• “Time-Saving” will increase. 
• “Transportation-Saving” between home and workspace or other spaces will increase so traffic flows and pollution are going to be controlled.
• “Land-Saving” will increase and rapid extension of cities will be controlled.

Economic trends change

• “Space saving with higher quality” is going to be increased as general economic trends

Social trends change

• “Independently living” especially for elderly (covered by the IEC AAL SyC ) 
• “Healthy living” – working at home
• “A man's house is his castle” – being better protected at home
• Higher preparedness for disasters

Technological trends changes

• Pervasive computing
• In-house ICT
• IoT progress
• Commoditisation of security equipment (video surveillance, presence detections, etc.).

Thanks,

AS

Thing-as-a-System reference architecture for #IoT

This article is a continuation of “Domesticate the #IoT as cyber-physical systems” article ( see http://improving-bpm-systems.blogspot.ch/2016/11/domesticate-iot-as-cyber-physical.html ). It uses the systems approach to define a reference architecture for Thing-as-a-System (TaaSy) which forms the IoT.

1 Basic concepts

Networking actors are humans, digital services, digital applications and systems interacting over the Internet.

Networking human actors: owner, manager, operator or customer.

Cyber-Physical System (CPS) is a system (comprises physical and computational discrete parts) that can interact with the physical world and networking actors.

Examples of CPS include autonomous automobile systems, process control systems, robotics systems, automatic pilot avionics, data acquisition and control systems for particle detectors at CERN, etc.

CPS for IoT is an CPS which makes a Thing as a System (TaaSy)which is accessible, programmable and collaborative via digital services.

Here is clarification of mentioned above characteristics of TaaSy:

1. Being a system, any TaaSy can carry out its essential functions without being rely on any other TaaSy(s).
2. Any TaaSy is a networking actor.
3. Any TaaSy provides some digital services for networking actors (as GUI for humans and as API for others).
4. Functioning of any TaaSy can be programmed (to some extent) by authorised networking actors.
5. Any TaaSy can collaborate with some networking actors in accordance with some digital contracts ( see “#IoT as a system of digital contracts” http://improving-bpm-systems.blogspot.ch/2016/08/iot-as-system-of-digital-contracts.html ).

TaaSy physical parts: TaaSy devices, computational hardware parts, networking hardware parts.

TaaSy device types: sensor or actuator.

TaaSy cyber parts: various software parts.

TaaSy gateway: networks and connectivity adapter for various TaaSy devices which may use various networks (e.g. Bluetooth, cables, etc.). This gateway collects and homogenizes the various mechanical signals or network-based data streams into manageable data.

2 Essential views of Reference Architecture (RA)

2.1 Viable system model viewpoint

The Viable System Model (VSM) – see https://en.wikipedia.org/wiki/Viable_system_model – describes principal functions and flow of data between them for viable (i.e. autonomous) systems. A viable system is composed of five interacting subsystems which may be mapped onto aspects of organizational structure.

Viable system model

By applying the VSM for TaaSy, it is reasonable to say that Systems 4 and 5 are almost absent because they are carried out by the owner and the manufacturer of the Thing. Systems 2 is about of routine coordinating various activities and System 3 is about exceptions handling and performance management. Considering the digital nature of TaaSy, Systems 2 and 3 can be combined together as well as necessary support for System 4. 

2.2 Functional domains viewpoint

TaaSy functional domains:

• physical – the thing and all TaaSy devices;
• device drivers to connect cyber parts with device-specific and network-specific equipment;
• supporting to provide typical functionality of a digital system (e.g. logging, monitoring, etc.);
• enabling to provide essential shared functionality (e.g. data handling, collaboration, process management, decision management, analytics, etc.);
• purpose-specific to provide core business functionality,
• IoT-specific to execute contracts between various networking actors, and
• managerial to reconfigure the system; [look at COBIT, ITIL, IT4IT]
• operational to maintain the proper functioning of the system. [look at ITIL, IT4IT]

Functional domains viewpoint

Standard networking (i.e. over the Internet) and commodity computing software and hardware parts are deliberately not discussed.

There are also several cross-domain functions which address typical quality requirements:

• security (confidentiality integrity availability)
• data and services interoperability
• safety
• resilience
• privacy

2.3 Application architecture viewpoint

Application architecture of any TaaSy follows the platform pattern ( see http://improving-bpm-systems.blogspot.ch/search/label/%23platform ).

Such a platform comprises drivers, supporting and enabling functionality as well as a layer with TaaSy-specific functionality.

Solutions which are built on top of this platform are from the following functional domains: operational domain, managerial domain, purpose-specific domain and IoT-specific domain. Those solutions use patterns, tools, services available in the platform. Preferably, those solutions are assembled from microservices ( see http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html ).

Application architecture viewpoint

This architecture is optimised for flexibility (quick delivery of new functionality), diversity (each TaaSy is different), uniformity (to avoid reinventing the wheel) and security (separation of functionality into units-of-deployment).

Such a platform may be deployed at the same time in cloud-computing, local-computing and fog-computing environments. Of course, different functions will be in different environments; on the contrary, some software may be the same in all three environments.

Multi-environment usage of the platform

2.4 Processes (flow of control) viewpoint

Potential processes in operational and managerial domains are the following:

• ITIL service design (partially)
• ITIL service transition
• ITIL service operations
• ITIL CSI (partially)
• COBIT DSS01 Manage Operations
• COBIT DSS02 Manage Service Request and Incidents
• COBIT DSS03 Manage Problems
• COBIT DSS04 Manage Continuity

2.5 Services viewpoint

All functionality is available as digital services and microservices. All of them have APIs which are developed under the same guidelines.

3 TaaSy collaboration patterns in the IoT

The specific feature of IoT is the ability of TaaSy(s) to collaborate between them and other networking actors.

3.1 Point-to-Point (P2P)

The P2P collaboration pattern is about ad-hoc interactions between one networking actor and a particular TaaSy.

3.2 Majordomo

The majordomo collaboration pattern is about interactions between master (i.e. Majordomo TaaSy) and slaves (other networking actors but, primarily, TaaSy).

3.3 Digital contracts

The digital-contract collaboration pattern is about interactions between several networking actors as peer (see http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ).

4 Conclusion

To manage the security of IoT, it is mandatory to define explicitly individual and collective behavior of Things. This is addressed in the proposed reference architecture by intensive used of processes, internally within a Thing-as-a-System and between them as digital contracts. 

Thanks,
AS

Domesticate the #IoT as cyber-physical systems

This article is a continuation of “#IoT as a system of digital contracts” article ( see http://improving-bpm-systems.blogspot.ch/2016/08/iot-as-system-of-digital-contracts.html ).

1 Introduction

The recent IoT-based DDOS attack confirmed the urgent necessity for more serious and systemic integration of the IoT into our civilisation. At present, many devices from the IoT “world” act as wild animals thus being dangerous.

Each member in our civilisation has to follow many rules & regulations & laws depending on contexts and his/her roles as citizen, husband/wife, father/mother, driver, employee, etc. Those rules and laws are wrapped as, usually, time-bound contracts. Just using a taxi is a short-time contract with its rules for a passenger and a driver.

IoT as cyber-physical systems must follow some rules & regulations & laws to become a very useful member of our civilisation. The famous example of such laws is “The three laws of robotics”.

Let us apply this practice of contract-based rules & regulations & laws to the Internet of Things – let us teach Things to follow their contracts thus domesticate Things.

To behave correctly, the IoT needs following digital contracts ( see “Digital-contract-as-a-process enables business in the digital world” http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ). A digital contract is an explicit and machine-executable process between several business-parties, primarily, Things, Services and People.

2 External digital contracts

For example, a future household fridge will have, as minimum, five types of external contract simultaneously:

• with People who are living a particular household;
• with a producer of this fridge;
• with a service company for maintenance of this fridge;
• with some online shops to order various food, and 
• with some other Things within a particular household to achieve together some goals of energy consumption.

The fulfillment of some of those contracts requires the usage of the Internet. Thus, the Fridge must be able to “demonstrate” to the in-house network Router that the Fridge has rights to exchange data with some Internet-based services. Any data exchange with other internet-based services will be prohibited by the Router.

3 Internal digital contracts

In addition, being a cyber-physical system, a Thing must follow many internal contracts. Governance of all software components must be carried out as contracts for requesting a change, approval of a change, etc. Actually, all the typical IT governance and operations processes are already well-defined in COBIT, ITIL and IT4IT. They, being designed for IT departments, have to be scaled-down to the needs of Things. Even a minimalistic patch-management processes will be a huge improvement.

4 Implementation considerations

The implementation of digital contracts can be simplified by the blockchain technology (as the best, so far, records storage) which provides integrity and traceability (see “Beauty of #blockchain - doveryai, no proveryai (trust but verify)” http://improving-bpm-systems.blogspot.ch/2016/10/beauty-of-blockchain-doveryai-no.html ).

All the digital contracts, separate tasks, software components, messages, documents, workflows are notarized by blockchain.

Considering that, capabilities of particular Things may be rather different, some kind of a “majordomo” Service may be necessary to execute various digital contracts; Things will be participants in their workflows.

Also, in complex households some coordination between various digital contracts must be carried out (e.g. no preventative maintenance during receptions). This is a natural job for a “majordomo” Service. Obviously, it has its own digital contracts with the People who are living a particular household.

5 Conclusion

The proposed use of digital contracts, explicit governance and blockchain can make an impression that it will increase the complexity of IoT. Fortunately, this is not correct, because although more components will be necessary, the links between them become explicit.

In accordance with the Cynefin framework (https://en.wikipedia.org/wiki/Cynefin_Framework ), explicit linking allows progressing:

- from “Complex” situation (in which the relationship between cause and effect can only be perceived in retrospect, but not in advance)

- to “Complicated” situation (in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge).

Of course, a lot of painful standardisation and regulatory work is necessary ahead, but, in accordance with a Russian proverb “volkov boyat'sya — v les ne khodit'”, no pain no gain.

Thanks,
AS

Some #entarch concepts derived from the #systemsapproach

In this blogpost I use the systems approach to derive some definitions for Enterprise Architecture (EA) subject field. The basics are in slides 3-12 of http://improving-bpm-systems.blogspot.ch/2016/07/enterprise-architecture-entarch-as.html .

System is a set of interacting discrete parts organised as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes.

Any system-of-interest has an architecture which is a totality of fundamental concepts or properties of a system in its environment embodied in its discrete parts and relationships, and in the principles of its design and evolution. Architecture of a system-of-interest maybe accidental or intended depending on the way of constructing this system. In any case, any serious change in an enterprise-of-interest implies changing in its EA.

Enterprise is an emotive or motivational structure, bounded by a shared vision, shared values and mutual commitments for joint efforts to achieve one or more stated purposes. An enterprise is realized by an organisation which is a legal structure, bounded by rules, roles and responsibilities. Obviously, any modern enterprise together with its organisation is a socio-technical system (in which the interaction between people and technology is a dominant consideration). Also, an enterprise is a self-evolution system.

Thus Enterprise Architecture (EA) is architecture of an enterprise as a socio-technical system. (Although, it is correct, it is a useless definition for many people). The main and unique power of EA is the ability to objectively estimate effect (cost, benefits and risks) of potential internal changes. For example, what could be the effect of changes in a business unit which necessitates some modifications in some enterprise and departmental applications?

A good EA is the primary enabler for any internal transformations of different extent: project, program and strategy. For any transformation, EA is used to define and validate the future version of EA (called target architecture or blueprint). For example, a good EA can evaluate a level of implementability of a proposed strategy.

Usually, EA is described via a set of architecture viewpoints. Those architecture viewpoints define a set of model kinds which establish relationships between various artefacts: vision, mission, objectives, rules, servers, etc. Architecture viewpoints applied to a system-of-interest generates views whcih comprise some models.

Ideally those viewpoints are aligned, but in the reality it is not the case because different viewpoints are created by different people.

Because of the socio-technological nature of enterprises and their high-level of complexity, EA historically considered as two domain architectures:

1. Business architecture is architecture of an enterprise considered as a social system for delivering Value (as products and/or services). Main artefacts in business-centric viewpoints are: mission, vision, products, services, directives, objectives, processes, roles, etc.
2. IT-architecture is architecture of an enterprise considered as an IT-system. Main artefacts in IT-centric viewpoints are: IT tools, processes, and methodologies and associated equipment employed to collect, transform, transport and present information. 

The dependency between those architectures is, in theory, very straightforward. The business architecture defines the IT-architecture. But, in practice, very often, the IT-architecture evolves much slower than the business architecture, thus there is always a gap or misalignment between them.

To avoid this gap, it is necessary:

1. version all the artefacts during their lifecycle;
2. evlove artefacts to become digital, externalised, virtual and components of clouds;
3. model explicitly all relationships between artefacts;
4. make all models machine-executable, and 
5. be able to convert models from one view to models in another view.

Thanks,
AS

Enterprise Architecture (#EntArch) as a #SystemsApproach applied management discipline

The goal of this presentation is to show how the use of the systems approach to address typical enterprise challenges

• an algorithm to generate an enterprise’s blueprint (as a step toward Software-Defined Enterprises)
• different people in similar situations come to similar solutions and possibly bring innovations
• an algorithm to build a bigger enterprise from smaller ones

Enterprise Architecture (#EntArch) as a #systems-approach applied management discipline from Alexander SAMARIN


This is a full version of my presentation “Components of software defined companies” given at the BPM Conference Portugal 2016 http://lisbon.bpmconferenceportugal.com/

Software-defined enterprise is an enterprise whose functioning is guided by various machine-executable and machine-readable artefacts.


Thanks,
AS