
Who Needs an Architect? (2003) [pdf] - kaankeskin
https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
======
snapetom
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.

~~~
mxschumacher
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.

~~~
sharadov
Sorry, but the ticket will never get done, once you stop coding, your skills
start getting rusty very quick.

~~~
nogabebop23
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!)

~~~
sharadov
But do you think they would work on those "trivial tickets" :-)

------
discreteevent
"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)

~~~
asdfman123
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.

~~~
MauranKilom
Ironically, the quoted part is Martin Fowler quoting Ralph Johnson...

------
jph
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]

~~~
lmilcin
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.

------
moksly
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.

------
blimey74
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.

~~~
phorkyas82
..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.

------
als0
> 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.

~~~
opmac
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.

~~~
apalmer
logistics is the crux of a software 'system'. Software systems are pretty much
the logistics of how to get a couple lines of business logic to happen.

Logistics is the bulk of a software system, software development, and a
software department.

------
kaankeskin
Published in: IEEE Software (Volume:20,Issue:5,Sept.-Oct.2003)
[https://ieeexplore.ieee.org/document/1231144](https://ieeexplore.ieee.org/document/1231144)

------
Wazzymandias
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.

~~~
mianos
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.

~~~
Wazzymandias
"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.

------
simonebrunozzi
Can we please say "software" before architect?

~~~
eatingCake
As an Architect, I would so appreciate it.

------
crb002
“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.

The architect’s role is to design for data flow and compose functionality so
it can be swapped out. Great new book on that:
[https://www.amazon.com/dp/0136524036/ref=cm_sw_r_tw_dp_U_x_u...](https://www.amazon.com/dp/0136524036/ref=cm_sw_r_tw_dp_U_x_ub67EbR1M89AG)

~~~
bluGill
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.

------
b20000
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

