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

Enterprise patterns: CESAR #entarch

The patterns OODA (Observe, Orient, Decide and Act) is very well know ( see https://en.wikipedia.org/wiki/OODA_loop ). But what’s happen AFTER it? In other words, is it possible to recommend a generic behavioral pattern when an action is taken by the OODA pattern?

This blogpost proposes a Coordination, Event Streams, Analytics, Rules (CESAR) pattern. This pattern is used after the OODA pattern because a process (initiated by the OODA) must coordinate some activities, continuously monitor (from many different sources) the permanently changing situation, make some predictions via analytical tools, and select the best next actions in accordance with existing rules.

d

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

#IoT as a system of digital contracts (thanks to #blockchain, #BPM, #ECM and #cryptography)

Ability to work together is one of the essential enablers for the civilisation. At present, countries, companies and individuals can work together. Considering the current huge interest to the IoT, this blogpost outlines how to enable the things also working together with other things and people.

From the three following definitions of IoT, the last one is the better fit with this blogpost goal.

1. Wikipedia states that “the internet of things (IoT) is the network of physical devices, vehicles, buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data”
2. The IoT European Research Cluster (IERC) definition states that IoT is “A dynamic global network infrastructure with self-configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are seamlessly integrated into the information network.”.
3. The Alliance for IOT Innovation (AIOTI) report http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11810 says “The IoT represents a concept and a paradigm that considers pervasive presence in the environment of a variety of things/objects that through wireless and wired connections and unique addressing schemes are able to interact with each other and cooperate with other things/objects to create new applications/services and reach common goals.”

A typical pattern for working together is the following – establish a contract, carry it out and close it. Considering that the things understand very well digital information, a contract must be digital to be used by the things.

As explained in “Digital contract as a process enables business in the digital world (thanks to #blockchain, #BPM, #ECM and #cryptography)” 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-entities, primarily, things and people.

For example, a new future household fridge will have as minimum four types of contract simultaneously: 1) with people who are living a particular household, 2) with a producer and service company for this fridge, 3) with some online shops to order various food, and 4) with all other things within a particular household to achieve together some goals of energy consumptions.

In general, the things are contracted to cooperate with other things and people differently:

• orchestration of several “slaves” by one “master” (also known as strong coordination)
• choreography of two or more business-entities (also known as contractual coordination)
• goal-achieving by a group of participants, like a football team (also known as weak coordination)

Of course, the same thing holds different roles in different digital contracts.

Fortunately, digital contracts as explicit and machine-executable processes are powered by BPM which already knows how to handle all these complexities.

But, can BPM-centric digital contracts provide necessary processing for high data volumes are being generated? Yes, with the help from microservices. Let us consider that all automation activities in a process are implemented as microservices (which are potentially externalised from a business process engine).

Firstly, each process (actually a digital contract) may be executed in a partially independent environment – only a common part would be a blockchain with all the records (or audit trails).

Secondly, each running process can anticipate what microservices will be required and can prepare secured and individual instances of microservices (with one-time passwords).

Imagine a football match. The venue starts an individual “customer” process for each person on the stadium. Knowing the customer, such a process prepares microservices which are the most probably used by this person.

Thanks,
AS

Synergy between #BPM, #digital, #IoT, #microservices and #blockchain

