... and no one understands Enterprise Architecture.

It's now a while since I am working in the information technology sector... almost 20 years to be more specific. During these years, I experienced many paradigm changes. With these paradigm changes, I also saw how organizations tried to align existing systems and processes with new technology. But unfortunately, I often observed how many organizations just were not able to apply new technology solutions because they just had no overview of how their existing processes and systems were correlated to each other.
When I had the possibility to ask (yes, some of these organizations were my employers... please don't rub it in 😅) why there was no Enterprise Architecture in place, my question either received a clumsy answer or (even "better") was simply ignored.

In this article, I would like to briefly explain what Enterprise Architecture is and why every organization should nicely make use of it.

Definition of Enterprise Architecture

Let's see what descriptions for Enterprise Architecture we get from some known sources:

According to Gartner

Ok, after reading this, I don't think everyone understands what Enterprise Architecture is and what actions it includes. The language is abstract and confusing. Who talks that way? “Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.” Really?

According to TechTarget

Ok, TechTarget seems closer to common language, but in my opinion still too vague.

Enterprise Architecture (EA) is actually derived from business strategy and focuses on “current and future (business) objectives” or “desired business vision and outcomes”.
While I have no idea why definitions don’t speak directly about strategy, I can live with the interpretation of EA around business performance. Clear enough, I guess, but why are there so many EA project failures?

Why technological abstractions often fail

To write down an Enterprise Architecture (EA), you need more than just a week of time and enough coffee. An Enterprise Architecture consists of various different topics harmonized with each other. As long as you're a tech guy and you don't have to interface tech-, business- and executive guys, then it's all fine. But as soon as technology-, business- and e.g. accounting people need to align their processes and systems... that's where it's getting challenging.

Different and Complex EA Frameworks

To cope with this challenge, a variety of Frameworks from different groups are available. Lots and lots of frameworks all with strange names, like TOGAF, Zachman and FEAF. Some of them are so brutally complicated that just eyeballing them makes one nauseous. I have never met anyone who has fully implemented any of the frameworks. Sure, some have implemented parts here and there, but none have consistently institutionalized the use of TOGAF, Zachman or FEAF. They’re just too damn hard to live with for any period, let alone as a continuous best practice.

Governance - Who wants to be responsible?

And what about governance? An Enterprise Architecture must be owned from the top-down, not from the bottom-up. Enterprise Architects (or Business Technology Strategists) should hang with the executive team and not with the tech guys, at least not initially. Their first job is to convert; their second job is to bridge and translate. If we were RACI charting this, Enterprise Architects are responsible and executives are accountable.
Initially, technologists are consulted. If there’s any variation to this governance, Enterprise Architects will fail. Why? Because technology “mischief” is everywhere. Tech guys always believe they know best – and sometimes they do when their architectures align perfectly with the Enterprise Architects– but often they do not. The disconnect between technology and business is greater than the disconnect between business and technology.

What EA should not be

EA should not be an abstraction with weird, esoteric terms. We do this all the time: SCRUM, ITIL, Cookies, Spam, Malware, Netiquette, Microblogging, SEO, API, Caching, Virtual, Firewalls, Routers, Bluetooth, API, SaaS (PaaS & IaaS), NLP and Waterfall. EA should not be another abstraction that needs translation. Nor should EA be a remote exercise — or outsourced to vendors who know very little about the company. It should not be mysterious or discrete, and should not be disconnected from current and projected business models and processes which together comprise the overall business strategy.

What EA should be?

The first step is demystification. All of the abstract terms – even the word “architecture” – should be modified or replaced with words and phrases that everyone – especially non-technology executives – can understand. Enterprise planning or Enterprise Business- Technology Strategy might be better, or even just Business-Technology Strategy (BTS). Why? Because “Enterprise Architecture” is nothing more than an alignment exercise, alignment between what the business wants to do and how the technologists will enable it now and several years out. It’s continuous because business requirements constantly change. At the end of the day, EA is both a converter and a bridge: a converter of strategy and a bridge to technology. The middle ground is the Business-Technology Strategy.

How to do Enterprise Architecture?

EA (in some cases also "Business Technology Strategy") isn’t strategy’s first cousin, it’s the offspring. EA only makes sense when it’s derived from a coherent business strategy.
For technology companies, that is, companies that sell technology-based products and services – the role of EA is easier to define. Who doesn’t want to help technology (AKA “engineering”) – the ones who build the products and services – build the right applications with the right data on the right infrastructure?

The official EA steps include the development of four “architectures”:

• Business Architecture

• Application System Architecture

• Data Architecture

• Technology Architecture

Let's dig deeper into individual architectures...

Business Architecture

Business Architecture defines business strategy and organization, key business processes, and governance and standards. In other words, it's a description of how the company makes money. A description of the processes, products and services that make money. A description of how the company makes money today and how it expects to make money in the next 3-5 years. A description of the competitive marketplace where the company makes money (There are tools to help do this).

Application System Architecture

Application System Architecture provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes. It is basically describing the software applications that enable the processes, products and services that make money. The software applications that will enable the company to make money in the next 3-5 years.

Data Architecture

Data Architecture documents the structure of logical and physical data assets and any related data management resources. So it's about describing the kinds of data the company needs to fuel the software applications that enable the processes, products and services that make money. The data will enable the company to make money in the next 3-5 years.

Technology Architecture

Technology Architecture describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications. So in other words... The technology infrastructure and technology delivery that uses the data the company needs to fuel the software applications that enable and optimize the processes, products and services that make money. The infrastructure that will enable the company to make money today and in the next 3-5 years.

Is Enterprise Architecture worth it?

Investing in a proper Enterprise Architecture is absolutely worth it if it's reduced to concrete business value. The goal of alignment has been with us for decades. It’s still here. It will always be here. BTS is just and all about alignment. Over the years EA methods, tools and frameworks were developed and foisted upon companies, strategists and technologists who barely understood them. It’s now time to strip EA down to its most basic properties –* the alignment of business strategy with operational and strategic technology*. We can continue to complicate all this, or just admit we’re seeking business-technology alignment through the development of a dynamic business-technology strategy.

My 2cts...

I personally had the pleasure to start creating an Enterprise Architecture for an Energy Company in Switzerland. We used Enterprise Architect from SparxSystems to draw what we could from our internal Business Processes, Systems and Goals. It was pretty cool to have a Map that shows all dependencies between Systems, Processes and Stakeholders. We used the Zachman- and TOGAF Frameworks to design our Enterprise Architecture and started in tiny bits which we could assemble into a bigger picture at any time. It was not complicated at all. The secret was simply in taking just the things out from the Zachman and TOGAF Frameworks we really needed and ensuring we could interface them together. So yes, it was not only useful and fun to put all the required information and connections together, but it enabled us also to constantly be aware of the impact management decisions had on our area of responsibility.