Software architects should be involved in earliest system engineering activities

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.

The relationship between the architect of a building and its general contractor is no different than it is in software: acrimony, with each thinking the other is wrong on most fronts. General contractors believe their experience gives them superior insight into how something should be built, and that architects make impossible-to-implement plans. Architects take great care to make precise decisions on hundreds of dimensions, ranging from cost engineering to air quality, aesthetics in the context of then, now, and the life of the built environment, and scoff when plans aren't followed. Somehow, usually, through a lot of bickering and change orders, things turn out alright.

The architect absorbs vast information and designs a solution, the builder makes it into reality, often making meaningful and lasting decisions during implementation. Both are competent and valuable. Sure there are design-build people and teams, sometimes they work very well. Architects will always have more context in the realm of ideas, that is the space they occupy. Builders have the most context in implementation, and may detect issues that make the whole plan invalid. Collaboration helps. Mistrust doesn't.

Architects don't have to swing a hammer to know where the planks should go, but boy it sure does help if they have.

Software Architecture is vitally important to the long term success of a software system.

Software Architects are not the only way to get software architecture. They may even be the worst way.

"Software Architects who Code" often do not suffer from this issue, depending on how much they actually get involved in production software and operations. However I would struggle to define a meaninful difference between a "Software Architect who Codes" and a sufficiently "Senior Software Developer".

Throughout my rather limited career (~7 years, 4 different companies) I am yet to encounter an actually beneficial (to the project) architect. All they do is talk too much and draw some useless diagrams and do a random task that other team members cannot be bothered with. All meaningful decisions and choices are made by the developers themselves, with little to no account for architect's mumblings.

As yet another data point, the website cannot handle Saturday HN front page traffic. How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?

EDIT: A few people mentioned that it would be incorrect to use `HN hug of death` as an example of author incompetence, since it was just some random university or institute. I was about to agree, but then I checked the website, which proudly stated: "The SEI: The Leader in Software Engineering and Cybersecurity". From my perspective, if you claim a thing like this, you definitely should be able to handle a minor spike in traffic.

Now, it also might be that author has nothing to do with the organization and hence not responsible for the website performance. However, this is also not true: "<AUTHOR> is a senior member of the technical staff and Principal Systems Engineer at the SEI...", as stated on their bio page. To me this either shows little ownership or little understanding of underlying resources the author relies on, which serves as another proxy of their actual architecture skills.

I’m surprised HN is so hostile toward IT architecture. I work in the public sector in Denmark, and enterprise architecture is vital for us. We’re 98 municipalities that each operate around 300 different IT systems. These need to interact with each other, as well as major IT systems on the regional and state level (citizen base data, healthcare, taxes and so on). They’re build/maintained by 50 major vendors and a few thousand small ones. Sometimes a system changes hands through public procurement. The longest running systems are from the 70ies, and have several layers of modern APIs build on top of each other.

Imagine doing all that by letting thousands of random developers run completely free. I mean, I don’t have to imagine because we didn’t actually involve architects early enough, and it’s cost us billions to correct that mistake.

I think a lot of posts here completely missed the point of the article, which is NOT about the role of architects in pure software products such as websites.

The author is talking about large defense systems like satellite arrays and airplanes. The status quo that the author is responding to is that engineers of the physical systems (missiles, satellites, etc.) make all the decisions with software bolted on after the fact. This is definitely true at places like Boeing.

You could replace architect with "senior software engineer" or whatever.

Point is, software should have some seat at the table during the design process.

The fundamental thesis of the piece is: "If, instead, system acquirers ensure that systems engineers address software concerns at the same time as the physical solution is conceptualized, acquirers can opt for a slightly different physical system, whose software architecture is tuned to optimize the provided capabilities."

Which, to me, sounds entirely reasonable. If some system needs an MLOC or so and the software will be doing a complex thing like piloting the aircraft, you better be thinking about the software from the beginning of the project...

This strongly reminds me about this over on Stack Exchange: https://workplace.stackexchange.com/questions/141278/complai...

I think this depends entirely on the organization and size of the product.

If you have one "squad" that owns the product top-to-bottom ("squad" being defined here as a team with daily discussion and syncing of progress) then I think the architect aspect is decentralized across everyone.

But once there's more than one "squad" that each own a separate chunk of the overall product and the work of these squads overlap even a little bit, then there must be one individual who is enforcing a confluence of design in that overlapped region.

This reminds me of Conway's Law https://en.wikipedia.org/wiki/Conway's_law

> organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Does software need to be architected? Yes. Does this require a dedicated role called "Architect"? No.

Usually the key implementor architects software. Even in a large complex system, you really want key implementors working together to design.

> “Software is never 'finished' but must be constantly updated to maintain capability, address ongoing security issues and potentially add or increase performance.”

Something that people really need to understand when they are asking if something is done. “Done enough for now” is the best, simple phrase I’ve learned to convey the sense of what was quoted above. It can easily segway into that conversation, if handled delicately, and teachable moments for management.

How do you convey doneness in your projects?

I think the word architect is a failed metaphor for software.

What is the role of architect in the real world? In some high profile cases they are designers - even to the point of doing something like project management/business development (the only reason we funded this project is because of the awesome ideas we got from the architect, we worked with the architect to make sure the building would meet our dreams for this project ...). But more commonly — I understand their role more in construction to me more in the realm of being a maintainer of documentation — maybe they have some role in proposing the original design but the majority of their time is probably spent ensuring that these plans satisfy all required regulations — and updating the plans in response to what actually happens during building so that the building itself will pass all regulations ...

