Better architecting with - standard viewpoints and model-types

1 Smart Cities Reference Architecture Methodology

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

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

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

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

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

2 Example of tailoring

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

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

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

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

For Reference solution architecture, consider the following:

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

3 SCRAM viewpoints and model-kinds

3.1 VALUE viewpoint

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

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

3.2 BIG PICTURE viewpoint

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

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

3.3 SYSTEM-SOLUTION ENGINEERING viewpoint

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

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

3.4 PLATFORM ENGINEERING viewpoint

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

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

3.5 PLATFORM COMPONENT ENGINEERING viewpoint

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

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

3.6 SOLUTION ENGINEERING viewpoint

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

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

3.7 CROSSCUTTING ASPECTS ENGINEERING viewpoint

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

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

3.8 CORPORATE viewpoint

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

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

3.9 RISK MANAGEMENT viewpoint

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

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

3.10 SOFTWARE FACTORY viewpoint

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

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

3.11 STANDARDS viewpoint

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

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

4 Conclusion

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

Thanks,
AS


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

MAP for Digital Transformation – Laboratory of Architectural and Technological Governance

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

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

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

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

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

The Laboratory is considered as a medium-term endeavour.

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

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

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

We believe that such solutions are digital sociotechnical systems, which are built with primary use of

• common architectural and technological approaches;
• potentials of information and communication technologies, and
• modern IT tools.

3 Problem landscape

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

4 Vision (description of the results)

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

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

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

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

5 Stakeholders

Primary beneficiaries:

• People,
• Businesses,
• The state.

Secondary beneficiaries:

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

6 Informal description of the digital sociotechnical system

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

2 Typical usage of the digital sociotechnical system follows this pattern:

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

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

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

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

7 The Laboratory is a pilot factory of digital sociotechnical systems

The main activity of the Laboratory is

• systemic building,
• practical use,
• continuous improvement and
• dissemination

of the Digital Toolbox for Digital Transformation as the primary mean of constructing digital sociotechnical systems for specific conditions.

The Digital Toolbox for Digital Transformation allows to:

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

The Laboratory functions in the follow way:

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

Digital Transformation of existing applications and business practices, related to the national program “Smart Everything” has the following specifics:

• The solution architecture implies the mandatory use of information systems, or subsystems for new solutions, or tool platforms, or other digital media using information and communication technologies;
• The solution architecture involves reengineering business processes to take advantage of primacy of the digital representation of the objects used in the business processes;
• The solution architecture implies the standardization of many IT components and business practices, as well as the availability of various documents in public access.

The Laboratory will work on the basis of business processes and architecture governance which are already regulated, are well documented and have been tested in practice. Also, the following good business practices will be used:

• development of initiatives, implementation and support of digital projects;
• project and portfolio management;
• development of effective mechanisms for the implementation of projects and accumulated competencies, and
• support dialogue between stakeholders to promote good practices in the digital domain.

8 Strategic plan of the Laboratory

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

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

9 Top level functions of the Laboratory

Gradual creation and development of the Digital Toolbox for Digital Transformation, which consists of:

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

Adapting digital sociotechnical systems to the realities of particular clients.

Creation of specifications for a new component within the common digital platform which can be implemented by start-ups or partners.

Building local teams for supporting of digital sociotechnical systems.

Enriching digital sociotechnical systems based on the experience of their implementation.

Supporting digital sociotechnical systems for various clients.

Dissemination of Laboratory experience.

10 Structure of the Laboratory

Office of the Chief Architect

• Architectural group
• Methodological group
• Digital sociotechnical systems group
• Group of new technologies
• Architecture supervision group

Project office

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

Training group

• Consulting centre
• Media Group

Service group

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

Digital sociotechnical system:

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

The roadmap.

The staffing plan of the Laboratory.

Budget of the laboratory for the first year.

Logistics services required for the successful operation of the Laboratory.


Thanks,
AS

Better architecting with – digital models

1 The expression “all models are wrong” is wrong

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

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

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

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

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

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

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

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

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

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

The usage of digital models:

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

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

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

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

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

It is observed that the difference between the system-of-interest and its architecture description is disappearing in two directions:

• Some elements of the system-of-interest can be used instead of some architecture description models. 
•  Some architecture description models became the system elements. 

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

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

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


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

Enterprise patterns: PEAS - example CUBE platform

An example of a Corporate Unified Business Execution (CUBE) platform.

This platform is architected from the several components. For each components, a set of capabilities was defined and then best-for-fit COTS products were selected.

See all the blogposts about PEAS pattern - http://improving-bpm-systems.blogspot.ch/search/label/PEAS

See all the blogposts about platforms - http://improving-bpm-systems.blogspot.ch/search/label/%23platform

Thanks,
AS

Help SME becoming #digital

The last from 3 presentations about #digital #transformation.


Thanks,
AS

An example of architecting #digital transformation

An example for an SME (Small and Medium Enterprise).

Architecting digital transformation v1 from Alexander SAMARIN

Thanks,
AS

Incremental transformation to #digital (explicit and executable) processes

All business processes within an enterprise form a complex structure. Everyone heard about hierarchical (pyramidal) structures of business processes with an enterprise.

In one extreme, it is recommended to model all business processes within an enterprise and then start to improve them (which a good deal for consultants but didn’t help to the majority of enterprises). In other extreme, it is recommended to implement many small process-automation projects. 

This blogpost is about a balance between these two extremes.


Used link:

• http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html

Thanks,
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

Interesting combination of two recent blogposts about #governance and #digital

In the following discussion
http://bpm.com/bpm-today/in-the-forum/do-you-think-the-more-talent-you-have-the-less-process-you-need I used a combination of two recent blogposts.

From the EA viewpoint, the topic of this discussion is the following:

1. There are two essential enterprise-wide artefacts “talented staff member” and “processes”. 
2. Are there some relationships between these artefacts? It seems yes.
3. Are these relationships strong? i.e. a small change in one artefact may strong affect to another artefact? It seems yes.
4. So, how to achieve synergy between these artefacts? Let us allow talented staff members develop processes which simplify and amplify their work for the best of an enterprise.
5. Can digital amplify this synergy? Of course! – please follow http://improving-bpm-systems.blogspot.ch/2015/03/entarch-view-on-ditigal.html
6. Thus it should be some governance around these artefacts? Absolutely! – To read more please follow http://improving-bpm-systems.blogspot.ch/2015/03/enterprise-patterns-ghost.html
7. Any questions, please?

Thanks,

AS