Enterprise Architecture: What is it and why do we need it?

This article is written by Thom Kearney, a Free Agent in the government of Canada.

This article is intended as a brief introduction to Enterprise Architecture (EA). It is filled with opinions and intended for folks that don't know much about the subject. If you are an Enterprise Architect please forgive my oversimplifications, there are 3,686 words that did not make it into this article.

I came to the government later in life, after careers in advertising, teaching and building web 2.0 sites for tech companies. One of my early government projects was to help some really smart people tell a complicated story about their vision for Enterprise Architecture — EA for short — in Canada. To do this I had to first try and understand the thing.

This is where you would usually find a definition of EA. But, as the wikipedia page also notes, there is no official definition. So I turned to my regular sources.

First I dug into my project archives, and came across the BIAT +4 framework that we used to try to explain it all very simply (see the diagram).

The idea was that these eight perspectives provided a convenient structure for organizing the artefacts of government. This was a very holistic vision that could include everything the government did and was, from network details to organization charts to public policy.

The promise of a shared language

Thinking it would be great if we could share knowledge about all these things across government, part of my job evolved into building a library for these artefacts. We decided we would try out this new Wiki technology. That in turn evolved into gcpedia — the wiki for Canada’s government, but that is a story for another time.

The promise of EA was that we would have a shared language between those that build IT systems and the public service program owners. The bigger promise was that if we did it right, we would be able to distribute government services across jurisdictions and sectors. The even bigger promise was that if we could define everything, we could model the entire system.

EA is a world of definitions and standards, defined relationships, design principles and tools for change — it is used to describe the enterprise as a system and in this way it shapes our organizational reality. It is important because like any architecture it can have a dramatic, yet barely perceivable impact on our behaviour.

EA is a methodology, a conceptual framework, and a common language

While I was reflecting on the meaning of EA it occurred to me that BIAT +4 and everything else I thought I knew was more than a decade old, so I thought I would check in with my other main source of knowledge, Twitter, and see what was new with this tweet:

"Here is something I am grappling with this morning.
How to describe Enterprise Architecture in one sentence?"

Neapolitan EA

Much to my delight I received dozens of thoughtful replies and several subthreads emerged. Looking at the threads I think I can discern four layers of meaning:

The Technical

Many people get into EA from the Information Technology and Management side of things. When you try to build things that will work with other things it becomes pretty obvious that you need some common language. Without architectural standards our computers couldn’t talk to each other and you wouldn’t be reading this article.

Mandy Hoyt pointed out one of the challenges when she observed that:

"A framework that lays out the methods, models and tools that are needed to build an integrated technology solution. It helps create a common lexicon and understanding for IT/business. .. And by the time you agree on it, it’s time to create a new one cause the tech has changed ;)"

The Conceptual

Other tweets used story and metaphor to communicate the idea that EA is a conceptual framework. Jacky Tweedie received a fair bit of support for their idea that if the enterprise is a shopping mall, then EA describes the common infrastructure like the plumbing/wiring and HVAC which must all follow standards, but the stores and contents can be unique.

EA can provide a shared language for providing better service to citizens and to communicate with the engineers building the service infrastructure. In this layer “Good EA actually has very little to do with technology,” Stephen K. Anthony wrote.

The Sceptical

Some tweets actually made me laugh out loud as they dismissed the idea or reflected some negative experience, for example Marcus Wigan reminded me of my conversations with architects from years ago when he replied:

"Depends on how many conditional and dependent clauses you will permit in a single sentence?" — Marcus Wigan

There were a few other tweets in this vein that I will get to later.

The official

I was happy to see government thinking in terms of enterprise and alignment and outcomes when Sara Minaeian shared the new Government of Canada definition:

"Enterprise Architecture: Conceptual blueprint that defines the structure and operation of an organization considering and aligning business, information, data, application, technology, security and privacy domains to support strategic outcomes source."

In summary, then, EA is a methodology, a conceptual framework, and a common language. It describes structure across domains, standards and relationships. It includes methods, models and tools and is constantly changing. It is used to build integrated technology solutions, align domains, make things work better, bridge gaps, plan transformation, and determine how an organization can best achieve its goals. Not everyone has had a positive experience.

Why is EA important?

Architecture affects how we work

"[EA is] the hopefully forgettable technological foundations that allow you to do your job. (They are forgettable because they just work and no one has to think about them ever again(except the people working on them of course))" — Jillian LeBlanc

In this way, EA is not so different from architecture in general. Unless you are involved in designing or building you may not even notice it. You just live inside of it, your behaviour invisibly shaped by the space and systems you interact with.