This is nothing at all like the nebulous responsibilities generally associated with software architects. Some projects could benefit from this level of book keeping requirement — but a lot of projects which contain “software architects” probably would reject paying someone to maintain specifications to a similar level of accuracy as is required of real world architects — especially if that was basically all that was being asked of them to do ...

Seems to be getting the HN hug of death. Here is an archive: http://archive.is/IT34b

That's a step in the right direction for all major components to be designed together but it's not adequate because normally you have to make structural changes to components over the course of the development and maintenance of the project.

So all components need to be designed and maintained with a high degree of visibility and ideally direct cooperation.

My impression is that the core structures of these contracts are always flawed. For example, they seem based on detailed pre-estimation and fixed fees. To me it would be more realistic to give ranges and focus on core goals and milestones with the expectation that detailed requirements will evolve.

But stepping back even further, the paradigm that drives all of this which is labelled as "defense" is quite an outdated paradigm. So expecting operational aspects to make sense might be asking too much. The paradigm goes back to for example https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars

I don't believe in architecture being done fully via a separate role, it's counterproductive.

What you need instead is developers on the team who also understand software architecture, and implement it especially in it's initial phases.

This takes more senior developers, then later on less experienced developers can jump in once the structure is in place.

But a completely separate person external to the development team, which is going to define the architecture using text and diagrams only?

That doesn't exist, it's a myth. What ends up happening in practice is that some senior developer on the team ends up implementing the actual architecture, and those documents are used just as broad guidelines at most.

I've recently taken time to start reading The mythical man-month book by Fred Brooks.

As far as I remember (first read through this week and big parts of the book is stuffed with quotable material) he says that

- that the architect should be able to provide an example implementation

- but that it is also important that the architect steps back and stays away from the actual implementation

I've more or less already decided to re-read that book.

Highly recommend and available in searchable selectable PDF form from archive.org

In agile world software architect does not fit in. This is where the conflict comes in. people thinking in old traditional software architect system meets agile teams. It does not work however we have been successfully working in a team as lean architectures which is a perfect balance for architect role combining with scrum teams.

> Software architects should be involved in earliest system engineering activities.

Rather, the people doing these activities should have a solid background in software.

If you don't have software kung-fu, you shouldn't be designing something that will be heavily programmed in order to fulfill its function.

The fact that someone needs to say that for it to be apparent is somewhat unsettling.

What is the role of an architect nowadays?

This conversation has gone in a completely different direction from the article. We're now all complaining about architects instead of the point it's trying to make.

But you can't fix that, so I'll chime in.

In my opinion, an Architect is just a role that gives advancement opportunities to individual contributors that doesn't go down a management path. You're still a part of the dev team, and you still do work.

When I've been in that role, that's how I treat it, and it's worked out pretty well. Generally speaking, when the position gets treated that way, I'd get involved in new products or major changes. For major changes, there's a specific thing we're targeting that needs something different. An extra complexity or just a different approach. That's all I focus on while writing the design document in response to the requirements document. Everything else is fine, but we need to do this one specific thing differently to make it work better. And this will have trickle-down effects on the rest of the system that's going to have to accommodate it. If I've done my job well, those are reasonably doable without that much explanation. I'll write the prototype that gets at the core of what needs to change, do code review with the team I'm eventually going to hand it off to, and explain my decisions in person. Once everyone is on the same page and gets what we're trying to do, I can hand it off and move on to something else.

For new products it's a little different. We want to make sure that we learn from our past wherever we can. Companies often have themes to their products and even a completely greenfield project isn't totally different from other stuff you've done. There's lots of stuff floating around that isn't great, but it's not so bad that you're ready to invest in a "major change." But if you had to do it all over again, you would do it differently.

That's what you want to make sure you capture when you start a new project. So again, there's requirements. And again, I write a tech document that represents my interpretation of the specs as it applies to the systems in play. The vast majority of these don't really matter, and any competent developers on the team can handle them. So my input is to focus on the things that are non-obvious and caused problems for us in the past. But the end result is the same: I write the prototype, workshop it with the team that's going to be taking it over, and hand it off and move on when everyone is confident that we all know what needs to be done.

Sometimes, it's not either of those things. Sometimes there's just a really annoying bug that needs tracking down and is really hard. It might not even be caused by the system your team is working on. You might need some cross-team investigation to figure it out. Sometimes you need a wider knowledge than a specialized team has. And sometimes it's just because some shit is broken that you wrote 6 years ago, and no one noticed until now because no one used it quite this way back then, but now everyone uses it that way, and it's awful, and half the reason you got promoted to architect is because that solution was mindblowing and novel, but now it sucks because no one knows how it works. Not even you. So it's your problem, genius, so go fix it. And you go crawl in a hole of shame.

Architect as anything other than really super double senior engineer doesn't make sense to me. Architect as an outside hire doesn't make a ton of sense to me. Architect as a layer of management that's not engaged in building software doesn't make any sense to me at all.

Architect makes sense as a retention strategy. It makes sense as an upward path for ICs. Architects should mentor. Architect shouldn't be a special title. It should be a normal result of doing solid work over time by a person who wants to keep doing solid work instead of switching to management track just to justify a raise/promotion.

Just my thoughts.

I never been able to get clear answer. What exactly is the role of a manager, why are they so highly paid. What does a software manager do on typical day.