
Software architects should be involved in earliest system engineering activities - runningmike
https://insights.sei.cmu.edu/sei_blog/2019/08/why-software-architects-must-be-involved-in-the-earliest-systems-engineering-activities.html
======
thinkersilver
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.

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

~~~
ex-aws-now-goog
> 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.

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

~~~
qznc
As a software architect myself, I agree.

It helps to do building. I recently took over the ownership of a small
component in our system myself. That was the first time I wrote a unit test in
our project. Finally I know how our testing and coverage infrastructure is
configured.

> The greatest architectures are the product of a single mind or, at least, of
> a very small, carefully structured team.

In a big project, I would rather relief the one or two architects from their
coding duties than to have four or more architects. While it helps to do the
building, there are more important things for an architect to do. For example,
I'm the one who has the overview of cross cutting concerns like logging and
safety.

Disclaimer: I believe there is a big difference what "software architect"
means in IT/cloud/web in contrast to embedded/safety-critical/real-time. Most
of the complains I hear are about the IT ones (often called solution
architects). The article and also my work is in the later category. The
methods are nearly the same, but regulations in the later category force the
architects to focus on much more details. Maybe that helps to stay more
grounded. We do have a similar acrimony with our "system architects" though.

------
glenjamin
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".

~~~
siggen
I feel managers, directors, etc. who cannot code should not be managing,
either.

You have two classes: management and individual contributors, when there
shouldn’t be. Management ought to be able to solve any problem people they
serve (i.e., their underlings) are facing, given certain amount of time to
familiarize.

~~~
sidlls
This depends on the size and context of the organization. I'd argue that
front-line managers should handle trivial, low-priority, low-glamour
development, but not more than a small fraction of their time (say between 10%
- 30%). If they're doing development work that is more sophisticated or
requires more of their time, they aren't going to be able to do their more
important job: managing. Managing, by the way, is more than just having 1:1s
every week and filling in the budget spreadsheets--it's negotiating for
priority, fighting for direct reports' career needs (e.g. fighting to get the
team assigned the projects that ICs will be able to use in their performance
reviews) and balancing that against the needs of the business, etc.

~~~
siggen
Mmm, what I was arguing for is that a manager ought to have sufficient
experience that they can substitute for and work as any individual under them.

I understand that many large institutions are constructed in a mechanism you
describe. In many cases, these managers are technical enough that they can
substitute any individual working under them. There are also many cases where
they are not sufficiently technical.

Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting
for projects, and assisting ICs career growth, I am not convinced that that
manager is necessary as I am not seeing his value. Prioritization ought to be
intrinsic for everyone and is more a collaborative choice, no? Why does a
single individual (manager) decide priority?

~~~
marcinzm
Because direct collaboration scales as O(N^2) in terms of person-to-person
interactions which becomes rather big as N grows. Having everyone spend 80
hours a week in meetings and still only understanding 1% of the business seems
a silly use of time and rather inefficient in actually getting things done.
Thus you get managers who are the ones in meeting with other managers which
leads to a smaller N.

~~~
siggen
Understood. Apologies, I didn’t understand what was being prioritized
previously. Previous replier clarified. Agree that otherwise this reduces to a
handshake problem.

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

~~~
notyourwork
7 years and 4 different companies is why your perspective is skewed. You’ve
never seen a system mature at that job change rate. Therefore you have never
really had to deal with decisions that impact long term which is where
architecture matters.

~~~
apaprocki
Everyone is their own worst critic. I frequently am editing production code I
wrote 15+ years ago. I also have to deal with the unintended consequences or
side effects from my code that were not thought out at the time. It certainly
is hard to teach this kind of thing and, more importantly, find a way to get
people who haven’t experienced it to find the value in doing so.

~~~
chmhsm
Pretty accurate. And if you ever get asked "why do we have to do that useless
thing you said?" and you reply using expressions like "futureproofing" or
"anticipation", eyes might get rolled at you and you might even get management
to disagree for the sake of tight deadlines or yagni.

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

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

~~~
jcurbo
Yeah, between this and the MITRE post the other day I wondered if it was
suddely Systems Engineering Week at HN. This is not the kind of content you
usually find here.

~~~
qznc
Do you know other places where such content does usually get posted?

~~~
throwawayjava
Professional conferences and the like. For better and worse, it more resembles
fields like medicine, law, traditional engineering where most shop talk
happens in professional settings and at a specific allotted time, as opposed
to online throughout the year during after work hours.

------
goatinaboat
This strongly reminds me about this over on Stack Exchange:
[https://workplace.stackexchange.com/questions/141278/complai...](https://workplace.stackexchange.com/questions/141278/complaints-
from-junior-developers-against-solution-architects-how-can-we-show)

~~~
dtech
Jesus Christ that post shows everything that's wrong with Software Architect
as a role and the guy is completely oblivious to it

~~~
qznc
There is a very interesting part "No complaints from senior developers".

~~~
dtech
Stockholm syndrome and self-selection, since people who are not willing to put
up with it leave long before they become senior developers

------
2bitencryption
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.

