There Ain’t No Architecture in EA

Ondrej Galik, vrijdag 10 juni 2011

I am more and more convinced about the following:

  1. Enterprise Architecture is not about architecture. Hardly at all.
  2. Enterprise Architects do not architect, let alone the enterprise.

Putting this up front, this post is likely to be a bit longer one as I can foresee as it deserves a bit of reasoning behind the statements. But feel free to leave now as I made my point: ) Nevertheless, I hope you won’t get bored.

Let’s take it word by word:

The “Enterprise”

In short: Little understanding, screwed by major misuse, too huge in scope, impossible to grasp and cover the whole with skills

When I was asked by a colleague of mine what is it “Enterprise”, I thought for a while there’s no more stupid question. Actually, there’s no better question to start with. I can be quite honest and say that I am pretty clear in how I understand the term, and it is exactly within the lines as Tom Graves puts it:

It’s the social construct beyond the organisation, that additionally includes competitors, regulators, wider community, government, prospects, anti-clients etc.

I really wish this was a common understanding of what enterprise is. But I am quite sure it is not. Let alone when put together with architecture. Myriad of discussions, tweets, job offers and title holders under the EA title proves the opposite. It’s really mostly just IT, at best. Kind of the whole IT, across the enterprise, right, but still just IT. A little bit of business understanding, but mostly in terms of business requirements and far away from understanding mission, values, value chain, business model, no notion of people, organization, processes, culture, social aspects, motivation and group dynamics, etc.

It’s a cruel reality that the above understanding of “Enterprise” is still marginal. Hopefully on the rise, but still mostly with a flavour of being “alternative”, “high-flying”, “ivory-towerish” kind of thing. The discrepancy between whole-enterprise focus and fancy title for senior IT architects (and I am not so sure about that senior part) is too big and I don’t see anybody from “the other camp” giving this fancy title up. And frankly, why should they, when it’s majority?

Additionally, there’s so much in the whole enterprise to consider, that the complexity is beyond capabilities of any single person to grasp and it takes so many varying skills to understand and tackle. Because for the whole, it’s about understanding business, information, technology, behavior, cognitive science basically in its entirety, sociology, group dynamics, social psychology, game theory, politics, management and leadership, motivation, analytics, number crunching, diplomacy, trends, competitors, regulations and so on and so on. It’s basically about understanding the world, the universe and everything. The scope is just too huge. So for every individual – I strongly believe - there is only a certain limited focus of excellence, based on experience and skills.

The “Architecture”

In short: No common definition & understanding, no business term, hardly understood outside IT at all, in the context of enterprise hardly any architecture in sight, missing so many aspects supposed to be in the scope of EA

Second challenge – architecture. Not that much unlike the “Enterprise”. Here are just few of definitions I found:

The art or practice of designing and building structures.

[Merriam-Webster Dictionary]

Those properties of a mission, its solution and their environment that are necessary and sufficient for a solution to be fit for purpose for its mission in that environment.

[Leonard Fehskens, The Open Group]

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

[Grady Booch]

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.


And there’s of course much more. But already these examples show significant difference. While the first one, widely understood, makes architecture and design equal and additional includes also construction, the others do not. The second one sees architecture from the perspective of its mission and then architecture defines those attributes that frame all solutions to fit the original mission. So there is one architecture for the mission, but potentially many solutions to that architecture. Also sound definition. The third one sees architecture through the perspective of change, where architecture is given by those decisions that are difficult to change. As well interesting. And the last one - perhaps the most prominent - sees architecture as structure of components of the whole. Have you got a “better” one? It does not matter. What matters is that it’s different. They are all quite different. Add to it a touch of architecture-is-a-noun versus -verb polemic on top and we are good to confuse everybody starting with ourselves.

Now pick your favorite definition, get all your colleagues on your side, go and explain this to executives or to business folks. Which we in fact tend to do quite often, right? If you say no, then why do you call yourself an architect? Simply, architecture is not a business term. We don’t understand it, they don’t understand it. Bottom line.

And no to me it’s not only about expressing architecture in the language of the audience. It perhaps is not in me to see everything as architecture and call everything architecture. I am pretty fine with talking about business capabilities, value chains, costs & benefits, organization structure, information, human behavior, psychology, knowledge sharing, management, governance, coordination, mediation without pushing everything to be sort-of-architecture.

When it comes to topics around target architecture, that’s a whole topicon it’s own to me.

The “Architect”

In short: You are not. Cannot be any shorter. It would be like being an architect of life.

Leaving the EA discipline aside, coming to the role (the verb) now. Do you really believe that you are actually architecting something???

I tried to collect in the past what most EAs actually do and how they are perceived. The list is here presents those findings in form of a role/perception rather than activities (simply because some roles are difficult to be express as a concrete activity and also the list of activities would be in fact much longer and bit less differentiating). I do tend to exaggerate here a bit and stereotype those perceptions. The list is not exhaustive , but good enough to start a discussion and I do invite you to come up with more. Answer for yourself how much are these about architecting.

