Better architecting with – value viewpoint

This blogpost is an example view based on the value viewpoint described in the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW also it illustrates the blogpost http://egov-tm.blogspot.com/2018/07/blog-post.html

The IEC System Committee (SyC) “Electrotechnical aspects of Smart Cities” has the following scope.

To foster the development of standards in the field of electrotechnology to help with the integration, interoperability and effectiveness of city systems.

Note 1 This will be done:
  • by promoting the collaboration and systems thinking between IEC/TCs, the SyCs and other SDOs in relation to city system standards; 
  • by undertaking systems analysis to understand the needs for standards and assess new work item proposals (NWIPs) related to city systems; 
  • by developing systems standards where needed and by providing recommendations to existing SyCs, TCs/SCs and other SDOs. 

Note 2: Overall common city goals include, for example, sustainable development, efficiency, resilience, safety and support for citizens' engagement and participation. However, individual city will follow its own approach.

Note 3: “Cities” refers to any geographically located population.


Staring from this scope, the SyC Smart Cities have derived the following governance details.


Problem space specifics which are derived from the general knowledge of Smart Cities domain are the following. 

All Smart City programmes and projects pursue many common goals including sustainable development, better efficiency, resilience, safety and wider support for citizen’s engagement and participation. However, each individual city tends to follow its own approach in Smart Cities programmes and projects. It is not surprising that the numerous technology activists are very vocal on various Smart Cities forums even though city systems cannot be reduced to just big data and IoT (see https://www.forbes.com/sites/federicoguerrini/2016/09/19/engaging-citizens-or-just-managing-them-smart-city-lessons-from-china/#52b675c2dab0 ). 

It seems that around Smart Cities there are many wonderful information and communication technologies, high levels of enthusiasm from software vendors, strong support from top leadership, obvious benefits for a significant amount of the planet’s population and no shortage of funding. But, there is a huge demand for a common understanding. 

The current implementation practices of Smart Cities are rather disjointed, namely: 
  • Smart Cities programmes and projects are, primarily, local initiatives; 
  • Smart Cities programmes and projects are considered as technology projects; 
  • numerous Smart Cities interest groups are, primarily, clubs; 
  • efforts for the development of a common vision are insufficient, and 
  • typical financing patterns do not promote a common vision, namely the government is funding (to some extent) some cities, which engage technological companies, and the government is funding some technological companies, which engage cities. 
As a result, there is no agreed basis for efficient and effective cooperation and coordination between different Smart Cities programmes and projects. There is a lot of duplication of work, developed solutions are not reusable, and the same mistakes are repeated. 

A look on the number of cities with in different population categories indicates the imperative of bringing standardization in this complex paradigm of cities which are systems of systems leveraging networks of networks to bring operational efficiency, sustainability & resilience in the city infrastructure to improve its citizens’ quality of life. 

City systems are multi-disciplinary and multi-technologies thus city systems must be carefully architected allow all technologies working together. 

Mission statement which outlines what the SyC Smart Cities is doing (see scope) for whom (see cope and problem space specifics) and how is the following: 

Systemically develop together with IEC/TCs, SyCs, other SDOs a coherent and highly useful set of city system standards for implementing any city system. 

Here is clarification of what is meant by the words of this mission statement: 
  • “systemically develop” – use the IEC Systems Approach; 
  • “set of city system standards” – a comprehensive collection of 
  • “together with” – organisations which have to use this set of city system standards can easily understand it and master it; 
  • “coherent” – all standards for city systems must be compatible and developed under the same guidance; 
  • “highly useful” – organisations which are working and using city systems must be included as stakeholders; 
  • “any city system” – the set of city system standards must flexible and extensible to be useful for all types of city. 
A correspondence table T1


Stakeholders and their estimated concerns are the following. 

Citizens are primary beneficiaries however they will profit this “set of city system standards”” indirectly. It will be for smart city architecture teams to collect the citizens’ concerns and treat them systematically in accordance with the “set of city system standards””. Below is an example of citizens’ concerns (which will be referred further as “Full city system functionality”): 
  1. Adequate water supply. 
  2. Assured electricity supply. 
  3. Sanitation, including solid waste management. 
  4. Efficient urban mobility and public transport. 
  5. Affordable housing, especially for the poor. 
  6. Robust IT connectivity and digitalisation. 
  7. Good governance and citizen participation. 
  8. Sustainable environment. 
  9. Safety and security of citizens, particularly women, children and the elderly. 
  10. Affordable healthcare for everyone. 
  11. Modern education for children and adults. 
  12. Attractive for business. 

City governance organs are responsible for prioritisation of city systems improvement activities. 

City governance organs’ expected concerns are the following: 
  1. Methods to understand needs of city systems stakeholders. 
  2. Methods to estimate complexity and cost for implementation of Smart Cities programmes and projects. 
  3. Good business practices and world-class knowledge in Smart Cities to properly manage and execute Smart Cities programmes and projects. 
  4. Enabling collaboration and coordination with other Smart Cities programmes and projects to improve the quality, share cost, reduce time-to-value and manage associated risks. 

Smart City architecture teams are responsible for adoption and tailoring this “set of standards” to the unique needs of the particular city. 

Smart City architecture teams’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Quickly mastered “set of city system standards””. 
  3. Easy to use supporting tools. 
  4. Wide usage of this “set of city system standards””.
Standards development groups (IEC/TCs, SyCs and other SDOs) are responsible for formal definition of some functional elements and their interfaces which are outlined by this “set of city system standards”. Also, this “set of instruments” provides enough information on how define interfaces as APIs and how to describe functional elements. 

Standards development groups expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Vendors are responsible for implementing some functional elements and their interfaces. 

Vendors’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Investors are responsible for taking informed decisions about their investments in city systems infrastructure. At the moment cities are missing out on significant investments that should be available to them because of: a) the potential to mitigate huge potential economic losses from disasters, b) the growing popularity of sustainable investments which pushes many investment and pension funds to leave the fossil-fuel industry and to look for another investment-safe industry and c) the high risks of existing city bonds. 

