The developers vs enterprise architects showdown: You shall know us by our trail of diagrams
Old McDonald had a server farm, EA, EA, Oh!
One of the more wizened roles in IT is the enterprise architect, or, “EA” for those in a hurry. Meanwhile, those cowpokes over in the wide open office plans of DevOps country have little regard for these EA types.
It’s a bit of a “what have you done for me lately?” situation: last time the devs checked, these EAs were saying no to cloud and before that they’d put in place something called “SOA” (service oriented architecture) which turned into a clever, if unintentional, ruse to fly in the WS-Deathstar.
As I loaf around the DevOps circuit, the future of enterprise architects has become my top, unsolved mystery: what role do they have in this fully autonomous, heavily automated DevOps world? You shall know us by our trail of diagrams.
EAs have a poor history of improving the lot of developers. Their focus has been on driving out duplication, mandating all-too-often baroque services and frameworks, and rounding up any rogue technologists who are trying new things, er, non-approved technologies. They certainly seem to show up to meetings, especially re-occuring ones with vague agenda like “review project status.” (Whether EAs are “good” at meetings is left as an exercise to the reader.)
Usually they’re armed with all sorts of diagrams, slides, and digital three-ring binders. Just binders, and binders full of diagrams and six deep nested sections titles.
Those diagrams are like the primary totem of EAs: I once met with an airline EA who had an entire wall covered with a giant collage of boxes and lines describing how the entire company was wired together. “Now, tell me how I make a ‘cloud strategy’ out of that!” they demanded as we were sitting at their deluxe, intra-office mini round-table, the sign of real big wheel at an enterprise.
To be fair, these diagrams are intended to be helpful and, if you stared at them long enough, would actually be so. Someone has to keep up with what the overall big picture is, how it fits together, and as our mini round-table baring friend was suffering through, keeping everything up to date, all flexible and crouched down ready for the next industry curve-ball. “What are we going do about AR?!”
And while it takes a lot of skill and toil to align those boxes and arrows up correctly - have you ever noticed how “snap-to” grid points just have no aesthetic when it comes to arrow-ended lines? - EAs are infamous for not having touched a line of code since, well, that time way back when they did all this DevOps stuff on mini-computers but didn’t call it “DevOps”.
This malady presents in two extreme forms. First, the diffusion of innovation suffers: EAs who recommend fantastically new technologies at a mile a minute (they’re probably saying “serverless” now, but hungering for some new word to chew up like a pack of sunflower seeds on a tee-ball pitcher’s mound). Second, the laggards, who I can only hear in Droopy's voice, saying things like “hhhmmm, let’s put it on the ESB.”
The DevOps work release programme
Still, that idea of making sure everything fits together well and that IT is actually helping the business side achieve its goals seems like something you’d want to keep. Take, for example, the scale of JP Morgan Chase with its 19,000 odd developers. Even the most sceptical of us is likely to feel like there’s some role in centralized governance at such scale.
I’ve been talking with EA types at DevOps-minded organisations for most of the summer and there are a few recurring roles for reformed enterprise architects that keep coming up.
Demilitarising the EA police
One such EA at a financial company described the shift in their thinking as moving from “policing to partnering.” Several years ago, an EA came in and put in place a traditional enterprise architecture, set of governance, and all the great diagrams. It didn’t work out.
Here, we have the traditional “policing” mode of doing EA which is often more about enforcement than, if you’ll pardon the use of vacuous terms for alliteration – enablement. After the policing debacle, that team now takes more of a “partnering” stance with the rest of IT. The goal is more to make doing the right thing easy rather than making the hard thing punishable by reprimand-by-meeting.
Blinking cursors over spinning slide transitions
This also means scouting out and verifying new technologies to use, while also keeping an eye on standardizing on technologies like platforms and build pipelines. A standardized build pipeline provides, in fact, a hidden control point for governance. Just as failing tests won’t let a build through, using unapproved runtimes and frameworks can halt a build. Similarly, with a good platform (the new, vague soupy word to use for “all that PaaS and container orchestration stuff”) in place you can control which languages, libraries, and even ports are open and network connections are made.
Most all of that governance about healthy and sound development and architectural practices can be baked into your infrastructure. You can see some intriguing work being done here in projects like InSpec from Chef and in the upper levels of the ever evolving container orchestration stacks. As any lazy parent knows, deflecting blame to some soulless enforcer like an egg timer is a much more effective way of getting children to comply with your wishes then just playing off your parental authority. So it goes with EAs and developers as well.
Your microservices Gordian knot is adorable
Planning out and managing microservices seems like another area where EAs have a strong role for both initial leadership and ongoing governance. Sure, you want to try your best to adopt this hype-y practice of modularising all those little services your organisation uses, but sooner or later you’ll end up with a ball of services that might be duplicative to the point of being confusing.
It’s all well and good for developer teams to have more freedoms on defining the the services they use and which one they choose to use, but you probably don’t want, for example, to have five different ways to do single sign-on. Each individual team likely shouldn’t be relied upon to do this cross-portfolio hygiene work and would benefit from an EA-like role instead, someone minding the big ball of microservices.
More of the same, just done differently
Though we’d like to think that the whiz-bang, new-fangled hotness of DevOps would erase the need for enterprise architects, as with agile, it seems to be more changing how EAs go about their jobs than getting rid of the EA.
Some functions - such as policing governance - can and should be automated, but should still be based on policy the EAs create and continually evolve. Also, who’s going to pay attention to policing if all those DevOps teams are actually doing a good job?
The relationship between developers and EAs has always been terrible, so it’s little wonder that individual contributor movements like DevOps are sick and tired of EAs. Nonetheless, especially in large organisations that don’t have the liberty of dealing with just five or 10 applications that help users graft party hats onto pictures of towering tempeh sandwiches, scaling up DevOps in enterprises likely needs much of what an EA does.
On the other side of the coin, the EA should actually know what they’re doing, and know the latest technology and processes that could help their business and developers. The EAs' mindset needs to change as well; those who create and run the actual applications have supremacy in a DevOps-minded organisation. Enterprise architects need to treat these teams as customers, product-managing their work appropriately. Maybe they could even work with those teams occasionally to see how the grub down in the trench is working out.
If DevOps people scoff at the idea of working with EAs, the feeling is usually mutual. EAs probably need to take the first step in mending the relationship. At worse, it’ll keep EAs relevant. After all: “good job filling out our TOGAF architecture library!” said no CIO ever at the annual review. ®