25 ms·

Enterprise, IT architecture and strategy is getting more and more frustrating

195 points by gctwnl 5y ago

mirekrusin 5y ago
Big corportations seem to be retarded in this area for sure. What seems to be working is skipping almost all meetings at the early stage about it – just go straight to PoC and start discussions from there. Also be careful what you wish for - because if it goes ahead – it may become business critical quickly, which means doubling team few times, onboarding systems/teams while providing near zero error rate/downtime etc.
hughrr 5y ago
This is actually spot on. I was offered a promotion into this space which I sensibly declined as money is a poor motivator for me. This was a surprise to the company. The poor guy who did get promoted is stuck with exactly This situation.
holoduke 5y ago
The word 'enterprise' alone is enough reason to walk away for me. Some companies have hundreds working with those titles. Beyond my understanding what they all do.
- killtimeatwork 5y ago
  A large enough company, which can have thousands of systems running in prod, needs someone to be the gardener pulling out the weeds (systems which duplicate each other's functionality, systems which try to introduce obscure technology for no benefit etc.) and also design the company's systems landscape (start initiatives, kill existing ones, move data and functionalities between systems etc.) so that it fits company's goals. Typically, you have to come up with some strategic vision and then convince all the high-level managers affected to commit to it - and then steer the execution across all teams, so that all the pieces come together. It's basically big picture job, and very difficult to do well, since it doesn't come with any managerial power or budget - EAs are the Cardinal Richelieus of corporate world.
  - jiggawatts 5y ago
    Just to add to what killtimeatwork said above: I'm watching what happens when enterprise architecture is done badly, right now. I'm currently assisting a huge agency that is a mish-mash of smaller agencies. Multiple clouds, several data centres, hundreds (if not thousands!) of "apps" and servers. Every combination of bare metal, VMs, and cloud IaaS, PaaS, and SaaS. Much of it overlapping or redundant functionality. It's an unmitigated clusterfuck: A nightmare tangle of interdependencies, band-aids, duplicated systems, inconsistent DR, non-existent DR, partial HA, and on and on. If you've ever seen a "spaghetti base" in Factorio, it's like that, but as if a hundred players had been building one for a decade. Not just spaghetti, but multiple interwoven styles of spaghetti. It's hard to explain to someone who hasn't seen it. Recently, someone upgraded a Layer 7 load balancer in a legacy data centre and broke an application in an unrelated Public Cloud because someone hard coded a HOSTS entry for the internal certificate CRL distribution point. Why was a cloud service using legacy internal PKI? Reasons. Why did it need a HOSTS entry? More stupid reasons. The technical details don't matter, of course. The moral of the story is that because they don't have a good EA at the helm, they're still adding to the spaghetti. I'm watching this unfold in slow motion. Layers of new stuff just draped over the existing garbage. No uplift. No clean-up. Nothing ever turned off. Just buried under new strata, slowly fossilising. It's fantastic yet horrifying to watch, like a slow motion shipwreck.
    - pjmlp 5y ago
      The irony is that with enough experience, you get a gut feeling for these kind of scenarios and the only thing one can do is to fasten the seatbelt and brace for impact, because of the politics involved no one really wants to listen.
    - ownagefool 5y ago
      When you say reasons, for me those reasons vary from "we have a PKI and I'm lazy" to "EA told me we have a strategic PKI that I have to use". And it's typically not the former, because getting the network connectivity is usually way more effort.
      - 5y ago
Aeolun 5y ago
I’m not sure what this role even does. As far as I see them they just appear in meetings once in a while to mess up our (the actual dev team) carefully balanced schedule by suddenly requiring us to do something completely different. Like suggesting it would be better to stick with Javascript over Typescript since it would be more stable.
- FourthProtocol 5y ago
  Simplisticly they do the same as you when you think about the building blocks or components of an app. They just do it at that dreaded "higher level". Higher level can be a bit ambiguous. Typically it's systems (ALL the apps in your org, their purpose, interrelationships, security, and so on). The good ones are able to identify, analyse and optimise processes, old and new tech, finance, and regulations the Co. is bound by (know your customer, HIPAA, GDPR and so on). They talk to C-level boss types and make a case for whatever they're making a case for. They do stuff like tracking and magaging risk and stakeholders, but at a higher level than dev. They (the good ones) also sleep less than you do, and know EVERYTHING about coffee. I've been doing this for some time and wrote down some of the things I learnt - https://www.wittenburg.co.uk/Work/Consulting.aspx https://www.wittenburg.co.uk/Work/Consulting.aspx
  - Koffiepoeder 5y ago
    Thanks for this resource, definitely going to look into it. I am currently considering to make the freelance/consulting jump, so timing is ideal.
  - unixhero 5y ago
    Very good resource, thanks for publishing your thoughts. The reference model is similar in spirit to the PRINCE2 overall framework: https://www.knowledgetrain.co.uk/res/prince2-processes-activities-v5.2.png https://www.knowledgetrain.co.uk/res/prince2-processes-activ...
    - FourthProtocol 5y ago
      Thanks and yes it is. The model is in fact an extrapolation of Microsoft's Solution Framework from the '90s. On the problem solving side I was far more impressed by a book from Betty Vandenbosch (Designing Solutions for Your Business Problems: A Structured Process for Managers and Consultants) than I was by Prince.
gonzo41 5y ago
I've often thought the other half or the Agile thing would be to try and build systems with really tight depreciation schedules so you are forced to retire a system and either rebuild or rethink the business context. So much of my work is trying to coax people to understand the operating environment has changed and we don't need a new thing, we instead need to do new things.
sach_r35 5y ago
Love the intro etymology lesson. In my exp, such roles don't seem to be super well-defined.
Foobar8568 5y ago
Oh it reminds me of one who used to be a sales consultant for an useless "modeling" tool (only by name) that nobody in the company wanted beside the CIO as it was on "required" on a Gartner checklist and ended up as the enterprise architect. The guy has never wrote a single line of code in his life, nor has seen a source code. It was madly frustrating, the rest of the IT leadership and developers were as bad
- laurent92 5y ago
  IBM?
- antman 5y ago
  Gartner has checklists?
  - hughrr 5y ago
    Yes each one has an elaborate story and a pile of cash behind it.
    - vishnugupta 5y ago
      My recent realisation has been these shops fall in a category of what I call "rating agency" all of which share common characteristics. For example; Moody's, Gartner, Michelin Stars. 1. Stripped of all the paraphernalia these are yellow pages ranked by popularity in their domains. 2. They are in the business of selling customers to the said businesses. So their primary customers are businesses; restaurants, mutual funds etc., 3. They need to maintain authenticity of impartiality so it's not easy to find out how they make money. 4. Their secondary audience is decision makers; CIOs, money managers etc., Think of -- "no one got fired for picking at the 1st ranked software from Gartner's list", "But Moody's rated it AAA, how was I supposed to know that fund would tank". It's a terrific CYA tool. 5. I'd say about 80% of the times they do a decent job of stack ranking. But there is an element of virtuous cycle there. The top rated "things" are popular because they are ranked to be so by these rating companies. Once a critical mass adopts then that tech/restaurant/etc indeed becomes numerically popular.
unixhero 5y ago
Well it certainly has propelled my life, bank account and career forward. I don't expect work to be (edit: purely) fun. I expect the rewards to be, and they certainly have been.
deleted 5y ago
[deleted]
ddmma 5y ago
Makes sense while working in EITA department but not that much before or even after. Actually the majority of the company not having a clue about their strategic role, that makes it so medieval hardcore.
pram 5y ago
Very senior titles can be difficult indicators of competence because it’s usually someone decently smart and political, or someone in a terminal position that’s been at the company for a billion years and is doing the ol “rest and vest”
tannhaeuser 5y ago
Which person on the intro graphic is to be associated with the role of an architect, though?
- gctwnl 5y ago
  The one one the rack
cjfd 5y ago
The article does not seem to be telling us what is the cause of this difficulty to change anything. Is it maybe the quality of the existing solutions that makes it very difficult to change them? I, personally, am inclined to blame the 'technical debt' philosophy. If you never clean up your messes, things will go slower and slower and slower. Also, the mythical man month comes to mind 'add more people to a project and it will take longer'. The biggest problem of too many people being that knowledge becomes increasingly fragmented. So, one should have fewer people than one actually needs in order to make sure that they have enough knowledge.
- ownagefool 5y ago
  Enterprise IT usually wants to push change without getting their hands dirty. Downstream that means you get people who don't care about about their profession just following orders, or you disrguntle them because they don't understand why they're not able to define a reasonble architecture and instead have to follow the edicts of that weird out of date team that gatekeeps and aren't involved in the problem. Of course, reality is sometimes the product teams don't quite get the full picture and need a guiding hand, but from my experience having someone removed from the practicalities of the situation usuaully doesn't help.
- gctwnl 5y ago
  The article is simply saying that with the growth of IT, change is getting harder (existing landscapes have inertia), something the top is slow (if at all) to accept. That makes the role of the person trying to explain that (and why) change is getting harder a more frustrating one.
livinginfear 5y ago
I used to be involved in solutions design a few years ago. Now I've retreated somewhat to being just a regular 'senior developer'. Solutions design, architecture, and DevOps stopped being interesting to me as soon as they inexplicably became a frustrating exercise in understanding every single method Amazon Web Services has conceived of to cost the company money.
- kennu 5y ago
  On the other hand, it doesn't make much sense to keep reinventing the same things that AWS has already packaged into convenient and reusable little Lego blocks. I guess the excitement of inventing new stuff needs to be related to new technologies not yet commoditized.
  - zo1 5y ago
    Dunno what everyone else thinks but these AWS Lego blocks are anything but convenient and reusable. Frankly they're oversold from my perspective as someone that came a little late into the "aws cloud" game.
    - scient 5y ago
      Unfortunately I think the issue not AWS here. You say you lost interest when it became a frustrating exercise, I read it as you lost interest once you realized setting up a cloud environment is not trivial.
    - tyingq 5y ago
      My experience is "it depends". I had, for example, a good experience with AWS Fargate. It's not inexpensive, but it did what it said it would. It let me focus on packaging apps into containers, and caring less about making them elastic. I had the opposite experience with Lambdas/Serverless. It made easy things very slightly easier, and hard things impossible.
      - Nextgrid 5y ago
lkrubner 5y ago
I find this essay to be abstract to the point that it is difficult to understand what the real point is. In contrast, I’d like to recommend my essay, already much discussed here on Hacker News, which covers the same subject (the difficulty of change at large firms) but with a detailed look at one of the world’s largest car rental companies: http://www.smashcompany.com/business/why-are-large-companies-so-difficult-to-rescue-regarding-bad-internal-technology http://www.smashcompany.com/business/why-are-large-companies...
- mirekrusin 5y ago
  I work with one of very large companies and I'm unfortunate to witness work of mulesoft as well, I don't know if this whole platform is simply so shit or the team "doesn't hold it right" but I would not surprise me if the sole problem in linked article is just that - mulesoft. Maybe it's programming-by-filling-in-wizards or something else - I don't know and don't care, judging from the output I see, they don't deserve to be called "system integration" by any standards, my recommendation is - avoid.
  - cgio 5y ago
    I have used Mulesoft, and while it was not the most exciting technology I would not consider it shit. Also I don’t remember it being wizard based, but could have changed in last couple of years. Depending on your role, if you don’t care what the root cause is you also don’t need to worry about it. Ask the people who have to care what the issue is and help them in resolving it.
davedx 5y ago
Ehh. I’ve worked as an architect alongside solutions architects and also directly under them. It’s a tough job but this whole post seems to be saying it’s hard because communication (engagement) with upper management is bad? This is an org specific problem not a systemic one. (My own anecdotes while working as an architect within an enterprise: some upper management - director level - engaged very constructively with architects and principle engineers).
123pie123 5y ago
Enterprise always operate on (usually oldish) stable versions so that allows some breathing space of time. and a good enterprise will have a reasonably well defined road map that can be used to set expectations of future risk/ technical debt
- gctwnl 5y ago
  Road maps are generally pretty useless. They are a form of trying to predict the future. Good Life Cycle Management is of course OK, but you cannot predict what you will need a year (or two) from now.
  - 123pie123 5y ago
    >but you cannot predict what you will need a year (or two) from now. I imagaine enterprise systems is like steering a monsterous size oil tanker. for the size of systems I work with - two years is extremely easily predictable. The shiney shiney new stuff does sway a few new green field projects, but keeping many very expensive systems (to develop and high impact if they fail) running/ up to date/ partially changed is the boring stuff thats is very critical to a lot of companies
- tatersolid 5y ago
  > Enterprise always operate on (usually oldish) stable versions so that allows some breathing space of time. Until it doesn’t. The number of enterprise projects I’ve seen that were “emergencies” due to neglecting updates is astonishing. If you’re not updating a COTS or custom system at least semi-annually you’re going to have a zillion security vulnerabilities, and will lose all institutional knowledge of operations and upgrade of said system. Then the stuff really hits the fan when you’re forced to upgrade due to EOL/EOS. This is the real reason SaaS is now popular.
wanderingmind 5y ago
It's easier for me to find a job as an Architect as all I need is to know the outline AWS/Azure tools and some ability to bullshit. Compare that to having convince recruiters that my background in MATLAB modeling can be transferable to do Python development. I'm happy to bullshit and collect a paycheck.
- witcher 5y ago
  Sure, you can fake that you do the job in any role if you want. Question is, do you enjoy doing this, going to such work every day?
  - wanderingmind 5y ago
    Nope I don't think anyone can enjoy faking for a long time. but its hell of a lot better than going hungry without a job.
  - ClumsyPilot 5y ago
    I think the key question is - does he perform any worse than someone with the 'right' background? I am not sure
- dragonelite 5y ago
  knowing AWS and Azure is like insta hire, only reason i studied for AZ-204 certificate just to fill up my resume and the boss paid for it. 3 weeks later I forgot like 75% of the material xD. It was really more a strategic carrier move then a love for cloud knowledge move.
  - pjmlp 5y ago
    The large majority of certificates are like that, sure the HN and Reddit crowd might shit on them and how they are useless, however in enterprise computing they are the key for even being entitled to buy from certain providers. So it isn't the knowledge one gets from the certificates, rather the checklist from having them in first place.
leroman 5y ago
This is a necessary and an important position to fill, as now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product (except for risks down the road). Companies need someone who understands the trade-offs, knows which use cases are right for this architecture and save the company (and future devs working on these systems) a lot of headache.
- tarsinge 5y ago
  That sum a critical part of my job, help clients navigate and find the middle-ground between bloated old-school enterprise solutions on one end and hype/resume-driven developers on the other.
- Nextgrid 5y ago
  > now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product Is there a way we can push back against this? I feel like the battle has been lost and it's not just devs being guilty of this, it's entire companies. For a lot of startups it seems that solving the business problem is now secondary to engineering itself, aka how many microservices and moving parts they can cram into their stack so they can then give talks about it and write on their tech blog. I've lost business in the past because a client wanted to build a prototype with Lambda and similar. They were either severely misguided, or their main objective wasn't to build a successful product but merely present themselves as the next hyperscaler due to the complexity of their tech stack (all to serve a whopping 2 HTTP requests/second, if even).
  - res0nat0r 5y ago
    I think this has been going on forever. I've had to deal with folks since the dawn of time who want to just try and make the geekiest new nerd tech out there part of their project because they want to screw around with something fun. It doesn't matter if it's 10x more complex or hard to support, it's a new toy to play with so folks want to use it. You have to filter those people out as being unreliable, and also when dealing in enterprise level companies also keep out of the room the complete and utter idiots who have no idea what they are talking about and haven't touched any of the tech hands on in decades but want to also throw up road blocks to everything you propose.
dkdbejwi383 5y ago
I’m not sure I really understand what “solution architects” do, or what value they bring. In my experience, they take a half-baked set of requirements and make a bunch of complex looking charts and diagrams that purport to explain how software that fulfils the requirements might be built. But most of the time, the “solution” is impossible due to various constraints they have glossed over, and doesn’t actually meet the requirements once you start to question what the user really wants. It seems to me the kind of role that fits in with waterfall-style planning, at odds with agile, yagni, building just enough and constantly iterating based on feedback from real users.
- leroman 5y ago
  A lot of the time, their job is to say "no", and shut down some over-engineered solutions brought fourth by dev teams
- glogla 5y ago
  Architects are supposed to sit higher, seeing both more systems (where developers focus on theirs) and seeing further in time (where developers are focused on their next release or two). I see the job of an architect to work on how things work together and make sure nobody "paints themselves into a corner". How well that works in practice is another matter of course. Architects have longer reach than developers, both in space and time, so the have larger blast radius. One bad architect can screw vastly more things than a bad developer.
- angulardragon03 5y ago
  (imo) Solution Architects are popular in big enterprise environments exactly because the organisation as a whole doesn't use/isn't familiar with agile or the like. They have to figure out what solution the org is looking for, how to best integrate it with what they already have, and how to do it with the least impact on employees. If the org has poor information management, getting requirements is already a mess, and the SA is already screwed. From what I've seen (with contracted SAs), SAs are just inventorying and working around the half-finished implementations the previous SAs left behind, ad infinitum.
djantje 5y ago
If you are capable to hold the overview for an organisation, and know the best interest of the organisation, you can become and IT Architect, if you can also communicate your ideas. Ofcourse this can come with great difficulty, and implementation of (some) of the ideas you might never see happening. I agree that upper management plays a crucial role, they have to be rightly informed, especialy if they hold the wrong intuitions. I also hold the believe that this is the case in smaller organisations and/or IT trajects, where there is no dedicated architect, or team of architects. Architecture is about envisioning the future and shaping how it looks and works, ofcourse you should take the role, if this is what you want. (No job is only easy and only fun, but it can be greatly rewarding at times, but as with most things, best do it for the doing of it ;)
bartread 5y ago
I'm as sceptical of the "architect" positions and the value they deliver, not to mention the job satisfaction they offer (or lack thereof), as the next person, but this is not a very good article: vague generalities, no examples, a poorly expressed and hazy argument to the extent that it's somewhat unclear what point the author is trying to make. Sorry, but no: this is not advancing the conversation. If anything it's illustrative of the kind of hand-wavy nonsense-talk that architects are often reviled for.
seanhunter 5y ago
I remember having a whiteboard conversation with an Enterprise IT architect. I drew my usual diagram of the actual systems and services and how they connect. He rubbed out all the arrows, drew a triangle and had all the arrows flowing into and out of the triangle. "What's the triangle?" I (perhaps naively) asked. "That's the source of ontological truth". That's when I realised there's a whole other level of ability that some people have. This guy was a zen master of bullshit.
- finikytou 5y ago
  I find it particularly true when I work with americans. this is because technical careers pay six digits in the USA. a sizeable part of the people that ended up in the technical field without really the right background or career just think they can do it because they got a degree from something "technical" that is not CS or even are so sure of themselves that they think they can do it even if they don't know how to. basically using salesmen training and candoit into the technical world. In europe that would never happen because people consider technical positions and knowledge below management skills and the crooks would end up into the mgmt positions because it pays better to be a PM than a tech guy. it is changing but slowly.
  - ivan_gammel 5y ago
    In Europe there's plenty of people with CS-related degree and decades of experience, which stuck in 1980-2000s with their solution and organization design skills and thus slowly becoming generally incompetent. It is not only American feature.
  - sidlls 5y ago
    On the other hand, the physicists, mechanical and electrical engineers I've worked with have been almost universally better engineers than the CS grads, with little or no formal CS training.
    - Duplicate-Fiber 5y ago
      My experience has been different. The backgrounds of the best engineers that I’ve worked with has been extremely varied: CS, History, Physics, Economics, Psychology, EE, etc.. However, one of the most frustrating colleagues has been a former Chemical Engineer. In 15 years, he has only implemented new technologies when absolutely forced to by people higher in org chart, even when the need is beyond obvious. He fought against 64-bit computing, hypervisor virtualization, automated config management, privileged account management, SaaS apps, and IaaS cloud platforms. So, I don’t think that you can determine whether someone is a good engineer solely based on their background. I just try to stay away from the people who want to change everything and the people who want to change nothing.
technion 5y ago
As a bit of a counterpoint to most other posts: I started working on a project where the lead developer told me they had no idea what OS their product was designed for, or even "if it needs a server". I spent a few days going through the source code working out "well it turns out they need x". Followed by coming up with a deployment process, and starting an fight to push everyone to use source control. According to the person running the show, they no longer needed an Enterprise Architect, because I'd completely filled what they expected of that role. This was a large Government project that would usually expect someone in such a role.
- Guthur 5y ago
  "This was a large Government project" that's your problem right there :)
  - technion 5y ago
    It wasn't a problem though. There's actually nothing wrong with someone saying "so I'll recommend this style of deployment, and management will get on board" over saying "each developer will just deploy their bits of code where they want" and ending up with two public clouds and a backend on some guys laptop (seen that in a small startup).
- ClumsyPilot 5y ago
  "would usually expect someone in such a role." Sometimes the roles are not there for you to produce usefull output, they are there to make sure massive mistakes aren't made and to have someone to hold to account when shit goes wrong.
bruce343434 5y ago
Vague article
- Slaren 5y ago
  In sociology, we've previously explored how a child often finds changes challenging. Then I produced a review on this topic, but putting it together and, to some extent, marking the final material to present it was difficult. That's why I came across essay writing service uk https://www.rushmyessay.co.uk/ https://www.rushmyessay.co.uk/ , where you promptly assisted me and made everything perfect. I hope I was able to assist others who aspire to write professionally.
arcturus17 5y ago
The article is a rhetorical trainwreck… For example it abuses emphasis - so the reader has to decipher all these hidden meanings in the author’s head - and is overly vague and lacks any examples to ground it. I’ve been lured in by an interesting title and have left scratching my head as to what I’ve just read.
- lbayes 5y ago
  It reads like pretty good GPT to me.
- richnwan 5y ago
  So I wasn’t the only one? I honestly have to question if this is a gpt-3 generated article
  - gctwnl 5y ago
    Definitely not
- tannhaeuser 5y ago
  TBH I also came for a good round of enterprise cost-center IT bashing but then wasn't understanding what the medieval torture copperplate engraving and digression about the word labor has to do with anything.
kgeist 5y ago
>Consider the etymology of the French travail and the Spanish trabajo, each a translation of the English noun “work”: their Latin root is trepaliare, “to torture, to inflict suffering or agony.” I also like this parallel: Latvian stradat "to work" Russian stradat "to suffer"
throwaway704 5y ago
I do this job. many people on HN would consider me an idiot i am sure many would be horrified to think that someone like me does this.. but here is my honest opinion: Consider me a noob-to-intermediate at many things in IT: infrastructure, development, networking, hardware all sorts.. i can generally understand the chat and the road blocks, and given any specific problem can suggest options and google/research as much i need to get up to speed. I have a similar type of knowledge for organisational functions (you could call it back office roles). I generally know what a payroll admin or accounts payable cleck does, what may a buyer or logistics specialist do.. not just in terms of where they sit in the org chart etc. but what data they work with, what challeneges they have, what software they use, standard processes consistent across orgs. The job definition i carry internally in my head is: strategically align people, processes, data, and systems under governance. You can call that BS all you want, I could make a strong case myself. However steel-manning it i could also say: the lines of decoupling at each of these levels must align with the organisational governance processes and be ready for changes in the direction the current strategy indicates. Essentially the software interactions and dependancies should have a certain similar look as the business process interdependencies. if i only need HR approval to change a given process, then the software and system changes should only require HR sign off (bar regression testing) to go live. This allows change to happen, increases engagmenet and that all to elusive user/business ownership - because they can understand their tools (at some level) and what freedom of movement they have. To me this means that the key skills fo a solution architecht are as much in the spaces of governance, business process definition, human interaction and behaviours etc. as they are anthing to do with IT. from the IT side i mainly have to know how to be an intelligent customer (capable of debugging code, reverse engineering and evaluating algorythms etc. ideally only as a last line of defense against bullshitting of non-imganitive technical people). Day-to-day what i do is talk to people and draw simple clear diagrams - creating abstractions that are strong enough to make sensible decisions around by backing it up with as much data and analysis as is needed. i see it as a communication and alignment role.. done right this work has the potential to be the greatest value multiplecation avaiable to an org... there are bullshitters out there (many many of them), but I hope everyone gets to see someone perform this role well at some point and appreciate the nuance and subtelty required (not saying that is me but i do try hard). IMHO the reason this role exists is because the gulf between "the business" and "IT" is way to big - otherwise you would have senior devs looking after their own systems and the business owning solutions/landscapes. I believe this role is done by business analysts often.. a very technically aware BA is the same as a very business aware IT consultant - honestly so long as you can get the right people in the room and they will hear/respect your agenda it doesnt matter (titles are BS, skills and knowledge matter). I am so far onto a different spectrum to the mulesoft and complex mess diagram crowd; if encounter that, i will only test the water with alternative architecture suggestions (often involving suggestions of interacting with the business more openly/honestly).. if that doesnt get immediate traction i know its time for me to look elsewhere for work. as one way or another, staff atrittion is going to be what gets the message out there, nothing else.
thrower123 5y ago
I wish that dedicated Ops people still existed. From what I can tell, DevOps has just meant less butter scraped over more pieces of toast. I used to be able to say to customers, "Our product needs a VM with xyz specs, and access to a database, and incoming HTTP connections," and their Ops team would take that recommendation and go spin it up. Now I'm dragged into the weeds of every little detail, because I'm really dealing with a PM who used to be a support person and doesn't have basic competency doing Ops work. Part of this is that Azure and AWS have made spinning up resources so easy that people can do it without knowing what they are doing.
BLKNSLVR 5y ago
> The frustration is that it will become harder to explain the ‘top’ what is going on and it will be particularly difficult to convince. This is especially true if that top has no interest in actually paying attention, because then it will be even harder as the first difficult step is to get them to hear you out. It seems entirely personal to the individual manager as to the level of detail they're willing to even listen to, and experience is the only way to learn, which only gives a number of opportunities to not piss them off.
andreskytt 5y ago
IMHO the source of confusion comes from how the term Enterprise Architecture has been interpreted not as the “Architecture of the Enterprise” but as “Architecture of IT systems in an enterprise”. Of course it gets frustrating, when the part you are trying to architect is inseparably intertwined with what you can’t - the rest of the organization. I’m trying hard to assemble a theoretical basis around the former definition from the MIT Systems Architecture paradigm and have been teaching it like this for several years now with moderate success. But I’m yet to find a single source moving in the same direction. Maybe I’m looking in the wrong places?
- gctwnl 5y ago
  The architects that think enterprise architecture is about designing enterprises and not about managing the effects of complexity that comes from IT at enterprise scale are generally the useless ones.
maigret 5y ago
Many people here seem to misunderstand the role of an architect. This is actually one of the most demanding in IT, and it usually has a tremendous impact on the team and on the business. A bad architecture will make engineers stressed for deadlines and will put the support under pressure, and ultimately the business will be impacted. A great architect is, while mostly not directly involved in the daily team process or code, not only able to draw diagrams but also to produce demos and working examples of their ideas. Also, they are good communicator, resolving conflicts when needed and choosing their battles wisely. They are rare, but I’ve seen a few great architect at work, and their ability to make hard things happen was very impressive. Complex projects often involve many teams and many stakeholders, and getting all aligned on a common goal is not easy, but the great ones master that.
- gctwnl 5y ago
  Agreed. And in my observations, these architects were engaged deep in technical discussions. They weren't the 'powerpoint-slide' types.
  - throwaway704 5y ago
    I don't shy away from the technical discussions peronsally. and i dig into the details - i want to see the code, data structures etc. If i can get access to test every system and try to break it i will. However the documentation of those things at that level of detail is not for the architecht.. the interfaces and dependencies and how they align (or do not) seem more the documentation they should be working on. my powerpoints may be high level but they must be accurate and comply with the true technical and business details and edgecases. IMHO the fewer slides and simpler diagrams that can still acurately do this (accuratly enough for decision to be made and to give freedom of movement to both IT and business stakeholders) the better - thats sort of the definition of good architecture in a way. But its a role that is not always needed and the more integrated IT and the business are and the more they understand each other the less its required.. as they will mirror each other natrually given the chance. EDIT: to be clear i dont "work" in powerpoint.. but i do copy and paste into it to increase engagement and remove barriers :) I "work" mostly in text files, databases and visualisation tools.. i want to communicate with each stakeholder in their preferred format if possible. Whenever there is a blocker i will happily try to mock up a solution in whatever tool that team is using, it dont default to fixing others problems though, i get enough shit for sticking my nose in as it is. this jobs requires keeping as many people as possible on side, burning bridges like that is risky business
ramoz 5y ago
Enterprise IT is hard because of human capital facing rapid technical progression, but also because technical abstractions have a cost. Should think in systems, not architectures.
reilly3000 5y ago
It is frustrating to the architect but it frustrates everyone they affect by the nature of the job. For better or worse, the actual process of execution means lots of the M word… migration. Data has to be moved, people have to be trained into new habits, managers have to put their other initiatives on hold while the business retools. You have to really love growth and change to be willing to endure the resistance that comes along with it- even with the perfect project.
- andendau 5y ago
  Agreed. I think with the pace of change happening more frequently it might require more disciplined focus on training, constraining systems, and number of products.
ggeorgovassilis 5y ago
A sign of the times is that people with no CS/architecture background aced the TOGAF certification exam while people with actual EA exposure had to take it twice.
- gctwnl 5y ago
  Nobody I take serious takes TOGAF serious. A while back Grady Booch was asked on Twitter what architecture books he would suggest. He replied with three images of sets of covers of what was on his bookshelf (some 45 books in all, I think). All of them more software architecture style books. One EA book: Chess and the Art of Enterprise Architecture. Which I personally found noticeable.
gctwnl 5y ago
One of the more interesting aspects is that the idea of what (enterprise) 'architecture' is, depends on who you talk to. There is an interesting relation between agile and architecture. https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meaning-of-architecture/ https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meani...

195 points by gctwnl 5y ago

Big corportations seem to be retarded in this area for sure. What seems to be working is skipping almost all meetings at the early stage about it – just go straight to PoC and start discussions from there. Also be careful what you wish for - because if it goes ahead – it may become business critical quickly, which means doubling team few times, onboarding systems/teams while providing near zero error rate/downtime etc.

hughrr 5y ago

This is actually spot on. I was offered a promotion into this space which I sensibly declined as money is a poor motivator for me. This was a surprise to the company. The poor guy who did get promoted is stuck with exactly This situation.

holoduke 5y ago

The word 'enterprise' alone is enough reason to walk away for me. Some companies have hundreds working with those titles. Beyond my understanding what they all do.

killtimeatwork 5y ago
A large enough company, which can have thousands of systems running in prod, needs someone to be the gardener pulling out the weeds (systems which duplicate each other's functionality, systems which try to introduce obscure technology for no benefit etc.) and also design the company's systems landscape (start initiatives, kill existing ones, move data and functionalities between systems etc.) so that it fits company's goals. Typically, you have to come up with some strategic vision and then convince all the high-level managers affected to commit to it - and then steer the execution across all teams, so that all the pieces come together. It's basically big picture job, and very difficult to do well, since it doesn't come with any managerial power or budget - EAs are the Cardinal Richelieus of corporate world.
- jiggawatts 5y ago
  Just to add to what killtimeatwork said above: I'm watching what happens when enterprise architecture is done badly, right now. I'm currently assisting a huge agency that is a mish-mash of smaller agencies. Multiple clouds, several data centres, hundreds (if not thousands!) of "apps" and servers. Every combination of bare metal, VMs, and cloud IaaS, PaaS, and SaaS. Much of it overlapping or redundant functionality. It's an unmitigated clusterfuck: A nightmare tangle of interdependencies, band-aids, duplicated systems, inconsistent DR, non-existent DR, partial HA, and on and on. If you've ever seen a "spaghetti base" in Factorio, it's like that, but as if a hundred players had been building one for a decade. Not just spaghetti, but multiple interwoven styles of spaghetti. It's hard to explain to someone who hasn't seen it. Recently, someone upgraded a Layer 7 load balancer in a legacy data centre and broke an application in an unrelated Public Cloud because someone hard coded a HOSTS entry for the internal certificate CRL distribution point. Why was a cloud service using legacy internal PKI? Reasons. Why did it need a HOSTS entry? More stupid reasons. The technical details don't matter, of course. The moral of the story is that because they don't have a good EA at the helm, they're still adding to the spaghetti. I'm watching this unfold in slow motion. Layers of new stuff just draped over the existing garbage. No uplift. No clean-up. Nothing ever turned off. Just buried under new strata, slowly fossilising. It's fantastic yet horrifying to watch, like a slow motion shipwreck.
  - pjmlp 5y ago
    The irony is that with enough experience, you get a gut feeling for these kind of scenarios and the only thing one can do is to fasten the seatbelt and brace for impact, because of the politics involved no one really wants to listen.
  - ownagefool 5y ago
    When you say reasons, for me those reasons vary from "we have a PKI and I'm lazy" to "EA told me we have a strategic PKI that I have to use". And it's typically not the former, because getting the network connectivity is usually way more effort.
    - 5y ago

Aeolun 5y ago

I’m not sure what this role even does. As far as I see them they just appear in meetings once in a while to mess up our (the actual dev team) carefully balanced schedule by suddenly requiring us to do something completely different. Like suggesting it would be better to stick with Javascript over Typescript since it would be more stable.

FourthProtocol 5y ago
Simplisticly they do the same as you when you think about the building blocks or components of an app. They just do it at that dreaded "higher level". Higher level can be a bit ambiguous. Typically it's systems (ALL the apps in your org, their purpose, interrelationships, security, and so on). The good ones are able to identify, analyse and optimise processes, old and new tech, finance, and regulations the Co. is bound by (know your customer, HIPAA, GDPR and so on). They talk to C-level boss types and make a case for whatever they're making a case for. They do stuff like tracking and magaging risk and stakeholders, but at a higher level than dev. They (the good ones) also sleep less than you do, and know EVERYTHING about coffee. I've been doing this for some time and wrote down some of the things I learnt - https://www.wittenburg.co.uk/Work/Consulting.aspx https://www.wittenburg.co.uk/Work/Consulting.aspx
- Koffiepoeder 5y ago
  Thanks for this resource, definitely going to look into it. I am currently considering to make the freelance/consulting jump, so timing is ideal.
- unixhero 5y ago
  Very good resource, thanks for publishing your thoughts. The reference model is similar in spirit to the PRINCE2 overall framework: https://www.knowledgetrain.co.uk/res/prince2-processes-activities-v5.2.png https://www.knowledgetrain.co.uk/res/prince2-processes-activ...
  - FourthProtocol 5y ago
    Thanks and yes it is. The model is in fact an extrapolation of Microsoft's Solution Framework from the '90s. On the problem solving side I was far more impressed by a book from Betty Vandenbosch (Designing Solutions for Your Business Problems: A Structured Process for Managers and Consultants) than I was by Prince.

gonzo41 5y ago

I've often thought the other half or the Agile thing would be to try and build systems with really tight depreciation schedules so you are forced to retire a system and either rebuild or rethink the business context. So much of my work is trying to coax people to understand the operating environment has changed and we don't need a new thing, we instead need to do new things.

sach_r35 5y ago

Love the intro etymology lesson. In my exp, such roles don't seem to be super well-defined.

Foobar8568 5y ago

Oh it reminds me of one who used to be a sales consultant for an useless "modeling" tool (only by name) that nobody in the company wanted beside the CIO as it was on "required" on a Gartner checklist and ended up as the enterprise architect. The guy has never wrote a single line of code in his life, nor has seen a source code. It was madly frustrating, the rest of the IT leadership and developers were as bad

laurent92 5y ago
IBM?
antman 5y ago
Gartner has checklists?
- hughrr 5y ago
  Yes each one has an elaborate story and a pile of cash behind it.
  - vishnugupta 5y ago
    My recent realisation has been these shops fall in a category of what I call "rating agency" all of which share common characteristics. For example; Moody's, Gartner, Michelin Stars. 1. Stripped of all the paraphernalia these are yellow pages ranked by popularity in their domains. 2. They are in the business of selling customers to the said businesses. So their primary customers are businesses; restaurants, mutual funds etc., 3. They need to maintain authenticity of impartiality so it's not easy to find out how they make money. 4. Their secondary audience is decision makers; CIOs, money managers etc., Think of -- "no one got fired for picking at the 1st ranked software from Gartner's list", "But Moody's rated it AAA, how was I supposed to know that fund would tank". It's a terrific CYA tool. 5. I'd say about 80% of the times they do a decent job of stack ranking. But there is an element of virtuous cycle there. The top rated "things" are popular because they are ranked to be so by these rating companies. Once a critical mass adopts then that tech/restaurant/etc indeed becomes numerically popular.

unixhero 5y ago

Well it certainly has propelled my life, bank account and career forward. I don't expect work to be (edit: purely) fun. I expect the rewards to be, and they certainly have been.

deleted 5y ago

[deleted]

ddmma 5y ago

Makes sense while working in EITA department but not that much before or even after. Actually the majority of the company not having a clue about their strategic role, that makes it so medieval hardcore.

pram 5y ago

Very senior titles can be difficult indicators of competence because it’s usually someone decently smart and political, or someone in a terminal position that’s been at the company for a billion years and is doing the ol “rest and vest”

tannhaeuser 5y ago

Which person on the intro graphic is to be associated with the role of an architect, though?

gctwnl 5y ago
The one one the rack

cjfd 5y ago

The article does not seem to be telling us what is the cause of this difficulty to change anything. Is it maybe the quality of the existing solutions that makes it very difficult to change them? I, personally, am inclined to blame the 'technical debt' philosophy. If you never clean up your messes, things will go slower and slower and slower. Also, the mythical man month comes to mind 'add more people to a project and it will take longer'. The biggest problem of too many people being that knowledge becomes increasingly fragmented. So, one should have fewer people than one actually needs in order to make sure that they have enough knowledge.

ownagefool 5y ago
Enterprise IT usually wants to push change without getting their hands dirty. Downstream that means you get people who don't care about about their profession just following orders, or you disrguntle them because they don't understand why they're not able to define a reasonble architecture and instead have to follow the edicts of that weird out of date team that gatekeeps and aren't involved in the problem. Of course, reality is sometimes the product teams don't quite get the full picture and need a guiding hand, but from my experience having someone removed from the practicalities of the situation usuaully doesn't help.
gctwnl 5y ago
The article is simply saying that with the growth of IT, change is getting harder (existing landscapes have inertia), something the top is slow (if at all) to accept. That makes the role of the person trying to explain that (and why) change is getting harder a more frustrating one.

livinginfear 5y ago

I used to be involved in solutions design a few years ago. Now I've retreated somewhat to being just a regular 'senior developer'. Solutions design, architecture, and DevOps stopped being interesting to me as soon as they inexplicably became a frustrating exercise in understanding every single method Amazon Web Services has conceived of to cost the company money.

kennu 5y ago
On the other hand, it doesn't make much sense to keep reinventing the same things that AWS has already packaged into convenient and reusable little Lego blocks. I guess the excitement of inventing new stuff needs to be related to new technologies not yet commoditized.
- zo1 5y ago
  Dunno what everyone else thinks but these AWS Lego blocks are anything but convenient and reusable. Frankly they're oversold from my perspective as someone that came a little late into the "aws cloud" game.
  - scient 5y ago
    Unfortunately I think the issue not AWS here. You say you lost interest when it became a frustrating exercise, I read it as you lost interest once you realized setting up a cloud environment is not trivial.
  - tyingq 5y ago
    My experience is "it depends". I had, for example, a good experience with AWS Fargate. It's not inexpensive, but it did what it said it would. It let me focus on packaging apps into containers, and caring less about making them elastic. I had the opposite experience with Lambdas/Serverless. It made easy things very slightly easier, and hard things impossible.
    - Nextgrid 5y ago

lkrubner 5y ago

I find this essay to be abstract to the point that it is difficult to understand what the real point is. In contrast, I’d like to recommend my essay, already much discussed here on Hacker News, which covers the same subject (the difficulty of change at large firms) but with a detailed look at one of the world’s largest car rental companies: http://www.smashcompany.com/business/why-are-large-companies-so-difficult-to-rescue-regarding-bad-internal-technology http://www.smashcompany.com/business/why-are-large-companies...

mirekrusin 5y ago
I work with one of very large companies and I'm unfortunate to witness work of mulesoft as well, I don't know if this whole platform is simply so shit or the team "doesn't hold it right" but I would not surprise me if the sole problem in linked article is just that - mulesoft. Maybe it's programming-by-filling-in-wizards or something else - I don't know and don't care, judging from the output I see, they don't deserve to be called "system integration" by any standards, my recommendation is - avoid.
- cgio 5y ago
  I have used Mulesoft, and while it was not the most exciting technology I would not consider it shit. Also I don’t remember it being wizard based, but could have changed in last couple of years. Depending on your role, if you don’t care what the root cause is you also don’t need to worry about it. Ask the people who have to care what the issue is and help them in resolving it.

davedx 5y ago

Ehh. I’ve worked as an architect alongside solutions architects and also directly under them. It’s a tough job but this whole post seems to be saying it’s hard because communication (engagement) with upper management is bad? This is an org specific problem not a systemic one. (My own anecdotes while working as an architect within an enterprise: some upper management - director level - engaged very constructively with architects and principle engineers).

123pie123 5y ago

Enterprise always operate on (usually oldish) stable versions so that allows some breathing space of time. and a good enterprise will have a reasonably well defined road map that can be used to set expectations of future risk/ technical debt

gctwnl 5y ago
Road maps are generally pretty useless. They are a form of trying to predict the future. Good Life Cycle Management is of course OK, but you cannot predict what you will need a year (or two) from now.
- 123pie123 5y ago
  >but you cannot predict what you will need a year (or two) from now. I imagaine enterprise systems is like steering a monsterous size oil tanker. for the size of systems I work with - two years is extremely easily predictable. The shiney shiney new stuff does sway a few new green field projects, but keeping many very expensive systems (to develop and high impact if they fail) running/ up to date/ partially changed is the boring stuff thats is very critical to a lot of companies
tatersolid 5y ago
> Enterprise always operate on (usually oldish) stable versions so that allows some breathing space of time. Until it doesn’t. The number of enterprise projects I’ve seen that were “emergencies” due to neglecting updates is astonishing. If you’re not updating a COTS or custom system at least semi-annually you’re going to have a zillion security vulnerabilities, and will lose all institutional knowledge of operations and upgrade of said system. Then the stuff really hits the fan when you’re forced to upgrade due to EOL/EOS. This is the real reason SaaS is now popular.

wanderingmind 5y ago

It's easier for me to find a job as an Architect as all I need is to know the outline AWS/Azure tools and some ability to bullshit. Compare that to having convince recruiters that my background in MATLAB modeling can be transferable to do Python development. I'm happy to bullshit and collect a paycheck.

witcher 5y ago
Sure, you can fake that you do the job in any role if you want. Question is, do you enjoy doing this, going to such work every day?
- wanderingmind 5y ago
  Nope I don't think anyone can enjoy faking for a long time. but its hell of a lot better than going hungry without a job.
- ClumsyPilot 5y ago
  I think the key question is - does he perform any worse than someone with the 'right' background? I am not sure
dragonelite 5y ago
knowing AWS and Azure is like insta hire, only reason i studied for AZ-204 certificate just to fill up my resume and the boss paid for it. 3 weeks later I forgot like 75% of the material xD. It was really more a strategic carrier move then a love for cloud knowledge move.
- pjmlp 5y ago
  The large majority of certificates are like that, sure the HN and Reddit crowd might shit on them and how they are useless, however in enterprise computing they are the key for even being entitled to buy from certain providers. So it isn't the knowledge one gets from the certificates, rather the checklist from having them in first place.

leroman 5y ago

This is a necessary and an important position to fill, as now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product (except for risks down the road). Companies need someone who understands the trade-offs, knows which use cases are right for this architecture and save the company (and future devs working on these systems) a lot of headache.

tarsinge 5y ago
That sum a critical part of my job, help clients navigate and find the middle-ground between bloated old-school enterprise solutions on one end and hype/resume-driven developers on the other.
Nextgrid 5y ago
> now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product Is there a way we can push back against this? I feel like the battle has been lost and it's not just devs being guilty of this, it's entire companies. For a lot of startups it seems that solving the business problem is now secondary to engineering itself, aka how many microservices and moving parts they can cram into their stack so they can then give talks about it and write on their tech blog. I've lost business in the past because a client wanted to build a prototype with Lambda and similar. They were either severely misguided, or their main objective wasn't to build a successful product but merely present themselves as the next hyperscaler due to the complexity of their tech stack (all to serve a whopping 2 HTTP requests/second, if even).
- res0nat0r 5y ago
  I think this has been going on forever. I've had to deal with folks since the dawn of time who want to just try and make the geekiest new nerd tech out there part of their project because they want to screw around with something fun. It doesn't matter if it's 10x more complex or hard to support, it's a new toy to play with so folks want to use it. You have to filter those people out as being unreliable, and also when dealing in enterprise level companies also keep out of the room the complete and utter idiots who have no idea what they are talking about and haven't touched any of the tech hands on in decades but want to also throw up road blocks to everything you propose.

dkdbejwi383 5y ago

I’m not sure I really understand what “solution architects” do, or what value they bring. In my experience, they take a half-baked set of requirements and make a bunch of complex looking charts and diagrams that purport to explain how software that fulfils the requirements might be built. But most of the time, the “solution” is impossible due to various constraints they have glossed over, and doesn’t actually meet the requirements once you start to question what the user really wants. It seems to me the kind of role that fits in with waterfall-style planning, at odds with agile, yagni, building just enough and constantly iterating based on feedback from real users.

leroman 5y ago
A lot of the time, their job is to say "no", and shut down some over-engineered solutions brought fourth by dev teams
glogla 5y ago
Architects are supposed to sit higher, seeing both more systems (where developers focus on theirs) and seeing further in time (where developers are focused on their next release or two). I see the job of an architect to work on how things work together and make sure nobody "paints themselves into a corner". How well that works in practice is another matter of course. Architects have longer reach than developers, both in space and time, so the have larger blast radius. One bad architect can screw vastly more things than a bad developer.
angulardragon03 5y ago
(imo) Solution Architects are popular in big enterprise environments exactly because the organisation as a whole doesn't use/isn't familiar with agile or the like. They have to figure out what solution the org is looking for, how to best integrate it with what they already have, and how to do it with the least impact on employees. If the org has poor information management, getting requirements is already a mess, and the SA is already screwed. From what I've seen (with contracted SAs), SAs are just inventorying and working around the half-finished implementations the previous SAs left behind, ad infinitum.

djantje 5y ago

If you are capable to hold the overview for an organisation, and know the best interest of the organisation, you can become and IT Architect, if you can also communicate your ideas. Ofcourse this can come with great difficulty, and implementation of (some) of the ideas you might never see happening. I agree that upper management plays a crucial role, they have to be rightly informed, especialy if they hold the wrong intuitions. I also hold the believe that this is the case in smaller organisations and/or IT trajects, where there is no dedicated architect, or team of architects. Architecture is about envisioning the future and shaping how it looks and works, ofcourse you should take the role, if this is what you want. (No job is only easy and only fun, but it can be greatly rewarding at times, but as with most things, best do it for the doing of it ;)

bartread 5y ago

I'm as sceptical of the "architect" positions and the value they deliver, not to mention the job satisfaction they offer (or lack thereof), as the next person, but this is not a very good article: vague generalities, no examples, a poorly expressed and hazy argument to the extent that it's somewhat unclear what point the author is trying to make. Sorry, but no: this is not advancing the conversation. If anything it's illustrative of the kind of hand-wavy nonsense-talk that architects are often reviled for.

seanhunter 5y ago

I remember having a whiteboard conversation with an Enterprise IT architect. I drew my usual diagram of the actual systems and services and how they connect. He rubbed out all the arrows, drew a triangle and had all the arrows flowing into and out of the triangle. "What's the triangle?" I (perhaps naively) asked. "That's the source of ontological truth". That's when I realised there's a whole other level of ability that some people have. This guy was a zen master of bullshit.

finikytou 5y ago
I find it particularly true when I work with americans. this is because technical careers pay six digits in the USA. a sizeable part of the people that ended up in the technical field without really the right background or career just think they can do it because they got a degree from something "technical" that is not CS or even are so sure of themselves that they think they can do it even if they don't know how to. basically using salesmen training and candoit into the technical world. In europe that would never happen because people consider technical positions and knowledge below management skills and the crooks would end up into the mgmt positions because it pays better to be a PM than a tech guy. it is changing but slowly.
- ivan_gammel 5y ago
  In Europe there's plenty of people with CS-related degree and decades of experience, which stuck in 1980-2000s with their solution and organization design skills and thus slowly becoming generally incompetent. It is not only American feature.
- sidlls 5y ago
  On the other hand, the physicists, mechanical and electrical engineers I've worked with have been almost universally better engineers than the CS grads, with little or no formal CS training.
  - Duplicate-Fiber 5y ago
    My experience has been different. The backgrounds of the best engineers that I’ve worked with has been extremely varied: CS, History, Physics, Economics, Psychology, EE, etc.. However, one of the most frustrating colleagues has been a former Chemical Engineer. In 15 years, he has only implemented new technologies when absolutely forced to by people higher in org chart, even when the need is beyond obvious. He fought against 64-bit computing, hypervisor virtualization, automated config management, privileged account management, SaaS apps, and IaaS cloud platforms. So, I don’t think that you can determine whether someone is a good engineer solely based on their background. I just try to stay away from the people who want to change everything and the people who want to change nothing.

technion 5y ago

As a bit of a counterpoint to most other posts: I started working on a project where the lead developer told me they had no idea what OS their product was designed for, or even "if it needs a server". I spent a few days going through the source code working out "well it turns out they need x". Followed by coming up with a deployment process, and starting an fight to push everyone to use source control. According to the person running the show, they no longer needed an Enterprise Architect, because I'd completely filled what they expected of that role. This was a large Government project that would usually expect someone in such a role.

Guthur 5y ago
"This was a large Government project" that's your problem right there :)
- technion 5y ago
  It wasn't a problem though. There's actually nothing wrong with someone saying "so I'll recommend this style of deployment, and management will get on board" over saying "each developer will just deploy their bits of code where they want" and ending up with two public clouds and a backend on some guys laptop (seen that in a small startup).
ClumsyPilot 5y ago
"would usually expect someone in such a role." Sometimes the roles are not there for you to produce usefull output, they are there to make sure massive mistakes aren't made and to have someone to hold to account when shit goes wrong.

bruce343434 5y ago

Vague article

Slaren 5y ago
In sociology, we've previously explored how a child often finds changes challenging. Then I produced a review on this topic, but putting it together and, to some extent, marking the final material to present it was difficult. That's why I came across essay writing service uk https://www.rushmyessay.co.uk/ https://www.rushmyessay.co.uk/ , where you promptly assisted me and made everything perfect. I hope I was able to assist others who aspire to write professionally.

arcturus17 5y ago

The article is a rhetorical trainwreck… For example it abuses emphasis - so the reader has to decipher all these hidden meanings in the author’s head - and is overly vague and lacks any examples to ground it. I’ve been lured in by an interesting title and have left scratching my head as to what I’ve just read.

lbayes 5y ago
It reads like pretty good GPT to me.
richnwan 5y ago
So I wasn’t the only one? I honestly have to question if this is a gpt-3 generated article
- gctwnl 5y ago
  Definitely not
tannhaeuser 5y ago
TBH I also came for a good round of enterprise cost-center IT bashing but then wasn't understanding what the medieval torture copperplate engraving and digression about the word labor has to do with anything.

kgeist 5y ago

>Consider the etymology of the French travail and the Spanish trabajo, each a translation of the English noun “work”: their Latin root is trepaliare, “to torture, to inflict suffering or agony.” I also like this parallel: Latvian stradat "to work" Russian stradat "to suffer"

throwaway704 5y ago

I do this job. many people on HN would consider me an idiot i am sure many would be horrified to think that someone like me does this.. but here is my honest opinion: Consider me a noob-to-intermediate at many things in IT: infrastructure, development, networking, hardware all sorts.. i can generally understand the chat and the road blocks, and given any specific problem can suggest options and google/research as much i need to get up to speed. I have a similar type of knowledge for organisational functions (you could call it back office roles). I generally know what a payroll admin or accounts payable cleck does, what may a buyer or logistics specialist do.. not just in terms of where they sit in the org chart etc. but what data they work with, what challeneges they have, what software they use, standard processes consistent across orgs. The job definition i carry internally in my head is: strategically align people, processes, data, and systems under governance. You can call that BS all you want, I could make a strong case myself. However steel-manning it i could also say: the lines of decoupling at each of these levels must align with the organisational governance processes and be ready for changes in the direction the current strategy indicates. Essentially the software interactions and dependancies should have a certain similar look as the business process interdependencies. if i only need HR approval to change a given process, then the software and system changes should only require HR sign off (bar regression testing) to go live. This allows change to happen, increases engagmenet and that all to elusive user/business ownership - because they can understand their tools (at some level) and what freedom of movement they have. To me this means that the key skills fo a solution architecht are as much in the spaces of governance, business process definition, human interaction and behaviours etc. as they are anthing to do with IT. from the IT side i mainly have to know how to be an intelligent customer (capable of debugging code, reverse engineering and evaluating algorythms etc. ideally only as a last line of defense against bullshitting of non-imganitive technical people). Day-to-day what i do is talk to people and draw simple clear diagrams - creating abstractions that are strong enough to make sensible decisions around by backing it up with as much data and analysis as is needed. i see it as a communication and alignment role.. done right this work has the potential to be the greatest value multiplecation avaiable to an org... there are bullshitters out there (many many of them), but I hope everyone gets to see someone perform this role well at some point and appreciate the nuance and subtelty required (not saying that is me but i do try hard). IMHO the reason this role exists is because the gulf between "the business" and "IT" is way to big - otherwise you would have senior devs looking after their own systems and the business owning solutions/landscapes. I believe this role is done by business analysts often.. a very technically aware BA is the same as a very business aware IT consultant - honestly so long as you can get the right people in the room and they will hear/respect your agenda it doesnt matter (titles are BS, skills and knowledge matter). I am so far onto a different spectrum to the mulesoft and complex mess diagram crowd; if encounter that, i will only test the water with alternative architecture suggestions (often involving suggestions of interacting with the business more openly/honestly).. if that doesnt get immediate traction i know its time for me to look elsewhere for work. as one way or another, staff atrittion is going to be what gets the message out there, nothing else.

thrower123 5y ago

I wish that dedicated Ops people still existed. From what I can tell, DevOps has just meant less butter scraped over more pieces of toast. I used to be able to say to customers, "Our product needs a VM with xyz specs, and access to a database, and incoming HTTP connections," and their Ops team would take that recommendation and go spin it up. Now I'm dragged into the weeds of every little detail, because I'm really dealing with a PM who used to be a support person and doesn't have basic competency doing Ops work. Part of this is that Azure and AWS have made spinning up resources so easy that people can do it without knowing what they are doing.

BLKNSLVR 5y ago

> The frustration is that it will become harder to explain the ‘top’ what is going on and it will be particularly difficult to convince. This is especially true if that top has no interest in actually paying attention, because then it will be even harder as the first difficult step is to get them to hear you out. It seems entirely personal to the individual manager as to the level of detail they're willing to even listen to, and experience is the only way to learn, which only gives a number of opportunities to not piss them off.

andreskytt 5y ago

IMHO the source of confusion comes from how the term Enterprise Architecture has been interpreted not as the “Architecture of the Enterprise” but as “Architecture of IT systems in an enterprise”. Of course it gets frustrating, when the part you are trying to architect is inseparably intertwined with what you can’t - the rest of the organization. I’m trying hard to assemble a theoretical basis around the former definition from the MIT Systems Architecture paradigm and have been teaching it like this for several years now with moderate success. But I’m yet to find a single source moving in the same direction. Maybe I’m looking in the wrong places?

gctwnl 5y ago
The architects that think enterprise architecture is about designing enterprises and not about managing the effects of complexity that comes from IT at enterprise scale are generally the useless ones.

maigret 5y ago

Many people here seem to misunderstand the role of an architect. This is actually one of the most demanding in IT, and it usually has a tremendous impact on the team and on the business. A bad architecture will make engineers stressed for deadlines and will put the support under pressure, and ultimately the business will be impacted. A great architect is, while mostly not directly involved in the daily team process or code, not only able to draw diagrams but also to produce demos and working examples of their ideas. Also, they are good communicator, resolving conflicts when needed and choosing their battles wisely. They are rare, but I’ve seen a few great architect at work, and their ability to make hard things happen was very impressive. Complex projects often involve many teams and many stakeholders, and getting all aligned on a common goal is not easy, but the great ones master that.

gctwnl 5y ago
Agreed. And in my observations, these architects were engaged deep in technical discussions. They weren't the 'powerpoint-slide' types.
- throwaway704 5y ago
  I don't shy away from the technical discussions peronsally. and i dig into the details - i want to see the code, data structures etc. If i can get access to test every system and try to break it i will. However the documentation of those things at that level of detail is not for the architecht.. the interfaces and dependencies and how they align (or do not) seem more the documentation they should be working on. my powerpoints may be high level but they must be accurate and comply with the true technical and business details and edgecases. IMHO the fewer slides and simpler diagrams that can still acurately do this (accuratly enough for decision to be made and to give freedom of movement to both IT and business stakeholders) the better - thats sort of the definition of good architecture in a way. But its a role that is not always needed and the more integrated IT and the business are and the more they understand each other the less its required.. as they will mirror each other natrually given the chance. EDIT: to be clear i dont "work" in powerpoint.. but i do copy and paste into it to increase engagement and remove barriers :) I "work" mostly in text files, databases and visualisation tools.. i want to communicate with each stakeholder in their preferred format if possible. Whenever there is a blocker i will happily try to mock up a solution in whatever tool that team is using, it dont default to fixing others problems though, i get enough shit for sticking my nose in as it is. this jobs requires keeping as many people as possible on side, burning bridges like that is risky business

ramoz 5y ago

Enterprise IT is hard because of human capital facing rapid technical progression, but also because technical abstractions have a cost. Should think in systems, not architectures.

reilly3000 5y ago

It is frustrating to the architect but it frustrates everyone they affect by the nature of the job. For better or worse, the actual process of execution means lots of the M word… migration. Data has to be moved, people have to be trained into new habits, managers have to put their other initiatives on hold while the business retools. You have to really love growth and change to be willing to endure the resistance that comes along with it- even with the perfect project.

andendau 5y ago
Agreed. I think with the pace of change happening more frequently it might require more disciplined focus on training, constraining systems, and number of products.

ggeorgovassilis 5y ago

A sign of the times is that people with no CS/architecture background aced the TOGAF certification exam while people with actual EA exposure had to take it twice.

gctwnl 5y ago
Nobody I take serious takes TOGAF serious. A while back Grady Booch was asked on Twitter what architecture books he would suggest. He replied with three images of sets of covers of what was on his bookshelf (some 45 books in all, I think). All of them more software architecture style books. One EA book: Chess and the Art of Enterprise Architecture. Which I personally found noticeable.

gctwnl 5y ago

One of the more interesting aspects is that the idea of what (enterprise) 'architecture' is, depends on who you talk to. There is an interesting relation between agile and architecture. https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meaning-of-architecture/ https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meani...