How was Training?

more

“Useful insight to EA and the benefits it could bring.” - Technical Consultant, Experian, UK, Mar 2013

Recommend PEAF?

more

“Yes - It's pragmatic - like me!” - Architect, Temasek Consulting Services, UK, Jun 2012





Volatility

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, etc.

Volume

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.

Impact

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 deployed.

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.

Population

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?

 

 

◄◄◄ Previous Page          

          Next Page ►►►












 

© 2008-2016 Pragmatic EA Ltd