Enterprise Architecture’s Missing Models

Enterprise Architecture is a discipline that produces a range of models to guide the development of an enterprise. Various model segments – or limited-scope models – are brought together in a coherent whole which may be called an architecture – or more precisely an architecture description.

The architecture description is founded on a consistent ontology – ideas of what there is in the enterprise – and a convention of representation – how these things and their relationships are represented in the models.

Key model sets
Typically, an enterprise architecture programme will focus on producing three key architecture descriptions – or model-sets – that describe the state of the enterprise as it changes over time. The three core architecture descriptions are :-

1) the Current or As-Is Architecture;

2) the Target or To-Be Architecture; and

3) a set of Transitional (or Intermediate) Architectures and Roadmaps whose purpose is to describe the step-by-step changes in the enterprise – across all relevant aspects or dimensions.

If you believe in strict determinist, mechanist theory, the As-Is and To-Be are derived in simple linear fashion from the strategy for the enterprise. The Transitional Architectures and Roadmaps are then derived by straightforward, pragmatic gap and dependency analyses from the As-Is and To-Be state descriptions.

An essential part of the enterprise architecture description is the set of organisational models – organisations, divisions, departments etc. and their relationships – for the organisations participating in the enterprise.

Management theorists, however, a long time ago, realised that social or socio-technical constructions – like people-intensive enterprises – by and large do not conform to any strict, mechanistic determinism. They are not like machines. People are important constituent parts of enterprises and people’s behaviours and actions are not subject to such strict determinism.

So, strategy explication and execution is not a simple linear process – a monologue – but much more of an ongoing dialogue, the “Strategic Dialogue”.

In this dialogue, all parts of an enterprise formulate and critique (or should do so) each other’s views of the future – both in terms of desirability and practicality. The days are long since gone when the idea that a small coterie of senior managers would formulate strategy in a (smoke-filled) boardroom to be announced to the enterprise and magically executed without hitch was regarded as a serious or accurate model of the enterprise. [See, for example, Mintzberg et al.’s ‘Strategy Safari’, Hrebiniak’s ‘Making Strategy Work’ and Mintzberg’s et al.’s ‘Strategy Bites Back’.]

In reality, there is much more toing-and-froing, much more discussion, much more iteration between strategy formulation, strategy explication and strategy execution. At the heart of this enterprise dialogue, is not small-group mental models but explicit large-group model sets that express the vision of the future and the changes necessary to realise it.

Actionable programmes of change
If done well, Enterprise Architecture provides these models explicitly and systematically and allows the consequences of strategic decision options to be worked through in a rigorous fashion, before large amounts of resources are committed.

However they are arrived at, the transitional architecture descriptions and roadmaps form the basis for actionable programmes of change in the enterprise. While ‘Change’ in general is constant – ie the periods of static stability are short compared with periods of change, contra the Greiner model – any specific change is of relatively short duration.

Because it is of relatively short duration and has simple, ‘contained’, bounded objectives, such specific, individual changes are usually best implemented as projects. Then, because changes in one area necessarily entail changes in another, programmes are necessarily sequenced structures of inter-dependent projects.

Programmes deliver large-scale change in the enterprise – conceived as the cumulative effect of many small changes – each individual change implemented in a project.

Every project may be considered as an investment in change and every programme as a planned series of investments.

Martin Op ‘t Land, Erik Proper et al. describe the relationship between Strategy (formulation), Enterprise Architecture and Programme Management in Chapter 3 of their book – ‘Enterprise Architecture – Creating Value By Informed Governance. These three disciplines may be regarded of the critical pillars for the effective systematic delivery of change in enterprises.

Missing models
This brings me to the first of several models that are missing from Enterprise Architecture descriptions, as delivered by common EA (poor) practice. Programmes and projects are temporary organisational structures and sequences of activities that exist in an enterprise for a limited duration (they are temporary even if programmes go on for several years – or even decades).

[Projects should not go on for more than a few years, of course. If the activities and objectives are so large that they require hundreds or thousands of man-years of effort, they should be considered as programmes and decomposed into a structured portfolio of much smaller projects. The bigger the project, the higher the risk, the greater the difficulty of managing it well and the higher the probability of falling short of the objectives. Only galactic project management geniuses (not found on Earth) can do big projects – humans should stick to small-ish projects.]

An essential part of the enterprise architecture description is the set of organisational models – organisations, divisions, departments etc. and their relationships – for the organisations participating in the enterprise.

