back to article The developers vs enterprise architects showdown: You shall know us by our trail of diagrams

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 …

  1. Anonymous Coward
    Anonymous Coward

    Personally I would just be grateful for some developers who could grasp basic networking and security concepts.

    Reviewing change requests from developers is often a study in 'let's see how many ports we can open up between two huge networks (in either direction) when what they really need is ssh in one direction between two specific servers.

    I can't count the number of times I go to their documentation to find they haven't even listed the traffic required, or gone to the vendors' site to confirm communication details that the developer hasn't even bothered to look up before requesting IP any any.

    Why is it, that as a glorified network security architect I have to understand all the other areas of the business (finance/budgets, project planning, business needs, deadlines, server types, infrastructure, applications, security etc.) yet developers only seem to have to know how to shove an install disk into a machine and still manage to fuck up the netmask?!

    /rant :)

    1. Amos1

      OMG, did you hit it on the head. I was going to post "This article was written by a true cowboy" but your response is much better. I'm not an architect but in Information Protection, the other nemesis of the cowboys.

      If I hear "It worked on my desktop! Fix your firewalls!" one more time I'm going to ____ _____ _____ _____ ____ ____ ____ ________.

      Or better yet "We know what we're doing. We need ports A, B and C only." So when it gets installed it needs a half-dozen more ports and servers and they say "Adjust your controls." and we say "We had a third-party review and risk assessment based on your docs and drawings. Make the app work like you said it would."

      And the devs squawk "We will need to double the number of services we wrote!" and we reply again "We paid for a third-party review and risk assessment based on your docs and drawings. Make the app work like you said it would." and then it goes to "arbitration" and the devs point out how much time it will take to make the app work like they thought it was already working. And we point out that since they do not have any clue how their app works on the network, we will need a full third-party pen test and a more thorough risk review before we'll advise Operational Risk that is it satisfactory. We usually "win" but the organization loses because of the cowboys' lack of operational discipline.

      No, cowboys, it is not a "sprint". It is a business.I get to deal with vendors who use DevOps. When we find an issue with an app they can't even duplicate it because they've got no change control and their internal builds are many iterations past what they give to the customers. Companies claiming to use DevOps now get marked as a higher enterprise risk because what they call "agile" is really known as "unstable".

    2. Eric Olson

      I can't count the number of times I go to their documentation to find they haven't even listed the traffic required, or gone to the vendors' site to confirm communication details that the developer hasn't even bothered to look up before requesting IP any any.

      Funny, I get tasked with that all the time as the business analyst, under the guise of "gathering requirements."

      Sure, there are some requirements there... but there is an element of RTFM that drives me a bit crazy when a dev swings by and bitches about how my requirements docs don't contain details on how to integrate with an external service. Never mind that I included the documents provided by said vendor as reference, rather than duplicate information in a way that won't be updated as the source is.

    3. Jim 59

      Broadly agree. Many "Devops" teams lack the "ops" experience to justify the name, and are sometimes just a group of well meaning developers and power users who have been given the root password. Cloud gives them the power to orchestrate, and they pump out instances blithely unaware of sysem basics, with predictable results. It isn't their fault though.

      1. Naselus

        "Many "Devops" teams lack the "ops" experience to justify the name"

        Very much this. A good Devops team should have a bunch of developers who have enough knowledge to do very basic ops, and a bunch of ops guys who have enough knowledge to do very basic coding. That way, the drudge-work parts of the ops tasks can be assigned to the developer portion of the team, and the drudge work of the dev tasks can be given to the ops portion, while the experts can concentrate on doing the really complex bits of their own specialty when needed. Developers aren't sat twiddling their thumbs waiting for a 100k a year solutions expert to click 'next' six times in the RHEL installer before they can start testing their new program, and ops guys aren't sitting in maintenance mode for half their time.

        Instead, a lot of Devops teams were set up by simply firing all the ops guys and giving the dev team root permissions. The result has been a cascade of cloud-based apps which have dreadful security and performance problems because their VM is running a default setup, because the developer has no idea how to properly configure an SQL instance and no problem with just opening a dozen extra ports on the firewall to make his shitty code work.

        This is the kind of thing that we used to fire developers for ten years ago. Now it's being forced on them.

    4. Anonymous Coward
      Anonymous Coward

      Popular cowboy apps

      > some developers who could grasp basic networking and security concepts.

      So I work at $VeryBigDBCo who's abandoning their in-house instant-messaging for Slack.

      Which is great, except I use Linux for my desktop. The Linux Slack app Doesn't Do proxies. It doesn't respect the usual env vars nor does it have proxy settings in the preferences.

      The response from Slack support staff? Just open the ports in the firewall!

  2. Anonymous Coward
    Anonymous Coward

    I thoroughly endorse this policing vs partnering analysis of the EA role and its increasingly poor fit in most organisations and am going to shamelessly steal it.

    My problem with EAs has been that, with very few exceptions, they've always fallen into the policeman archetype with the droopy voice and the 9-5 schedule of "review" meetings where they present the latest round of the Architecture Deck v2.088-3 (2).pptx which has little to no bearing on what currently exists or what will actually be delivered. It just adds no value to the services being delivered.

  3. Anonymous Coward

    Awesome article

    First off: I'm a huge advocate of modeling languages such as UML / SysML / BPMN and even though I realize not everyone values those standards I do think they're sometimes under appreciated. However...

    "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”."

    I think this really nails the main problem.

    I've been following a few seminars in the past and I'm (somewhat) active on a few fora dedicated to modeling practices and if there's one thing I can't help but notice it's that a lot of data analysts seem so stuck up with their rules ("guidelines") that they'll often spend more time debating (or researching) modeling standards than actually addressing the (theoretical ?) problems they're trying to solve.

    And one reason for that, in my opinion obviously, is two fold. There's a huge difference between theory and reality. So having some kind of hands on expertise with the way things are done can seriously help to understand the reason for any possible caveats and/or problems. Yet most analysts will approach all this purely based on their precious modeling standards, thus theoretical.

    Which is in my opinion another major problem within this field of work: the standards should be a means, not a goal. When it comes to modeling languages (such as UML / BPMN) I always try to draw parallels with real (spoken) languages. Despite the official rules (as laid out in the dictionaries) we often use the language in the way which works best for us. And sometimes the language changes and adapts a bit. So why can't the same thing apply to modeling languages?

    I think that's a major caveat sometimes... I know of situations where people tried to change the way a company worked based on a pre-determined ruleset instead of basing themselves on what would be the most optimal way for the departments to work. Said company dumped this way of work within 2 months or so and then went back to their old ways. And I think that fuels the ideas of those 'weird diagram packed guys' who can recite a lot of theory but don't seem to fully understand how things work.

    1. Sir Runcible Spoon

      Re: Awesome article

      All company systems/guidelines/policies, whatever, first and foremost have to *serve* the business.

      I've seen many large companies struggle to keep their agility because they become so reliant on their policies and procedures that they are followed to the letter. People inherit these guidelines who might not really understand them (and how to change them for the better if the company or circumstances change) and the result is a 'computer says no' type of mentality that cripples the business.

      It should be simple. If the process is no longer serving the business, then it is the process that needs to be updated (rather than forcing the business to follow the process).

      1. Doctor Syntax Silver badge

        Re: Awesome article

        If the process is no longer serving the business, then it is the process that needs to be updated (rather than forcing the business to follow the process).

        I've long thought that a process/rule/whatever you want to call it should include a rationale as to why it exists. This would serve two purposes:

        Firstly it would allow everyone* to be aware of its significance so that "Legal requirement due to GDPR; failure to compy might cost 4% of global turnover in fines" might carry the implication "being CEO isn't a good reason to ignore this".

        Secondly it makes it clear when the rule no longer applies: "This information is required in order to complete the the 1998/9 accounts after which new accounting procedures will apply".

        *Everyone = senior management

        1. Naselus

          Re: Awesome article

          "I've long thought that a process/rule/whatever you want to call it should include a rationale as to why it exists"

          The problem is, these often become so long and convoluted that no-one will bother to read them, or so technically-specific that most people won't understand them.

    2. Anonymous Coward
      Anonymous Coward

      Re: Awesome article

      Speaking as someone who grew up in the industry long after formal modeling approaches had begun to wane, my problem with them is that they're inherently reactive. A UML diagram might, if you're very lucky, describe something akin to reality, or some form of desired reality. In practice it just turned into Yet Another Document you've got to fudge to match up to what you actually ended up delivering. And in this day and age you can produce exact specifications for your systems based on the actual implementation programmatically, which begs the question.

      1. Roland6 Silver badge

        Re: Awesome article

        And in this day and age you can produce exact specifications for your systems based on the actual implementation programmatically,

        Which begs the question, how were they (the specifications) written in the first place...

        Programmatic produced specifications are just a starting point, just like source code reversed-engineered from executables.

        I produce UML and other diagrams to communicate with others so they can do their job and contribute their knowledge and expertise. The problem with UML diagrams etc. is that they are too sterile!

        I subscribe to the Peter Checkland viewpoint that such diagrams represent a view of reality (either as-is or to-be) that is likely to change over time. Thus Peter always hand drew his diagrams, because people don't treat freehand diagrams as 'gospel'.

    3. Anonymous Coward
      Anonymous Coward

      Re: Awesome article

      Exactly what I was thinking.

      "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”."

      Yep, I'm from that generation. We did the lot back then. Even racking the 2.4Mb RK05 Disk Drives and we wrote code, lots of code.

      These days, everyone is compartmentalised. "not my job Guv!" is now commonly heard.

      Many don't even want to know about the other stuff that goes into making complex systems work.

      When I left my last job, or rather got laid off some 15 months ago, then the company sent it to India, my job was replaced by four people. Ironically their costs ended up being close to mine. And they are ******** it up royally. My old boss wants me back as a contractor to go sort out a major project cock up because a load of essential things fell through the gaps. Did those 4 people talk to each other? Did they heck.

      Told him no. I get my state pension next month. Time to put my feet up and work on some RaspberryPi robots.

      1. Naselus

        Re: Awesome article

        "Told him no. I get my state pension next month."

        Should have said yes, but you'd be needing a full year's salary per month.

  4. Anonymous Coward
    Anonymous Coward

    Developers are just usually insterested in CV driven development, and using the latest best for one week frameworks just because it sounds good. It’s us EA’s that bring the whole picture to the table, thinking about the solution as a whole not just the development which under AGILE is just an excuse to throw things out there and hoping they all work. Luckily I work in the finance sector with a strong EA process that the devs ain’t getting round any time soon!!!

  5. Roland6 Silver badge

    So we're not really talking about EA's then...

    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!”

    If an EA said that to me I would be questioning their suitability for the job. Now, if on the other hand, they asked if the use of cloud could both support and change the way the company was wired together...

    1. Korev Silver badge

      Re: So we're not really talking about EA's then...

      I once worked with a PM who loved printing out his Gantt Charts having made sure that all the dependencies fed off each other even if that wasn't the case. Some of the Devs would deliberately complete some of the discrete tasks out of order so he'd have to redo his huge diagram. Other than it being a bit of fun this also meant that he would leave the developers unmolested to write code instead of unnecessary paperwork.

      1. Roland6 Silver badge

        Re: So we're not really talking about EA's then...

        >this also meant that he would leave the developers unmolested to write code

        Nearly 20 years back I came to the conclusion that any large project needed two Architects/Technical Design leads - who understood each others thinking: one to do the job the other to head off the constant requests for status updates, explanations etc. from the Programme Dir./PM/Project Office.

  6. Merrill

    There is also the matter of consistency


    - what the business needs to run

    - what is installed

    - what is running

    - what operations is charging the organization to run

    - what finance is charging the organization for depreciation

    - what vendors are billing the organization for licensing

    and now what various cloud vendors are billing the organization for.

    These can be amazingly far apart in an corporation with a complex organizational structure and a few thousand developers.

  7. Anonymous Coward
    Thumb Up

    How it really is...

    The role of a true Enterprise Architect is to shield the developers (who do the actual work) from the herds of middle managers (who vaguely remember doing some work, but remember their crippling mortgage and school fees far more) who oversee the budgets. The Enterprise Architect applies a layer of technical sounding management drool, enough diagrams to keep the managers who aren't so good on words and thinking happy, ensures that no single budget item ever relates to a piece of concrete development, and sufficient procedures and protocols to give the ever circling auditors just enough for a full stomach and not quite enough for outright heartburn or death. Although giving auditors heartburn isn't actively discouraged.

    For maximum efficiency, there should be no reporting lines - actual or implied, dotted or solid - between any developer and anyone who calls themselves an Architect (Enterprise or other), in the same way that developers should never be allowed to meet clients. When companies are so badly run that architects are allowed to converse with, and worse still, influence the direction of developers, the end result is always something totally overblown, baroque and unusable, but with as much tenacity as a skid mark on pure white porcelain - a fairly recent example is of course J2EE, a product and concept so laughably bad that even some architects are starting to have vague doubts about it.

    In a truly ideal world, companies would not need Enterprise Architects, but in that same ideal world, companies would also not need anyone with 'Expert' in their job title, HR, Audit and General Counsel.

    Finally, if you're ever in doubt whether you're sitting near a developer or an architect and you feel a direct question is somewhat inappropriate, ask them what their car is like, and who their mortgage is with. An architect will answer 'Beemer/Audi' and 'Santander'; a developer 'Can't remember/don't own one' and 'Paid it off years ago'.

  8. Mike Timbers

    DevOps should not be an excuse to be cowboys. Agile has the concept of the architectural runway where the architecture is rolled out just in time for the solution to work. I have always found it ironic that something "just in time" would try to use an analogy where there is so much health and safety that "just in time" is years in advance!

    Anyways, this promises to be an interesting discussion given the readership of El Reg.

    The problem I have with allowing Devs to decide all aspects of how something should be done is that they ignore the cost of technical debt. Six months in, when performance in the real world is poor, and the architects are finally allowed to look at the crap that was released, the Devs just claim ignorance and say that it passed the sprint demo.

    The Devs then get all the credit for delivering the widget on time, and "legacy IT" gets all the blame for the last-minute costs of making it secure, performant and operationally reliable.

  9. Steve Channell

    no showdown

    Very amusing article, but fails to nail the two core issues for a showdown

    1. Creating excellent systems is hard, especially Complex and/or Realtime systems. The more layers, more integrations, more sponsors, the greater the need to communicate design early on in the cycle when cost of change is lower.

    2. Incompetent people will find something to do, rather than finishing the job. The closer to the metal, the more difficult it is to hide.

    It’s an easy mistake to strip down the Software Design process like a Daytona track car, when the design problem is the same as it was when Fred Brooks wrote the mythical man month – productivity.

    The DevOps approach improves the productivity of developers, and can be applied to Architecture through code generation and automated reverse engineering. Arch-Ops is the next phase not an alternative

  10. Cederic Silver badge

    Speaking as someone with 10 years of EA, including merging two airlines, this article is an interesting blend of truth and nonsense.

    My job has almost no relation to that of developers. I trust them to know how to do software engineering and don't really care whether they're hosting in the cloud or on premise. I care about where the company is going, what's stopping us getting there and how we can exploit technology to either get there quicker or maybe also get somewhere better.

    How a single system is put together is for application architects and solution architects. How data flows across the organisation is for data architects. How the whole business works, engages its customers and creates value for its staff and shareholders is where I'm focussed.

    I can work magic without touching technology; never underestimate the processing power of a building full of Indian graduates. I can guide corporate strategy down a technology direction that cuts costs. I can help the budget holders avoid wasting a few hundred million in a dead-end project.

    Developers don't really come into it.

    1. Anonymous Coward
      Anonymous Coward

      Truth and nonsense

      > "this article is an interesting blend of truth and nonsense"

      Exactly. Does the company need an EA who can write code, or an EA who can organise the group so 1,000 developers are delivering the required code?

      My [AC] working life involves looking at too many organisations that want to buy a thing or lots of these things to magically make all the problems go away. What they don't want to hear is that they need a better organisation. That is the objective of a good EA and the metric is the ability of the business to thrive or survive.

  11. Tom 38 Silver badge

    Troll is obvious

    The whole article is written in a style to insinuate that EA are hopelessly out of date dinosaurs who just cannot survive with DevOps. Split people off in to binaries, and then insult both of them - It's a good troll, I see it, but I'm still failing for it.

    The truth is different. DevOps does not mean not planning your architecture. The worst kind of DevOps is unplanned, with developers slapping instances without thinking of why or how.

    Even when you have a DevOps team doing things brilliantly, you still need someone who has that top level view of projects and systems, how they interconnect and talk to each other, and what the effects of modifying those systems are. That's the EA. If that EA is causing problems for developers, probably he is preventing the developers causing problems for the business.

  12. John Smith 19 Gold badge

    When the business (and it's systems) gets big enough someone has to have the big picture.

    All those little "agile" teams chewing on something and spitting out v 0.1, 0.2, 0.3 etc are very unlikely to talk to each other.

    Systems which work together multiply their effects. That can multiply positively or negatively.

    The odds on bet is a real EA will have been with the same company for decades and know it inside out. They are aware of new technology and can assess its impact to their business, even if they don't use it themselves. IOW they have very good BS detectors.

    So there aren't very many real EA's around because it's damm hard to do right and IRL no modern company wants to pay the salary real ones deserve.

  13. jake Silver badge

    Thanks, ElReg!

    I've been looking for a good article demonstrating why, exactly, DevOps is bad for business. You've just provided one. Much appreciated.

  14. Missing Semicolon Silver badge

    You forgot....

    "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"

    So, you automate the "architecture rules" put in place to prevent Wild-West coding and framework use.

    Then a Dev spots the bug in the pipeline that's preventing the most recent build, and goes into Ops mode and removes it. Job done!

  15. Paul Hovnanian Silver badge

    Enterprise Architects

    When I worked for a large Seattle-area aviation concern, the position of EA was created to wrangle multiple development teams and internal customers into not using yet another host architecture, OS or tool suite. 15 minutes after the job was created, vendors* figured out that the EAs would be an excellent foot in the door to shill for their particular products.

    *Being just across the lake from one of the biggest OS vendors, you can probably guess who had the biggest foot.

  16. JoeCool

    I am astounded by the proportion of EA commenters with an axe to grind. I'd guess most devs read the article, and think "well, yeah. next article".

  17. Anonymous Coward
    Anonymous Coward

    Ye shall know us not by our architect's diagrams but collectively by our Gold-Plated Turds

  18. Wowbagger42

    Oh dEAr

    When having a meeting with EA's my first question is always "have you ever worked or finished a project with xyz before?" followed by "do you wanna go tech deep or do you just want to go over some diagrams you made?".

    Gets 'em tiptoe'ing instantly and you can seperate the idiots from the real EA's pretty quick.

    It's always a pleasure to work with experts but since some years the EA field has been invaded with vendor-trained shills or pretty clueless body shopped PFY's. A real EA with proven trackrecord is hard to find, like one that figures out 443 is probably https... and working as a dev(/ops) with expert EA's there is never any friction but only cooperation towards a mutual goal.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like