Who Needs an Architect? (2003) [pdf]
martinfowler.com
martinfowler.com
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.
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.
Truth. At every job I start, I manage to say, "Wow, I am way behind these guys on what I know." That's not a bad thing because it's pushed me to grow.
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.
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.
Even an out of touch manager can contribute to and/or observe the state of the code base while pairing with someone who works on it full time.
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.
You probably mean on average, and yeah, I agree. But the literal reading of programming half a day per week feels horrible.
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.
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.
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.
However, it sounds like your architect is more of project manager than an architect.
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.
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)
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'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.
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.
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.
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.
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.
Logistics is the bulk of a software system, software development, and a software department.
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.
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.
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.
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...
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.
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).