Enterprise Architecture is probably one of, if not he the most, misunderstood terms in the business and IT world today. Most people have a definition for it - The problem is, a lot of those definitions are either incomplete or just plain wrong. I know because I used to be one of those people. It has become clear to me that Enterprise Architecture is not complicated, is not difficult, is not expensive. Of course there are elements out there who would prefer boards and organisations to think that it is complicated, is difficult and therefore is expensive. That is not to say that Enterprise Architecture does not have its issues problems and risks. However, so long as the key tenet’s are understood and the issues, problems and risks are managed, any organisation can instigate and reap the benefits of Enterprise Architecture.
Here we see an organisation which is existing and running. There is the current state which comprises: The Contextual Model (the Enterprise Strategy – Mission, Vision, Goals, Objectives, etc) Stuff that people are using that fulfils that Enterprise Strategy. Nothing is changing.
Now we introduce the element of change. Immediately we introduce the notion of Change Planning and Target State. Within those areas we introduce the process of Visioning - which considers the current state Contextual Model and produces a target state Contextual Model. Our journey has begun....
To complete the are of Change Planning we introduce the notion of a Conceptual Model. The Conceptual Model is a structural model of the Enterprise but at the Conceptual level (one level above a logical model) We also introduce the Planning process which: - Takes the Target Contextual Model as it’s primary input Considers the Current Conceptual Structural model Uses those two things to decide what the Target Conceptual Structural Model should be In addition, the Planning process also considers what steps need to be taken to transform the Organisation from the current Conceptual State to the Target Conceptual state. These steps are expressed in the Organisation Change Model initially at the Roadmap level, then at the Programme level and finally at the Project level as the Planning process proceeds. The out therefore is a Target Conceptual Model supported by an Organisation Change model. The next step is to execute the programmes & projects that have been defined...
We are now at the project level. We therefore introduce the area of Change projects, the first sub area of Solution Architecture and the notion of a Logical Model. The Logical Model is a structural model of the Enterprise but at the Logical level (one level above a physical model) We also introduce the Architecture process which: - Takes a slice of the Target Conceptual Model as it’s primary input which defines the scope of this project Considers the related slice of the Current Logical Structural Model Uses those two things to decide what the slice of the Target Logical Structural Model should be. When the project finishes the main Current Logical Structural Model is updated with the Target slice created.
We now introduce the second sub area of Design and the notion of a Physical Model. The Physical Model is a structural model of the Enterprise but at the Physical level (one level below a logical model) We also introduce the Design process which: - Takes a slice of the Target Logical Model as it’s primary input which defines the scope Considers the related slice of the Current Physical Structural model Uses those two things to decide what the slice of the Target Physical Structural Model should be In addition for a solution that requires things to be built rather than bought another level of design is required When the project finishes the main Current Physical Structural Model is updated with the Target slice created.
We now introduce the third sub area of Build and the notion of a Component (or internal) Model. The Component Model is a structural model of the Enterprise but at the Component level (one level below a Physical model) We also introduce the Build process which: - Takes a slice of the Target Physical Model as it’s primary input which defines the scope Considers the related slice of the Current Component Structural model Uses those two things to decide what the slice of the Target Component Structural Model should be. Uses that slice to either build or buy the solution. (Of course there could be a mixture of both) When the project finishes the main Current Component Structural Model is updated with the Target slice created.
We now overlay the area where a CMDB (Configuration Management Database) exists. Note that although the Operational Model needs to be related to the Physical Model for requirements.
Moving further up we can see the areas for Systems/Software Architecture Modelling. Note that although the Physical Model is at the centre, the information needs to be related to the Logical Model for requirements and down to the Operational Model for impact assessment.
Now we can see the areas for Solution Architecture Modelling. Note that although the Logical Model is at the centre, the information needs to be related to the Conceptual Model for requirements and down to the Physical Model for impact assessment.
Now we add the areas for Enterprise Architecture and Planning. Note that although the Conceptual Model is at the centre, the information needs to be related to the Contextual Model for requirements and down to the Logical Model for impact assessment. Note also that we also produce the Change Model.
This is the area for Enterprise Strategy Modelling. Note that although the Contextual Model is at the centre, the information needs to be related to the Market &The Enterprise Model for requirements and down to the Conceptual Model for impact assessment.
Peeling back the processes we can more clearly see the areas of concenr for each type of modelling
We now add the area concerned with Enterprise Architecture Modelling What all of this illustrates is that whilst there are separate models, they are inextricably linked – for that is their power and value. This means that depending on how many modelling tools are used there will be interfaces between them to be managed
The small red bar illustrates the data that many organisations populate an “EA” Model with. Essentially an application inventory in the Physical domain with maybe a business capability Model in the Logical domain.
Many people and organisations think that they cannot model everything, but everything has two dimensions – breadth and depth This diagram illustrates the respective breadth and depth for each model. Actually the diagram is not draw to scale as can be seen from the percentage of content at each layer. The bars on the left comprise the various levels of the Structural Model. The bars on the right are comprise the Enterprise Strategy and Planning Models.
Now we can see the area concerned with Enterprise Architecture Modelling. 100% the breadth - 0.111% of the depth.
This illustrates the work required to populate the various domains. The Contextual, Conceptual and Operational domains are populated by specific projects requiring specific funding. The Change domain is populated by the normal Annual Business Planning cycle/process whenever that occurs. The Logical and Physical domains are populated on an Ad-Hoc as-needed basis as the project portfolio executes
