Platform-based #digital transformation (example egov)

This blogpost is an example of digital transformation in e-government with the use of platforms (extracted from "e-government reference model #GeGF2014 #egov #entarch #bpm #soa" http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html  ).

In general, the e-government implementation architecture is as in Figure 1. It is a combination of an initial coordination platform (the social collaborative extranet) and an e-gov business execution platform (the coordination and integration backbone and functional services to be “cabled” to it).

Figure 1 Implementation architecture overview

Let us put this architecture in the evolution context. For the long time, e-government implementation architecture was portal-centric and its applications (blue "emabas") were extensions for some internal applications as show in Figure 2.


Figure 2 Implementation architecture – portal-centric stage

The proposed e-government implementation architecture is actually, the introductory architecture which introduces necessary flexibility. E-government applications may span several existing applications as shown in Figure 3.


Figure 3 Implementation architecture – introductory stage

As existing applications are evolving, they will be replaced by processes and services as well thus creating transitional application architecture as shown in Figure 4.

Figure 4 Implementation architecture – transitional stage

With converting all previously monolith applications into processes and services, the target application architecture will be reach as show in Figure 5. E-government applications will be just connections to a cloud of governmental services.


Figure 5 Implementation architecture – target stage

And, moving e-government to the really e-social system, the application architecture will morph into a social cloud interacting with the government service cloud as shown in Figure 6. The latter serves as a platform for social, professional, private, voluntary and other services to be integrated into e-social system.


Figure 6 Implementation architecture – e-social system stage

For existing e-government systems the evolution from the introductory architecture upwards does require primarily the systematic use of BPM and SOA. Green-field e-government initiatives may start from the target architecture.

All stages form a sort of ladder for step-by-step evolution as shown in Figure 7.

Figure 7 Implementation architecture – all stages as a ladder



Achieving synergy between diversity and uniformity via platforms