------
asimpletune
This reminds me of Conway's Law
[https://en.wikipedia.org/wiki/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.

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

~~~
twblalock
Where I have worked, the architect is the person who helps the key
implementors work together smoothly, shares knowledge about the design, gives
advice, and brings in other teams he knows can help.

It takes a lot of "tribal knowledge" about the various teams involved in a
project to do this kind of thing well. The most successful architects I have
worked with are the ones who have a lot of experience at the same company.
They don't design the architecture -- they convince all of the participants in
a project to collaborate on designing the architecture.

~~~
paulsutter
Their title is architect, but they ... don't architect?

> They don't design the architecture -- they convince all of the participants
> in a project to collaborate on designing the architecture

~~~
twblalock
The people I am describing are more technical than project managers and are
able to give informed advice on the architecture and the code, and often
commit some of the code to the project in addition to the other project
management duties.

~~~
paulsutter
If you avoid nontechnical project managers, you wouldn't need a special title
for technical project managers

------
9wzYQbTYsAIc
> “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?

~~~
cbanek
At one previous job I was at, people were saying things are done when they
weren't. Then the PM started going, is it done-done? Oh sure. I think that
mostly meant "is it actually checked in and running?" Then when we had bugs,
they would come around and ask, is it done-done-done (said quickly, with a
sense of doom)?

I love the "done enough for now.," although I do find some use in breaking
down doneness.

My levels of done:

1) I've got a prototype or POC that works. I've cracked the hardest issues and
gotten it to work, at least in some way.

2) Code is buttoned up, checked in, and running in the build (probably in a
branch), maybe even reviewed.

3) Code is tested, and tests pass

4) Code is integrated and working functionally as part of a system. People are
able to call it and rely on it. Proves code does what it needs to.

So I really try not to say "it's done," but more where it is at in this SDL.

~~~
qznc
This is why I like the Scrum idea of having an official "definition of done".
It is valuable to have a shared understanding about it.

[https://www.scruminc.com/definition-of-
done/](https://www.scruminc.com/definition-of-done/)

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

~~~
username90
Software architects are more like ancient architects who were responsible for
everything, which includes structure integrity and load requirements.

------
RcouF1uZ4gsC
Seems to be getting the HN hug of death. Here is an archive:
[http://archive.is/IT34b](http://archive.is/IT34b)

------
ilaksh
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](https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars)

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

~~~
jnurmine
For larger or more complex systems, focusing on a subsystem software
architecture from a purely technical execution point of view is myopic, since
the overall architecture is much more than a subsystem architecture.

Even if a senior developer ends up "implementing the actual architecture", if
that does not mesh with the other subsystems and the other stakeholders, their
conflicting requirements, and their weighting of the architectural quality
attributes, and so on, the end result misses the goal.

Details become more concrete the more closer one gets to the developer.
Conversely, if one goes the other way, things become more abstract. You need
people for the topmost abstraction level, people in the middle levels who
understand both the abstract and the concrete, as well as the people at the
lowest abstraction level where the implementation happens.

Of course, sometimes the systems are small enough or well-defined enough so
that the person in the middle level can be the same as the highest-level
keeper of abstractions.

I don't think having a separate role of an architect is always counter-
productive. The architect as a separate role can be useful: that person
listens to other people and teams and filters and translates their desires
into something which can be defined unambiguously to be actually implemented.
If the architect has time to code too, that's great. If not, then there must
be those senior developers who can create the more technical parts and write
code, too.

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

~~~
closeparen
The book’s use of the term “architecture” is pretty different from modern
usage. It refers to the shape that the new computer/OS will present to
application developers. The architect is something like a product manager; a
voice for what the customer wants.

What my team calls “architecture” - the decomposition into services and
classes, database schemas, interfaces between major components - I think
Brooks would call “implementation design.”

~~~
eitland
Partially agree:

It seems to me that he would think interfaces between major subsystems would
be architect level while any database table that only gets used within a
single sub system is implementation level.

Trying to be careful as I realize HN is the kind of forum where he or a close
friend of him might show up to correct me :-)

~~~
bboreham
Brooks famously showed up to correct himself: the book advocates against
information hiding but he later changed his mind and said encapsulation was a
good thing.

~~~
qznc
Interesting. Do you have a link or reference for that?

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

~~~
pm90
I don’t think this is true. Agile doesn’t mean that you don’t consider long
term trade offs, only that you don’t wait until all the requirements and
studies are done before commencing system implementation. Involving software
architects in the process actually makes agile work better, as they’re able to
provide insight into fixing emergent issues that crop up in a better way.

~~~
cryptozeus
That is what I meant but you have to think differently from traditional
architecture. Like you can’t be design system upfront when scrum teams are
sprinting

------
kazinator
> _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.

~~~
cc81
She is talking about systems as in "GPS" or "Drone fleet", i.e. huge systems
with significant hardware components and that these days software will be such
an important part that it needs to be a part of the earliest designs and
requirements.

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

------
shyneeup
What is the role of an architect nowadays?

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

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

~~~
atian
Resource allocation, so you don't have to.

~~~
dominotw
not sure what this means. We do scrum board type thing at work and pick tasks
off of that board. Manager is not allocating tasks.

Perhaps you mean talking to recruiters to about hiring more resources for a
project ?