This “set of city system standards” can be used to benchmark various Smart Cities related works. Also, applying this “set of instruments” brings good business practices and world-class knowledge in Smart Cities programmes and projects. 

Investors’ expected concerns are the following: 
  1. Quickly understandable “set of city system standards”. 
  2. Easy to use supporting tools. 
  3. Wide usage of this “set of city system standards”. 
Stakeholders’ requirements (except citizens’ ones) as a systematised set of all concerns of all stakeholders are the following: 
  1. Full city system functionality. 
  2. Quickly understandable “set of city system standards”. 
  3. Quickly mastered “set of city system standards”. 
  4. Easy to use supporting tools. 
  5. This “set of instruments” must help stakeholders to estimate, plan, manage and execute Smart Cities programmes and projects. 
  6. Ability to share experience, collaborate and coordinate among Smart Cities programmes and projects which use this “set of city system standards”. 
  7. Wide usage of this “set of city system standards”. 
Additional requirements are the following: 
  1. Addressing city system quality characteristics such as: interoperability, safety, security (including confidentiality, integrity and availability), privacy, resilience, simplicity, low cost of operation, short time-to-value, combining diversity and uniformity, s-referential 
  2. Covering the whole life cycle of city systems. 
  3. Widespread and transformative use of data and technology. 
Vision statement which outlines a solution space in accordance with the mission statement and satisfies the citizens’ requirements, other stakeholders’ requirements and additional requirements is the following. 

Transparently developed a set of city system instruments including a detailed Smart Cities Reference Architecture which are easily adaptable for unique needs of any city system. 

Here is clarification of what is meant by the words of this vision statement: 
  • “transparently developed” – thus everyone can understand the logic of our work, validate our work and bend or reply some parts of our work if necessary. 
  • “set of city system instruments” – a coherent collection of various types of tool such as methodological, domain-specific, informational, software-intensive, standard and informative 
  • “Smart Cities Reference Architecture” – commonly-agreed architecture which all smart cities can use as a template for solution architecture of their city systems because the key decisions taken in the Smart Cities Reference Architecture will guarantee that future city systems (built in accordance with this Smart Cities Reference Architecture) will possess the required essential characteristics, e.g. security and privacy, by design. 
  • “detailed” – it is necessary to provide enough scope and enough decomposition of Smart Cities Reference Architecture to reach a level of details which is suitable for effective standardisation of city systems – functional blocks may be implementable as black-boxes and interfaces between them must be not too complex. 
  • “easy adaptable” – although there are a lot of communalities between cities, each city always has its own unique features. Thus city systems may use many of common system elements and easily intermix them with their own system elements. 
  • “unique needs of any city system” – the set of instruments must flexible and extensible to be useful for all types of city. 
A correspondence table T2


Strategic goals which are mandatory to achieve the vision statement are the following:
  1. Commonly-agreed multidisciplinary concept system to enable all the stakeholders use the same “language”; 
  2. Commonly-agreed Smart Cities Reference Architecture Methodology (SCRAM) to make transparent and understandable how the Smart Cities Reference Architecture (SCRA) has been developed and can be used; 
  3. Commonly-agreed SCRA to serve as a tailorable template for implementing any city systems; 
  4. Guiding materials on how to tailor the SCRAM and SCRA to easily address unique needs of any city system; 
  5. Mapping of existing and potential standards to the SCRA to quickly navigate in standards pertinent for city systems; 
  6. Additional instruments to simplify adoption of the SCRAM and SCRA, and 
  7. Achieve that practically all Smart Cities programmes and projects use the SCRAM and SCRA. 

A correspondence table T3


Solution space constraints which limit potential solutions to reflect some nuances of the mission statement, the strategic goals and take into account the problem space specifics are the following:
  1. Adopting and adapting the IEC Systems Approach (see Annex A); 
  2. Although the IEC SyC Smart Cities responsibility is only about electrotechnical aspects of Smart Cities, the SCRA cover city systems as the whole. Then the extracted system elements will be sorted among various SDOs depending of the nature of those system elements. 
  3. Working together with the pertinent stakeholders, including IEC/TCs, SyCs, other SDOs, cities, and various bodies of knowledge implies that alignment of existing knowledge must be enforced; 
  4. Digital presentation of everything (applying the digital “twins” concept) because of digital transformation necessity, and 
  5. Making some digital models explicit, formal, machine-readable and machine executable thus creating some system elements which are good for description and execution (see “Towards software-defined organisations” https://www.slideshare.net/samarin/towards-softwaredefined-organisations ). 
Emergent characteristics of the solution space which address the strategic goals and the solution space constraints are the following:
  1. Friendliness: The set of instruments must explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her concerns and change his/her personal, professional and social life for the better 
  2. Systematic: The set of instruments provides a common approach for architecting city systems, so different people in similar situations find similar solutions or propose innovations. 
  3. Efficient: The set of instruments help stakeholders, programmes and projects to collaborate and coordinate their efforts via common agreements (i.e. standards) on various system elements (e.g. services, interfaces, data, etc.), common vision, common tools, common products, etc. 
  4. Flows handling: Cities are self-referential systems of flows ( see http://www.academia.edu/15717758/Conceptualising_the_Urban_System_as_a_System_of_Flows ) and, those flows are flows of entities of various types: digital, physical, living, social, political, legal, etc. If no flows then a city is dead. 
  5. Multidimensionality: Those flows co-exist and interrelate in the several dimensions: spatial, temporal, cybernetical, technological, etc. 
  6. Unpredictability of growth: Smart Cities are organically-grown and must be scalable. (What do you see in 70 million people moving to cities every year?) 
  7. Technology absorption: Because of the technology progress, many various (and unknown right now) intellectual devices (or “Things” from the IoT) and digital technologies will progressively automate, improve and drastically change various aspects of Smart Cities functioning including planning, execution, monitoring, prediction, optimisation of flows. 
  8. Synergetic: Intellectual devices, digital applications and digital services must work synergistically in several dimensions. 
  9. Holistic: Various aspects of the Smart Cities functioning (e.g. level of security, environmental impact, etc.) must be integrally (i.e. including all the available data, information and knowledge) anticipated, monitored, analysed, controlled, alerted and acted on. 
  10. Trustworthiness: High level of trustworthiness (includes security, privacy, safety, reliability, and resilience) is mandatory by design and by default. 
  11. Digital: For a man-made object, a digital twin comes first. For a nature-made object, a digital twin comes second. 
  12. Sufficient granularity: The SCRAM and SCRA must provide the level of granularity low enough for efficient implementation of city systems and high enough for standardisation purposes.

A correspondence table T5


Architectural principles of solution space which shape the proposed solutions to deliver the emergent characteristics of the solution space are the following:
  1. Explicit systems architecting and engineering is only a way to achieve essential characteristics of Smart City implementations. 
  2. Smart City as a System of Digital Interrelated Flows (SoDIF) which implies total digitalisation and intensive use of intellectual devices from the IoT. 
  3. Separation of concerns is very critical to reduce the complexity of Smart City implementations. 
  4. SoDIF is an assembly to be very adaptive and flexible. 
  5. SoDIF is constructed and operating on the basis of explicit and machine-executable digital contracts ( see “Digital-contract-as-a-process enables business in the digital world” http://improving-bpm-systems.blogspot.com/2016/07/digital-contract-as-process-enables.html ) between people, services, applications, devices and organisations. 
  6. Time and place must be integrated to handle flows properly. 
  7. Ontology is a must because the Smart Cities domain covers many, historically, disjoint subject fields. 
  8. Architecture description is based on the ISO/IEC/IEEE 42010; thus the SCRAM comprises a coherent set of viewpoints, model-types and artefact-types; the SCRA comprises a similar set of views, models and artefacts. 
  9. Alignment of views and models must be carried out systematically to preserve the conceptual integrity of the SCRA and tailored architecture. 
  10. Digital models must be used whenever is possible (see “Better architecting with – digital models” http://improving-bpm-systems.blogspot.com/2018/04/better-architecting-with-digital-model.html ). 
  11. Methods of the SCRAM are based on the following considerations: a) There is an extensible set of formal and semi-formal methods for creating some model-types from other model-types. b) Those methods are defined to facilitate their usage without high-level of creativity. c) Those methods are based on existing bodies of knowledge. 
  12. Processes of the SCRAM, if applicable, are borrowed from ISO/IEC 15288. And the SCRAM have three levels of coordination: a) between viewpoints; b) between model-types, and c) within some model-types. 
  13. Tailoring flow of the SCRA to unique needs of city systems (to be carried out by Smart Cities architecture teams) is the following: a) Copy the SCRA to the city Solution Architecture (SA). b) Select part of this SA to be tailored. c) Tailor this part of this SA by applying the SCRAM. d) Validate that all parts of this SA are aligned. e) Proceed to the item b) if necessary. 
  14. Derived reference architectures Potentially, a Smart Cities architecture team can use the SRCAM and SCRA to create their own reference architecture, for example, for a particular country. However, it is recommended to follow the SCRA and SCRAM to be able to use all benefits of the standardisation. 
  15. Maximum flexibility allows a reasonable variety of tools and techniques to be potentially selected for Smart Cities implementation. 
  16. Everything may be changed by design and by default thus imposing less limitations for Smart Cities implementation. 
  17. Governance & Management practices of the SCRAM are borrowed, if applicable, from existing bodies of knowledge, including, Quality management, CoBIT and IT4IT. An architecture group must provide the following four groups of service: a) Architecture Delivery services. b) Architecture Guidance services. c) Innovation & Optimisation services. d) Maintenance services. 