Strategists– Assist in strategy creation across the enterprise and its breakdown to tactics overall and in various domains. Usually do not actively create content (at least not in general), but ensure that strategy and tactical statements are sound, aligned, not overlapping and without gaps.

Consultants- Provide analytical and structured thinking, assessment services, have broad know-how and lot of experience, should be un-biased, often assist in “wicked” problems.

Mediators- Help in bringing different interests, cultures within the company and help various parties to communicate and arrive at a consensus. Assist in managing conflicts, do counseling.

Governance Squad- Define, establish and operate mechanisms through which architecture is defined (in terms of target or direction) and controlled in the enterprise. This covers processes, roles, responsibilities, advisory and decision bodies for decision-making, transparency of consequences, risks and dependencies of architectural changes and managed and intentional deviations from targets/direction in a continuous manner.

Leaders– Strong personalities that can sell vision to crowds, motivate and get high commitment by strong communication.

Documentarists– Document and model current state of matters (applications, integration points, infrastructure, services, capabilities, mappings, people…)

Wisemen– Trusted experts, usually long in the company, with informal authority and respect, knowing a lot about the company and its past with good relationships. Often approached regardless hierarchy for advice or when things seem to go wrong.

Academics- Theoreticians with strong theoretical background, creating concepts, often with “teaching” attitude, assessing and investigating new ideas.

Directors– Have an actual authority do decide in important matters (very often in practice only within IT domain).

Tools Providers- Folks with always some framework, model, tool, repository or a structure at hand to help others understand and solve their problems. Difference to “Consultants” is that they do not use these internally, but market and give the tools to others.

Requirements Engineers– Help in transforming ideas into clear requirements with strong focus on differentiating what are functional and non-functional requirements, wishes and what are attributes of an envisioned solution, usually with the goal of alignment on the company level.

Risk Watchdogs– Mostly architecture quality assurance with strong focus on identification of potential risks, assessment of impacts and timely communication to involved parties (management, projects, business…).

Environment Watch- Keep an eye on what the competition is doing, how the environment changes, watching current trends, focus on short-term future (1-2 years).

Visionaries - Predict long-term future, potential evolution, communicate opportunities soon enough in order
not to miss a train (e.g. cloud computing, PaaS, Gamification…). To most people in the company this is when it’s really ivory-tower kind of thing.

Law-makers– (aka Government) – Write “laws” – policies, directives, principles, rules – and get their approval.

Police– Actively identify breaking of defined policies, rules, etc., investigate in detail identified cases.

Judges– Judge concrete cases, however, do not actively seek breaking of rules. Have the right to set fines (e.g. in the form of an enterprise debt value, cutting bonuses etc).

Auditors- Regularly or occasionally check if processes are being followed and all needed artifacts are available and maintained. This is a post-mortem type of activity.

Cost-Benefit Analysts– Calculate/estimate costs & benefits of issues/opportunities at hand.

Solution Architects- Responsible for overall architecture of a solution to a particular problem, usually delegate work further to designers, serve as a single-point-of-contact for the solution. Work closely with business analysts on identifying the boundaries in which the solution must exist and work closely with existing application owners to assess potential solutions (money, time and risk wise).

Artists- Visualize information in different forms to different audiences, strive for a form that passes on the key message, enables proper interpretation and all that in an appealing form.

Standards Managers– Manage standardization process and maintain corporate standards. This can span from driving a process only to be the main content provider.

“Sacred cows”– “Not to be touched” (laid out) - often as a sign of unclear expectations of the management towards EA, but a certain fear of what would happen if EA wasn’t there.

Magicians– In fact, often expected to achieve a lot with very little or no real support, buy-in, authority and investment.

Hmm, I feel like I am missing something there. Right! Architecture! But WHAT do we actually architect???

I invite all of you to share your view. If I get to it, I’ll try to make a survey out of it to find out what we are really doing and in which scope. In the meanwhile, I welcome any suggestions to the topic.

Published on : ondrejgalik/there-aint-no-architecture-in-ea/


Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 7 Maart 2012 op 16.21

Geschreven door Paul L. Jansen op 27-06-2011 12:17

Best we get back to the 'original' then, as the very term 'architecture' is not unclear by itself, but made unclear in the realm of the enterprise, organization and virtual world(s). In fact, Vitruvius wrote some interesting stuff about the subject, 2000 years ago! I had the opportunity to interview him recently ( and this is one of the things he said on the question 'what is architecture?': "Here the men and the boys are separated. While boys proclaim the building, the technology, the construction itself or its building instruction even as the architecture, the men know that not the building itself, but its use as a means to the design of the space, which is aimed at evoking human experience, emotions even, is the real subject. Also in the virtual realm the construction is not the architecture, but the experience of the (virtual) space reveals the architects hand."



© 2021   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden