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. 



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.



Beauty of #blockchain – ugovor dorozhe deneg (contract is more important than money)

There is a Russian proverb “Ugovor dorozhe deneg” which means “Contractual agreement is more important than money”. Breaking a contract is a huge risk (reputational, financial, etc.) that is difficult to “pay back”. Also, having business with an unknown business party may be a high risk because of anti money laundering.

The key of doing business properly is a contract that is an agreement with specific terms between two or more business parties in which there is a commitment to do something in return for a valuable benefit known as consideration ( see “Digital-contract-as-a-process enables business in the digital world at http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ).

Blockchain (as the best, so far, records storage) 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 ). This is a mandatory component of digital contracts as enablers of the safe digital economy, but not sufficient one. Let us see in a few following scenarios what is missing yet for the trustful sharing of data and documents in digital business transactions within digital contracts.

Variant 1 - P2P anonymous

As simple as giving a few coins to a poor person.

Variant 2 - P2P with zero-knowledge proof

Transaction participants may verify that their counterparts are a real and respectable person. In case of problems with a transaction, its participants can be reveal by court’s request.

Variant 3 – simple B2B

Some documents (e.g. offer, payments, certificates of digital assets, etc.) must be exchanged between participants. Thus they must be managed properly within each transaction by specialised “chains” as docs-chain and assets-chain. Their lifecycles are bounded by the relevant transaction. Actually, they are temporary secured storages that may use the blockchain for storing digital hashes of their content (see also “Electronic Health Records ( #EHR ) implementation with #blockchain, #BPM, #ECM and #platform” http://improving-bpm-systems.blogspot.ch/2016/07/electronic-health-records-ehr.html ).

Of course, the best contract is a digital one ( see again “Digital-contract-as-a-process enables business in the digital world at http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html ).

Variant 4 – B2B and partners

If the PartyB has a partner (PartnerB1) to produce PartyB’s goods then some documents from the PartnerB1 may be embedded (like a Russian doll) into the documents from the PartyB. In some cases, such documents may be anonymised.

Variant 5 – Supply Chain (SC)

As firms now rely on ecosystem partners for many of the functions once done in-house, one of their major organizational challenges is how to best manage their increasingly complex operations across a network of interconnected companies. Distributed operations can lead to increased risks, unanticipated consequences and new kinds of serious frictions. ( from http://blogs.wsj.com/cio/2016/10/14/blockchains-and-the-promise-of-more-frictionless-trusted-economies/ )

To be able to run comprehensive monitoring and, potentially, some global optimisation, all the partners, all related data and all related documents must be in one secured storage of records, ideally, blockchain-based.


By looking at those variants, it is prudent to say that blockchain is only one of many serious issues to be addressed and architecture together to enables the digital economy. Fortunately, the current hype around blockchain is accelerating the better understanding of many things to be done together and, I hope, in well architected way.



Enterprise Patterns: EASE #entarch

This pattern “Enterprise Architecture Services Engagement (EASE)” is a continuation of the enterprise pattern ADAGIO ( http://improving-bpm-systems.blogspot.ch/2015/12/enterprise-patterns-adagio-entarch.html ).

Architecture Delivery services

  1. Impact analysis (Evaluate implementability of any enterprise-wide or departmental initiative)
  2. Solution analysis and design service (Contribute strongly to solution analysis, selection, integration and evolution)
  3. Solution and Platforms life cycle assurance service (Give confidence and guaranty on implemented platforms and solutions)

Architecture Governance services

  1. Architecture vision, strategy and roadmap service (Anticipate a 2-3 years enterprise-as-system and its solutions evolution)
  2. Architecture policy and regulation service (Supply rules and regulations, to ensure sustainability and global coherency)
  3. Architecture validation service (Ensure enterprise-as-a-system compliance to rules and regulations)

Innovation & Optimisation services

  1. Technology watch service (Follow existing and new technologies important for the enterprise)
  2. Technology-enable improvements service (Propose and prototype how the enterprise can benefit from the technology progress)
  3. Internal consulting service (Engage with anyone from the enterprise to apply the EA knowledge to improve operations)

Maintenance services

Architectures are the primary artefacts of EA functioning thus require explicit maintenance.
  1. Architecture repository maintenance service (Capitalise knowledge for impact analysis and coherency management)
  2. Business architecture maintenance service (Give a common understanding of the organisation and its processes)
  3. Application architecture maintenance service (Provide the means to influence design decisions and/or to use proven solutions)
  4. Data/Information/Content architecture maintenance service (Provide models and conditions to manage collected, stored and transformed data)
  5. Security layer maintenance service (Ensure cross-coherency with others layers)
  6. Infrastructure layer maintenance service (Ensure cross-coherency with others layer)



Beauty of #blockchain - doveryai, no proveryai (trust but verify) for voting at the digital age

The aim of this document is to provide a big picture of voting with the use of various modern technologies, primarily #blockchain. This technology is ideal to implement the “doveryai, no proveryai” (trust but verify) principle to achieve the trust.

1 Basic concepts

Each vote sheet has its unique ID which has its address in the Voting BlockChain (VBC) as VBC-ref1, which also encoded as QR-code-1.

2 Remote voting through the Internet

A Registered Voter (RV) receives a Voting Sheet (VS) via a secured channel or in a secured envelope.

The RV using a Server-Less App (SLA) in his/her internet browser.

  • Opens the VS
  • Fills it
  • Hits the button “FILLED”
  • Uploads the VS and some metadata into the VBC at VBC-ref1
  • Asks the VC to verify the voting results at VBC-ref1
  • Scans QR-code1 (e.g. mobile) to see the voting results at VBC-ref1 (optional)
  • Hits “OK” (and may save VBC-ref1)
  • Starts a smart-contract to release VBC-ref1 to the voting authorities AFTER the ballot period is over
  • Closes the SLA


3 Physical presence voting

Still a secret.



Some #entarch concepts derived from the #systemsapproach

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

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

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

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

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

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

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

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

Because of the socio-technological nature of enterprises and their high-level of complexity, EA historically considered as two domain architectures:
  1. Business architecture is architecture of an enterprise considered as a social system for delivering Value (as products and/or services). Main artefacts in business-centric viewpoints are: mission, vision, products, services, directives, objectives, processes, roles, etc.
  2. IT-architecture is architecture of an enterprise considered as an IT-system. Main artefacts in IT-centric viewpoints are: IT tools, processes, and methodologies and associated equipment employed to collect, transform, transport and present information. 

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

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



Beauty of #microservices: part 9 explicit coordination as a microservice

1 Introduction

This blogpost is inspired by several blogposts about microservices and it is based on the blogpost [REF1] “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html

See also the previous blogposts of “Beauty of #microservices” series

2 Things work better when they work together, on purpose (from www.tetradian.com )

To be efficient, their work must be explicitly coordinated. Certainly, this is strongly applied to all the microservices comprise an application. Of course, it is considered that an application is a several very loosely-coupled clusters of microservices to be coordinated (for example, each such a cluster is responsible for the lifecycle of a particular business entity).

Although there is an opinion that “Service is not comprised of other services due to the independence requirement” (see https://www2.opengroup.org/ogsys/catalog/W169), it is considered that some (with bigger responsibility) microservices can be assembled from other (with smaller responsivity) microservices.

There are several techniques to implement coordination.


  • nature: centralised at design-time and centralised at run-time thus may be explicit
  • specific: there is a misconception that it uses only synchronous communication (à la RPC) although it may use also asynchronous communication (à la message-passing)


  • nature: decentralised at design-time and decentralised at run-time thus implicit
  • specific: uses only asynchronous communication (à la message-passing)

Reactive streams and runnable graphs

  • nature: decentralised at design-time and centralised at run-time thus implicit
  • specific: optimised for high volume event processing


  • nature: centralised at design time and decentralised at run-time thus explicit
  • specific: each case is a completely separate instance with its own lifecycle; and the process may be another microservice

3 Implementation of business-process-based coordination

Of course, it should be a DSL to define an explicit coordination (e.g. BPEL, BPMN, etc.). Using the terminology from the section 7 of [REF1], a DSL-processor may act as a specialised container for DSL-scripts. Also, some microservices which are coordinated by a DSL-script may use some specialised containers. For example, a specialised container for human-operations, a specialised container for business rules, a few specialised containers for automated-operations.

4 Conclusion

Some advantages of the business-process-based technique:
  • Assembled microservices have no routing logic (thus they follow SRP). 
  • All the necessary microservices (assembled and dependent) can be instance-bound (help to predictive analytics).
  • All the necessary microservices (assembled and dependent) can be instantiated on demand (this minimises DEVOPS).
  • A particular instance may be stopped for the error-recovery without influencing other instances (operational isolation).
  • A few versions of the same coordination (i.e. business process) may co-exist (versioning is easy).
  • Different instances of the same process and their may be executed on different nodes (linear scaling out).
  • Easy to visualise for the business people.