The Enterprise Architecture (EA) discipline is at a crossroads. Originally born from a need to understand the burgeoning cost and complexity of IT systems, it has changed substantially in execution and perception over its brief 30+ year history. Further complicating this evolution is the astonishing developments over that time in the prevalence and capabilities of technology adopted by organisations.
This has resulted in an increasing rate of change, with which those responsible for a company’s future must continually contend. As a result, there is an increase in the potential for EA-based approaches to align business and technology strategies, cut through the hype-driven promotion by vendors, and enabling a holistic view to be formed of the enterprise’s operations – including gaps and opportunities.
To meet the changing expectation of businesses, the EA discipline must also evolve. In late 2017, EA Principals and the Enterprise Architecture Professional Journal conducted a survey of EA practitioners. The intent was to establish a current state view of the practice, problems and potential future of the EA discipline, in order to better understand how the discipline is changing, and how practitioners see its relevance now and in the future.
In this Special Edition of the EAPJ Journal, we look at the results of the survey, and analyse what this might mean for the EA discipline. Head over to the Journal section of the website to view or download your copy.
Darryl and Steven — congratulations on a timely and useful survey, and on the publication of the results.
To begin with, I define an enterprise’s architecture as the structure of its data + the structure of its processes + the interactions between the two, in terms of the enterprise’s goals and objectives.
I have identified three EA killers — conflating EA with a) IT, b) transformation (including solutions), and c) the enterprise’s strategy. The Enterprise Architect should have architectural oversight authority over all of those (with veto power), but should be directly responsible for none of them.
For more on my EA views and prescriptions, see my own LinkedIn Pulse articles, available via my LinkedIn profile — “What Is Enterprise Architecture”, “How to Start an Enterprise Architecture Practice”, and “How to Create Your Enterprise Data Schema”.
I disagree with lumping the Zachman Framework in with other “Frameworks”. The others are mainly prescriptive and “methodology” oriented. The ZF is descriptive and “methodology” agnostic. I have suggested to John A. Zachman that his famous Framework is, in fact, an EA meta-model, and he agrees. I think of it as a meta-ontology as well. It is also a powerful checklist to ensure that, as an EA, you’ve covered all the bases.
“…The Zachman Framework…has been superseded by TOGAF in most industries.” As you can imagine, I see this as mixing apples and oranges. The ZF is foundational; TOGAF (like so many other “frameworks” and “methodologies”) is, IMHO, mainly a prescription for getting acceptable results out of unacceptable practitioners.
The characterization of ArchiMate by respondents as a “framework” is a good illustration of the current state of confusion between the essence of EA and tools that may be used in its practice. Tools and artifacts are _not_ EA; they are just assistants used in its practice. The essence of EA is (surprise!) the enterprise’s architecture.
The distribution of report positioning is sadly telling. Because an enterprise’s architecture crosses every organizational boundary, both vertically and horizontally, IMHO the EA _must_ report to the CEO; any other arrangement dooms EA to second-class status, distractions, conflicts of interest, and ultimately to failure. And yet only 11% of self-reported EAs report to the CEO. The 65% who report to an IT-related position are inescapably sucked into my #1 EA killer.
“… IT Services as their main industry…highlights a historical prevalence of EA being offered as a consulting service” — the latter may be alarming, depending on the actual consulting roles. As an EA consultant myself, I see my role as “working myself out of a job”; EA is too vital and central to the enterprise’s success to outsource its practice.
“Solution Architecture, Information Architecture and Application Architecture occupied nearly 70% of all responses” — that’s not surprising, because the skills required for effective EA (especially data and process structure analysis and design) are almost exclusively taught under the aegis of IT. But, IMHO, EA must escape the chains of IT to achieve its potential (which I view as enormous). An enterprise’s architecture encompasses the breadth and height of the enterprise, in every nook and cranny — not just the computerized parts (although in a modern enterprise those parts play a major and increasing role).
The EA success metrics and EA value themes identified by respondents are, IMHO, a sad commentary on the conflation of EA with IT, strategy, and transformation. For comparison, what are the metrics for the success of the CFO function? They’re hard to come by, because, like EA, Finance is foundational; it’s part of the enterprise’s “plumbing”, and like plumbing, its task is to ensure and maintain the effective flow of money throughout the enterprise. EA’s task is even larger — to achieve, document, maintain, enhance, educate about, and consult about the very architectural foundation of the enterprise.
Thank you for your thoughtful and informative posting, Stephen. It is clear to me that you have a very idealistic view of what EA is, are of the Zachman Framework school of thought, and are therefore on rather shaky ground in terms of what EA must become. The way you have described EA in your posting puts it in the rather “Ivory Tower” and “Bureaucratic” stances that have actually hurt EA so much in the past 20 years — sorry, but that is the way I see it. EA must be linked to such disruptive drivers and quests as Digital Transformation and there is no shame with being linked to what must be an evolving CIO/IT role in support of enterprise strategies.
The biggest concern of most of the organizations at which I do EA training and consulting is how to have EA perceived as essential value added by business. With this in mind, I try to help organizations with their communication strategies, explaining that EA is about helping to design the way to fill modeled gaps en route to a vision of new or enhanced business capability. This must be done via increasing maturity of workflows between the data and processes you refer to, but in context of transformation efforts at the strategic, segment, and incremental capability levels — across the whole architecture landscape, including over time.
I simply do not see your vision of EA reporting directly to a CEO as even remotely possible and I think the practice must succeed, at least in the next few years while it matures, under the CIO, if that is where it is nested.
Again, thanks for your ideas on this topic — they are important, especially as there really is a resurgence of interest in EA, but more along the lines of TOGAF than Zachman based on my intense experience in the field.
IMHO? There’s nothing humble about your views on EA or on yourself. Let it lie, the EA as the Architect of the Enterprise never landed (hint – it’s in the stats). The best you can hope for is IT Architect on behalf of the Enterprise
Steven — “It is clear to me that you have a very idealistic view of what EA is” — no, I have a very realistic view, because, IMHO, any other approach a) isn’t EA and b) will fail to achieve EA’s enormous potential.
‘The way you have described EA in your posting puts it in the rather “Ivory Tower” and “Bureaucratic” stances that have actually hurt EA so much in the past 20 years’ — no, my definition and recommendations put EA into every nook and cranny of the enterprise, top to bottom and side to side, every day. That’s the polar opposite of “ivory tower”. And the results of my prescription are a documented, normalized, optimized, and defended enterprise architecture; that’s the polar opposite of “bureaucratic”.
What has hurt EA so much are the 3 EA killers I described. When you say “EA must be linked to such disruptive drivers and quests as Digital Transformation”, you are succumbing to the #1 (and most common) EA killer, namely conflating it with IT.
“The biggest concern of most of the organizations at which I do EA training and consulting is how to have EA perceived as essential value added by business.” EA’s job is not to “add value to business”; it is to provide, maintain, and enhance a robust and flexible architecture on which strategists and solution architects can devise transformations and solutions that add such value. Without such an architectural base, those transformations and solutions (and even strategies) are what are on the “shaky ground” you mentioned; they are built on sand.
“This must be done via increasing maturity of workflows between the data and processes you refer to” — workflows are not “between” data and processes; they are the processes themselves and the data they create, transform, and consume. It is the structure of those data and processes that is the proper concern of EA, not the details or the outcomes. The tendency over time is for special interests to attempt to denormalize those structures to serve their parochial interests. It is EA’s task to defend the enterprise’s architecture from those depradations, to consult with stakeholders about the architectural aspects of what they do, and to educate the entire enterprise, from the Board and CEO down through the janitors, about the critical role the enterprise’s architecture plays in its ability to achieve its goals and objectives. (Note that IT is one of those stakeholders.)
“I simply do not see your vision of EA reporting directly to a CEO as even remotely possible” — and yet it has been done, very successfully. I have done multiple EA and IT audits of major enterprises, reporting directly to the CEO, and have helped them establish the kind of EA practice I recommend — also reporting to the CEO. The result is a robust and agile enterprise, with a clear vision by all stakeholders of how to achieve its goals.
“I think the practice must succeed, at least in the next few years while it matures, under the CIO” — that dooms EA to failure, because it’s really just a fancy name for IT and just fades out for lack of an identity. That also means that IT calls the shots regarding the enterprise’s architecture, and we’ve all seen the woeful results of that — high project failure rates, blown budgets and schedules, and massive bug and enhancement backlogs because the software is too brittle to touch without shattering.
Proper EA, as I define it, can actually help the CEO clean up the usual IT mess, because it imposes discipline on the IT chaos and exposes the dysfunction in IT. It shines a glaring spotlight on any “misalignment” between IT and the rest of the business (a term I regard as a euphemism for rampant malpractice, like “technical debt”).
“…more along the lines of TOGAF than Zachman” — yes, because of the massive conflation of EA with IT, which dooms EA to irrelevance. Unfortunately your approach appears to contribute to that problem.
Darryl and Steven,
thank you for your excellent report. I feel the same way, I think EA is at a crossroad and needs to be renamed or at least rebranded.
In your report you state the question ‘Where will the drive for change come from’? – I think the only answer is from the EA community. Other Disciplines like Business Analysis founded the IIBA, created the BABOK, provide certification programs. The businessarchitectureguild created their BIZBOK and so on.
What I do not understand – why is this not happening in EA? Where is the EABOK? If I would like to participate in creating one – what is the right place to go? The Association of Enterprise Architects? Browsing through their web pages I did not find much activity.
So, compared with communities of other disciplines, beeing a passionate business architect / enterprise architect with 10+ years of experience feels a bit lonely.
Any hints where to go to participate in creating an EABOK?
Regards
Wolfgang
Thanks for your comment Wolfgang.
This is very much the question that concerns me. There have been prior, and ongoing, attempts to establish both the community, and the central body of knowledge. IASA have an ITABoK, which theoretically covers Enterprise Architecture, and I’m sure they would welcome input. The Open Group and the AEA have forums and groups where people can contribute also. Beyond that, there are a multitude of smaller organisations and individuals that have attempted to do the same thing.
As a discipline, we seem to be unable to coordinate ourselves. Perhaps this is because of the dominant personality type or mindset that pervades the discipline, or perhaps this is just the way professions form, through conflict, divisions and finally some sort of dominance of a particular view or group. This is not something I’ve studied, so I’m unsure how to frame it.
Perhaps as we continue the conversation, something will become clear. Regardless of how we move forward, I would welcome your input.
Regards,
Darryl.