A correspondence table T6

Dynamic analysis of relationships

The graphical presentation mentioned above can be used for analysis of relationships between various artefacts. Selection of an artefact (it is in red) highlights all upstream artefacts in green and all downstream artefacts in blue.



Post-platform enterprise pattern: EEYORE

Post-platform enterprise pattern: Enterprise-Enterprise Yet Open Robotic Environment (EEYORE)

With thanks to John Morris (@JohnHMorris) and Michael Poulin (@m3poulin) for their valuable comments.

An updated version of the article is available at https://bpm.com/bpm-today/blogs/1292-post-platform-enterprise-pattern-faster-and-cheaper-inter-enterprise-ecosystem-business


In the modern business world, the vast majority of work is done by joint efforts of two or many enterprises. Inter-enterprise “working together” is a norm right now. It may have different longevity: one-off or sporadic or permanent (as B2B partnership). Can such “working together” be used systemically? For example, a modern enterprise is trying to get competitive advantage by
  1. perfecting, digitizing and innovating its core-business capabilities, and 
  2. using the best “other” enterprises for provisioning “other” capabilities needed to achieve the particular goal (even its mission); note that, those “other” capabilities for the enterprise point of view are the core-business capabilities from “other” enterprises point of view. 

In other words, an enterprise may combine its own “internal” capabilities with “external” capabilities obtained from other enterprises to achieve the particular goal.