Recently, I made a prediction for 2016 (see http://bpm.com/bpm-today/in-the-forum/what-are-your-bpm-predictions-for-2016 ) 

The following synergies will start to be implemented:

• BPM and blockchain
• BPM and microservices
• BPM and IoT
• BPM and digital

Below this prediction is in more details.

Each process instance becomes a self-secured on-demand personal solution which:

• is built on-demand from several microservices (some data are kept within this individual solution)
• has a limited, well-defined (roles are known) and validated set of stakeholders: direct participants, indirect participants (e.g. customers), controlling bodies, governing bodies, etc.
• operates in the way that each action is secured via blockchain technology (signed by some stakeholders) - see about blockchain http://improving-bpm-systems.blogspot.ch/search/label/%23blockchain 
• operates in the way that its audit trail is secured via blockchain technology (signed by some stakeholders)
• instantiates on-demand microservices in accordance with process-instance evolution - see about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices
• secures microservices dynamically at their instantiation (see 6.3 in http://improving-bpm-systems.blogspot.de/2015/04/architecting-cloud-friendly-application.html ) - each microservice is just binary data
• may use (via IoT) some sensors (physical world to digital world adapters) and “materialisers” / "actuators" (digital world to physical world adapters) - of course if they understand this process and agree to act particular roles
• is fully digital (see http://improving-bpm-systems.blogspot.ch/2015/03/entarch-view-on-ditigal.html )
• is virtual
• may use several existing clouds

Note that each process instance may comprises of some other process instances (i.e. pools in BPMN) thus being a distributed process instance.

Thus, for each individual client it will be possible to have an individual process instance which is built in accordance with the customer's needs and behaviour and which is fully secured for this customer. (See my comment to http://bpm.com/bpm-today/in-the-forum/by-2017,-will-70-percent-of-successful-digital-business-models-rely-on-unstable-processes )

A real-life example – a stadium during a football match is full of fans. Each of them has his/her own needs and behaviour. Perfect peak performance case which can be economically reasonable only via on-demand provisioning of processes and microservices.

I think, healthcare could be another example.

Happy BPMing,
AS

Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)

1 Introduction

This blogpost extends the blogpost “Architecting application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html to “cloud-friendly application architecture”. You may jump to chapter 8 to see a demo of it.

This cloud-friendly application architecture opens the way to synergy between #BPM, #SOA, #cloud, #microservices, #IoT, #digital and #security.

2 Clarification of some terminology

2.1 Process

Many articles about microservices mentioned “process”. I believe they mean “computing process” (e.g. an instance of JVM) which should not be confused with “business process”.

2.2 Orchestration

Another confusing term is “orchestration”. In some articles, it means “container orchestration layer” which allows one to specify how the micro-services are handled in fault tolerant and in scaling up and scaling down (see http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture ).

See also http://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices slide 70 “Orchestration for Applications”

O’Reilly book “Migrating to Cloud-Native Application Architectures” http://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook says “The ESB becomes the owner of all routing, transformation, policy, security, and other decisions governing the interaction between services. We call this orchestration, analogous to the conductor who determines the course of the music performed by an orchestra during its performance. ESBs and orchestration make for very simple and pleasing architecture diagrams, but their simplicity is deceiving. Often hiding within the ESB is a tangled web of complexity.” I think, this is a wrong analogy. The conductor delivers only one symphony at a time. ESB delivers many symphonies at the same time. Not surprising that it such “centralised orchestration” is difficult.

In other articles, it means one of two BPMN ways to compose business processes – orchestration as a strong coordination and choreography as weak coordination. This orchestration is a domain bounded because it is carried out in the scope of a particular business process.

3  Commenting some posts about microservices

From http://intellyx.com/2015/03/11/microservices-avoiding-dumb-pipes/ “Rather, we simply have a new way of thinking about “smart” pipes – microservice integration that is architected following web scale, cloud-centric principles.”

Good point although I think being “cloud-friendly” is better than “cloud-centric” as the hybrid environment is very attractive right now.

From http://www.computerweekly.com/feature/Microservices-How-to-prepare-next-generation-cloud-applications “Each microservice is an independent, autonomous process with no dependency on other microservices. It does not even know or acknowledge the existence of other microservices.

Microservices communicate with each other through language and platform-agnostic application programming interfaces (APIs). These APIs are typically exposed as Rest endpoints or can be invoked via lightweight messaging protocols such as RabbitMQ. They are loosely coupled with each other avoiding synchronous and blocking-calls whenever possible.”

The first of these two paragraphs says that each microservice is “independent” from other microservices and the second paragraph says “microservices communicate with each other” thus there is some dependency.

Certainly, microservices are interdependent by design and operationally-independent. It seems that microservices may refer to each other indirectly via a “naming service” (some kind of URI to URL mapper or like in CORBA). Therefore, a microservice may employ other microservices to complete its work. In extreme, a microservice may be an assembly of microservices. Article http://microxchg.io/2015/slides/02_01_DomainServiceAggregators.pdf provides an example of data aggregation with a business domain.

From http://www.ben-morris.com/how-big-is-a-microservice/ ‘Perhaps “micro” is a misleading prefix here. These are not necessarily “small” as in “little”.’

Yes, size in LOC does not matter. There is only one limit – SRP. Interesting, that no limitations on “size” of this single responsibility. Thus a microservice with a greater and single responsibility may be assembled from microservices with lesser and single responsibilities.

From https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/ “In the comments, it was suggested that granularity was irrelevant as multiple granular microservices could be composed to form a coarser-grained microservice that would provide a more appropriate level of abstraction. My response was that while this is theoretically true, aggregating service calls in that manner risks issues due to network latency.”

In addition for my comments to that blogpost, I would like to add that designing microservices as distributed autonomous components (each with own computing process) is forcing to consider (up-front and not as refactoring) a proper error-recovery which is much more difficult than the error-handling when components are in the same computing process.

From http://avirosenthal.blogspot.co.il/2015/04/micro-services-new-soa-style.html “How could a [Business] Capacity will be related to a Fine Grained entity such as Micro Service?”

In general, a business capability is a cohesive set of processes (or cluster of processes in accordance with http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ). Those processes are implemented as assemblies of microservices. Some of those microservices are unique for a particular process and for a particular cluster; others are shared between clusters.

From https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/ “Microservices and their granularity are ideal for the development and maintenance of the service. But that does push complexity more towards the app itself. A complexity that those apps cannot manage as they are often executed on platform with constrained resources (battery, network, CPU). Combining services in a higher level logic to serve the purpose of apps or business processes proves to be faster to develop and easier to maintain.”

Yes, assembling of microservices is the way to reduce complexity.

From http://martinfowler.com/articles/microservices.html “In short, the microservice architectural style is an approach to developing a single application as a suite of small services.”

If application as a unit of deployment (even decomposed into a few tiers) is no more the physical boundary then boundaries becomes logical and they are coming from the business – business functions, business services and business capabilities. Note they are actually just different viewpoints – see “Common understanding of #bizarch (business architecture) and #BPM” http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.html . Less IT applications and more business-process-centric solutions.

From http://nealford.com/memeagora/2015/03/30/architecture_is_abstract_until_operationalized.html “Continuous Delivery and the DevOps movement illustrated the pitfalls of ignoring the effort required to implement an architecture and keep it current. There is nothing wrong with modeling architecture and capturing those efforts, but the implementation is only the first step. Architecture is abstract until operationalized. In other words, you can’t really judge the long-term viability of any architecture until you’ve not only implemented it but also upgraded it. And perhaps even enabled it to withstand unusual occurrences.”

Correct, but slightly simplified observations – actually, 3 (three) major upgrades are necessary to demonstrate that architecture is good. Rationale: it is recommend leaving a solution team before the 3th major upgrade of this solution.

From http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems “Integration suites offer a complete stack that not only gives ESB capabilities but also more business-specific tools such as BPM (business process management), business activity monitoring, master data management, and a repository.”

Sorry, but ESB is not the centre of the universe if the business position is taken http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-software-architects-from.html .

4 Forces

4.1 Containers enables the free movement of microservices

As microservices are not confined any more by the physical boundaries of application, they can freely move among on-premises environments, private and public clouds, intellectual “things” and even mobile devices. See “We’re finally headed towards autonomous, self-migrating containers for cloud-application automation” http://research.gigaom.com/2014/12/are-we-moving-to-autonomous-self-migrating-containers-for-cloud-application-automation-i-think-so/

As microservices become place-independent, it is necessary to have a good “naming service” (as we had in CORBA) to allow mapping of microservice’s URI to new URL. Such “naming services” is also known as discovery services.

The most popular container is www.docker.com. From http://www.infoq.com/articles/microservices-revolution “Docker’s appeal is twofold: it’s fast and it’s portable” and “Docker containers can start, and stop, in hundreds of milliseconds.” 

4.2 Microservices vs API

At present, there is no synergy between microservices and API as illustrated by the following quotes:

• From http://sdtimes.com/digging-into-microservices/ “The fundamental difference between microservices and APIs is that microservices are used to build applications, whereas APIs are used to integrate applications...” 
• From http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.jhtml “In MSA (microservice architecture), integration is the problem, not the solution”. 
• http://apievangelist.com/2015/04/10/on-apis-and-microservices/

Considering that “IT application” as a physical boundary is disappearing with microservices and integration between “IT applications” often follows the span of business processes ( http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html ) then microservices and API must “fuse”.

From http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ “Part of the problem with API management and micro-services or with the mediation / message broker middleware technologies is that these can impose a software layer that is burdensome on the micro-services architecture... Let us say an approach to implementing micro-services would be to put them into a traditional API Management service as offered by a number of vendors. There would indeed be an overhead introduced because the API Layers impose a stiff penalty of authentication, authorization, then load balancing before a message can be delivered. What is needed is a lightweight version of API Management for some trusted services behind a firewall that are low risk and high performance.”

And from http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ “Micro-services however should still be implemented in an API Management framework and ESB’s, Message Brokers and other SOA architectural components still make sense in this micro-services world especially when augmented with a container composition tool. In fact these components should be used to make micro-services transparent and reusable.”

Agree about simplification of API management which should not repeat mistakes of ESB being over complicated. 

4.3 Potentials of microservices

Are microservices going to replace apps and potentially be executable in Things linked to Internet of Things ? From http://www.computerweekly.com/feature/Microservices-How-to-prepare-next-generation-cloud-applications “The evolution of the internet of things and machine-to-machine communication demands new ways of structuring the application modules. Each module should be responsible for one task participating in the larger workflow.” Also, http://iot.sys-con.com/node/3289475?utm_content=buffer97b76&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer .

Microservices and mobile apps from http://www.feedhenry.com/microservices-for-mobile/

Microservices and digital from https://www.linkedin.com/pulse/microservices-role-digital-business-architect-mike-clark and from http://forms2.tibco.com/rs/tibcoinfra/images/WP-microservices%20part1-web.pdf

Potentially better resilience from http://www.slideshare.net/ufried/patterns-of-resilience ?

Are microservices the next big thing from https://genehughson.wordpress.com/2015/04/09/are-microservices-the-next-big-thing/ . 

4.4 Concerns about microservices

From http://research.gigaom.com/2014/12/are-we-moving-to-autonomous-self-migrating-containers-for-cloud-application-automation-i-think-so/ “Using containers is not a new procedure: They certainly predate Docker. However, auto-provisioning and auto-migration are concepts that were often pushed but very remained elusive in practice.”

How does eventual consistency relate to SLA? Is eventual consistency applicable to all sectors?

Performance in https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/

Misuse of technology from http://blog.christianposta.com/microservices/youre-not-going-to-do-microservices/

Challenges from https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/

A long list from http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html “Significant Operations Overhead” “Substantial DevOps Skills Required” “Implicit Interfaces”, “Duplication Of Effort”, “Distributed System Complexity”, “Asynchronicity Is Difficult!”, “Testability Challenges”.

From http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/ ‘However, “there is a price to pay for microservices,” cautions Thomas. “You are increasing the complexity of the application system by having a lot more moving parts and a lot more interdependencies.”’

Various system-design related concerns from http://particular.net/blog/microservices-future-or-empty-hype .

A longer list on slide 34 from http://www.slideshare.net/myfear/eisele-architecting-largeenterpriseprojects-46546852 .

A collection of scaring factors from http://www.infoq.com/research/adopting-microservice-architecture?utm_source=infoqresearch&utm_campaign=rr-content .

And a few future problems from http://www.thoughtworks.com/talks/software-development-21st-century-xconf-europe-2014 .

5 Characteristics of cloud-scale applications

From http://devops.com/blogs/containers-designed-antiquated-application-architecture/ “Cloud-scale applications by nature are stateless with any application state being managed by cache or database services. The compute unit of measure is the process not the CPU, which enables greater scalability. .... They scale across network architectures easily allowing businesses to run in private data centers and leverage cloud for excess capacity when needed.”

From http://thenewstack.io/best-practices-for-developing-cloud-native-applications-and-microservice-architectures “Be micro”, “Be explicit”, “Be stateless”, “Be temporal”.

From http://12factor.net/backing-services “Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.” and “Treat backing services as attached resources”.

From http://www.infoq.com/articles/microservices-revolution “The point is that in the modern stateless application architecture, state is actually everywhere--and this state needs to be managed.”

A huge list from http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ .

Slide 68 from http://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices .

6 Becoming cloud-friendly

6.1 State management

Potential techniques for the state management:

1. one persistency service (or backing service) for the state of the whole solution (even distributed solution) 
2. predefined state which is created by embedding state into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) 
3. idempotency 

6.2 Performance

Potential techniques for performance improvement (primarily the network latency):

1. easy moving an individual containerized copy of the microservice between nodes (thus moving a microservice close to its consumer upto his/her mobile device) 
2. on-demand creating an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) 
3. creating an individual containerized copy of the microservice for a particular consumer to diminish the security overhead (but the run-time knowledge about the context is mandatory) 

