1. Gentle Introduction to Enterprise
Architecture
"Enterprise Architecture" is a name that doesn't instantly speak to everybody. With its slightly grandiose
sound, it might even inspire mistrust.
I'll try to take you through a step-by-step discovery of the problem, the solution(s) and how these solutions
came to be known as "Enterprise Architecture" (or "Urbanisation" for the French). I hope that in the end,
by understanding what his work is about, you might be better-disposed toward your friendly Enterprise
Architect.
A. The Problem
1. IT serves the business
First, let's lay down my initial assumptions and see if they match yours. First assumption, "IT serves the
business". That is, in most organizations, "people do stuff" - they produce products or they deliver
services; and because some of the stuff that needs to get done is performed more efficiently by
computers, an IT system emerges. Around the IT system, a team forms to take care of it - run it, correct
errors, make it evolve and acquire new functionalities, etc. Thus an "IT department" is formed, "owning"
the IT systems and the relationship between those systems and their users (who collectively become "the
business").
2. The business is performed through series of
distinct activities
No big news here - in any moderately complex organization, "the inputs" (whatever they are) are dealt
with in a series of activities which are quite distinct and are chained (the intermediate output of an activity
becomes the input of the next activity in the chain and so on until the output of the very last activity is the
actual product or service of the organization). These series of activities are what is generally called
"business processes".
The drive for efficiency and effectiveness makes people specialize in doing what they know best.
Gradually, as companies / organizations get more complex, people lose sight of the exact details of how
other activities (than the one they specialize in) are performed. They form relatively tightly-knit teams of
experts (each one in a specific field). Mastering an activity, while by-and-large beneficial, has an often
overlooked price: losing sight of the "big picture". Which is only normal, because nobody can be an expert
in everything.
3. Dedicated business teams interact with the IT
department autonomously
Being an expert in a field (about each others know little) confers legitimacy and a sense of "belonging to a
community". Feeling entitled to act autonomously and express needs that are meant to help the business
by allowing their activity to run more efficiently, they ask the IT department for help. This often leads to

2. new IT systems appearing (being developed, or bought and deployed). Small, expert IT team form
naturally inside the IT department to service these separate IT systems, requested by different business
units.
4. "Silos" develop inside the IT department
The natural result of the development above is that IT teams, inside the IT department, become
spontaneously segregated. They are experts knowing very well their system(s) and potentially the exact
business activity that their system serves. They know their users well. All this gives these teams a
personality. Take a moment to think of your organisation and try to identify the main systems and teams
of professionals who service them. There is little to no structural, institutional need for these separate
teams to interact with each other on matters related to their core concern, the IT systems. I'll repeat this
because it's a key observation.
5. There is no structural need for the different IT teams
to interact with each other
The business teams interact structurally more on their core concerns, because the output of one team is
the input of another. In contrast, the input of an IT team comes from its business users (in the form of
requirements), from the IT infrastructure provider (in the form of computing infrastructure) and from the IT
industry at large (in the form of constraints and limitations of existing technologies and of new
technologies). Its output is the service the team and the IT system it manages provides to the business
users. Such interactions as exist are usually either "accidents of good design", ad-hoc ones or are "non-
core" (e.g. financial aspects, sourcing, contract management). Take a moment to think about this in the
precise context of your organisation. Does it apply? Moreover, it is important to stress that whatever links
there are, they are entirely due to the chance of having good solution architects, and "chance" is not a
very sound business asset to bank on; these links exist despite the natural barriers that form and in a
sense are the "exceptions to the rule".
Lack of a structural need to interact between IT teams leads to gaps in knowledge sharing. This is
compounded by the natural propensity of IT people to be introverts and less-than-stellar communicators.
6. If you think "so what ?", think again
An initial, naive reaction along the lines of "so what?" is understandable. However, nobody can ignore the
massive amount of evidence that has accumulated over decades of practising IT in various organisations,
both public and private. The facts are here for everybody to witness. Specialization does have powerful
advantages in terms of productivity. But it is inseparable of the side effect of "silo-isation", a side-effect
that has numerous drawbacks, which have been extensively explained, such as imperfect information
leading to sub-optimal or downright bad decisions, duplication of effort, knowledge loss, decreasing speed
and efficiency.
7. Keeping the baby; throwing away the bathwater
Specialization is good. The loss of communication, information, knowledge that comes with it needs to be
addressed. Duplicate efforts are better avoided, good decisions (good governance) need to be fostered
(by making sure the decision-makers are in possession of as much relevant, exact, timely information as
is available). This is the problem.

3. B. The Solution
By this point, I believe everybody has something in mind. An "information repository" or "knowledge base"
or "what-you-call-it" appears needed. But then it is important that:
1. there's only ONE (so that everybody puts information in the same place and the probability that
someone in need of information knows where to look for that information is maximal)
2. it is curated - bad information is worse than no information at all. If you don't find something, you
look for it and stand a chance of finding what you need. If you are given something that you
mistake for being what you are looking for, but instead is outdated or downright false, you stand
no chance. Therefore the "information repository" needs to come with a guarantee.
3. a lot of communication is needed - so that people volunteer fresh information for the repository,
provide the right type of information at the right level of granularity, are able to validate it once it's
been stored and can make sense and use somebody else's information.
To summarize, one solution that has been proven to work to the above problem is to build a central
knowledge-base, establishing it as "the single version of the truth about IT systems in the organization"
and enmesh it within the internal processes of the IT department. By "internal processes of the IT
department" I mostly mean the process of software development and the process of operating existing,
deployed applications in order to ensure a quality of service to the users. It is important to stress that
these processes are impacted by the arrival of a central repository. Someone has to think about how
these processes should evolve in order to:
1. support a successful knowledge base
2. take advantage of its existence.
C. Why "Enterprise Architecture" (or
"Urbanisation" for the French) ?
It's not only about building and curating a central knowledge-base. There are a number of other activities
that share the same goal: "keep the baby" - the benefits that specialization brings are essential to all
progress; but "throw away the dirty bathwater" - get rid of the nastiest side-effect of specialization, i.e. the
weakening of communication and knowledge sharing between groups of people that grow gradually apart
in what they know and how they approach various issues (because people base their opinions on prior
knowledge).
In a nutshell, we could say that the answer proposed is to create a new category of specialists,
"specialists in creating and maintaining bridges between the silos", in gathering, curating and
disseminating knowledge. This is what the English called "Enterprise Architects". The French took the
original analogy between "architects" and "IT architects" a step further. Architects build houses. Houses
next to other houses grow into towns and cities. Pretty soon, people realize that they need to give serious
thought to new problems: how to deal with providing electricity, roads, sewerage to groups of houses.
They call in a new function, a "city planner", or "architecte-urbaniste" in French. If you transpose this in
the IT realm, the analogy holds pretty well: IT applications next to IT applications grow into complex IT
systems which make new problems appear related for instance to the flow of data between them, to the
sharing of common functionalities, to the risk of duplication. This is when a new capability is called for,
that of "urbanizing" the applications into a coherent system.
I hope that goes at least a little way toward explaining what the "Enterprise Architecture" label applies to.
And maybe even makes you want to know more.