#entarch frameworks are typical monoliths which have to be disassembled for better architecting

This blogpost starts the "Better Architecting With" series http://improving-bpm-systems.blogspot.bg/search/label/%23BAW

#entarch frameworks are considered as a must for any serious #entarch work. There are about 1 000 #entarch frameworks on this planet. The most popular of them are typical monoliths – huge in size, contain a lot of overlaps, slow to evolve, difficult to adapt to particular needs, expensive to learn, tricky to explain, etc.

Not surprising that some organisations have to use a mixture of #entarch frameworks although some #entarch frameworks allow some tailoring. For example, an organisation has to use FEA because they work with the local government, TOGAF for solutions and ZF as a foundation.

Considering that organisations are demolishing/modernizing/transforming their application monoliths, let us, enterprise architects, apply the same tendency to #entarch frameworks. Such a transformation must:

1. preserve and externalise (from the monolith frameworks) the knowledge which is accumulated by those #entarch frameworks, and
2. provide a guidance how to build and operationalize unique #entarch practices from a coherent set of repeatable (proven or innovative) #entarch techniques and methodologies.

De facto, the “erosion” of the monolith nature of #entarch frameworks is already ongoing (examples, Tom Graves work).

Let us outline the target way of architecting:

• Commonly-agreed terminology. Example - http://improving-bpm-systems.blogspot.bg/2015/10/concepts-crisis-in-it-and-sister-domains.html
• A set of viewpoints, model kinds and artefacts. Tey have to be properly described. Example – see slides 7-28 from http://improving-bpm-systems.blogspot.bg/2015/10/concepts-crisis-in-it-and-sister-domains.html
• Set of repeatable techniques and methodologies. This is the key point – a lot of patterns and algorithms must be available to various views, models and artefacts. Ideally, a change in some models should be easily propagated to linked downstream models. Example – IT strategy, some of the enterprise patterns, see http://improving-bpm-systems.blogspot.bg/search/label/enterprise%20patterns
• A configurator to define which viewpoints and models kids are required in a particular case. It may be manual at the beginning. 
• A guide how to explain different viewpoints and model kinds to all various stakeholders.

The process of architecting will be as the following:

• use the configurator to describe the problem space and generate a set of viewpoints for the solution space
• use techniques and methods to specify an initial set of models
• obtain OK from all the stakeholders
• use techniques and methods to specify all the rest models

Again, the key point is a set of techniques and methodologies to link models. Repeatable techniques and methodologies will lead to better #entarch tools and high level of automation. The whole architecting process will be faster, better and cheaper.

Thanks,
AS