This blogpost continues the blogposts “Typology of platforms” ( see http://improving-bpm-systems.blogspot.ch/2015/12/typology-of-platforms.html ) and "Platform-based #digital transformation (example egov)" ( see http://improving-bpm-systems.blogspot.ch/2016/01/platform-based-digital-transformation.html ).

Ron Batdorf ( https://www.linkedin.com/in/ron-batdorf-b0a62610 ) in his comments ( https://www.linkedin.com/pulse/typology-platforms-alexander-samarin ) asked me to provide more explanations how to achieve synergy between uniformity and diversity.

Both concepts uniformity and diversity are antonyms.

uniformity, noun
state or condition in which everything is regular, homogeneous, or unvarying
[Source http://www.collinsdictionary.com/dictionary/english/uniformity ]

diversity, noun
the state or quality of being different or varied
[Source http://www.collinsdictionary.com/dictionary/english/diversity ]

They were used in the following text “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 uniformity and diversity then the same platform may serve the whole industry-sector (public services, healthcare, smart-city, etc.).”

A few techniques below provide the explanation.

1 Explain the concept platform

An example of platforms: A lot of modern mobile phones, tables, TVs, etc. are built on top of Android platform or iOS platform. Generic characteristics of platforms are:
  • The platform frees up resource to focus on new opportunities
  • Successful agile innovations are rapidly scaled up when incorporated into the platform
  • An agile approach requires coordination at a system level
  • To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives
  • Existing elements of the platform also need periodic challenge

2 Demonstrate to the business that there is a huge opportunity for uniformity

Although each company (in the same industry sector) is unique with its different capabilities, processes, strategy and priorities, there are many similarities (in the same industry sector). Naturally, each business exaggerates the level of diversity.

The blogpost http://improving-bpm-systems.blogspot.ch/2013/02/enterprise-patterns-peas-example-and.html is an example to prove to the business that their unique processes are actually assembled from the same services. The latter will be shared among all the business unit and the former may be unique in each business unit. 

3 Demonstrate to the IT that an assembly-based solution is better than a monolith solution

A monolith solution is often not good for any Business Unit (BU).

An assembly-based solution is adjustable to needs of each BUs with their own pace.

The assembly-based approach promises re-use and shared services.

4 Demonstrate to the top management that a platform is economically reasonable

To determine whether a platform is economically reasonable or not, one has to estimate the initial cost of the platform, the cost of an application (delivery without the platform), the cost of a solution (delivery with the platform) and the number of expected applications. Figure below demonstrates the financial comparison (Note: the value 8 is an example).

5 Explain to the IT management that the platform will be built incrementally

The level of platform functionality is like as the sea level which absorbs small islands if it is increased.

For each new solution, it will be possible to decide an extent of the usage of the platform. Obviously, the first platform-based solutions will contribute into the platform more than further platform-based solutions.

6 Explain to the governance group how to manage the platform

See http://improving-bpm-systems.blogspot.ch/2012/07/delivery-via-peas-architected-platform.html 

8 Explain to all the architects that the platform is about coordination of work not data flows

Making flows-of-control explicit and machine-executable is the primary goal of the platform because flows-of-control or “when who is doing what” is fundamental in business. Flows-of-data (and more generic, flow-of-assets), which are popular in SOA and more “visible” by all the architects, can be derived from the flow-of-control.

See slides 30-35 from http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html

Different between flow-of-control and flow-of-assets - http://improving-bpm-systems.blogspot.ch/2015/01/business-process-in-bpm-flow-of-control.html

9 Explain to business architects that each BU will advance with its own pace

Considering that, a platform is intended for all smart-city service providers, but how is it possible to achieve some degree of uniformity among all smart-city service providers if they have different abilities to absorb the benefits of information technologies. Computerisation is a journey, and each smart-city service provider needs to be allowed to adopt a suitable pace for itself, but we also need to maintain coherence in the progression of the whole set. The use of a “ladder” model can be useful since it permits progression of each entity in a stepwise manner but at the same time guides the overall progression in a coherent manner. Design the “ladder” to have a few levels of capability from “not able” to “fully capable”. Entities are permitted to advance at different paces in their ascent to the top of the “ladder”. For example, their progress could be planned as in figure below. 

10 Explain to software architects how the platform will be built

The platform is designed to be tools-independent by standardizing data, information, interfaces and coordination between various capabilities. This will allow building the platform incrementally by provisioning needed capabilities from COTS, FOSS, platform-community-owned and in-house components. A few components may be offered for one capability as shown in figure below.

Remember to avoid the use of exotic features of software which is not fully controlled otherwise it will be difficult to replace it.

Evolution of platform is carried out incrementally, continuously and with some verification, in accordance with the classic Deming wheel – Plan, Do, Check, Act
  • [Plan] how to implement a new improvement as part of a solution
  • [Do] to implement this solution,
  • [Check] to validate that this new improvement is valuable at the scale of the platform, and
  • [Act] to refactor the platforms to incorporate this new improvement and some solutions to use this improvement. 
The extent and frequency of these improvements depend on various factors (capability, risk ,etc.). Also, different improvements may have different scopes. And, the implementation of several improvements may overlap in time.

11 Explain to software architects how address versioning of everything

Careful versioning of everything is mandatory! To achieve the versioning of artefacts it is necessary to understand how to treat relationships between artefacts. We recommend that a system be evolved via some kind of transformation cycle as shown in figure below. Start with a stable configuration of approved artefacts. Then introduce a new version of the artefact B3 which is available only for one consumer (i.e. artefact A2) which has to be also versioned. After achieving higher confidence with these new versions, switch all other consumers (i.e. artefact A1) to the new version of the artefact B3. When it is considered that all new artefacts are functioning correctly, their old versions can be removed. The transformation is over and a stable configuration of approved artefacts is once again reached.

Although versioning is mandatory, the use of processes allows to avoid situation in which architects are forced to change all artefacts simultaneously (typical for upgrades and migrations of monolith applications). The changes are process-instance dependent, i.e. already running instances use old versions of some components and newly started process-instances will use new versions of some components. Completion of some process-instances will allow decommissioning of old versions.

Thus architects have the full control over the versioning. Switching for new versions is an independent decision of each application’s owner (i.e. each application may evolve with its own pace).

See http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-digital-age-shifting.html

12 Teach solution architects to implement assembly-based solutions

Microservices are perfect for such assembles. See “Architecting #cloud-friendly application architecture” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html

Another useful resource is practical enterprise patterns ( see http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns ). Similar to cooking recipes, such patterns may be use as-is to start with and then gradually tailored for some unique business needs.

Solutions architects must be properly train that different solutions architects in similar situations find similar solutions elements or propose innovations.

13 Finally, educate enterprise architects to build-in flexibility

It is mandatory to anticipate changes in the enterprise’s typical artefacts.
  • All artefacts must be versionable throughout their lifecycle.
  • All artefacts must evolve to become digital, externalised, virtual and components of clouds.
  • All relationships between artefacts must be modelled explicitly.
  • All models must be made to be machine-executable.

Basically, the platform starts from the provisioning capabilities for handling generic artefacts: data structures, documents, events, processes, rules, roles, audit trails, services, processes, etc. Then business reference data/information are managed enterprise-wide. Then core-business data are managed enterprise-wide. Then all the data are transformed into information. At the same time, various services (generic and enterprise-specific) are incorporated into the platform.

14 Explain to industry groups the potentials of platforms

An industry-specific platform can be built in collaboration and coordination between various enterprises – common data schemes, trusted data and documents exchanged, inter-enterprise processes, etc. Enterprises will compete in their core-business innovations but not in re-implementing of their IT systems.



#entarch view on #blockchain

This blogpost is aimed to outline some basic mechanisms of blockchain and to demonstrate how they can be combined with other enterprise technologies and methodologies.

This blogpost was discussed at BPM,COM forum http://bpm.com/bpm-today/in-the-forum/how-big-of-an-impact-will-blockchain-have-on-bpm

1 Basics concepts around digital assets, cryptography and blockchain

Primarily based on https://www.youtube.com/watch?v=Lx9zgZCMqXE

A digital asset is a valuable digital object whose owner can be cryptographically ascertained. Example: bitcoin.

A transaction describes changes in digital asset ownership.

A block is a collection of transactions.

A blockchain is a well-ordered tamper-proof collection of blocks, on which all stakeholders must (eventually) come to consensus. This determines the history of transactions and provides a computationally unforgeable time ordering for transactions.

Bitcoin is a digital money application built on top of blockchain to enable transactions without trust between stakeholders.

Hashing is a cryptographic procedure to map a digital object of arbitrary size to data of fixed size (called “hash”). Features: easy to compute, irreversible (not feasible to generate original digital object from its hash), commitment (any change in the digital object changes its hash) and collision free (not feasible to find two digital objects with the same hash).

Public and private keys are a pair of keys of asymmetric cryptographic algorithm.

A digital signature is a hash of a digital asset (e.g. a message, document) encrypted with the owner’s private key. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, that the sender cannot deny having sent the message (authentication and non-repudiation), and that the message was not altered in transit (integrity).

2 Basic techniques in bitcoin

Any owner of bitcoins (i.e. digital assets) is an anonymous who is known by its public key. An owner may have many public keys.

Digital signatures safeguard bitcoins (i.e. digital assets money).

A chain of transactions (actually, a direct graph) stores history of ownership. The history of ownership (i.e. all the transactions like a public global ledger) is used to determine amount of digital money own by a stakeholder (to prevent double spending) – a transaction validation procedure (bitcoin-specific).

Blockchain holds transaction order (linear sequence) and blockchain is protected by cryptographic hash (i.e. a blockchain is immutable).

Blocks of transactions to be added to the blockchain must be agreed by decentralised stakeholders through a blockchain integrity procedure (also called “consensus protocol”). Transactions are sent to the whole network of stakeholders and proposals for “potential next block” may be different from different stakeholders. In bitcoin, the blockchain integrity procedure is called “digital race”.


Certainly, blockchain as technology may be use together with many other technologies and methodologies.

Also, I would not call blockchain as a "global ledger" - it is bitcoin as an application uses blockchain as technology to implement a ledger. Note that bitcoin uses its transaction validation procedure to prevent the double-use of digital money.

3 Synergy between #BPM (as a practice) and #blockchain (as a technology)

As continuation of "Synergy between #BPM, #digital, #IoT, #microservices and #blockchain" http://improving-bpm-systems.blogspot.ch/2015/12/synergy-between-bpm-digital-iot.html 

Usually we use monetary transactions in more complex business transactions, for example, the latter is a sequence of atomic transactions (as a happy path):
  1. Vendor: Propose contract
  2. Buyer: Accept contract
  3. Escrow: Seal contract
  4. Buyer: Transfer money to escrow
  5. Escrow: Announce payment to vendor
  6. Vendor: Deliver goods 
  7. Buyer: Announce acceptance of goods to escrow
  8. Escrow: Transfer money to vendor
Right now, money is digital and goods maybe a personal copy of a digital book or a car ownership certificate.

Now, imagine this process must be carried out without trust between its participants (buyer, escrow and vendor) and with the use of blockchain-technology-based storage to secure the process-instance audit-trail. As everything is digital (process, money, goods, etc.) then the escrow may be digital as well – the process instance itself is a digital escrow which coordinates all the atomic transactions.

0. Digital escrow is requested to be involved

The digital escrow amends the contract by this process template (definition) & this process instance information, signs everything with its private key, and sends everything to a blockchain-based audit-trail storage.

1. Vendor: Propose contract

This contract is signed by the vendor’s private key and is sent to the blockchain-based audit-trail storage.

2. Buyer: Accept contract

This contract is signed by the buyer’s private key and is sent to the blockchain-based audit-trail storage.

3. Escrow: Seal contract

The digital escrow (actually, the process-instance) sings the contract (which is already signed by buyer and vendor) and sends it to the blockchain-based audit-trail storage.

The digital escrow invites the buyer to pay.

4. Buyer: Transfer digital money to escrow

The buyer transfers the agreed amount of digital money to the digital escrow. This transaction is sent it to the blockchain-based audit-trail storage.

5. Escrow: Announce payment to vendor

The digital escrow invites the vendor to “ship” digital goods in accordance with the contract.

6. Vendor: Deliver digital goods

The vendor change the ownership of the digital assets to be sold in accordance with the contract. This transaction is sent it to the blockchain-based audit-trail storage.

7. Buyer: Announce acceptance of digital goods to escrow

The buyer confirms to the digital escrow the reception of the all digital goods. This transaction is sent it to the blockchain-based audit-trail storage.

8. Escrow: Transfer digital money to vendor

The digital escrow transfers to the vendor the digital money. This transaction is sent it to the blockchain-based audit-trail storage.

The whole history of this business transaction is sent it to the blockchain-based audit-trail storage for the buyer and for the vendor.

Again, this is only a happy path without any problematic situations. Important that all the procedural formalities can be implemented exactly in accordance with the legislation of a particular country. Because of the detailed and immutable audit-trail, any disputes about a particular contract may be resolved by a digital judge.

Hmm, maybe also digital buyer and digital vendor?

4 Just an idea – sell #microservices (with one-time password) via blockchain

See "Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)" http://improving-bpm-systems.blogspot.de/2015/04/architecting-cloud-friendly-application.html

5 Another idea - super-reliable audit trail

Keywords: certificate transparence, https://en.wikipedia.org/wiki/Merkle_tree