6.3 Lightweight security

1. predefined state which is created by embedding security keys into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) thus achieving self-containment of PEPs 
2. one-off execution (i.e. self-destruction) 

See also the blogpost “Enrich RBAC and ABAC with ProBAC” http://improving-bpm-systems.blogspot.ch/2015/01/enrich-rbac-and-abac-with-probac.html which explains how the run-time knowledge about the context can be provided to achieve “embedded” security.

7 Cloud-friendly architecture

Let us look at the post “Architecting application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html and extend the described in it architecture to being cloud-friendly. In that blogpost, I introduced Autonomous Component (AC) with a note that at present, it is not possible to claim that ACs are microservices or services.

This architecture implements business solutions (instead of IT applications because the boundaries of IT applications are not relevant any more) as a coordinated collection of autonomous components. Each AC is a unit of functionality (as SRP) which can be executed in its own computing process (thus a unit of deployment which can be deployed in a separate host somewhere). An AC may be an assembly of several ACs. In general, ACs are structurally interdependent, behaviorally (or operationally) independent and contractually dependent.

Below, several typical ACs are described from the “being cloud-friendly” viewpoint through the following characteristics:

• state: “stateless”, “stateful” 
• idempotency: “yes”, “no” 
• instantiation: “availability-based”, “on-demand” (or “lazy loading”), “individual” 
• place: “place-dependent”, “place-independent”, “multiple-place-independent” 
• security: RBAC, ABAC, ProBAC, “embedded” 

