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.
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.
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.
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.
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." -_-
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.
If you're building a bridge over a small pond, iteration based on feedback from users will likely work well.
"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.
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 am not sure
So it isn't the knowledge one gets from the certificates, rather the checklist from having them in first place.
I'm not sure about that.
Until AWS's margins aren't insane, I will not trust their stuff.
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).
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.
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.
I honestly have to question if this is a gpt-3 generated article
Like suggesting it would be better to stick with Javascript over Typescript since it would be more stable.
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
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 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.
and a good enterprise will have a reasonably well defined road map that can be used to set expectations of future risk/ technical debt
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.
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
http://www.smashcompany.com/business/why-are-large-companies...
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
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.
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.
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.
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.
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 ;)
(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 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.
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.
https://ea.rna.nl/2018/09/01/agile-teaches-us-the-true-meani...
I also like this parallel:
Latvian stradat "to work"
Russian stradat "to suffer"
