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.
