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

https://ea.rna.nl/2021/07/31/dont-become-an-enterprise-it-architect/

by gctwnl • 5 years ago

195 131 5 years ago

ea.rna.nl

hughrr4• 5 years 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• 5 years 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• 5 years 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.

jiggawatts2• 5 years 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.

heisenbit• 5 years ago

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.

Aeolun• 5 years 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.

FourthProtocol3• 5 years 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

Koffiepoeder• 5 years 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.

unixhero3• 5 years 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-activ...

gctwnl13• 5 years ago

That is probably a good example of the _bad_ architects the article mentions

gonzo41• 5 years 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• 5 years ago

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

Foobar8568• 5 years 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• 5 years ago

IBM?

antman• 5 years ago

Gartner has checklists?

hughrr4• 5 years ago

Yes each one has an elaborate story and a pile of cash behind it.

varjag• 5 years ago

He's just good at seeing the big picture, you see :)

zoover2020• 5 years ago

Resume-driven development

towelpluswater• 5 years ago

Erwin?

unixhero3• 5 years 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.

ddmma• 5 years 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• 5 years 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”

tannhaeuser2• 5 years ago

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

gctwnl13• 5 years ago

The one one the rack

cjfd• 5 years 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.

ownagefool2• 5 years 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.

gctwnl13• 5 years 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• 5 years 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.

kennu3• 5 years 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• 5 years 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.

Ericson2314• 5 years ago

convenient

I'm not sure about that.

Until AWS's margins aren't insane, I will not trust their stuff.

mpfundstein• 5 years ago

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

lkrubner• 5 years 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...

mirekrusin2• 5 years 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• 5 years 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• 5 years 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).

123pie1232• 5 years 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

gctwnl13• 5 years 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.

123pie1232• 5 years 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• 5 years 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.

wanderingmind2• 5 years 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• 5 years 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?

wanderingmind2• 5 years 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.

ClumsyPilot2• 5 years ago

I think the key question is - does he perform any worse than someone with the 'right' background?

I am not sure

dragonelite• 5 years 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.

pjmlp2• 5 years 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.

leroman2• 5 years 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• 5 years 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.

Nextgrid2• 5 years 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• 5 years 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.

lnenad• 5 years ago

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.

dkdbejwi3833• 5 years 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.

leroman2• 5 years ago

A lot of the time, their job is to say "no", and shut down some over-engineered solutions brought fourth by dev teams

glogla2• 5 years 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• 5 years 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.

CapricornNoble• 5 years ago

>>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• 5 years ago

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• 5 years ago

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.

hyperman12• 5 years ago

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.

dkdbejwi3833• 5 years ago

To me it sounds like the devs in these disparate teams need to talk more and work closer together, rather than having a person whose job is to increase the distance between them.

FooHentai2• 5 years ago

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.

gctwnl13• 5 years ago

Architects that sit constantly in that abstract realm are useless (and they are not architects in my view). But there are architects that do exactly what you describe in your ideal world.

gctwnl13• 5 years ago

Architecture is simple: it is that in your landscape that is hard to change. Making design decisions that are wise is the task of an 'architect', which is just another word for 'designer' (though it has been sold as something else). How you organise architecture processes depends on how you organise development, but the subject is the same. For instance, too much yagni is awful: everybody ends up waiting when something is needed that was not clear before. Finding those elements that improve your future speed is part of a good architecture process. Secondly, users are very focused on features and defects, but architecture is potential features and defects, and users are not a good source for those.

russellendicott• 5 years ago

This is my job now as of 2 months ago. Best I can figure, the value we add is talking to the customer and translating their requirements into a build diagram for devops team that fits into the constraints of the enterprise restrictions.

Hashing out ports for NACLs, nudging them to use AKS instead of Beanstalk, deciding whether they need connectivity to corporate network, validating whether they go into a high/medium/low risk account, etc.

mirekrusin2• 5 years 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.

djantje• 5 years 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• 5 years 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• 5 years 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• 5 years 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• 5 years 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• 5 years 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.

rightbyte• 5 years ago

Maybe he tried to make the point that he wanted the discussion on a less detailed level?

_y5hn• 5 years ago

The funny thing is that at the physical layer, it's more or less true. With things like F5 even more so.

drewcoo• 5 years ago

What does it even mean for the arrows to flow _into_ the source of ontological truth? That's possibly an amazing compliment!

throwaway7043• 5 years ago

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?

gctwnl13• 5 years ago

Yep, there is a lot of BS in EA.

technion2• 5 years 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• 5 years ago

"This was a large Government project" that's your problem right there :)

technion2• 5 years 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).

ClumsyPilot2• 5 years 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• 5 years ago

Vague article

arcturus17• 5 years 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• 5 years ago

It reads like pretty good GPT to me.

richnwan• 5 years ago

So I wasn’t the only one?

I honestly have to question if this is a gpt-3 generated article

gctwnl13• 5 years ago

Definitely not

tannhaeuser2• 5 years 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• 5 years 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"

throwaway7043• 5 years 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.

WDCDev• 5 years ago

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• 5 years ago

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.

thrower1232• 5 years 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• 5 years 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• 5 years 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?

gctwnl13• 5 years 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• 5 years 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.

gctwnl13• 5 years ago

Agreed. And in my observations, these architects were engaged deep in technical discussions. They weren't the 'powerpoint-slide' types.

throwaway7043• 5 years 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• 5 years 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• 5 years 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• 5 years 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• 5 years 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.

gctwnl13• 5 years 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.

gctwnl13• 5 years 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-meani...

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

Related Stories