Here we see the approximate rate of change for each of the
levels of the structural and transformational Models.
The Contextual level (consisting
of the Enterprise’s Strategy - some call Business Strategy) tends to change
annually. In general an Enterprise’s overall strategy changes very slowly.
The Conceptual level (consisting
of the Business, Technical and Transformational roadmaps and portfolio of
programmes and projects) tend to change annually or bi-annually. In general
Enterprises tend to largely create/update these once per year as part of the
annual business planning cycle.
The Logical level (consisting
largely of the Logical designs of the Enterprise) changes more often, perhaps
monthly as transformation projects execute.
The Physical level (consisting
largely of the Physical designs of the Enterprise) changes more often again,
perhaps weekly as transformation projects execute.
The Operational level
(consisting largely of the CMDB - Configuration Management Database) changes
more often still, perhaps on a daily basis.
Both the Contextual and Conceptual levels could also be changed at any time
due to pressures in the Enterprise context such as Mergers & Acquisitions,
This view gives an indication of the volume of information
(as a percentage of the whole) that exists at each level. It can be seen that
volumes increase the further down the phases we go. This seems pretty obvious
but this fact tends to be ignored in most Enterprises. This therefore
illustrates that an Enterprise Architecture Model is actually quite small in
terms of the volume of information where a common misconception is that it is
very large and therefore cannot be populated easily.
Here we see the potential impact of decisions made at each
level. The impact could be positive or negative. Good decisions will have
positive effects, bad decisions will have negative effects. In general, the impact
will be felt in terms of the effectiveness and efficiency of subsequent phases
and in terms of the effectiveness and efficiency of what is ultimately
If good decisions are made, the impact will be felt in terms
of reduced costs, reduced timescales, reduced risks and increased agility and
durability of the transformation. If bad decisions are made, the impact will be
felt in terms of increased costs, increased timescales, increased risks and
decreased agility and durability of the transformation.
The impact (positive or negative) is greater the higher up
the Transformation Phases we go. For example, bad decisions made in the
Roadmapping phase that are not picked up until we get to Construction can be
severe and difficult and costly to correct (from a resource point of view but
also from a cultural point of view), whereas bad decisions made in the
Transitioning phase are mild by comparison and generally tend to be of low cost
to correct (from a resource point of view but also from a cultural point of
view). Conversely, good decisions made in the Roadmapping phase can have
massive benefits for the Construction phase whereas good decisions made in the
Transitioning phase will not have as much impact.
Since the Enterprise Architecture Model is concerned with
the Contextual and Conceptual information set in the context of the Enterprise
Context and the Logical Information, it is obvious what impact (positive or
negative) this can have if done well or done badly. This is why Enterprise
Architecture is so important for many Enterprises.
Here we propose how each level of information should be
populated and some ball-park timescales.
Information at the Enterprise Context, Contextual
and Conceptual levels can be and should be
populated by a concerted effort to so - a project, which is generally the
annual Strategy and Business Planning work that many Enterprises undertake on
an annual basis.
Information at the Operational
level could also be populated by a project, despite the volume of information
involved. This is because automated tools can be deployed to break the back of
this work although interpretation and massing by humans is still required.
Information at the Logical
and Physical levels is normally far too large
to be populated by a single project and also tends to be very difficult to
obtain. While a project could be created to populate this information
wholesale, the time and money involved is usually very high with the benefits
of doing so only realised over a long timeframe as subsequent projects utilise
the information collected. A more Pragmatic
approach is to populate this information as and when individual projects from
the project portfolio require it. Every project will need to create some of
this information for the purposes of being able to execute the project anyway,
and so capturing this over time in an ordered and well managed way, will mean
that the information builds up gradually on an as-needed basis. Some may say, Pragmatically!
Does your Enterprise
understand the low volume of information required for a complete EA Model?
Does your Enterprise
understand the large volume of information required for a complete EE Model?
Does your Enterprise populate
this information in a Pragmatic way?
Can you improve the way your
Enterprise populates and maintains this information?