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.