Thus every enterprise involved is carrying out only its core-business capabilities! This is a big difference with the current situation in which some of enterprise’s capabilities (i.e. core-business) must compete in the world-wide market and some of enterprise’s capabilities (supporting) have no competitor at all.

The economist Ronald Coase - said that “Firms exist when the transaction cost of doing something within the firm, even with all its overhead, is lower than cost of doing things through a marketplace of free agents”. At present, an enterprise possesses core-business capabilities and supporting capabilities. Historically, the cost of intra-enterprise transactions is lower than the cost of inter-enterprise transactions. At the digital age the costs of inter-enterprise transactions are constantly dropping as digital technology develops (the so-called "API economy" is a good example of this). Of course, the cost contracting out versus direct management is only one of many factors such as risks, time lag, security, etc. to be taken into account.

Thus, the famous classic representation of an enterprise may be redrawn as shown in the illustration below. Note: Also logistics, marketing and sales may be considered as non core-business capabilities and be provided by “other” enterprises.

Ability of several enterprises to work together with maximum synergy and minimum overhead (thus much better than a classic enterprise) is critically important. Potential list of common activities to achieve that is not long but daunting:
  • formally define a work to be done ; 
  • find the best other enterprises for this work to be done; 
  • contract selected other enterprises; 
  • activate and configure a trusted working environment for all participating enterprises; 
  • carry out the work with secured sharing some data and information among participating enterprises and 
  • complete all contracts related to this work to be one. 
Certainly if modern digital technologies are properly architected together then they can enable this new way of working by making it more efficient and more effective that the current way of working.

Explicit, formal, machine-readable and machine-executable processes can act as a neutral and natural referee for coordinating inter-enterprise work. A potential implementation is an BPM-suite tool. A target is to position a BPM-suite tool as an independent and trusted 3rd party (a referee or a coordinator) to execute legally-bound processes for 2 or more mutually non-trusted parties. See http://improving-bpm-systems.blogspot.com/2016/07/digital-contract-as-process-enables.html

Of course, when many enterprises contribute into some common work, records management must be centralized (i.e. accepted by all the participants) and suitable for digital way of working. A digital archive with good availability and integrity can act as an escrow for some transactions and documents. Potential implementation is the blockchain technology.

An example of such a “disaggregation” of a classic enterprise – https://news.cgtn.com/news/35636a4e33637a6333566d54/share_p.html


Working together for the same goal requires sharing some things (business and technical artefacts) and, probably, some agreed means. Such a sharing is lesser for cooperation (different enterprise for different activities) and greater for collaboration (different enterprises for same activities).

Imagine that 10 enterprises have decided to work together. Shall each of them implement business processes required for this engagement? Add complex EDI infrastructure for communicating between processes from different enterprise? Keep everything within each enterprise? It looks a bit difficult. If something that must be shared is done once for everyone then everyone will gain. Thus some processes related to this engagement may be implemented once at an independent provider and linked to existing processes in each enterprise.

WHAT to share
Supporting means
Data (see the DIKW pattern)
hashes, cryptographic keys
common immutable storage
Information (see the DIKW pattern)
business objects
Interoperability, e.g. in interfaces
common immutable storage
audit trails, signed documents, agreed goals, demonstrated KPIs, inputs & outputs of inter-enterprise transaction
common immutable storage
some facts important for business
synchronization of work
common event queue
agreed business logic
regulation of work
common decision mechanism
agreed procedures, agreed SLAs, agreed protocols
common scripts in domain-specific languages
agreed testing methods
coordination of work
common coordination mechanism
KPI calculations
agreed formulas and results of calculations
common view on performance
common dashboard
agreed algorithms and results
common view on planning
common prediction mechanism
some proposals for better working
better joint performance
common set of digital models and agreed scenarios
Estimations of uncertainty which are evolving along the time
participants opinions on some factors
non-biased corporate security for all the enterprises involved
common immutable storage
Estimations of risk which are evolving along processes
participants opinions on adverse impacts
non-biased corporate security for all the enterprises involved
common immutable storage
payment mechanism
minimizing transactions with banks
own local currency

Things, which are shared in the particular case, must be a) architected together and b) digital (explicit, formal, machine-readable and machine executable) to achieve desired values of the important emergent characteristics such as:
  • the transactional cost for inter-enterprise transactions, 
  • risks, 
  • time lag, 
  • security, 
  • manageability, 
  • etc. 