By any rational methodology, this set must include the significant temporary organisations – the programmes and projects – not just the “BAU“- Business-As-Usual – operational organisations. Yet, how many Enterprise Architecture descriptions actually model the temporary organisations – the programme and projects – that will deliver the changes?

This omission is even more glaring when you consider that Programme Management will, if it uses a proper systematic methodology, produce most of the models anyway! Every programme will have an explicit model of the target or transitional state of the enterprise at the end of the programme. In the MSP (Managing Successful Programmes) methodology, this is captured in the programme’s Vision and Blueprint documentation (and elsewhere), which should be identical to the relevant EA model segments.

Most programmes will also have an implicit model of the current state of the enterprise because the programme ‘knows’ (or should) what it is going to change. The programme will also have a (dynamic) model of its constituent projects, and by extension, what specific changes each project is going to make, and their temporal and logical inter-dependencies in the programme’s project portfolio. These dependency models should have an obvious, direct relation to the EA Roadmaps – and be consistent with them and integrated into them.

But it goes even further.

Every project may be considered as an investment in change and every programme as a planned series of investments. Programmes, managed in accordance with a good methodology, will produce cost and benefit profiles that model how increases in the value of the enterprise are generated – including changes in cost and revenue streams – as projects are executed. [If the project did not increase the value of the enterprise, you would not do it of course. Or would you?]

These are models that describe how the enterprise will use its financial resources to change, for the better, its financial, social and technological structure and dynamics. The finance or accounting department – or departments – in the enterprise will (should) be producing these models anyway (if the enterprise is well-managed). When was the last time you saw the models of the financial structure and dynamics of the enterprise integrated into the Enterprise Architecture description?

The people factor
But finance/money, is not the only consumable, perishable resource consumed by projects and programmes. Another important resource is that associated with people.

The resource is not people’s time. Nor is it some generalised notion of effort – the product of people’s activity and time. The consumable, perishable resource is knowledge-skill X people X time – the product of the right knowledge and skills exercised at the right times (and in the right places) by the right number of people.

So, to execute project ABC in timeframe T, you are going to need 100 man-days[1] of project management, 200 man-days of technology XYZ level 1 knowledge, 40 man-days of technology XYZ level 2 expertise, 250 man-days of technology UVW level 1 knowledge, 30 man-days of solution architecture know-how, 10 man-days of EA consultancy, 10 man-days of EA Governance, 10 man-days of Financial Governance, 30 man-days of programme management and so on.

This is the human/knowledge resource model – or plan (a time-based model !) – for the project.

Adding these up for all the projects in the programme’s portfolio – together with the overheads of programme management not allocated to projects – gives the programme’s human resources model. When summed up or integrated across all the programmes and aligned with the EA roadmaps, it provides the ‘Strategic Staffing Plan’ or HR model for the change-making parts of the enterprise.

This is a model of the changes in the personnel compliments and structures, and dynamics in the organisations in the operational enterprise. It complements and relates to the ‘Strategic Staffing Plan’ for the BAU operational enterprise. When did you last see this most important aspect of enterprise development included in an EA description?

These are just a few of the models missing from common Enterprise Architecture practice – there are many more. But I would like to leave you with just one more.

Enterprise Architecture – the reflexive and reflective analysis and modelling of the enterprise – is itself a part of the enterprise. It is the only part that critically reflects on the whole enterprise – apart from possibly the Executive Management. It has its capabilities, organisation (structure), processes, methods, flows of funding, personnel, skills and knowledge etc. and relationships to other parts of the enterprise – other organisation, process, functions, capabilities etc.

So any scope-complete model (not detail-complete) of an enterprise that does change systematically using the discipline of Enterprise Architecture must, logically, include a model of the EA operation itself. To be consistent, logical and holistic, Enterprise Architecture must model itself in its context. When was the last time you saw an Enterprise Architecture organisation/function model itself and its place in the enterprise?


[1] The “man-day”, conventionally 8 man-hours, is the unit of effort and uses the word ‘man’ as a shorthand for ‘human’ – meaning both men and women. Female man-days of effort in the same knowledge-skill class are just as valuable as male man-days. There is no implied sexism here – just the aesthetic judgment that ‘person-day’ is an ugly expression.

Technical drawing courtesy [email protected]

There are no comments

Add yours

freshmail.com powered your email marketing