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 

7 Explain to the PMO the specificity of mini-projects

See http://improving-bpm-systems.blogspot.ch/2013/02/quick-delivery-of-solutions-via-peas.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.


Thanks,
AS