Post-platform Enterprise Pattern: Faster and Cheaper Inter-Enterprise Ecosystem Business

“If everybody minded their own business, the world would go around a great deal faster than it does.”
-Lewis Carroll, “Alice in Wonderland”.

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


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. Each effort may have a 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 some of its core-business capabilities, and
  2. using the best “other” enterprises for provisioning “other” capabilities needed to achieve the particular goal (or 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. In 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 of contracting out versus direct management is only one of many factors. The other factors include risks, time lag, security, etc., which must be taken into account.

Thus, the famous classic representation of an enterprise may be redrawn as shown in the illustration below. Both support activities (previously considered as “horizontal integration”) and some core-business capabilities (previously considered as “vertical integration”) may be provided by “other” enterprises.

Classic Representation of Enterprise

The ability of several enterprises to work together with maximum synergy and minimum overhead (thus much better than a classic enterprise) is critically important. The potential list of common activities to achieve that is not long but daunting:

  • formally define the 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 partnering enterprises;
  • carry out the work with secured sharing some data and information among partnering 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 than 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 a BPM-suite tool. One method 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 two or more mutually non-trusted parties. See

Of course, when many enterprises contribute into some common work, records management must be centralized (i.e. accepted by all the partners) and suitable for a 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 –


Working together for the same goal requires some sharing (business and technical artefacts) and, probably, some agreed means (i.e. tools). Such 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? Shall each enterprise add complex EDI infrastructure for communicating between processes from other enterprise? Shall each enterprise keep everything inside? 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 with an independent provider and linked to existing processes in each enterprise.

WHAT to shareExamplesReason(s)Supporting means
Data (see the DIKW pattern) hashes, cryptographic keys Security common immutable storage
Information (see the DIKW pattern) business objects Interoperability, e.g. in interfaces common immutable storage
Facts audit trails, signed documents, agreed goals, demonstrated KPIs, inputs & outputs of inter-enterprise transaction Traceability common immutable storage
Events some facts important for business synchronization of work common event queue
Rules agreed business logic regulation of work common decision mechanism
Activities agreed procedures, agreed SLAs, agreed protocols automation common scripts in domain-specific languages
Processes agreed testing methods coordination of work common coordination mechanism
KPI calculations agreed formulas and results of calculations common view on performance common dashboard
Intelligence agreed algorithms and results common view on planning common prediction mechanism
Improvements 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 partners’ opinions on some factors non-biased corporate security for all the enterprises involved common immutable storage
Estimations of risk which are evolving along processes partners’ opinions on adverse impacts non-biased corporate security for all the enterprises involved common immutable storage
Finances 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. Retention perion does matter.
  • 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 a high level of creativity) – process templates define the granularity and interfaces for microservices and a digital archive keeps all the artifacts (of course, they must be versioned). Process instances define validity of various facts.

See also for process to microservices conversion.

Some hurdles – processes modeling

Modeling 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 communicate by exchanging messages thus it is necessary to handle exceptions in communicating processes. Good modeling 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
  2. Bonita can use blockchain –
  3. ConsenSys uses Camunda BPM-suite to use blockchain as a data storage, creating new users and executing smart-contracts

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.


See 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 right picture (TO-BE), actual processes from the left picture (AS-IS) were lost. And, “Erroneous behavior 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.

Quote from Alberto Manuel‏ (@AlbertoManuel) "Architecting expanded value chain in the era of digital ecosystems and shared capabilities."

By the way, the idea of software-defined enterprises ( see ) is perfectly supported by such “disintegration” of enterprises.

1000 Characters left

Dr Alexander Samarin