#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:
- preserve and externalise (from the monolith frameworks) the knowledge which is accumulated by those #entarch frameworks, and
- provide a guidance how to build and operationalize unique #entarch practices from a coherent set of repeatable (proven or innovative) #entarch techniques and methodologies.
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.
- 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