Typology of platforms

Platform concept

platform, noun
pre-existing piece of software to provide comprehensive functionality to other software pieces (i.e. applications) during some phases of their lifecycle

Note: Good platforms make simple things simple and complex things possible.
Note: "Piece" is a unit of deployment.
Note: All platforms are digital.
Note: Types of platforms mentioned below may be mixed in a particular software product.

Well-designed platforms follow the enterprise pattern Platform-Enabled Agile Solutions (PEAS) - see http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html

See also "Achieving synergy between diversity and uniformity via platforms" http://improving-bpm-systems.blogspot.ch/2016/01/achieving-synergy-between-diversity-and.html and "Platform-based #digital transformation (example egov)" http://improving-bpm-systems.blogspot.ch/2016/01/platform-based-digital-transformation.html

Development platforms 

Origin: IDE
Typical characteristics: developed applications operate outside the platform
Typical provisioning: on-premises
Typical creator: FOSS or COTS

Technological platforms

Origin: runtime libraries
Typical characteristics: technology encapsulation for applications
Typical provisioning: on-premises
Typical creator: FOSS or COTS
Examples: ESB products, mobility, API gateways, etc.

Operational platforms

Origin: OS
Typical characteristics: platforms improve non-functional characteristics of applications
Typical provisioning: on-premises
Typical creator: FOSS or COTS or home-made
Examples: automation toolset for devops, monitoring, performance measurements, containers, virtualisation, application servers

Application platforms (programmable monoliths)

Origin: IDE
Typical characteristics: applications operates within such platforms only (beware of the vendor lock-in)
Typical provisioning: SaaS or PaaS, APaaS or on-premises
Typical creator: FOSS or COTS
Examples: BPM-suites, etc.

Functional platforms (configurable monoliths)

Origin: corporate functions automation
Typical characteristics: generic solutions have to be configured for needs of a particular business
Typical provisioning: SaaS or PaaS or on-premises or hybrid
Typical creator: FOSS or COTS
Examples: ERP, CRM, ECM
Note: Also called "Vendor platforms"

Intermediation platforms

Origin: portals
Typical characteristics: middleman between service consumers and service providers
Typical provisioning: IaaS or on-premises
Typical creator: home-made
Examples: Uber, Airbnb, Facebook, Alibaba, Paypal
Note: The owner of an intermediation platform helps to match demand and supply without any ownership over supplied resources (Uber does not owe cars, Airbnb does not owe hotels, Facebook does not generate any content, Alibaba does not produce consumer goods).
Note: Also called "Digital platform" or marketplace.

Business execution platforms

Origin: corporate functions automation
Typical characteristics: a coherent set of functionality sufficient to run business in a particular business domain as a set of solutions which are assembled from microservices.
Typical provisioning: hybrid or on-premises
Typical creator: FOSS or COTS
Examples: Salesforce
Note: Business execution platforms may be collected from previously mentioned platforms.

Corporate Unified Business Execution (CUBE) platforms

Origin: digital transformation, application portfolio rationalisation, application portfolio modernisation,  legacy ERP transformation, etc.
Typical characteristics: whole-enterprise-specific business execution platform
Typical provisioning: hybrid
Typical creator: home-made
Example: http://improving-bpm-systems.blogspot.ch/2015/10/enterprise-patterns-peas-example-cube.html
Note: Corporate unified business execution platforms are collected from previously mentioned platforms.
Note: Also called "Digital business platforms".

Potential industry-sector synergy

Any corporate within the same industry-sector do, in principal, the same things but in slightly different way. If a corporate unified business execution platform enables synergy between diversity and uniformity then the same platform may serve the whole industry-sector (public services, healthcare, smart-city, etc.).



Enterprise patterns: ADAGIO #entarch

This pattern summarises the essential capabilities to be delivered by enterprise architecture as a practice:
  • Architecture Design (AD)
  • Architecture Governance (AG)
  • Innovatives and Optimisation (IO)

Architecture Design or Delivery (AD) – do right things