Resource-access (RA) AC to carry out basic operations over data or documents which are stored in a single repository.

• Cloud-friendly: stateful, place-dependent for updates, place-independent for reads, idempotent, availability-based-instantiation. 
• Security techniques: RBAC, ABAC and ProBAC. 
• Contracting ACs: No use of other ACs. 
• Examples: access to a database, access to a document management repository. 
• Note: Usually have an internal database. 

Resource-assembly-access (RAA) AC to carry out basic operations over a compound business entity (which comprises several resources).

• Cloud-friendly: stateless, multiple-place-independent, idempotent, on-demand-instantiation. 
• Security techniques: RBAC, ABAC, ProBAC and embedded. 
• Contracting ACs: Use of some ACs, primarily, resource-access ACs. 
• Example: virtual data layer, MDM. 

Persistence backing (PB) AC to keep a state or configuration.

• Cloud-friendly: stateful, place-dependent, idempotent, availability-based-instantiation. 
• Security techniques: ProBAC. 
• Contracting ACs: No use of other ACs. 
• Example: Database persistence layer. 

Utility (U) AC to transform or analyse data/documents.

• Cloud-friendly: stateless, multiple-place-independent, individual-instantiation 
• Security techniques: RBAC, ABAC, ProBAC and embedded. 
• Contracting ACs: No use of other ACs. 
• Note: May have its own configuration database. 
• Example: Word-to-PDF converter. 

