[HN Gopher] Enterprise, IT architecture and strategy is getting ...
___________________________________________________________________
Enterprise, IT architecture and strategy is getting more and more
frustrating
Author : gctwnl
Score : 189 points
Date : 2021-07-31 09:46 UTC (1 days ago)
(HTM) web link (ea.rna.nl)
(TXT) w3m dump (ea.rna.nl)
| hughrr wrote:
| 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.
| livinginfear wrote:
| 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 wrote:
| 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.
| mpfundstein wrote:
| i dont know. i.moved a lot of services and functionality from
| aws to self hosted and open source and my monthly bill
| reduced to 100 bucks. from multiple k's
| zo1 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My experience with AWS services is that the ones that
| merely provide low-level building blocks (such as EC2) or
| host existing open-source software such as Postgres,
| Redis, etc are good, but the proprietary AWS-specific
| ones are bad because they not only lock you into AWS but
| make it more complex to develop against as you can't
| always run it locally (there is LocalStack, but it's a
| simplistic reimplementation that doesn't always reflect
| the real thing especially when it comes to edge-cases),
| can't inspect it or debug it easily (it is a black box)
| and costs money even during development.
|
| AWS-hosted Redis? Sure! AWS-hosted RabbitMQ? Of course!
| AWS SQS? No thanks - it wouldn't give me anything useful
| that RabbitMQ can't do, however it will lock me into
| forever having to pay AWS, deal with their terrible
| console (or stacks of YAML files) to control the thing
| and expose me to potential edge-cases I will have no way
| to debug or replicate locally.
| glogla wrote:
| Yup.
|
| The other axis is "do they dogfood?" meaning "if I go to
| amazon.com is the service used?"
|
| The services Amazon built for themselves - s3, rds, ec2,
| dynamo, ... are generally pretty good. Redshift and glue?
| Not so much.
| orf wrote:
| > AWS SQS? No thanks - it wouldn't give me anything
| useful that RabbitMQ can't do
|
| Allow other AWS services to send it events (SNS, lambda,
| etc etc)? Reliably handle millions of messages per second
| without managing anything yourself? Transparent KMS
| encryption? Fine-grained role based permissions via IAM
| without any hard-coded credentials?
|
| Come on.
| Ericson2314 wrote:
| > convenient
|
| I'm not sure about that.
|
| Until AWS's margins aren't insane, I will not trust their
| stuff.
| lkrubner wrote:
| 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...
| mirekrusin wrote:
| 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 wrote:
| 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.
| throwaway704 wrote:
| 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_.
| WDCDev wrote:
| Yeah this matches up with my experience when I was working as a
| consultant and trying to get large organizations to buy into
| managed and structured changes to their enterprise IT
| environment. It is not an easy job and it is very necessary for
| enterprises to coordinate their systems development. I've seen
| the messes first hand, the frustration from "the business" at
| how "long" everything takes. I've seen tech teams struggling to
| communicate the complexity of certain requirements in a way
| leadership can understand too.
|
| After 5 years I was done with that type of work. Way too
| frustrating to try and get buy-in from development teams,
| leadership, IT etc. to make changes necessary to support the
| business _at the enterprise level_.
|
| I do think SaaS has relieved form pain for organizations.
| Hopefully legacy Peoplesoft and Lawson systems are being
| replaced by things like Workday etc. It does open up a new set
| of problems (and expenses) but these seem way more manageable
| than the problems and challenges with working with on-prem
| ERPs.
| mattowen_uk wrote:
| You are not alone here my friend.
|
| I too am an Architect. Put very simply, our job is to bridge
| the technical-managerial gap. For all those devs on this thread
| saying we add no value or simply get in the way...
|
| What you don't see is all the meetings we have with senior
| stakeholders and c-suite level management where we explain to
| them why they need something, and how it's going to happen, and
| in words and diagrams that they understand. You call it BS, but
| in my experience what devs are NOT good at is summarising a
| problem or a solution into a single slide that conveys only the
| information needed to make an informed decision. I used to be
| one of those devs that thought everyone in the room had the
| same knowledge I had, and could keep up with the highly
| detailed descriptions I was sharing. Now I know different.
|
| Also, how do you think that you devs get given the deliverables
| you do? Someone has to step back and look at the whole
| infrastructure holistically and provide an informed steer on
| what the solution to a problem should look like and how it
| should fit into the architectural landscape yet also deliver
| what the business actually needs, and more often than not, not
| what someone 'wants', and also within a specified budget.
|
| We have to keep up with all the IT trends that cover the
| technology in use within the organisation, and be quick to
| pivot should something new appear that becomes the new IT
| strategy (something we also contribute heavily to).
|
| Being an architect is a thankless job, but as other have said,
| it pays well and is a natural progression for ex-devs or
| engineers who don't want to be people managers. That's
| certainly how I ended up being one.
|
| All that said, I don't enjoy my job, but no-one wants a 50 year
| old engineer or programmer who asks for an Architects salary.
| davedx wrote:
| 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).
| holoduke wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| closeparen wrote:
| The way my Silicon Valley company manages this is basically
| by having an infrastructure org. There is a catalog of
| about 3 managed storage services. One stateless compute
| platform. One HTTP ingress platform. One message broker.
| One workflow orchestrator. One RPC fabric. Two supported
| languages with central CI infrastructures.
|
| There are hundreds of teams serving specific business
| goals, and thousands of services between them, but
| everything gets made out of substantially the same parts.
| No one person has the 10,000 foot view, but the platform is
| sufficiently comprehensive and it's sufficiently hard to
| deviate, that no one really needs to.
|
| Now if you were hoping to have each team build from raw
| materials while still having coherence between projects, I
| can see why you might think you need this role. But I
| submit that it's probably simpler and more effective in the
| long run to just give people the building blocks you want
| them to use.
| ownagefool wrote:
| 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.
| jiggawatts wrote:
| Precisely. Enterprise Architects can fail by being bad at
| their job, or they can fail in absentia.
|
| This place is a heady mix of both.
| MattPalmer1086 wrote:
| Ah reasons... we've all had to approve horrible kludges to
| get something delivered.
|
| The truth is you never get completely clean beautiful
| architecture or code, there are always trade-offs to make
| along the way.
|
| Most change takes place in individual work streams, which
| are most concerned with delivering their scope on time and
| budget. There is typically no budget to consider changes
| that have wider scope or which might derail delivery. So
| kludges.
|
| But without the longer term vision and commitment to paying
| down technical debt it becomes spaghetti as you say,
| whether you're a developer or an architect.
| heisenbit wrote:
| Working at a big consulting company where we have enterprise
| and senior technical architect paths. The EA reaches salary
| wise one level higher. I deliberately stay on the technical
| one as doing the EA from the outside as consultant i.e. from
| the outside is really hard even if positioned correctly. The
| nature of the EA job is political and long term. Often
| product/service follows organization so to affect change one
| needs to reshape the org in selective places requiring really
| high level sponsorship.
| thrower123 wrote:
| 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.
| seanhunter wrote:
| 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.
| gctwnl wrote:
| Yep, there is a _lot_ of BS in EA.
| finikytou wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rightbyte wrote:
| Maybe he tried to make the point that he wanted the discussion
| on a less detailed level?
| loopz wrote:
| The funny thing is that at the physical layer, it's more or
| less true. With things like F5 even more so.
| drewcoo wrote:
| What does it even mean for the arrows to flow _into_ the source
| of ontological truth? That's possibly an amazing compliment!
| throwaway704 wrote:
| steel-manning for fun: if its a master data governance tool
| then you could use it to load all systems master data and
| also extract all master data from those systems and reconcile
| it to ensure all rules are being followed. you may even use
| this info to trigger masterdata workflows..
|
| there are so many bozos faking this precicley because a
| surface glance doesnt necicarily tell you they are full of
| shit.
|
| A key indicator is do they dig into code?, do they look at
| data bases?, do they mock stuff up and prototype? do they
| reference company strategy and financial targets?.. they cant
| just talk the talk, they also have to walk the walk.
|
| If someone said this to me then showed me a prototype
| integrated masterdata and business intellignence solution,
| how it would interface with busines governance, change
| management etc. i would be happy.. if they just had that
| triangle and wanted someone else to "do the technical stuff"
| then its another story :)
|
| Or a cheeky way of looking at it.. does involving this person
| normally make things more or less clear? does the time to get
| value from work reduce or increase?
| Aeolun wrote:
| 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 wrote:
| 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
| unixhero wrote:
| 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-
| activ...
| FourthProtocol wrote:
| 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.
| unixhero wrote:
| Great, thanks for the book reference. I will look into
| that. Even the PRINCE2 framework itself states that it is
| meant to be adapted to the context where it is applied.
| It is way overkill when applied 100%, which has led to
| several IT fiascos[0]. But the workflows and overall
| goals PRINCE2 seeks to achieve are productive I would
| say. I have applied it to orgs where there was NO insight
| into how to run projects and programs, it has at given a
| meaning to what we have been working on. It has also
| given legitimacy of why one chose to focus heavily on
| things which might seem uninteresting to some managers.
|
| Whenever I deviate we just say "since we're now in agile
| mode, we don't have to do this particular step here" :)
|
| 0, https://en.wikipedia.org/wiki/PRINCE2#Advantages_and_c
| ritici...
| FourthProtocol wrote:
| I agree. ANY structured process will be better than
| chaos. Most people dislike Prince especially just because
| it seeks to tame the chaos that came before. People don't
| like change.
| Koffiepoeder wrote:
| Thanks for this resource, definitely going to look into it. I
| am currently considering to make the freelance/consulting
| jump, so timing is ideal.
| [deleted]
| 123pie123 wrote:
| 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
| gonzo41 wrote:
| 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.
| ramoz wrote:
| 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.
| sach_r35 wrote:
| Love the intro etymology lesson. In my exp, such roles don't seem
| to be super well-defined.
| wanderingmind wrote:
| 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 wrote:
| 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?
| ClumsyPilot wrote:
| I think the key question is - does he perform any worse than
| someone with the 'right' background?
|
| I am not sure
| wanderingmind wrote:
| 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.
| dragonelite wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Nextgrid wrote:
| > 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 wrote:
| 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.
| lnenad wrote:
| Two of those are not like the other. Having queues in your
| system is most of the time a good decision. Decoupling
| workloads, buffering jobs, distributing workload, all of those
| are great benefits and with queues you get them all with an
| extremely simple interface (put, get). There isn't a lot of
| gotchas (there are some as with any software system) but it's a
| completely different thing compared to lambdas or kinesis.
| tarsinge wrote:
| 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.
| Foobar8568 wrote:
| 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
| varjag wrote:
| He's just good at seeing the big picture, you see :)
| zoover2020 wrote:
| Resume-driven development
| towelpluswater wrote:
| Erwin?
| laurent92 wrote:
| IBM?
| antman wrote:
| Gartner has checklists?
| hughrr wrote:
| Yes each one has an elaborate story and a pile of cash behind
| it.
| vishnugupta wrote:
| 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.
| fphhotchips wrote:
| I think it's worth adding: the domains that these
| organisations rank are chosen by those organisations. How
| the ranking works is chosen by the ranking org. A major
| source of revenue for the ranking orgs is conference
| sponsorships, and one of the things included in those
| sponsorships is access to the analysts writing the
| reports.
|
| It's also worth noting that ranking companies don't rank
| products, they rank vendors. So a company that does
| everything kind of ok over multiple products can get an
| advantage over a company that solves one problem very
| well with one product, if the ranking companies choose to
| define the category in an overly broad way.
| thrower123 wrote:
| With Gartner, you literally just pay them and they put
| you on their Magic Quadrant
| TecoAndJix wrote:
| Have a source on this? I researched this and found that
| the only benefit of paying them as a client is access to
| the analysts that make the determination.
| rapnie wrote:
| I've been in a company where the slick presentations of
| marketing & sales were instrumental in placing our product
| in the 'Leader' quadrant with features we didn't even
| offer, but were subsequently asked to 'just build'. It was
| terrible.
| hughrr wrote:
| Oh yes we had one of them. It was a leading vendor in
| security analysis. We pointed their product at itself and
| it kicked out a ton of CVEs and lead to a very
| embarrassing Zoom call for them :)
| GekkePrutser wrote:
| Yeah I worked with some solutions that Gartner considers
| 'Magic'. And one that wasn't.
|
| The one that wasn't is so much better and the magic one is
| still playing catch up. Most people that actually work in
| the field also consider the non-magical solution the best
| by far.
|
| I really think this is just a 'who paid us the most'
| contest.
|
| Ps I'm also an Enterprise IT architect and also leaving it.
| Not sure if my reasons are the same as I didn't get a
| chance to read the article yet :)
|
| But in my case the reason was that we're becoming too much
| of a Microsoft shop. It went from 'Find the best solution
| and implement it' to 'Implement what Microsoft tells us
| to'. Usually those solutions are _not_ the best and I end
| up having to find workarounds for workarounds. Sure all the
| integration is great but it 's more of a walled garden
| thing than a real benefit.
|
| Basically ruined the job for me.
| hughrr wrote:
| Good luck with that one. When you're a unix guy with a
| Dell slapped in front of you running windows that you
| can't do anything useful in then you know you've reached
| peak enterprise IT!
| unixhero wrote:
| 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.
| BLKNSLVR wrote:
| > 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.
| arcturus17 wrote:
| 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.
| richnwan wrote:
| So I wasn't the only one?
|
| I honestly have to question if this is a gpt-3 generated
| article
| gctwnl wrote:
| Definitely not
| tannhaeuser wrote:
| 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.
| lbayes wrote:
| It reads like pretty good GPT to me.
| technion wrote:
| 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.
| ClumsyPilot wrote:
| "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.
| Guthur wrote:
| "This was a large Government project" that's your problem right
| there :)
| technion wrote:
| 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).
| andreskytt wrote:
| 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?
| maigret wrote:
| 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.
| kgeist wrote:
| >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"
| [deleted]
| reilly3000 wrote:
| 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 wrote:
| 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.
| dkdbejwi383 wrote:
| 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.
| angulardragon03 wrote:
| (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.
| CapricornNoble wrote:
| >>>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.
|
| ^This has been my life for the past 5 years. I was the
| Information Management Officer for a military org with
| ~25,000 personnel, and our org suffered ~50% turnover in
| senior leadership EVERY SUMMER. It's been like groundhog day,
| every day. Operations personnel don't have the domain
| knowledge of the IT systems and Communications folks don't
| have the domain knowledge of the Operations, so neither side
| can put together a coherent, efficient architecture alone.
| The IMO is supposed to bridge that gap, focusing on
| documenting the business processes and helping to turn those
| into requirements, and possessing just enough IT systems
| knowledge to sanity-check the solutions proposed by the
| Communications staff. It's even harder to document the
| business processes when they are a) evolving b) rarely
| adhered to c) massive in breadth/scope. Sometimes the job
| entails telling Senior VP/ C-level staff that their proposed
| solution is dumb and completely unworkable.
|
| Now I'm a contractor "Operations Research & Information
| Management Analyst" which basically means the same
| organization is paying me for my domain knowledge and
| continuity of experience in trying to get some good ideas
| from the past 18 months actually into production.
|
| Previously I had looked into what might help me bill myself
| as a Solutions Architect while job-hunting and 90% of the
| resources I found were just "how to sell people on AWS." -_-
| RandyRanderson wrote:
| Just as the process of building a bridge has a lead engineer,
| supported by likely many different different types of
| subordinate engineers, large IT projects succeed more with a
| similar structure and process.
|
| If you're building a bridge over a small pond, iteration based
| on feedback from users will likely work well.
| z3t4 wrote:
| Software development is not like building a bridge, it's more
| like building a road blindfolded and without planning, and
| without knowing if the road is for pedestrians, trains, or
| boats... So you build a dirt road aka MVP, but if you are not
| lucky it might involve tunnelling and also a few bridges. The
| key is to first "walk" the path, rather then laying pavement
| from day one.
| hyperman1 wrote:
| I've just seen a project desperately needing one. I'll have to
| be a bit vague in the description here.
|
| The project is migrating a lot of small interconnected pieces
| of software, each managed by its own team. None of the teams
| has any idea what the others are doing. There are smart people
| in the project, but each is on his own island.
|
| It turns out one of the pieces of software has been installed
| twice in 2 different locations, for decent reasons. Nobody
| noticed, so while migrating they were mixed up and replaced
| with 1 instead of 2 new versions. The resulting mess of wrong
| interconnections is very hard to untangle and causes all kinds
| of weirdness.
|
| Apart from that, no one really understands what has been
| delivered and what not, as nobody knows which chains of pieces
| are already complete. Different teams use different names for
| the same thing or even the same name for different things, so
| people don't even understand they are working on different
| aspects of the same thing. Recently somehow we managed for
| person A to configure a thing, while person B migrated it to a
| new server, loosing person A's changes.
|
| A solution architect should have some overview of what all the
| pieces are, what should be connected to what, and how the whole
| thing should behave.
| FooHentai wrote:
| I've been one for the last seven years, and recently quit
| because I felt unable to make positive contributions to the
| success of the organisation due to the way the role had
| developed.
|
| In an ideal world, solution architects are really your most
| senior design engineers, have long-term plans for how the sum
| total of your businesses IT systems fit together, and steer
| development, acquisition, and upgrades across all aspects
| (clients, network, back-end, in-house code, cloud etc) to turn
| those long term plans into reality.
|
| Without that view, a businesses IT landscape will lack cohesion
| resulting in higher cost, complexity, and risk. Done well,
| architecture can keep all those things at better levels as well
| as serving as a bridge between the technical world and
| management that often doesn't have the domain knowledge to
| understand the implications of the choices they make. Likewise
| engineering (whether software, infra, or network) likely don't
| have an agreed view of all the stuff outside of the tech itself
| and architecture is a place for that to be considered. Stuff
| like what support processes and staffing needs to look like and
| how it will be funded, or ensuring that some compliance gotcha
| coming down the pipe in five years time won't conflict with
| some technical minutiae being planned for right now and likely
| to still be there, or utterly essential, when that five years
| comes to pass.
|
| Now, that said that's just my personal interpretation and the
| role is interpreted quite differently from org to org. I
| probably won't re-enter the field because I have a dim view of
| architects that sit exclusively in the abstract conceptual
| realm all day long and don't/can't roll their sleeves up to
| design and deploy tangible systems and services any longer. The
| longer anyone spends in that abstract space, imo the more
| useless, self-serving, and eventually actively harmful their
| output becomes. Solution design and infrastructure deployment
| (storage, networking, client, systems management layer stuff)
| is more my speed but that realm is being eaten up by cloud in
| the SME space where individual contributions actually matter.
| leroman wrote:
| A lot of the time, their job is to say "no", and shut down some
| over-engineered solutions brought fourth by dev teams
| glogla wrote:
| 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.
| mirekrusin wrote:
| 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.
| djantje wrote:
| 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 ;)
| ddmma wrote:
| 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.
| bartread wrote:
| 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.
| pram wrote:
| 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 wrote:
| Which person on the intro graphic is to be associated with the
| role of an architect, though?
| bruce343434 wrote:
| Vague article
| cjfd wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2021-08-01 23:03 UTC)