Architecture Design defines (at the scale of an enterprise) how solutions to be designed, delivered, operated, monitored, evolved and decommissioned (covering of their full life-cycle). EA has to deliver an overall solution for the whole enterprise. It is possible only as a set of smaller ("normal") solutions. Thus EA must control/influence them.

See related blogposts:

Architecture Governance (AG) – do things right

Architecture Governance controls how all artefacts are managed through their life-cycles, individually and in various assembles.

See related blogposts:

Innovations and Optimisation (IO) – at the right time

Because it is not possible to anticipate everything, EA must be adjustable to quickly changing situation without losing the focus. 

A few related thoughts

Considering that, IT is only the enterprise-wide function which very critical right now (thanks for #digital) then EA must resolve firstly all the problems of IT.

Architecture Design (AD) is actually responsible for a design of transformation.

Innovative Optimisation (IO) primarily is about validating and executing the strategy.

At the same time, EA has no direct responsibility over IT and business. EA a system-thinking applied management discipline for coordinating people, processes, projects and products – see http://improving-bpm-systems.blogspot.ch/2014/12/yet-another-definition-of-enterprise.html


In ballet, adagio refers to slow movement, typically performed by a group of dancers with the greatest amount of grace and fluidity than other movements of dance.

Adagio in music (from Wikipedia):

True and heartfelt transfer Adagio is the touchstone of the art performance of each musician and singer. However, the Adagio is a clear indicator of the degree of true talent, a sign of the composer's talent, because the adagio (which are total internal consistency and richness of musical thought) exposes the talent and skill of the composer.

In acrobatics adagio is the performance of partner acrobalance poses and associated movements that involve stationary balances.



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

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


Example of dependencies between stakeholders, their interest and models

The illustration below is an example of dependencies between stakeholders, their interest/concerns and models. This example was used in a discussion about smart-cities.

As with the complexities between the components within the smart city system-of-systems, so are the interrelations between stakeholders of a city intricate and highly complex. Mapping out the dependencies between stakeholders allows one to better understand the impact and effects of decisions and changes from one stakeholder to another.

At present, is shows only the mapping between "interests" and "
Smart-city implementation reference model" http://www.slideshare.net/samarin/smartcity-implementation-reference-model

All the stakeholders are classified below.



Concepts crisis in IT and sister domains

1   Introduction

One of the fundamental tendencies in the modern IT and sister domains is the intersection of many, previously, independent methodologies and disciplines. If somebody wants to address holistically (i.e. enterprise-wide) the operations excellence then it is mandatory to deal with business architecture, operation models, BPM, SixSigma, Lean, EPM, ERM, CoBIT, ITSM, SOA, agile, and many others.

Historically, all these methodologies and disciplines were developed in isolation and, some of them are presented differently by various schools and “bodies of knowledge”. Thus, any transversal communication is hampered by the absence of common agreements for the many of used concepts.

In accordance with ISO 1087-1, concept is unit of knowledge created by a unique combination of characteristics. Concepts are mental representations or entities that exist in the brain. Concepts are not necessarily bound to particular languages. Concepts are, however, influenced by the social or technical background which often leads to different categorizations. Concepts in order to be communicated, stored, etc. indeed require a linguistic form.

To understand how concepts related to each other it is necessary to use descriptive (linguistic) statements which serve to differentiate concepts. Ideally, IT and sister domains need a single concept system which is a set of concepts structured according to the relations among them. Then various designations (graphical and verbal) can be defined to represent concepts.

Following international terminological standards, the “intensional definition” approach is used below. It describes the intension of a concept (set of characteristics which makes up the concept) by stating the superordinate or broader concept and the delimiting (indispensable for distinguishing) characteristics. (See the last chapter for some basics of the terminological science).

The following is an example of an intensional definition for the concept 'incandescent lamp': incandescent lamp is electric lamp in which a filament is heated by an electric current in such a way that it emits light.

The following relationships are used for constructing concept systems (see ISO 1087):
  • generic relation or genus-species relation
  • partitive relation or part-whole relation
  • associative relation or pragmatic relation
  • sequential relation
  • casual relation

2 Additional type of relation

In IT and sister domains, there are many complex concepts. Because of the complexity, different people consider the same concept from different perspectives and for different concerns. Without providing an explicit context (perspectives and concerns), it is not possible to understand adequately different people.

This is a similar situation when the architecture of a system is discussed because different people see this system differently. To avoid potential confusions, the architecture description is built on viewpoints or ways of looking at systems ("a viewpoint frames a concern" – see http://www.iso-architecture.org/ieee-1471/ads/ ). Also, viewpoints are designed for the purpose of communicating and focusing on certain aspects of an architecture.

Each architecture viewpoint is specified by:
  • the concerns framed by this viewpoint;
  • the stakeholders interested in this viewpoint;
  • the model kinds used in this viewpoint;
For more detail about viewpoints, please see http://web.mit.edu/rihh/www/writings/hilliard-TrustVP-r1.pdf and http://web.mit.edu/richh/www/writings/hilliard-TrustVP.pdf

The aim of this article is to demonstrate that some competing definitions for the same concept are just different viewpoints. Usually, one of those viewpoints is the “meta” (the most comprehensive) one and all the other viewpoints are “periphery” (or simplified versions) ones. Using this additional type of relation between concepts (called ‘projection’) will help to build a commonly agreed concept system for the IT and sister domains.

Below there are several examples of using ‘projection’ relation.

3 Concept ‘system’

3.1 Meta viewpoint

A system is a set of interacting or interdependent components (parts or elements) forming a complex/intricate functional whole. [ adopted from https://en.wikipedia.org/wiki/System ]

This viewpoint emphasis “working together” of parts which makes "The whole is more than the sum of its parts".

3.2 Nomenclature viewpoint

System is a collection of interrelated elements. [ see https://www.linkedin.com/grp/post/36781-6057819803043852292 ]

This viewpoint considers primarily individual elements (components or parts) – like seeing the trees not the forest. This viewpoint mentions the structural perspective, i.e. “A system has structure, it contains parts (or components) that are directly or indirectly related to each other”. Moreover, to some extent, this viewpoint ignores the fact that “a system has behaviour and it exhibits processes that fulfil its function or purpose”.

3.3 Artefact-centric viewpoints

Considering that, parts of systems are different artefacts (or types) such as processes, services, etc. then a particular viewpoint may concentrate only on a particular artefact. Examples of these viewpoints are:

4 Concept ‘capability’

4.1 Meta viewpoint

Capability is a measure of the ability of a component (or a system) to achieve a particular result.

This viewpoint emphasis the performance (planned, demonstrated and potential) of a component to perform its function (or ability to do something). Compare: 1) Can you play football? Yes, of course! 2) Can you play football at the level of Champions League? Of course not!

Obviously, the top management of an enterprise perfectly knows what their enterprise can do and their main concern is how well their enterprise doing that. Another concern is the following question which was asked by the President of a development bank: “The bank is doubling its funds, shall we double our IT department as well?”

See also http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.htmlhttp://improving-bpm-systems.blogspot.ch/2013/03/bizarch-artefacts-definition-again.html and http://improving-bpm-systems.blogspot.ch/2014/08/concept-capability-for-bpm-entarch-and.html

4.2 Functional viewpoint

Capability is the ability to do something [ see http://weblog.tetradian.com/2015/09/27/why-service-function-and-capability/ ]

This viewpoint is not aware about the performance aspect of capability (maybe because it is usually not shared publicly).

4.3 Other viewpoints

  • availability of resources to achieve a particular result
  • availability of skills to achieve a particular result

5 Concept ‘business process’

5.1 Meta viewpoint

Business process is an explicitly defined coordination for guiding the purposeful enactment of business activity flows.

In other words, a business process is an agreed plan which may include some variants and may be adapted during its execution.

This viewpoint emphasis an intentional, systematic and shared design of future work which is the primary concern of any business process owner. Thus any business process owner must be capable to logically explain WHY his/her business processes as they are. (An explanation "we always do like that" is not acceptable.)

See also http://improving-bpm-systems.blogspot.ch/2014/01/definition-of-bpm-and-related-terms.html

5.2 Observer viewpoint

Business process is a collection of related, structured activities (or tasks) that produce a specific service or product (serve a particular goal) for a particular customer or customers. [ see https://en.wikipedia.org/wiki/Business_process ]

This viewpoint is typical for an external observer for whom the design of future work and "WHY of processes" are not fully known.

6 Concept ‘architecture’

6.1 Meta viewpoint

Architecture is a fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system. [ adapted from ISO/IEC/IEEE 42010 ]

6.2 Other viewpoints

  • architecture as a blueprint
  • architecture as a description

See also https://www.linkedin.com/grp/post/36781-6057819803043852292

6.3 Related research

Technical Report №1 String 2015 “Architecture, architecting” http://fess.workem.org/images/papers/Architecture-Archtecting-senses-draft.pdf

7 Concept ‘enterprise architecture’

7.1 A possible approach

A possible approach is used in the article Eight Ways We Frame Our Concepts of Architecture" published by Leonard Fehskens ( see http://c.ymcdn.com/sites/www.globalaea.org/resource/resmgr/JEA/jea_sep2015_final-rev.pdf ). A small fragment from this article is below:

When applied to enterprise architecture, these frames have the following characteristics.

  • Concept – the Platonic Ideal (as the “pure” abstraction) of enterprise architecture.
  • Class – the class of all possible actual enterprise architectures.
  • Instance – the architecture of a specific enterprise or some specific part of an enterprise.
  • Representation – the representation or description of an instance of an enterprise architecture.
  • Discipline – the set of skills and knowledge required for the competent practice of enterprise architecture.
  • Practice – the use of these skills and knowledge in the actual performance of the activities of enterprise architecture.
  • Representing – the act of representing an instance of an enterprise architecture.
  • Profession – a collegial ecosystem that maintains and enforces a set of constraints (usually implying mastery of a specific set of skills and knowledge to some minimal level of competence, and conformance to certain standards of behaviour) on the practice of the discipline.

7.2 Various viewpoints

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. (See http://www.gartner.com/it-glossary/enterprise-architecture-ea/ )

Enterprise architecture (EA) is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. (See https://en.wikipedia.org/wiki/Enterprise_architecture )

Design or 'blueprint' of a business that depicts the components of a firm employed in its operations, interrelationships of those components, information flows, and how each component supports the objectives or the strategy of the enterprise. (See http://www.businessdictionary.com/definition/enterprise-architecture.html )

7.3 Coordination viewpoint

See “Yet another definition of enterprise architecture #entarch and metrics for enterprise architects” http://improving-bpm-systems.blogspot.ch/2014/12/yet-another-definition-of-enterprise.html

8 Terminology basics

We have to maintain a clear distinction between terms referring to objects, concepts and terms. A term, and more generally a linguistic expression, referring to:

  • itself, i.e. a term, is delimited by double quotes;
  • a concept, i.e. its meaning, is delimited by single quotes;
  • an object, i.e. its referent, is not delimited.

Hence, (the concept) ‘measurement’ is expressed in English by (the term) “measurement” and is about (the object) measurement.

unit of knowledge created by a unique combination of characteristics

NOTE Concepts are not necessarily bound to particular languages. They are, however, influenced by the social or cultural background which often leads to different categorizations.

NOTE Concepts as mental representations, where concepts are entities that exist in the brain.

NOTE Concepts in order to be communicated, stored, etc. indeed require a linguistic form.

anything perceivable or conceivable

NOTE Objects may be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. conversion ratio, a project plan) or imagined (e.g. a unicorn).

subject field
field of special knowledge

individual concept
concept which corresponds to only one object

NOTE 1 Examples of individual concepts are 'Saturn', 'the Eiffel Tower'.

general concept
concept which corresponds to two or more objects which form a group by reason of common properties

NOTE Examples of general concepts are 'planet', 'tower'.

abstraction of a property of an object or of a set of objects

NOTE Characteristics are used for describing concepts.

type of characteristics
category of characteristics which serves as the criterion of subdivision when establishing concept systems

NOTE The type of characteristics colour embraces characteristics being red, blue, green, etc. The type of characteristics material embraces characteristics made of wood, metal, etc.

essential characteristic
characteristic which is indispensable to understanding a concept

delimiting characteristic
essential characteristic used for distinguishing a concept from related concepts

NOTE The delimiting characteristic support for the back may be used for distinguishing the concepts

set of characteristics which makes up the concept

totality of objects to which a concept corresponds

concept system
system of concepts
set of concepts structured according to the relations among them

representation of a concept by a descriptive statement which serves to differentiate it from related concepts

intensional definition
definition which describes the intension of a concept by stating the superordinate concept and the delimiting characteristics

representation of a concept (3.2.1) by a sign which denotes it

NOTE In terminology work three types of designations are distinguished: symbols, appellations and terms.
verbal designation of a general concept in a specific subject field

NOTE A term may contain symbols and can have variants, e.g. different forms of spelling.



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



Mistery of end-to-end processes

Inspired by http://bpm.com/bpm-today/in-the-forum/should-processes-be-end-to-end-1

If you want to know how an input into your enterprise (which is a system of processes -- http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ) influences some outputs from it then you must know "End-to-End (E2E) processes". But in the majority of situations, it is not possible to present an E2E process as an BPMN diagramme because there are various coordination techniques (see http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html ) may be used to "construct" E2E processes from classic (presentable as BPMN diagramme) processes.

This is a mystery of E2E processes - they do exist but in many situations they can't be made explicit and machine-executable with the majority of modern BPM-suite tools.



Laws of #BPM (Business Process Management)

Note: General thanks to Peter Schooff ( https://www.linkedin.com/in/pschooff ) and bpm.com

1st law of BPM

Each BPM vendor, each BPM consultant, each BPM “body-of-knowledge” and each BPM client (i.e. enterprise) understands BPM differently.

Note: Thanks to Emiel Kelly ( https://nl.linkedin.com/pub/emiel-kelly/11/464/824 )

Corollary 1 All BPM quotes must be taken critically.

2nd law of BPM

BPM covers three different concepts:
  1. a management discipline (a discipline for the better management of the enterprise functioning in support of the enterprise goals - managing business by processes); 
  2. tools (also known as BPM-suite software products to manage business processes per se), and 
  3. practices (usage of BPM to solve unique problems of a particular enterprise). 
Corollary 1 The meaning of BPM must explicitly defined.

3rd law of BPM

As any enterprise-wide undertaking, the usage of BPM within an enterprise must be systemically architected: designed, governed and optimised.

Corollary 1 Architecting BPM for an enterprise must comprise BPM as a discipline, BPM tools and BPM practices.

4th law of BPM

At present BPM is a vendor-driven market.

Corollary 1 A vendor-independent understanding of BPM is mandatory for successful using BPM in an enterprise.

Corollary 2 A vendor-independent understanding of BPM is mandatory for successful acquiring an BPM-suite software product.

Corollary 3 Current BPM standards are optimised to vendors not customers thus to be reviewed.

5th law of BPM

The vast majority of unique business processes can be constructed from a limited set of business-centric patterns.

Corollary 1 BPM achieves synergy between diversity and uniformity.

6th law of BPM

BPM employs the power of coordination.

Corollary 1 There are many coordination techniques which are used by BPM, e.g. flow-chart, intrinsic knowledge, social knowledge, business rules, etc.

Corollary 2 BPM is mandatory in a digital enterprise.

7th law of BPM

Done correctly BPM is 50 % of Enterprise Architecture (EA).

Corollary 1 Consider BPM and EA concerns (business, application, information, technology and security) together.

See http://improving-bpm-systems.blogspot.ch/2014/05/ideas-for-bpmshift-delenda-est-vendor_11.html

Corollary 2 Some enterprise architects do not understand BPM. (They consider that business processes exist only in EA repositories.)

8th law of BPM

BPM challenges arise because its theory is both unfinished and unacknowledged.

Corollary 1 BPM-related theory is a combination of math, ontology and systems theory. And on top of that then, engineering.

Thanks to John Morris ( https://ca.linkedin.com/in/johnhwmorris )

9th law of BPM

BPM establishes and maintains the explicit, machine-executable and measurable (qualitative and quantitative) linkage between various enterprise artefacts.

Corollary 1 BPM is an enabler for sound risk management at the enterprise scale.

Thanks to Venkatesh Thiruvarul  ( https://www.linkedin.com/in/venkyt ) and
Hadi El-Khoury ( https://fr.linkedin.com/in/helkhoury )

10th law of BPM

BPM delivers digital business solutions as explicit and machine-executable assemblies of artefacts.

Corollary 1 BPM delivers digital business solutions in an agile and incremental way.

Corollary 2 BPM delivers digital business solutions considerably faster than the traditional software development.

Thanks to Sergei Penkov ( https://au.linkedin.com/in/sergeipenkov )

11th law of BPM

Because the value is created in interactions between a customer's process and enterprise processes, BPM makes explicit the creation of value.

Thanks to Kai Laamanen  ( https://fi.linkedin.com/pub/kai-laamanen/6/384/913 )

12th law of BPM

BPM induces significant technological, organisational and work-related-cultural changes.

Corollary 1 Management of technological, organisational and cultural changes is a must in process-centric transformation.

13th law of BPM

BPM will die a new death every year in the press and among pundits... but not in the market place. 

Thanks to Scott Francis ( https://www.linkedin.com/in/sfrancisatx )

14th law of BPM

BPM community knows very well what universally does not work; at the same time the knowledge of what universally does work is hidden or non-existent.

Corollary 1 BPM community is a group of alchemists.

16th law of BPM

Successful BPM implementation is an enterprise-wide digital transformation.

Corollary 1 It is mandatory to keep the big picture and implement it in several small projects. ( see  http://improving-bpm-systems.blogspot.it/2015/06/incremental-transformation-to-digital.html )

Corollary 2 All the enterprise-wide functions must be aligned to optimised the use of BPM.

Corollary 3, ICT, as the most common enterprise-wide function, must have all its functionality “in tune” to optimise the delivery of process-centric solutions. Namely: Governance, Security, Software development practices, Operations, Monitoring, Support, Maintenance & Small enhancement, User Experience, Data Architecture, Use of the selected BPM-suite tool, Overall continual improvement.

Corollary 4 An enterprise needs a small group of agreed minds to architect and guide others to execute this digital transformation.

17th law of BPM

Thou shalt consider business process model as a description of WHY this process is as it is depicted in its diagrams.

Note: Such a description is:
  • explicit
  • computer-executable (i.e. formalised)
  • multi-viewpoints (process diagrams are some of those viewpoints)
  • multi-diagrams
  • understandable by all the stakeholders of the process
Corollary 1 A process template is "cognitive assist".

Thanks to http://bpm.com/bpm-today/in-the-forum/how-do-you-make-sure-bpm-doesn-t-get-overwhelmed-by-too-much-data

18th law of BPM

BPM is the revolutionary technology that no one likes to admit is revolutionary.

Thanks to John Morris ( https://ca.linkedin.com/in/johnhwmorris )

19th law of BPM

The following BPM-specific aspects must be present in any successful use of BPM:
  1. BPM good practices (they are software-independent and enterprise-independent)
  2. enterprise BPM architecture (how a particular enterprise is using processes to manage better its work)
  3. target enterprise application and information architectures to integrate a BPM-suite tool into the existing enterprise computing environment
  4. BPM-suite tool suitable for the job to be done at a particular enterprise
  5. process-centric project management (which is agile-like because each process, being a composite artefact, defines all its component and their implementation follows agile practices)
  6. organisational and/or operational changes for optimising working practices for the best use of BPM potentials
  7. availability of leadership resource(s) to achieve synergy between all other items

20th law of BPM

BPM people must become friends with business architects, solution architects and enterprise architects.

Thanks to www.bpmtips.com

21st law of BPM

The BPM industry is ready for a next 'round' of standardization.

22nd law of BPM

Level of automation of your processes = c1 * "Level of modelling"**2 + c2 * "Level of coding" + c3

Corollary 1 Formalise your work before even thinking about automating it.

Thanks to bpm.com discussions.

23rd law of BPM

Do not mix up coordination with subordination.

Note 1: If the task B is planned to be executed after the task A then it does not mean that the performer of the task B is working for the performer of the task A.

Note 2: If the task B is planned to be executed after the task A and the performer of the task B may reject the work done by the performer of the task A then it does not mean that the performer of the task B must have the higher corporate power than the performer of the task A.

Example: A doctor works after a nurse but not for a nurse.



#BPM helps the medical emergency service to save lives faster

With the use of BPM, the medical emergency service in Geneva reduced the service time (from a call to an emergency team on place) in 2 times!
Their BPM is at level "Explicit" - see slide 7 in http://improving-bpm-systems.blogspot.ch/2015/06/help-sme-becoming-digital.html



My chapter about actionable patterns in "Business Architecture Management" book

My chapter "Liberate Your Business Potential via Actionable Patterns" in "Business Architecture Management" book. http://www.springer.com/us/book/9783319145709



Help SME becoming #digital

The last from 3 presentations about #digital #transformation.



An example of architecting #digital transformation

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



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:


Beauty of #microservices: part 2 architecting for change

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 which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

See the part 1 “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html for the definition of the following terms: business process, orchestration, microservice or Autonomous Component (AC), and microservice architecture.

2 Review of two recent posts

Several articles about changeability of microservices-based solutions.

2.1 “Rotem Hermon on Change Driven Design” http://effectivesoftwaredesign.com/2015/05/12/rotem-hermon-on-change-driven-design/

START quote

In particular I like very much Rotem’s definition of the four principles of Change Driven Design:

1. Areas of change should be contained.

2. Things that are more likely to change should be easier to change.

3. Things that are less likely to change should not depend on things that are likely to change.

4. Change should entail extending the system rather than refactoring.

END quote

RE item 2: Many types of changes must be anticipated in the architecture and thus they are easy to do. Other changes must be possible. For example, [REF1] states that business-process-centric solutions have several types of artefacts: event, business-process, rule, role, activity, data, document, audit trail, and KPI. Their changes are anticipated and these artefacts are structured as shown below.

All artefacts are available as microservices – see below (only 4 lower layers are shown).

Techniques for composition of microservices: DSL (BPMN, DMN), interpretive general languages (Groovy), compiled generic languages (Java). Off-The-Shelf (OTS) microservices can be used as necessary, e.g. business process engine for BPMN.

RE item 4: Technical changes should be fused with business changes in accordance with the PDCA cycle.
  • [Plan] measure how the work is done,
  • [Plan] observe the business environment,
  • [Plan] decide in what areas the solution should advance,
  • [Do] implement the decisions taken,
  • [Check] validate the effect of those decisions, and
  • [Act] refactor some microservices to adopt internally the improvements.

2.2 Microservices – Sharpening the Focus https://genehughson.wordpress.com/2015/05/18/microservices-sharpening-the-focus/

RE “In short, the application architectural style known as microservice architecture (MSA), is unlikely to be an appropriate choice for the early stages of an application.”

On the contrary, at the early stages of solution elaboration as a functional prototype, a high rate of changes is mandatory thus microservices-based solutions offer a huge gain in development time.

RE “The moral of the story, at least in my opinion, is that intentional design concentrating on separation of concerns, loose coupling, and high cohesion is beneficial from the very start. Vertical (functional) slices, perhaps combined with layers (what I call “dicing”), can be used to achieve these ends. ”

Yes and [REF1] offers slicing and dicing out-of-the-box – vertical separation by business processes and horizontal layers as shown in illustrated above.



Beauty of #microservices: part 1 #entarch #apparch

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 which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

As usual, some terminology must be clarified.

2 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 microservices are handled in fault tolerant and in scaling up and scaling down.

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.

2.3 Microservice or Autonomous Component (AC)

Microservice is a unit of functionality which is
  • explicitly-defined for a potential consumer how to use it (yes, there is a formal contract)
  • universally-accessible for its consumers via standard protocols (not just REST)
In addition, microservices are:
  • design-interdependent (design-time dependency in accordance with the overall design of a software-intensive solution)
  • operationally-independent (i.e. unavailability of a particular microservice may be compensated without total unavailability of the whole solution)
  • contractually-dependent (run-time dependency in accordance with the formal contract)
“Unit-of-functionality” means Single Responsibility Principle (SRP). Thus a microservice with a greater and single responsibility may be composed from microservices with lesser and single responsibilities.

Obviously, microservices is that old-known services should be.

2.4 Microservice architecture

Microservice architecture (as well as SOA) is an architectural style for constructing software-intensive solutions from a set of universally interconnected and interdependent services/microservice.

The artificial separation “SOA is for integration between applications” and “microservice architecture is for applications” has no sense anymore because the integration between two “microserviced” applications is the same as integration between microservices within each of “microserviced” application.

3 Review of some posts

Several articles about (mainly negative) about applicability of microservices.

3.1 “Microservices” https://www.linkedin.com/pulse/microservices-matthew-kern-msea-cea-pmp-itil-cissp-issap

START quote

Here are a few reasons the microservices approach is a bad idea:

1. As mentioned above, web services have large overhead and making the invoked service smaller increases that overhead.

2. Increasing the number of service dependencies runs counter to the reliability equation and hard physics. Availability may suffer.

3. Regression testing of such a distributed system with additional parts can increase complexity and time.

4. Web services can be difficult to secure. Additional overhead may be piled on to secure these many services.

5. Additional interfaces to manage means additional governance and work for those not coding.

END quote

RE item 1: Each time people talk about performance of a system to be designed I remember a quote from Prof. Donald Knuth: “Premature optimization is the root of all evil (or at least most of it) in programming.” See a related discussion in https://genehughson.wordpress.com/2015/01/30/microservice-mistakes-complexity-as-a-service/ and https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/

RE item 2: On the contrary, a proper use of microservices makes error-handling explicit and scalability is in the design – see REF1.

RE item 3: Because the context for each microservice is well defined then testing is an integral part of the design.

RE item 4: See REF1 how the security problem can be addressed.

RE item 5: interface must be crafted in any case – either for components of a monolith or components of a distributed system.

3.2 "Microservices: a real world story" http://watirmelon.com/2015/05/14/microservices-a-real-world-story/

A very good article showing that the current “microservice architecture” is a bit weak to be considered as a real architecture (thus provide a solid based for industrial delivery of software-intensive solutions).

Of course, it is very difficult to maintain an application with a rather weak architecture. Just a few points.
  1. Structure is necessary instead of a flat microservice-to-microservice topology. It helps to testing, integrity and reducing the level of complexity.
  2. Strongly and statically typed language is preferable for interfaces, i.e. between microservices. Weak and dynamic type language is OK within microservices.
  3. Monitoring and testing may merge: testing becomes on-going, and monitoring becomes more functional.
  4. Real architecture must enable quick deployments of new versions of solutions.

3.3 "MicroservicePremium" http://martinfowler.com/bliki/MicroservicePremium.html

RE “So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.”

This is yet another confirmation that the current “microservice architecture” is a bit weak to be considered as a real architecture. There are two viewpoints: a) external service provider viewpoint who is engaged for a well-defined scope and b) enterprise-wide viewpoint for considering software-intensive systems within an enterprise TOGETHER. The different between them is like seeing the trees or the forest.

Obviously, some initial efforts are necessary to establish microservice-centric environment and practices. These efforts will pay-off after several applications.

In addition, each subsequent solution is cheaper because it reuses the same tools, the same services, the same architecture.

3.4 "Making Architecture Work in Microservice Organizations" http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice

An excellent example of bring an enterprise-wide apparch approach to an enterprise.

See also “Enterprise patterns: Platform-Enabled Agile Solutions (PEAS)” http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS



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:
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.