DSL-manager (DM) AC to manage DSL scripts.

• Cloud-friendly: stateful, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Use its own configuration persistence backing AC. 
• Example: A business rules engine, process execution languages. 

DSL-processor (DP) AC to execute scripts in the DSL.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Stateful DSL-processor has its own state persistence backing AC. 
• Note: Business rules are considered be immutable thus its DSL-processes is stateless.

DSL-script (DS) AC to execute a particular DSL algorithm with some parameters.

• Cloud-friendly: stateless or stateful, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: Use DSL-processor AC. 
• Example: A particular rule for a particular business rules engine. 

Resource role-based mini-portal (RRBMP) AC to select data/documents and initiate an operation on them as a user-facing AC.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation 
• Security techniques: RBAC. 
• Contracting ACs: Use of some resource-access ACs and short-running ACs. 
• Example: Web-client or Fat-client for a document management system. 
• Note: Operation are usually short-running human and short-running automated ones. 

Functional role-based portal (FRBP) AC to select a function and execute it with some data/documents as a user-facing AC. It provides two types of operations: 1) static list of functions what this role may do and 2) dynamic list of activities what this role has to do. A function is a set of activities.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Use some various ACs. 
• Example: Intranet with some workflows. 
• Note: There are two types of operations: 1An operation may be short-running human, short-running automated and long-running one. The latter is a coordination of short-running ones and other long-running ones. 

