A software architect that can't code or refuses to has no business architecting the system.
A software architect who doesn't show up to stand ups really shouldn't be dictating a solution to the team who have to build it.
Ideally the software architect should be as hands on as possible with the team leads as the system is built up to the point that the architecture is proven or at least to see if the assumptions around the architecture actually hold up.
Really strictly on teams leads to accurately communicate the architecture before it has been proven to hold up is risky.
I get this issue and I share the frustration but is this really a comment on the article posted?
In this case we seem to be talking about huge military projects like GPS or Drones and that there is a divide between the hardware parts and the software parts that might have made sense in the past when the interfaces between the hardware were simpler and software was mostly internal. But now when software is such a big part you need to involve software people earlier looking at the bigger picture from the beginning. It will also drive how hardware will be developed, i.e. what you can do with software will drive how you should develop your autonomous military drone fleet.
Yea I don't get a huge number of the comments in this thread. The article was pretty specific in what it was talking about, which seems to be not what people are talking about here.
The examples given are all defense projects, but the article does not ever limit its claims to defense projects. Its thesis is stated and re-stated in general terms and it consistently makes broad claims like:
> Today and into the future the best way to ensure that a new system's software architecture supports needed capabilities and also system evolvability is to involve software-knowledgeable personnel--specifically software architects--in the early system decisions about breaking up a system into acquirable parts. At this early stage, many software problems are either caused or avoided, and software architects are needed to ensure the latter.
A similar problem I've seen a few times are the consultants that participate only in the first few months of a multi-year software project as architects, so never get to experience the long-term implications of their design and the mess they prescribe. Not only is this bad for the project, but also breaks the feedback loop for their own learning.
This is something I'm afraid of at my current company.
We just used 3-5 contractors to implement Zuora, Salesforce, and Netsuite in "record time". They're gone now, along with the biz ops person leading the rollout.
As an engineer, I feel like I'm eventually going to have to deal with that flaming pile of shit.
In the world of web development, and devops etc. this is probably very true.
However there are a lots of non-web orientated systems out there; banks, emergency services as an example. I fall into the latter, and have also worked in the former. In those kind of environments we often have an architect (who is indeed quite a talented and hands on coder), but the hairy implementation details of the architect's design tend to be worked out either by dedicated designers, or some other form of implementer (systems administrators/programmers).
It's unfortunate that this off-topic, general comment has derailed what could have been an interesting discussion about specific types of architecture (large HW/SW systems). And I have a feeling that like several other commenters you have some specific architecture work in mind and are incorrectly generalizing based on it.
Taking part in stand-ups for instance would be a complete waste of time for anything except application architecture and it's only relevant in projects which are using Scrum. Even then, it's possible to do the job by being available (at the risk of missing some unofficial or ephemeral info) and taking part in the sprint review.
I prefer involving the team in design decisions and giving them freedom to implement things as they see fit, as long as the architectural requirements are being met.
The usefulness of coding skills decreases the higher one climbs the abstraction ladder. Writing production code for a project is from my POV an anti-pattern unless we're talking application architecture and the architect is only part of that one project, which sounds like title inflation for anything except bigger applications.
In my experience there were two kinds of situations where it was worth it to write code: tackling less glamorous, but useful tasks that the team didn't have time for and solving trickier problems that the team couldn't yet work out.
Otherwise I expect and prefer mature dev teams which can implement on their own, while I am available for guidance if needed and to ensure that the business reqs are correctly translated and their piece of software integrates properly in the platform.
Personally, I found domain knowledge, connections and social skills invaluable for architecture roles. Technical skills are also valuable, but they're table stakes to be honest.
Totally agree. If you don't know to code and but are an architect you pretty much live in permanent la-la land. I bet on paper I could architect a whole company within a few hours. It would look good on paper but in practice it wouldn't work because there are a ton of implementation details that make my design impossible or hard to achieve. Much better to empower the devs to be involved in architecture from the start so they can give real-world input quickly. I have seen it so many times where managers and architects decided on an unsuitable stack because all they do is listen to sales reps and read whitepapers.
Software security architect here. Senior management strongly discourages writing code on my team. But this is because we work at-scale with hundreds of products comprised of thousands of microservices.
I don’t attend product teams’ standups , but our engagements run on the order of weeks to months.
We don’t micromanage development or design choices made by product teams. Yes, we review code and make (strong) suggestions, but we leave service teams free to make choices as long as the risk is low and commensurate with the threat model. It’s our job to guide major decisions and, occasionally, advise on the “least-bad” short-term solution, pointing out where, when, and why a re-architecture will be required in the future. Generally speaking, teams want our feedback on design proposals and concepts. It’s a healthy relationship.
Occasionally we have to force teams to reimplement, or block release, but that’s a very rare occurrence.
Unlike many comments on this thread, service teams leave us with pretty positive feedback. It’s very rare that teams leave negative feedback on our design engagements.
That’s definitely the case when thinking about security in a strictly limited scope. In contrast, my team is holistic — any issue that could affect ICA (integrity, confidentiality, availability) is in our purview.
My team engages in the earliest phases of design. Holistic security is our priority, but not a limiter for our engagements.
Oddly enough, I'm an architect for a company that makes scientific equipment. Mostly hardware rather than software. The software team is its own independent entity.
I'm usually present at every stand-up. Realistically, the engineers tend to be fairly specialized, not multidisciplinary, and are not up to speed on quantitative engineering, so my role in defending and adapting the architecture is continuous throughout the project.
They should also accept most of the blame for any problems, because anything higher level than "my code won't compile because the syntax is wrong" is an architecture problem.
You want to be the architect and me just a lowly coder? Ok, I'll fix my own compile errors, all other problems are on you.
Architects shouldn't be dictating your class structure or code choices. That's a code concern and not of the system. If the system has fundamental issues around performance, scalability, extension, or security, then it's probably on the architect.
This attitude seems to be the default "holier than though" attitude about architects. I think it's more likely that you would encounter pragmatism when the company culture is healthy. Unhealthy company or engineering team and there's no way to tell whether it would be good or bad
Only issue is, a bad dev can still make mistakes that compile and run but fail at the first hint of trouble.
A friend used to say, "every line of code you write, you make at least one, if not more decisions about the architecture of the program" and I totally agree. So I can still see a really good architect being betrayed by a below mediocre engineering team even if the architecture is sound.
> A software architect that can't code or refuses to has no business architecting the system
Well, in construction, you have both architects and civil engineers that never, ever place out rebars or pour the concrete. The architects know how to design the building, while the engineers materialize those designs according to the laws of physics and economy.
So I guess one could ask, why should it be any different in software?
In fact, it's like that in pretty much every other industry. I'm an electrical engineer by trade, and even though I know how to practically do the work myself (since I worked as a electrician apprentice before college), it is something that I never touch - nor have to touch. That's what electricians are for.
> So I guess one could ask, why should it be any different in software?
Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
I agree, but as an architect who does all that, it is also a constant struggle to deal with developers that don't think more than one step ahead and need to be spoon fed concept to prevent them from e.g. writing custom code instead of preparing for reuse.
When you have developers who understand how to generalise and abstract, then the interactions can often be very simple, and deferring to team leads etc. can work just fine.
