EA is like City Planning

In recent discussions about the purpose of EA in business I brought back an old metaphor: that of EA as the "city planning" process. It's an old metaphor in the sense that I first heard it used in the late 1980's to set Enterprise Architecture off against Solutions Architecture, for example, with SA seen as the architecture of the individual buildings and EA as the architecture of the city areas those buildings are part of. It is an interesting metaphor that - in my opinion - gives some useful insights and directions to a profession still very much in search of a clear definition of itself.

The metaphore compares the enterprise to a city: a complex organisation of people, locations, functions, services and infrastructure. To thrive and grow the city must provide its residents (both private and corporate) with facilities such as water, power and waste disposal, transportation infrastructure, support for constructive activities and protection against destructive ones. Moreover, the city council must plan and manage the city so it develops a sustainable and encouraging mix of residential, industrial, agricultural, recreational and natural zones that together cater - in a balanced and mutually reinforcing way - for all the myriad functions and services a healthy city requires; without actually providing most of those functions and services directly, since that is usually left to private and corporate initiatives and developments.

Likewise, the EA looks at the enterprise as a whole and plans the facilities, infrastructure, functions, services, support and protection the enterprise requires to grow and develop.

To do so, the EA must have both a thorough understanding of the inner workings of the enterprise in its current state and an equally or more thorough understanding of the direction the enterprise is heading and what that direction means in terms of future requirements and needs. As with city planning, since creating the future infrastructure and services takes time (months and often years), waiting with creating them until those needs and requirements have fully manifested themselves is not a sustainable strategy. Instead, the EA is constantly looking ahead and planning for the enterprise to be.

This is not an easy feat and most certainly not a linear or even entirely rational process. Like a city, an enterprise is subject to a large number of forces influencing its direction and development: internal forces such as available intellectual, financial and production captial, internal politics and cultural trends; and external forces such as competition, legislation, regulations, national and international politics and socio-economic developments. All these forces push and pull the enterprise in any number of directions. Rather than being able to predict exactly where the enterprise will be at any given moment in the future a good EA develops a sense of which of the possible future states are a) most likely to come true and b) most in line with the enterprise's vision and strategies, as directed by its executives and directors. It is then the EA's task to plan and design the high level architecture that will best prepare the enterprise for those most likely future states, including the flexibility to adapt and change direction as the future unfolds.

There is a curious paradox hidden in this process: by sensing and assessing the most likely and appropriate future states and then planning to provide for those, the EA (like the city planner) is not just following the trends but in a very real way setting and solidifying them. Where a possible direction may be just a theoretical possibility, when the EA starts planning and 'architecting' for that direction, the enterprise will more strongly lean towards it, discarding alternatives the more concrete the architecture becomes.

And herein lies the greatest responsibility of the EA. Her task is not 'simply' aligning the enterprise's assets and structures with that enterprise's current and future needs - that would imply the EA has no influence on the enterprise's future state and direction and is just a passive 'follower of fashion' and provider of services to an enterprise that is wholly determined by forces and determinants outside her. Instead, in the complex environment of the enterprise, there is no such passive role: every decision the EA makes influences the direction of the enterprise and even the act of observing and analysing the enterprise in motion can change the course of what is being observed.

This means that the best EAs are constantly looking ahead, trying to see patterns and trends in what happens inside and outside the enterprise and extrapolating those patterns and trends to possible directions and future states the enterprise is likely to reach. Based on that extrapolation the EA then has to make the choices that set direction as much as follows it; that shape the future as much as prepare for it; that create new strategic imperatives as much as align with existing business strategies; and - most important of all - that create facilities, infrastructure, support and services for what the future enterprise needs before it needs it, rather than wait till the need is there. As long as Enterprise Architecture is seen as a "follower" rather than a "co-creator", the products of the EA will always come too late, be less than the enterprise needs at any given moment and too much of what it doesn't need.

Talking about EA - Architecture vs. Engineering

I have the feeling that we need to be very clear in our thinking and definitions when talking about Enterprise Architecture, or we run the risk of confusing levels and overlooking important issues that will reduce our effectiveness in moving forward.

One distinction I think is important to make is the difference between Architecture and
Engineering.

Architecture takes a holistic view of the organisation and tries to work out what kind of support (procedural, structural, technological) this organisation needs to be able to realise its vision, goals and strategies (i.e. its desired future state). Engineering, on the other hand, takes specific problems and solves those within the strict boundaries of the problem definition and requirement specifications, without having to look at the larger context in which these problems occur.

The focus of engineering is on improving the parts, whereas architecture focuses on developing the whole.

This may sound trivial, but when this distinction is lost when planning Enterprise Architecture initiatives there is a tendency to skip the important step of actually designing a new and better architecture (i.e. an architecture that supports and enables the organisation to realise its desired future state) and instead dive straight into optimising what is already there, without a clear understanding of how much that will actually support the future organisation.
Doing this brings the risk of getting priorities wrong and tackling things in the wrong order, or worse, tackling things that are not actually relevant in the bigger picture. The worst risk, however, lies in developing constructs and solutions that are contrary to the direction the business needs to go to reach its goals.

When architecture and engineering are in balance, architecture provides the roadmap, frameworks and guidelines, while the engineers provide the best possible way to build the roads that architecture specifies.

One of the remarks made during the discussion about producing results soon enough to satisfy the expectations of the organisation was that it is not necessary to wait for the high-level architecture to be complete but that "we can start in the middle" - meaning we can optimise and fix things without waiting for the architects - that way we can produce 'quick wins' and buy time (and support) to do the more strategic work.
This may well be possible and there may be cases in which a solid business reason can be given to go ahead. But this is not architecture, it is engineering: a strictly local optimisation without the strategic context to determine the longer-term impact and relevance.

This means that extreme caution should be taken when approving such optimisations and at least the following conditions must be met:
- the ROI must be demonstrated over a relatively short time span;
- the effort required must be small;
- the impact must be localised; and
- the optimisation must be removable.

After all, without the strategic context that architecture provides there is a very real chance that the effort will turn out to be misaligned with the future needs of the organisation. This can be compared to the various efforts to improve tank designs in WWII without (yet) understanding the changed strategic imperatives of modern warfare and the different terrains the tanks were to be deployed in. Some of those improvements seemed great in isolation (e.g. using a lighter, more maneuverable gun) but failed dramatically in actual battle situations (when faced with heavily armoured opponents).