Data Vault Ensemble Modeling

The Mapmaker’s Guide to the Galaxy – a
Top-down View of Enterprise Architecture

John Alexander

The idea that developing an Enterprise Architecture (EA) for an organisation can provide predictive capabilities with respect to IT investment and deployment, as well as business efficiencies and effectiveness, is one of the core ambitions of the EA disciplines.  However, because EA traditionally looks almost exclusively at the internals of an organisation, it is almost bound to be limited or even to fail in its predictive ambitions.  Why is this so?

The key lies in understanding that all organisations are like organisms – they exist in their specific environments, and their internals need to support and make them thrive in that environment.  Thus if something in their environment changes, their internals will be impacted and need to change accordingly to deal with the environmental change.

Most EA’s are like a full-body MRI scan – they provide lots of information about the internals, but tell us nothing about the environment the organisation has to operate in.  Crucially, they can’t tell us that if something in the environment changes, which parts of the internals are going to be affected and how.

What we need is for EA practitioners to take a step back and map the organisation AND its operating environment, linking the various external parts of that environment to the internal bits which need to deal with it – we need a high-level map of the environment, as well as the details provided by the MRI scan.  We need to be able to say that if this external thing changes, then this or these internal things will need to change.  We need to also be able to say in which way this internal thing needs to change.

This short workshop will try to provide a quick overview of how to arrive at that high-level map before driving down into all the details we traditionally include in an EA.  As change is a constant factor, this will make EA’s both more cost effective as a planning tool, and more valuable to all organisations.

Having started work in the area of industrial relations in the Australian shipping industry (when Australia still had merchant ships), John finally got tired of listening to people-problems, and decided to switch to programming computers where the problems were solvable (until SQL Cartesian products came along).  Having made that major life-change, John’s propensity for never refusing a new challenge, landed him in data analysis and data management, then enterprise architecture, then project management, and finally senior consulting in various roles and organisations, mainly telecoms companies, in many different countries.  On one such telco gig in the mid 1990’s, and in a heavy discussion lubricated with beer, the question was asked that something outside the organisation drove changes to the enterprise architecture – what was it, there must be a link of some kind?  Trying to answer this question took years of more wondrous experiences in different places, and finally to this book.  All that time to join up the dots.  Let that be a lesson to young enterprise architects.