It isn't.

That is, it's entirely dependent on what teams and groups you are in.

Famously, Conway's law says you ship your org chart...

For a brief overview of how software engineering is done at Google, see my paper "Software Engineering at Google" <https://arxiv.org/abs/1702.01715>, and with regards to architecture, see in particular sections 2.9, 2 11, 3.3, 3.4, and 4.1.

We typically talk more about "design" than "architecture", so for example our architecture is typically documented in "Design Docs".

This is an excellent overview. Thanks for sharing!

Depends on the area and the team.

For product web-related teams, it’s often “pick something decent that will get you shipping the fastest”, with product-y infrastructure teams generalizing/cleaning/more carefully designing things up later, assuming the investment doing so makes sense. Documentation happens minimally if at all; architecture conversations happen but are somewhat on the fly (ie a few folks making a drawing on a white board before moving on). This is generally the pattern for anything new/hot/needs to get out of the door yesterday.

Larger scale infra code tends to be a bit better. Newer iterations on older systems (which may have a bit less pressure) tend to have a bit more time for structure. Many teams will have architecture review structures in place, though it is by no means mandatory. There is no separate architecture role. Who is doing what architecture depends on the complexity of the system/subsystem. Documentation here tends to be better though, IMO, it’s only really the open source stuff -— or that 20% of the engineers in the company are using, and only maybe API-level at that -- that has “good” documentation.

(There is also some code that the company has which is tightly coupled with hardware. Due to the longer timeline of these projects and how hard it is to change things, these have more architecture and process.)

Overall, everyone is responsible for their own code quality/architecture. How much it’s important depends on “where a feature is in the product cycle” and “how critical is it to get this component correct”. Folks are free to use whatever design they want as long as it makes sense. The constraints of “what is reasonable for the product/what already exists/what will others on a given team understand”, however, will tend to strongly imply some best practices. These best practices generally end up being codified in an internal searchable wiki/message board, usually in a team’s onboarding doc or in a “how do you use this” doc for a feature.

Pros to this are relative freedom, speed, and ability to adjust as a situation deems fit. Taking a theoretical approach here, you can think of it as there being a “best-appropriate-velocity” that a given team/organization can function at given their product/environment constraints. Rather than being prescriptive about what this should be by inducing artificial tangential constraints, letting folks choose the structure that makes the most sense tends to increase the likelihood these teams will approach this “best velocity”. To this end, I would say doing so (and structuring a culture around it) has been a large part of this company’s success.

Cons are that oftentimes code is not documented (which can be a struggle for folks unused to the culture); particularly spaghetti systems may remain untouched for years. Systems that could be unified may be left un-unified for longer than they should be. It can also be hard to push for large systemic changes without a lot of effort, though whether that is a bug or a feature (and whether some of the missteps these cause are about “architecture” versus “product intuition”) is another question.

Not sure what you mean by “business architecture” —- if here you mean the structure of large divisions within the company, there are plenty of directors/VPs/etc for that.

This was an very solid breakdown. If I may lend some color: (disclaimer: I'm part of a team doing architectural design of new SDKs at MS, and am somewhat proud that we're actually Trying To Get Outside Involvement, so willing to hold that up here, all thoughts and opinions are only my own.)

To your points about "api-level" and "open source", in my end of the world I have the rare opportunity to share "Real world examples" of how we do architectural design, as we're extremely open with that process/do an increasing amount on github. @Op, feel free to take a peek if it'd be useful, we try to do enough of our discussions in issues/PRs (tagged per product) that you may be able to get a sense. [0]

The parent's comment certainly covered the bulk of my bigCo experiences, but I'd be remiss to not give examples of the niches where more of this does happen; as we also tend to cover many of the questions OP asked (guidelines on tech and arch choices, documentation, alignment and freedoms, etc) The downsides may also be apparent from this example, especially to anyone who has been an open source participant: Many cooks in the kitchen, many competing interests, and many often conflicting idioms. While these are in some part specific to shared API architecture over e.g. system architecture, I do find they take the same broad shape (largely incentive/stakeholder based) as the compromises we make broadly, but indexing far higher on backcompat, consistency, and alignment.

[0] https://github.com/Azure/azure-sdk-for-net/tree/master/sdk

Thanks for your insightful reply! The discussions I see on GH seem to be mostly about software architecture (by which I mean: how to solve a certain problem with code). How do you design and discuss systems architecture? (ie. how do you choose components/technologies like databases, API protocols? How do you discuss the interconnectedness of components/systems?)

Thanks for your response, very useful! May I ask you what companies you work/have worked for where you experienced what you described? (I understand if you cannot say)

Regarding "business architecture": your question is in a way already an answer to my question. "Business architecture" doesn't seem to be something that is done at digital-first companies like FAANG, but is something that is prevalent at brick & mortar enterprises that have IT. In my understanding it involves breaking down business processes and assigning them to different business domains so that applications/systems can be built to support those processes. It does not involve any technical choices.

In tech companies, the systems are products themselves, they do not support company's business processes. Hence, not much need for business architecture (although they may have some related to HR, IT, payroll, accounting etc. ?)

That's an excellent point. I hadn't thought about it that way.