- By what roles is architecture done at your company? Is it a separate architect role, or part of engineering roles?
- How are architecture decisions made and validated?
- How is architecture documented?
- How much freedom is there in making architecture decisions as a (product) team?
- Related to the previous question, are there top-down "rules" in terms of technology choices? For example: what databases you can use, what API protocols are mandated (e.g. REST vs GraphQL vs gRPC). If there are general rules, who makes those rules and who updates those rules?
- Does your company explicitly deal with "Business Architecture" next to technology architecture? If so, how and why? (ie. what problems does it solve for you?)
- What downsides do you perceive to the way architecture is practiced at your company?
Some background: I'm working at a big enterprise/corporate in Europe that wasn't originally a digital business. Like most companies, we've been focusing on making more parts of our operations digital and basically becoming a digital-first company. Now I'm interested to have a look outside my own bubble and to see how companies that are technology-focused at heart and digital-first are approaching architecture.
I'm not looking to start a flamewar on the merits of architecture roles or anything. I just want to understand how others are doing it, so I can learn.
Thanks in advance for your answers!
That is, it's entirely dependent on what teams and groups you are in.
Famously, Conway's law says you ship your org chart...
We typically talk more about "design" than "architecture", so for example our architecture is typically documented in "Design Docs".
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.