Human operation (HO) AC to interact with a human.

• Cloud-friendly: stateless or stateful, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: May use some resource-access, resource-assembly-access and utility ACs. 
• Example: Interactive form. 
• Note: The state is kept in a solution-state persistence backing service. 
• Note: Human operation AC may be short-running and long-running. 

Automated operation (AO) AC to transform some resources and/or solution-state data.

• Cloud-friendly: stateless, idempotent, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: May use some resource-access, resource-assembly-access, utility and other ACs. 
• Example: PublishDocument 
• Note: May be implemented as a robot (scripts and their processor). 
• Note: Automated operation AC may be short-running and long-running. 

Implicit coordination operation (ICO) AC to coordinate several human and automated operations AC.

• Cloud-friendly: stateful, place-dependent, individual-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Human and automated operations ACs. 
• Example: A composite service. 
• Note: Implicit coordination operation AC may be short-running and long-running. 

Explicit coordination operation (ECO) AC to coordinate several human and automated operations AC.

• Cloud-friendly: stateful, idempotent, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: Human and automated operations ACs. 
• Example: An assembly of other ACs. 
• Note: Used human and automated operations ACs may be unique for this coordination operation AC. 
• Note: It is implemented in a DSL; its DSL-processor AC has its own state persistence backing AC which acts as solution-state persistence backing AC. 
• Note: Explicit coordination operation AC is mainly long-running. 

Legacy pseudo (LP) AC to access functionality of a legacy system.

• Cloud-friendly: stateful, place-dependent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Unknown. 
• Example: ERP. 

8 Demo

The cloud-friendly application architecture is demonstrated on video below to show how various ACs implement a typical process-centric solution (this video is inspired by http://improving-bpm-systems.blogspot.ch/2014/12/bpm-for-soaesbapi-and-cloud-paas-and.html ). Obvious, presented scenario may handle several process-centric solutions and several copies of the same solution (a copy per user) simultaneously.

The scenario has the following stages:

a) The functional-role-based-portal AC offers to a user some functions to initiate (as a static list). Each of functions is an explicit-coordination-operation AC which comprises several human-operation ACs and automated-operation ACs. Human-operations ACs are to be executed by users and they are dynamically listed for each users.

b) All explicit-coordination-operation ACs are implemented as DSL-script. The DSL-manager AC provides a list of functions which are offered for users. The DSL-processor AC provides a list of activities which have to be executed by some users.

c) A user executes a function which is implemented as a DSL-script; the DSL-manager AC instantiates an individual copy of this explicit-coordination-operation AC via the DSL-processor AC. (Covered by markers 1-3.)

d) The first of two operations within this explicit-coordination-operation AC is the automated-operation AC which uses several other ACs; the explicit-coordination-operation AC instantiates an individual copy of this automated-operation AC and individual copies of two of ACs used by it (“Utility” and “Resource assembly access”). Then the automated-operation AC is executed (Covered by markers 4-6.)

e) The second of two operations within this explicit-coordination-operation AC is the human-operation AC; the explicit-coordination-operation AC instantiates an individual copy of this human-operation AC and an individual copy of the other AC used by it. (Covered by marker 7).

f) The human operation AC must be completed by a user and it informs the explicit-coordination-operation AC. (Covered by markers 8 and 9).

g) The explicit-coordination-operation AC terminates.

and its static view

9 Conclusion

The cloud-friendly application architecture follows the business domain boundaries, processes, entities, documents, roles and rules.

The cloud-friendly application architecture reduces complexity by adding a structure among ACs:

• long-running functions (actually, business processes) 
• short-running operations (actually activities or routines) 
• assembly of resources (actually, business entities or business objects) 
• resource (actually data and documents) 

The cloud-friendly application architecture reinforces the information security by dynamics security for resources and embedded security for ACs

In the cloud-friendly application architecture the majority of ACs are cloud-friendly thus solutions based on this architecture are scalable.

The cloud-friendly application architecture covers majority of cross-cutting concerns : event handling, error recovery, persistence (state management), concurrency, security, interactions, distributed transactions, logging, monitoring and testing.

Thanks,
AS