The Decline of the Enterprise Architect
Happy reader question Monday, everybody! Unlike last week (exigent circumstances) and the week before (US holiday), I can actually bring you one on Monday. I’m trying hard not to pull a muscle patting myself on the back.
Anyway, today’s reader question has to do with the enterprise architect position. Specifically, what do I think of it?
It’d be great to hear your thoughts on [the enterprise architect], I’m sure there’s more than an article’s worth on that subject.
Simple enough. So let’s talk enterprise architect.
Prior Art on Enterprise Architects and Regular Architects
I have, in fact, talked about the architect position before. It’s hard not to when you’ve blogged for as long as I have and as much as I have. The architect role is almost as ubiquitous as the software developer role.
I once talked about the architect role as a pension plan for developers. The pyramid shaped corporation creates a stigma that staying “just” a programmer means failure in a career development context. So even as organizations (mercifully) move away from the “software as construction” metaphor, the concept of architect persists. It persists because it gives companies an organizationally meaningless way to let someone be “more” than “just a developer.”
I’ve also made posts about the needless division between reasoning about software at a holistic versus granular level and about moving beyond this distinction and the construction metaphor. These probably weren’t quite as provocative, and they didn’t dive into the toxic role of the pyramid shaped corporation in knowledge work.
But it appears I’ve never specifically talked about the enterprise architect. Well, let’s do that now.
The Impressive Enterprise Architect
What is an enterprise architect, anyway? Well, presumably, it’s someone who trades in enterprise architecture, which is like architecture, but more enterprise-y. Let’s ask wikiepdia.
Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”
Wow. Pasting that into the WYSIWYG made my Flesch Ease of Reading score plummet by 20% as I’m typing this. That alone probably makes it enterprise-y. Plus, it plugs in “utilize” as a synonym for “use,” so you know it’s official.
If we unpack — eck, who am I kidding? There’s no unpacking that rhetorical peacock. Enterprise architecture is, truly, using a comprehensive approach to practice conducting analysis, design, planning, and implementation to develop and execute architectural patterns and practices that guide organizations through changes related to business, information, process, and technology utilizing various aspects of the enterprise to identify, motivate, and achieve said changes.”
Crap, there goes another 15% off of my readability. Now only people with tattoos of Gantt charts can read this post.
So what is enterprise architecture, and what, then, does the enterprise architect do? Well, whatever else they do, they apparently seek to make sure no one ever asks them what they do again.
Demystifying the Enterprise Architect Role
In case you hadn’t figured it out, I’m having a bit of fun and being a little fatuous. But still, that meaningless business-ese vomit is the top entry when you google “enterprise architecture.” Next up is Gartner’s definition, which starts out by saying that it “is a discipline for proactively and holistically leading enterprise responses…” But that’s all the further you’ll get before your eyes cross from the pungent smell of what the writers of these definitions would refer to as “feces originating from a bovine male.”
Man, it’s a lot easier to figure out what software developers or CIOs do from the internet. So let’s go ahead and give up on internet wisdom for defining the responsibilities of the enterprise architect. I’ll, instead, relay what I’ve seen anecdotally when I’ve consulted with enterprises.
It’s easy to understand the role of software developers in the enterprise. They take specs and crank code. When they do that successfully for enough years, building up technical, domain, and systems knowledge, they get promoted. Eventually they get the “enterprise architect” designation. Usually, this occurs when their intricate knowledge of the organization’s systems and the way they work together starts to outpace their code-writing contributions.
In other words, people that can crank out code are easy to come by. Someone familiar with why line of business app X has an elaborate event sourcing system for integrating with both the CRM and the accounting package is not easy to come by. This person becomes an enterprise architect and spends a lot of times in meetings about orchestrating APIs and such.
Wherefore Art Thou, Enterprise Architect?
Let’s get back to a world where things make sense. What are these folks really doing? Well, it varies at each organization. In fact, it varies so much that I’ll offer a very faint defense of the self-important definitions I’ve shared. To cover everyone with that title, they’d need to go with something sufficiently vague, like “enterprise architecture is the stuff that IT people with a lot of seniority come up with to help other IT people.” But that sounds both stupid and unimpressive, so they just say “utilize,” proactive” and “holistic” until you go away.
So what you really have in these organizations are software developers who no longer develop software. Rather, they “supervise” in sort of a Tom Sawyer sense of the word. Don’t get me wrong — their insight is valuable. But they hover somewhere in the murky world among business analysts, software developers, and project managers, attending lots of meetings, waxing poetic about best practices, and recognizing that you can never have too many event buses.
In practice, their role becomes to persuade dev teams to keep in mind where they fit in in the larger puzzle. No, you can’t switch to using JSON because it’s cool. Everyone else in the org is using SOAP. Remember to use the common logging framework. Let’s keep that test coverage up. Given their many years of experience, both with software and with their organizations, they tend to have more credibility than most when engaging in these persuasion activities. They’re also in a better position to lobby for the right things, since they know where the bodies are buried.
So What Do I Think of the Enterprise Architect?
I’ve said it before in other posts, and I’ll say it again here. No matter their place in a lumbering bureaucracy or how many eye-rolls they may inspire among developers, these people are smart, competent, and valuable to their organizations. So my opinions and criticisms have nothing to do with the humans involved.
That said, I think this role is on the decline, and I think that’s good. This role exists in the space among many large software groups. In the old days, they coordinated in elaborate, mutually dependent waterfall dances. These days, they “go agile” with methodologies like SAFe, which help them give their waterfall process cooler, more modern sounding names, like “hardening sprint” instead of “testing phase.” In both cases, the enterprise architect has a home, attending committee-like meetings about how to orchestrate the collaboration among these groups.
But that’s frankly, a pile of fail. When enterprises really, finally flip the bit and get efficient, it’s not because they suddenly have an epiphany about how to properly conduct a daily standup. It’s because they start to understand how to decouple and isolate their work so that teams can work in smaller, more autonomous units. Instead of spruce gooses, they build drone swarms. And that makes sense. Can you imagine the internet today if, instead of evolving as an incredibly distributed series of autonomous efforts, it had been controlled by some Enterprise Architect Committee of Doom? You know what? Don’t try to imagine that. It’s horrible.
The enterprise architect role, I believe, is on the decline. And I celebrate that because I think the people occupying it will find more rewarding ways to apply their talent. Most of them speak wistfully about rolling up their sleeves and writing code. Maybe they can again.
To be fair, there are committees in charge of governing Internet standards. W3C and IETF come to mind.
A fair point, though I’d say that the relationship between internet standards organizations and the broader development community is much looser than the one between enterprise architects and their constituent dev teams.
Another over-utilized (yeah, I know) word: “leverage”. As in “We will leverage the service bus”.
I always want to ask where the fulcrum will be located.
Heh. Although that’s a word I use, so I may induce an eye-roll from time to time. I may also use it less now, since it will now always remind me of mechanical advantage.
[…] The Decline of the Enterprise Architect (via Erik Dietrich) […]