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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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?
Do you have examples of which AWS "Lego blocks" are not convenient and reusable?
For me, the convenient "Lego blocks" that I use a lot include CloudFront (web server/CDN), S3 (file/web server), ACM (certificate manager), DynamoDB (NoSQL database), Firehose (message batching and storage), SQS/SNS (queuing and publish/subscribe), Step Functions (low-code business logic), Lambda (event-driven custom code execution) and API Gateway (REST API / WebSocket service). It is very rare to need to run any self-managed servers any more with all these services available.
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.
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
You must have run some really heavy stuff on AWS for it to cost that much, if you are taking advantage of serverless services (not just running idle containers or servers that cost by the hour).
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.
> 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).
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.
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.
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.
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
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.
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.
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.
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.
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!
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.
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 :)
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.
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.
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.
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.
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.
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.
While this is technically correct, the problem is one of scale and organisation.
There are hundreds of people like this in the org, each responsible for one tiny brick. These people are included in dozens of projects and have a small task for each of these projects for a few weeks, then go to the next project. It is unreasonable to demand knowledge for all projects, the org is simply too big.
Personally, I'd say they need a more focused organisation: Everybody on 1 project at a time, and an enterprise architecture that does not sprawl one business task over all these tiny items so meaningful work can be done in 1 team. But this would require the top to loosen control a bit and trust people under them more. To be honest, it would also require all the people at the bottom to be more trustworthy and think about more than their own tiny world.
Trust relations in both directions are basically broken, the top tries to control their people like puppets, and the bottom reacts by protecting their own world against not always well though out orders from the top, no matter the impact on other people's work. Now you're talking about re-tuning the culture of a big corporation, which is very hard.
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.
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.
And that's why I had to go. What started out as the latter was drifting towards the former. In part due to the onwards march of IT services to cloud providers, but also attempts by the organisation to 'mature' their IT landscape, with the view that architects should certainly not be doing any actual engineering.
(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.
>>>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." -_-
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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 ;)
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.
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.
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).
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.
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.
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.
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" :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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”
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.
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.
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
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.
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.
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.
> 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.
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.
>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
> 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.
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.
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.
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.
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.
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.
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.
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.
>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.”
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.
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.
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.
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.
"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.