In my first real dev job, we had a team of architects that were rockstar developers. One of their jobs was to write libraries for use throughout the enterprise. Their other job was to decide on technology used throughout the company. Those guys were great. They were smart, and good people skills were essential. This model worked well when it's a few expensive, good devs, and a lot of meh devs that were cheap and just generate code without question.
Over time, with Agile and I as I worked in smaller companies, I ran into fewer architects, and the people I did meet were basically senior-senior devs - People who had been at the company for a while. It was more of a reward and respect for them. Same as before though - really good devs.
This article is good at narrowing the requirements, but I think it's still a bit vague and abstract for this age. My last job, a large hospital, we had an architect that I constantly butted heads with. He hadn't coded in decades (not sure if ever) and was obsessed with picking technologies based on the wrong criteria. He thought of himself as this high level, European academic-type that was too busy with big issues. This style basically made him out of touch with anything going on in modern tech.
He had a knack for picking old, dying technologies. I got a particular kick out of sending former colleagues the post here on HN last month about Apache Drill, which he advocated for, being discontinued.
My argument to our CDO was that if he walked outside and yanked any senior engineer from Amazon, they could do a better job than this guy. His job, picking tech, is less important these days with Agile and modern applications, well, architecture. From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.
My first lead position, I was hired with money saved by firing an architect who was all talk (on a small team, like this one, that becomes glaringly apparent very quickly). They wanted someone with rudimentary architecture chops who could grow into a lead role, but who was hands-on. I obliged.
Over the years, I've found the most productive way to go is for the leads to share the responsibility, with input, tie-breaking, and the occasional veto by a technically literate project manager ("yes that sounds neat but it's antagonistic to our business goals so pick something else").
Architecture as a responsibility, not a title. It's harder to prioritize - there is no point person - but the payoffs if you do manage it are not to be sneezed at.
You trust people with skin in the game, who suffer along with you when the 'right decision' results in near-term pain. Some guy who barely writes code lecturing you about how you're doing it wrong? Nobody respects that guy, except to their face, when the bosses are around.
I believe that everybody in an engineering organisation, no matter how senior, should at least spend half a day per week on programming tasks.
Take a ticket and deploy a solution to production. Such a rule takes peoples' heads out of the clouds and connects them with reality. Time and again, I perceive programming as a humbling experience.
Disclosure: I've had an architect title for nearly a decade.
I actually don't think half a day is nearly enough. BUT I also don't think that this needs to happen every week. Sometimes, there are periods of exploration and discovery - whether it be with new technology, new approaches within the company, or coming up with some more grand long-term vision to align the tech org towards.
However, when you're out of discovery mode, you need to be in the weeds writing prolific code, feeling the impact (good or bad) of your decisions and course correcting as you go. Moreover, you need to see how other people are feeling about your decisions. At the end of the day, you're working in service of them, helping a team, teams, or the overall tech org to be successful, which in turn will (hopefully) help make the business successful. Often times when I hear disparaging stories about architects, they aren't fulfilling that tenet - either because they don't have the skill to do so or they believe everyone else just needs to keep up with their brilliance.
I've been in too many situations where once the "architecture" was done, the project was to be tossed to some engineers while I work full time on something else. Unless you have some awesome leads that are in lock step with the architect, then that is a recipe for disaster.
The last thing I'll say is that everyone writing code is an architect. You're inevitably making decisions about the way things will be built, no matter how small. Virtually all software has an architecture - but too often it's incidental architecture rather than intentional architecture. Make conscious decisions about your code, reflect on those decisions, and keep an open mind - whether you're just starting out or have decades of experience.
This is a key point, but People might say "software is eating the world", but many organizations are not yet at this point. You can find modern healthcare or pharma organizations which are doing real engineering, but this is still the exception in many places.
What you find is organizations which can still survive on old technology and the processes which got them there. At some point modernization will also have meant outsourcing tech to the lowest bidder. You have an organization which is unfit for engineering in the current state and the architects are more familiar with managing this process work than doing what folks here would consider real engineering.
These organizations are ripe for modernization. They have aging tech and tenured teams which can only make very incremental improvements. As market conditions change, leadership may decide that they really need to make changes and these people will be cast aside. It's a somewhat double-edge sword because the old folks do have value in that they understand all of the details of their business processes which are apparent to even a really good engineering and product team replacing them.
You pretty much described that last job. They outsourced a lot in the past decade, but now the issue is that to do what they want to do, they can't because of outdated tools and infrastructure. They don't have the expertise in-house. They keep talking about "leading" and "pioneering" work, but by definition, if you're buying off the shelf products that solves a problem, it's not pioneering.
The problems they want to solve require an engineering culture. There are no ways around that.
Like many hospitals, they've been hit hard by COVID-19. They recently announced golden handshakes for people close to retiring. It's painful for people now, but hopefully someone will see it as an opportunity to change the culture.
Some of the most vicious arguments on Blind are about senior ICs with conspicuously empty commit histories. This is a great rule - half a day per week preserves the “other things are more important than coding” aspect while preventing the “couldn’t even do my job, why should I listen to him” angle.
I have worked all my life in organizations producing software, never once was this true: there was always some level in the organization were people stopped all programming tasks (with all the bad side effects of that, that the head does not really understand the capabilities of the organization, what is feasible and what is not...).
I agree with you, I just have not had the luck to see it.
So there are a lot of tickets that are trivial, or a bullshit job, or just really not fun but still need to get done and a manager/architect is perfectly capable of doing any of these. They SHOULD NOT be doing the big/hard/risky ones because that's not their job; they'll block the team or worse, steal the most rewarding work from those who deserve it. Senior non-ICs and BS tasks are a match made in heaven (for many reasons!)
i don't think this is the message you're trying to convey, but seriously i'm reading so many stories in this post about how non-technical people can get into these (presumably) high-paying architect jobs where they are not expected to do any coding... how do i apply for those jobs? i have 2 degrees, business and computer science, but i hate coding. so far, the most value i could have leveraged out of my CS degree without having to do coding is working as a technical project manager, but i know architects get paid WAY more. how do i find those jobs?
I'm going to try to answer that, even if only for myself.
Partially, because the organization is a lot bigger than 1 man. I'm working close to my home in a company that respects work/life balance. Pay is reasonably good, especially as i don't have a multi-hour commute anymore. I wont be fired from one day to the next. I'm pretty sure the organization is all in all doing good work helping people forward. There are a lot of people with great technical and other expertise. Also good, nice, solid people. My work is appreciated. I have a good amount of freedom. There are enough layers of management that I don't have to deal much with the architects.
And the weird thing is, it is working with him as head architect. He is the kind of person that can sell anything to anyone, even turning around people that were disgusted of him a few months before. I'm pretty sure he makes technological choices by reading Garner slides and doesn't really understand what they are or what the results will be. Even so, he manages to get things moving and agreement built in a very complex organization. He causes change, others give that change a usefull direction, and the net result is, well, usefull results. Strange but true.
That even partly fits to something the article alludes to, and maybe should have been stated more explicitly: that it's about communication: so getting the people talk to each other and be motivated and try to solve a problem in a specific, commonly agreed way - that is more important than the used technology (which can be overhyped crap)
> From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.
As it should be, I'm an architect, worked for Central banks (equiv of the FED), working for crypto startups, and also medium size enterprise... I don't respect architects that can't "do". That said It's an important function IMO.
"There is no theoretical reason that anything
is hard to change about software.
If you pick any one aspect of software
then you can make it easy to change,
but we don’t know how to make everything
easy to change. Making something
easy to change makes the overall system
a little more complex, and making
everything easy to change makes the entire
system very complex. Complexity is
what makes software hard to change.
That, and duplication."
This is generally how things get over-engineered. The excuse is usually "flexibility", often for some future unknown requirement. (and as an aside - one of the weakest reasons for complexity-causing flexibility is to support mocks/TDD)
But TDD done right usually use coarse-grained tests which usually require less flexibility because it's almost end to end, and require less layered architecture. It's more like a description of the desired business behaviour.
Even better, TDD done right requires people to write those business cases as test first, then implement with minimalist approach - this enforce people to write straightforward code which happened to just support what the business requires.
I've worked in maybe a half-dozen projects where flexibility was a critical concern and, as the result, the end product became harder to understand and maintain. Besides, the vast majority of the flexibilities built into the product haven't came to be exercised along the years those products remained in production.
I don't think it's fair for me to criticize those architects, since I have now the privilege of hindsight and might well have taken the same wrong decisions in their place. But I learned some lessons and, with all due respect to the author's credentials, I don't feel convinced.
Different kinds of applications are certainly more or less prone to certain sorts of changes, but it doesn't seem to me that engineering most aspects for change should be the default approach.
I'm not trying to hate, and I know Martin Fowler is a great developer, but can anyone else not get past how dry his writing style is?
I read all kinds of long things on the internet, but I can never get through stuff he's written, despite his obvious brilliance, because of it. I feel like I'm missing out on the gems like the one you quoted.
I find the style just fine and that article is pretty easy to get through, it tells a good story. As an aside I had the pleasure of an afternoon with him and Mary & Tom Poppendieck back in ~2003'ish as an audience member at one of their talks. Super interesting folks with a good stack of war stories to tell.
Summary: This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. The most noticeable part of the work is the intense collaboration. The architect raises the level of the development team so that they can take on more complex issues. [n.b. edited for clarity]
I think the problem with definition of who is an architect is the fact everybody wants to have a job description.
My understanding is that architect is somebody who decides which details are interesting and important to him and which are not. A lot will depend on the project and its environment.
In my current project the team may need a little bit help so I do stuff like define more important internal APIs or migration paths. I also typically do it in form of pair programming to get to know people and have occasion for discussion, to up their level a little bit if possible. In another project the team would get much more freedom and I would be having more teams with shallower view.
One thing that an architect should be doing is being responsible for overall health of the application and development process. Right architecture and approach to problems can solve a lot of problems and an architect that just blames other for problems and spends time preaching new fantastic shiny frameworks is no architect at all.
A lot of the time the enterprise architect is a project manager with technical insights, ability to talk to both the business and the development side, and, most importantly someone who has a real impact on decision making.
We use them quite a lot, to reasonable success in the Danish public sector. The real trouble starts when you get too many MBA types and no technical experts on your “architect team”, but they tend to work their way into decision making in any form in enterprise anyway, so it’s not like you can really avoid them even if you don’t use EAs.
I get the article though, architect can be so many things in IT. It can be the techie who took an MBA and now uses it to get top management on board with what IT needs to the guy who set up and maintains your office365/ADFS/Azure administration, to someone who is telling you how to build software. And enterprise architect is often the most meaningless title of all. Doesn’t mean they’re all useless, because they really aren’t, but it does mean you never know what you get until you’ve seen what they can do.
Martin forgot to mention money as being the most important limitation on software. Some customers just don't have the budget to let you deliver good software or to evolve an architecture so that's its cheaper and easier to extend.
..or if we take serious the "social construct" thing then it'll be limited by all the vices and pitfalls of human nature, ain't gonna get far in that swamp of narcissism, arrogance, ignorance and bad listening.
> There is no theoretical reason that anything is hard to change about software
There are practical scenarios where upgrading or changing software is logistically difficult. In those cases, a good design can really go a long way and last 10+ years.
I would say logistics is outside the realm of the software itself, but rather with the organization. It's a valid point, but somewhat tangential to what Fowler is trying to say here. That is, software is not inherently complex, but rather becomes complex through our own doing, and it takes good architecture to attempt to prevent this.
In my previous job we hired someone in a "Senior Architect" position. They had extensive experience at a larger company, but there were red flags from the beginning (including the interview, where they got visibly upset and melodramatic when they were unable to finish the algorithmic problem we gave)
Working on anything related to design and architecture with them was a disaster. They preferred waterfall over agile, didn't take feedback very well, was obsequious towards leadership but toxic towards the team they led, and would terminate collaboration with someone if there was disagreement.
The soft skills for an architect are essential, and I think that includes excellent communication skills, documentation, and ability to take feedback and constructive criticism. Needless to say, the coworker I describe fit none of those criteria. It's been pure bliss not having to work with someone like that, and helped me better understand what to avoid in the path to becoming a legitimate software architect.
Everything you say is true, but being melodramatic when asked to solve some irrelevant algorithmic problem is not a red flag. It could be he has been busy doing real work in the last ten years and not researching solved problems that are generally encapsulated in well tested existing modules.
Lack of respect for your team and not collaborating are real red flags. Soft skills are very important and not at all related to not being able to solve an obscure problem in an interview.
It's also pure bliss when you do whatever you like when you like with no overall architectural leadership putting constraints on your solutions. This, in my experience, has lead to whole firms going bust when reality strikes.
"It could be he has been busy doing real work in the last ten years and not researching solved problems that are generally encapsulated in well tested existing modules."
Sorry, I should have been more clear. We didn't ask the problem with the expectation of a perfect solution, it was more to gauge his problem solving skills. However as we were running out of time we asked him to implement a naive solution, which was met with a very negative response. Maybe I'm not explaining it properly but it gave the impression of a serious ego problem. Actually part of the criteria for our interview is to see how well a candidate can take feedback and make changes accordingly. They did poorly on that front.
Agree that architecture leadership is critical, especially when dealing with business teams that acquiesce to every single client demand with impunity.
“Software is not limited by physics like buildings are.” is dead wrong. Information transfer is bound by the speed of light. We are light architects, and L1 cache vs a remote call to a server hundreds of miles away matters.
Taken to its limit, you are not entirely wrong. But, practically speaking, the bounds are much higher in software than in physical construction.
The limits of physics, with respect to, software determine more its performance limits rather than its logical limits. Setting aside performance (which is important), I can make a complex piece of software with 1000 modules each directly connected to the other. A building is not capable of a similar degree of direct connectedness. There may be critical components, your keystones, but each brick is only attached to each neighboring brick. Outside of the critical components you can remove (up to a limit) and replace many components in place without bringing the entire structure down, and often without local damage. And replacing a damaged brick in place requires rejoining with only those immediately around it.
Good software is written in a similar fashion, but software itself is not bound by the physical limits that force that fashion (until you start considering performance, which will encourage better design but only when it hits a particular pain point, or if dealing with a global network of computers).
Maybe, maybe not. I am architect on a system that gets by on 16 but cpus with no cache. Or we did until they went out of production, I'm hired to duplicate what was working on something more modern (32 bit) . I don't worry about l1 cache because no matter how bad I am to the cache I know the code used to work on a cpu much slower.
Of course that is just one of my domains. I have other systems that are pushing bounds of what 64 bit systems can do, and there I'm more worried about how can I avoid synchronizing the cache between the cores without a race condition. I don't have to worry about the servers hundreds of miles away though, that is a different architect.
Hardware is defined by physics. I can write code that is logically the same no matter what hardware it's running on. Of course, some software has to take the hardware it is intended to run on into account, but this is not a fundamental property of software as a whole.
maybe it's more important to focus on
1) putting a union in place to protect computer scientists
2) stop negotiating against each other
3) stop undercutting each other
Over time, with Agile and I as I worked in smaller companies, I ran into fewer architects, and the people I did meet were basically senior-senior devs - People who had been at the company for a while. It was more of a reward and respect for them. Same as before though - really good devs.
This article is good at narrowing the requirements, but I think it's still a bit vague and abstract for this age. My last job, a large hospital, we had an architect that I constantly butted heads with. He hadn't coded in decades (not sure if ever) and was obsessed with picking technologies based on the wrong criteria. He thought of himself as this high level, European academic-type that was too busy with big issues. This style basically made him out of touch with anything going on in modern tech.
He had a knack for picking old, dying technologies. I got a particular kick out of sending former colleagues the post here on HN last month about Apache Drill, which he advocated for, being discontinued.
My argument to our CDO was that if he walked outside and yanked any senior engineer from Amazon, they could do a better job than this guy. His job, picking tech, is less important these days with Agile and modern applications, well, architecture. From what I've seen in my career, the expectations for an architect are far more "hands in the dirt" as time goes on.