As Alexander Beiner points out in his article Lost Ways of Knowing, “... constructing maps of reality, and convincing others that these maps show the world how it truly is” can be a problem because “Often these maps become realities in themselves, and trap us in rigid, narrow ways of perceiving that keep us lost.”

Reflecting on all of this, I had a thought that maybe the real value of EA lies in the forum for dialogue it provides. Because “common understanding” is not very common, what we call governance really needs to enable dialogue if we hope for any kind of common understanding to emerge

If we want to be self-aware enough to deal with enterprise issues, I think it is important that we be aware of the architecture we live in. In order to consider multiple perspectives, we need to understand the one we are in. Certainly, the big platforms know how to create architectures that maximize shareholder value — Surveillance Capitalism anyone? Maybe it's time public servants put some of that understanding to work for the public good?

Common language?

This mini deep dive into EA reminded me that the field of enterprise architecture is filled with rabbit holes. Back in 2007 one of those rabbit holes led me to creating this image to try and sell the concept.

Perhaps this picture, more than anything else, captures the nature of EA. Two birds of a feather that think they’re talking about the same things, but have completely different visions. Otis and Saul are my two dogs of infinite wisdom.

What is wrong with EA?

The fact that I observed a sceptical layer in my earlier analysis implies that something is wrong with EA, that maybe the simple idea of having a common language is not so simple. Taking another look at the comments I see sometimes EA becomes a heavy weight and can stifle innovation.

Stifles innovation

EA demands that everyone in the enterprise adopts a common language, and we know that anything common, usually isn’t so we need a mechanism to come to agreement. We often call this mechanism governance, and usually implement it via some form of committee structure that reviews and approves or rejects proposals. This seems reasonable until you consider these responses from people I know and respect:

For instance, the most popular tweet in the thread came from Sean Boots who replied that Enterprise Architecture is:

""No longer used by tech companies"? *ducks and runs away*"

While Alistair Croll had this to say:

"IT designed for predictability and scale over adaptability and opportunism."

And Tracey Lauriault reminded me of scope with her short answer:

"The thing of all things!"

I love these answers because they point to how institutions and individuals deep in the weeds can sometimes lose sight of the ultimate goal in their quest for architectural perfection. For those who are trying to innovate and experiment with new approaches EA governance can seem like little more than a barrier to progress. Governance sometimes becomes so layered and obtuse that agile innovation is nearly impossible.

Maybe what we need is a distributed governance mechanism, put something on the blockchain eh?

Becomes overweight

Sometimes architects spend all their time documenting and not enough doing. There are those that would argue that trying to document all the details in a complex system is a fool's errand.

Others chase the Newtonian dream of cause and effect and cry out earnestly that the devil is in the details and if only we can understand ALL THE THINGS, they obsessively drill down trying to apply engineering methodology to what are fundamentally human problems.

This can lead to what a friend of mine calls barnacleization — where an EA framework becomes so detailed and complex that it simply collapses of its own weight.

I think that like physics, there is a point where EA loses its ability to clarify and misleads us into thinking we can predict human behaviour.

Creates a false sense of reality

For some, EA is a mindset and world view. I am ok with it being a mindset, albeit one with a bit of an engineering bent. But I think that sometimes well meaning individuals internalize too much dogma associated with a particular scheme, when this happens it can lead to polarization — something we have quite enough of in the world today, thank you very much!

What we need to remember is that any framework or blueprint or methodology is only one way to see the world. Mindsets are all the rage these days but there is no absolute view — there are only many views.

The world turns

Back to twitter for a moment, and as the world spun and daylight returned to Australia, I received what is probably my favorite answer, from Pia Andrews:

"I think you'd need two sentences :)

1) Done well, EA provides a strategic, clear, commonly understood & commonly applied approach to technology & system design.

2) Done badly, EA provides an incomprehensible & unaccountable gatekeeper between business & tech that hurts the org."

The architecture is not as important as the conversation

There are many maps of reality and all of them are true from some perspective.

I feel the appeal of a system that explains everything and lets us understand and modify complex systems, yet I am also reminded of the need for humility and understanding the people that work in those systems. BIAT+2 completely forgets the user. Oh, and here is a rabbit hole for you — what if the systems we model, aren’t systems at all but just collections of complex responsive processes?

Reflecting on all of this, I had a thought that maybe the real value of EA lies in the forum for dialogue it provides. Because “common understanding” is not very common, what we call governance really needs to enable dialogue if we hope for any kind of common understanding to emerge. — Thom Kearney

(Picture credit: Unsplash)