New application architecture for inter-enterprise agile engagements can be built on the following pillars:
  • Immutable common digital archive (FACTS) to store all versions of all the artefacts. 
  • Microservices (ACTIONS), potentially in a serverless computing environment (because a digital archive is used as a common immutable storage). Please note that microservices are normal services (according to OASIS) except that one unit-of-functionality is one-unit-of-deployment is one-unit-of-execution. 
  • Machine-executable processes (COORDINATION). 
These pillars perfectly work together (in a robotic way without high level of creativity) – process templates define the granularity and interfaces for microservices and digital archive keeps all the artifacts (of course, they must be versioned). Process instances define validity of various facts.
See also http://improving-bpm-systems.blogspot.com/2018/06/architecting-modern-digital-systems.html

Some hurdles – processes modelling

Modelling of inter-enterprise processes is not easy because such processes are distributed (each of them may be executed in its own computing environment) and they communicated by exchanging of messages thus it is necessary to handle exceptions in communicating processes. Good modelling styles and process patterns will help.

Some hurdles – process execution

Some BPM-suite tools are already connected to the blockchain which is used as a common immutable storage.

1) Ultimus can use blockchain as a data storage - "Ultimus uses Tierion to create an audit trail for business processes and prove the integrity and timestamp of documents." See https://medium.com/tierion/ultimus-integrates-tierion-for-blockchain-digital-process-automation-f8331d76216a

2) Bonita can use blockchain – https://www.youtube.com/watch?v=lkwvko2Uy24

3) ConsenSys uses Camunda BPM-suite to use blockchain as a data storage, creating new users and executing smart-contracts https://www.youtube.com/watch?v=oww8zMzxvZA&feature=youtu.be
Some hurdles – process execution as a smart contract

One of the option to bring process to existing blockchain implementations is to implement a BPMN-like interpreter as a smart contract in the blockchain technology.

Some hurdles – blockchain mentality

People from the blockchain domain follow the “if you have a hammer then everything is a nail” negative pattern. https://blog.apla.io/report-of-the-egaas-team-556e5e4717bd

See http://ipe-lab.com/publication/223/?sphrase_id=41 as a case of the blockchain for control of third-party services. This an attempt to change a group of processes (from a few B2B partners) into a blockchain application. On the bottom picture (TO-BE), actual processes from the top picture (AS-IS) were lost. And, “Erroneous behaviour is judged by voting among all participants”, not by thorough analysis!


This pattern opens new perspective for the traditional Business Process Management which becomes also Inter-Enterprise Ecosystem Business. In other words, processes will expand outside enterprises to enable faster and cheaper “working together” for enterprises. 

And a quote from Alberto Manuel‏ (@AlbertoManuel) "Architecting expanded Value chain in the era of digital ecosystems and shared capabilities."



Architecting modern digital systems #entarch #bizarch #apparch #bpm #security #microservice

Mini-course at VFU

1 Title

Architecting modern digital systems

2 The problem to be addressed

At present, there are many IT-related methodologies, technologies, tools and schools of thoughts which overlap and contradict each other. The best practices are actually the best only in particular situations. Often decisions about software-intensive solutions are taken on the in-complete and subjective base. All of this tremendously complicates the modern digital systems thus reducing their potential effectiveness and efficiency. 

3 Objectives

The purpose of this course is to provide the basic knowledge and experience necessary to better understand how to deal with the increasing complexity of the information technologies to obtain the synergy between business needs and IT potentials. 

4 The approach

The course is based on the practical use of Enterprise Architecture (EA) which a methodology and practice for architecting solutions. EA provides an overarching guideline for understanding a “problem space” and take necessary decision about the “solution space” to deliver which addresses the problem. 

5 Learning outcomes

The trainees will
  • learn a systematic approach for architecting digital solutions; 
  • learn about some modern information technologies; 
  • learn how those technologies are working together for a systematic architecting, design, implementation, operations and evolution of digital systems; 
  • carry out a practical architecting exercise. 

6 Target audience

Bachelor and master level students specialising in IT. 

7 Requested knowledge

General knowledge of IS/IT. General programming experience. 

8 Layout of the teaching

Teaching will be given as six 1.5-hour lectures. The first 4 lectures will be about presenting some methodologies and technologies. Then the students will be asked to architect a solution based on a practical situation. The last session will be about presenting the student’s solution and wrapping up this mini-course. 


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
1. Territory
2. Menu (probably)
3. Drawings (mandatory)
4. Program (inevitable)
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



Many viewpoints on the concept capability

This blogpost is based on the several recent LI discussions about the concept “capability” (see their URLs at the end of this blogpost).

Those endless discussions only confirm a well-known systemic observation – a complex concept is better understand via its relationships to other concepts. Thus, to define the concept “capability”, it is necessary to define together the several related concepts, such as “function”, “service” and “process”. (Other concepts could be added on demand.)

Another complexity is, again, a well-known systemic observation – different people see the same thing differently. It is called “architecture viewpoint” (like an 3D object may have 3 projections). The many problem with architecture viewpoints is that they must be aligned.

The aim of this article to outline a main (or master) viewpoint which allows to align all other viewpoints. (With special thanks to Michael Poulin for his valuable comments for this article.)

1 Different viewpoints on capability

So far, the several viewpoints on the concept “capability” have been detected.

Demand viewpoint – to achieve our mission and vision we need a system with a particular performance of doing something. Demand-capability is a relative measure of ability of a system (or its element) doing something at a particular level of performance.

This viewpoint is about WHAT and HOW-WELL without any information about WHO, HOW, WHERE, WITH-WHAT-RESOURCES, etc.

Supply viewpoint – we have a system with a particular performance because we made it and deployed some resources. Supply-capability is a proven performance of a system (or its element) doing something.

This viewpoint is about WHAT, HOW-WELL, WHO, HOW, WHERE, etc.

Reference viewpoint – all the systems with a similar purpose (or mission) should be able to do this. Reference-capability is an ability of a system (or its element) doing something.

This viewpoint is about WHAT only. Typically, the reference viewpoint relates to a particular type of business, e.g. banking, rent-a-car, telecom, etc.

2 Let us classify some of the existing approaches

The list below is copied from https://www.dragon1.com/terms/capability-definition to be annotated.

ArchiMate 3.1: A capability represents an ability that an active structure element, such as an organization, person, or system, possesses. AS: It seems that it is the supply viewpoint.

TOGAF 9.1: A capability is an ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing. AS: It seems that it is the supply viewpoint.

BIZBOK 4.1: A capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. AS: It seems that it is the reference viewpoint.

Bas van Gils (Strategy Alliance): CAPABILITY = CAPacity x ABILITY. - ABILITY refers to skills and proficiency in a certain area. It should be noted that ability is a relative term: one actor (human, machine, computer) may have higher levels of proficiency than others. The level of ability can be increased due to (formal) training, and practice. - CAPacity refers to the degree to which actors (human, machine, computer) are available to use their skills to achieve a goal. Capacity can be influenced by freeing up / adding resources to the available pool. More information on the Strategy Alliance Website. AS: It seems that it is the supply viewpoint.

Tom Graves (http://weblog.tetradian.com/2013/12/14/definitions-on-capability/ ) RE “Performance is an attribute of a service – not of a capability as such”. AS: It seems that it is the supply viewpoint.

Mark Paauwe (https://www.dragon1.com/terms/capability-definition ) A capability is a set of tasks that a system is potentially able to perform at a certain performance level, but only with the use of required resources. AS: It seems that it is the supply viewpoint.

Michael Poulin (https://organicbusinessdesign.com/agile-business-capability-part-1/ ) - A business capability is an ability of an entity - person or organisation - to create or deliver certain Real world Effect (outcome) in particular business execution context. If the context changes, yesterdays capability can vanish. A fact that you did something yesterday does not mean (itself) that you can do this tomorrow. A capability exists only if there are all needed resources available for the capability realization. No resources - no capabilities; competencies/knowledge/skills are not enough for having the capability. You lose capability if you outsource it. AS: It seems that it is the supply viewpoint.

Richard Hillier - A business capability is the ability to perform a business activity which is recognized as being required for success and which needs to be specifically managed. AS: It seems that it is the supply viewpoint.

So far, there is no demand viewpoint. Why?

3 Where is the demand viewpoint? 

Any demand viewpoint it is dynamic and organisation specific. In any business, “bigger” (with emergent characteristics) capabilities are assembled from “smaller” (available or not yet) capabilities. Because such emergent characteristics are exhibited as the result of interactions of “smaller” capabilities between themselves and with other capabilities then some coordination of such interactions is mandatory.

Note: It is not a bottom-up approach, but a recursive combination of analysis (finding what "smaller" capabilities are necessary) and synthesis (proving that "smaller" capabilities and some coordination between them achieve "bigger" capability). 

Imagine, an enterprise or solutions architect has to implement a particular demand-capability within an organisation (which is, obviously, a system). There are several choices:
  1. Implement this demand-capability within the organisation as a coordination of some other capabilities.
  2. Outsource this demand-capability via Business-to-Business (B2B) partnership and access it in accordance with a contract between two organisations.
  3. Acquire this demand-capability as commodity maybe via a tender.
  4. Ignore this demand-capability by providing some good reasons.

With the option 1 the enterprise architect must chose a set of “smaller” capabilities and a way to coordinate them. The reference viewpoint, if any, may help to find out those “smaller” capabilities. (Of course, some “smaller” capabilities may be not available yet and have to be implemented recursively).

Also, saying that “to implement this capability we will use those two capabilities” is not enough because the way to coordinate those capabilities will affect the performance of this capability. Sure that various estimations of the performance of this future supply-capability may be provided.

Any demand-capability or reference-capability which is implemented by (or within) the organisation is called function. Creating a function implies that several organisational, technical, contractual, resourcing, staffing and other changes must be carried out within the organisation. Function immediately has some performance approximation as supply-capability, i.e. its expected performance is stated. Ideally, the performance of such supply-capability exceeds the requested performance of the related demand-capability. (Sometimes, a gap between them can be huge – remember that we never drive our cars at their maximum speed.)

An illustration of relationships between various concepts is shown below. The left half of this illustration is the reference map of an organisation and the right half of this illustration is the functional map of this organisation. The functional map is smaller then the reference map, because some capabilities were implemented as commodities or via B2B partnership. A formal procedure for moving from “left” to “right” can be produced on demand.

Because functions can’t provide a good approximation of its expected performance, organisations uses services – service is an arrangement to access to one or more functions on a contractual basis. (Note: such an access may be within the same organisation as well as between different organisations). Because any service must take into consideration its contract (including SLA) and its expected usage, its performance may be anticipated better than for functions. Creating services also implies some organisational, technical, contractual, resourcing, staffing and other changes.

Nevertheless, neither functions nor services specify explicitly the coordination between “smaller” capabilities thus their estimations of the expected performance is still a guess. So far, only Business Process Management (BPM) allow the organisation to build, run and improve “bigger” capabilities in predictive, transparent and provable manner because process is an explicit, formal, machine-readable and machine-executable coordination. Obviously, one can evaluate (with a high level of confidence) the performance of a “big” supply-capability by knowing the process, its usage and performance of “small” supply-capabilities.

A few notes: Considering that there are many coordination techniques then there are no principal differences between BPM and Adaptive Case Management – see http://improving-bpm-systems.blogspot.bg/2014/03/coordination-techniques-in-bpm.html . BPM is actually a trio: discipline to manage business via processes, software to manage processes themselves (BPM-suite tools) and practice & architecture. Also, orchestration and choreography are variants of coordination.

Some assets and skills are required to operate services and processes. Obviously, assets and skills may be outsourced (or insourced).

Organisational structure depends on the structure of functions (or functional map). (Think about the separation of responsibilities). http://improving-bpm-systems.blogspot.bg/2011/10/enterprise-pattern-structuring-it.html http://improving-bpm-systems.blogspot.bg/2012/01/enterprise-pattern-sito-extended.html

4 Big picture

The overall logic is the following:

  1. Capability The organisation has to be able to do something (because of the mission) with a particular level of performance (because of the vision).
  2. Function Some of needed (demand-)capabilities must be implemented within the organisation. For example, because it is a core-business capability. By definition, a function is already a supply-capability (as a system element of an organisation as a system) and some assets, skills and coordination have to be provided. 
  3. Service Although function is already a supply-capability, the evaluation of its performance is rather approximative. Service allows improving the evaluation of its expected performance by specifying its contractual conditions.
  4. Process For better estimation of the expected performance, processes (actually, BPM) offer an explicit coordination of ”smaller” capabilities.

5    Conclusion

To avoid confusion when talking about capabilities, please, be explicit about what viewpoint(s) you are using. Also, please, define related terminology up-front.


Related LI discussion

Other discussions: