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. ®

Similar topics

Broader topics

Narrower topics


Other stories you might like

  • Talos names eight deadly sins in widely used industrial software
    Entire swaths of gear relies on vulnerability-laden Open Automation Software (OAS)

    A researcher at Cisco's Talos threat intelligence team found eight vulnerabilities in the Open Automation Software (OAS) platform that, if exploited, could enable a bad actor to access a device and run code on a targeted system.

    The OAS platform is widely used by a range of industrial enterprises, essentially facilitating the transfer of data within an IT environment between hardware and software and playing a central role in organizations' industrial Internet of Things (IIoT) efforts. It touches a range of devices, including PLCs and OPCs and IoT devices, as well as custom applications and APIs, databases and edge systems.

    Companies like Volvo, General Dynamics, JBT Aerotech and wind-turbine maker AES are among the users of the OAS platform.

    Continue reading
  • Despite global uncertainty, $500m hit doesn't rattle Nvidia execs
    CEO acknowledges impact of war, pandemic but says fundamentals ‘are really good’

    Nvidia is expecting a $500 million hit to its global datacenter and consumer business in the second quarter due to COVID lockdowns in China and Russia's invasion of Ukraine. Despite those and other macroeconomic concerns, executives are still optimistic about future prospects.

    "The full impact and duration of the war in Ukraine and COVID lockdowns in China is difficult to predict. However, the impact of our technology and our market opportunities remain unchanged," said Jensen Huang, Nvidia's CEO and co-founder, during the company's first-quarter earnings call.

    Those two statements might sound a little contradictory, including to some investors, particularly following the stock selloff yesterday after concerns over Russia and China prompted Nvidia to issue lower-than-expected guidance for second-quarter revenue.

    Continue reading
  • Another AI supercomputer from HPE: Champollion lands in France
    That's the second in a week following similar system in Munich also aimed at researchers

    HPE is lifting the lid on a new AI supercomputer – the second this week – aimed at building and training larger machine learning models to underpin research.

    Based at HPE's Center of Excellence in Grenoble, France, the new supercomputer is to be named Champollion after the French scholar who made advances in deciphering Egyptian hieroglyphs in the 19th century. It was built in partnership with Nvidia using AMD-based Apollo computer nodes fitted with Nvidia's A100 GPUs.

    Champollion brings together HPC and purpose-built AI technologies to train machine learning models at scale and unlock results faster, HPE said. HPE already provides HPC and AI resources from its Grenoble facilities for customers, and the broader research community to access, and said it plans to provide access to Champollion for scientists and engineers globally to accelerate testing of their AI models and research.

    Continue reading

Biting the hand that feeds IT © 1998–2022