Internewscast
Image default
Home » Why No One Understands Enterprise Architecture & Why Technology Abstractions Always Fail
Business

Why No One Understands Enterprise Architecture & Why Technology Abstractions Always Fail

Abstract and complex technology solutions fail.  Enterprise Architecture is all that and more. 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.  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 Business-Technology Strategy.

What Is It?

According to Gartner, Enterprise Architecture (EA) is:  

“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.  EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions.”

Perhaps like you, I have no idea what any of that means.  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?

OK, maybe someone else – like TechTarget – can clarify EA:

“An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of organizations.  The intent of enterprise architecture is to determine how an organization can effectively achieve its current and future objectives.  Enterprise architecture involves the practice of analyzing, planning, designing and eventual implementing of analysis on an enterprise.”

A little better, but still too vague.  

If I have this right, EA (at least everyone agrees on the acronym) is 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 to 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?  (WhiteCloudSoftware suggests that 66% of all EA initiatives  fail.)    

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 definitely not be disconnected from current and projected business models and processes which together comprise the overall business strategy.        

So What Should EA 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 (Or BTS)

EA – or should I say “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 – defines business strategy and organization, key business processes, and governance and standards.

Application systems architecture – provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes.

Data architecture – documents the structure of logical and physical data assets and any related data management resources.

Technology architecture – describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications.”

Let’s translate all this:

“Business architecture – defines business strategy and organization, key business processes, and governance and standards:

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 systems architecture – provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes:

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.  (There are tools for this too.)

Data architecture – documents the structure of logical and physical data assets and any related data management resources:

The kinds of data the company needs to fuel the software applications that enable the processes, products and services that make money.  The data that will enable the company to make money in the next 3-5 years.  (There are tools for this.)

Technology architecture – describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications:”

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.  (There are tools for this.)

One test is how understandable all this is to non-technology executives.  We can go with “Business Architecture,” “Application Systems Architecture,” “Data Architecture,” and “Technology Architecture,” or we can simply go with strategy, applications, data and delivery.  (I am constantly perplexed by IT’s insistence that everyone learn their language even though IT serves the business.)   

Of course there are “frameworks” for all this.  (There are always frameworks.)  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 successfully implemented any of the frameworks.  Sure, some have implemented parts here and there, but none have actually consistently institutionalized the use of TOGAF, Zachman or FEAF.  They’re just too damn hard to live with for any period of time, let alone as a continuous best practice.   

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

Is It Worth It?  

BTS 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. EA was a nice idea, but it’s not a practical solution. BTS will yield better results.

Source:

Related posts

Dow futures sink 500 points, adding to the market’s 3-week losing streak

InterNewsCast

Stock futures are flat as traders monitor earnings, stimulus talks

InterNewsCast

House Democrats say Facebook, Amazon, Alphabet, Apple enjoy ‘monopoly power,’ recommend big changes

InterNewsCast

Leave a Comment