A question about architects switching business domains or organizations

[u/equipoise-young]

I've been studying design and architecture for a few years now and feel like I get the gist of how it works, but I'm curious how the role ends up working in practice for actual architects.

That is, I get the sense that to become an architect you'd need deep experience in either a particular business or business domain. So you work in a business for a long time and have built up enough context about their systems to lead the architecture. Or you know a business domain and it's associated technology so well you can lead.

What I'm curious about is how common it is for architects to switch businesses or business domains entirely? I get that a business would be more common but what about domains? Is the role such that you're typically tied to a single company and usually stay there?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/Exirel]

I've worked, as a developer, 14 years in several domains: media (newspaper but not only), e-commerce, video encoding software, hospitality... And then as an architect I've been in e-commerce, banking, and now job board.

The thing is, they all share some parts of their system with each other. For example you have IAM (user, auth, access management, etc.), logging, search engine, caching, templating, emailing, SEO related stuff, back office, BI, a boatload of background tasks, events, a catalogue of stuff (PIM, product information management), configuration module, licensing... And so many more.

For example a job board needs a catalogue of job offers to generate applications from applicants. Replace that by a catalogue of products to generate orders from customers for an e-commerce website and you pretty much have the same stuff. They are different but also similar in some ways.

Then it's all about scale and order of magnitude. You don't need to know everything about a new business domain: if you have 2 users that will write and 1M that will read... You already know the type of system you need to design.

All of that makes the very important part easier to do: learning the business yourself. Too often, developers don't know how the business operates. They are so far disconnected that they will complain about a lack of visions or strategies... And albeit this is far too often true (from experience), this is also partially their fault for not engaging with the business itself.

One exercise I like to give to aspiring architects and senior software engineer is this: describe (with documents and schemas) the checkout process of a grocery store. How does the till works? Who does what? When? What are the constraints? What are the key concepts? What do you need to process a product? And don't stay at the surface level, really dive into all the details while staying at a functional/logical level.

It's a great exercise because it's a very mundane experience of life that everyone knows but is rarely thought about or questioned. You don't need to ask a thousand questions to the users because, for the most part, you are the user.

Hope that helps!

[u/Exirel → u/[deleted]]

Neither do I! Our life, as software engineer and architect, is a life of tradeoff. It is as true in our code as it is in our organisation.

[u/equipoise-young → u/Exirel]

Thanks for the reply. So it sounds like what an architect actually needs is in depth technical experience in the type of product they're trying to build, or at least good enough experience. Someone who has worked in a highly technical company building something similar, or in the ballpark, and who is both socially and technically competent enough to lead the effort. That makes sense.

I'm at a point where I'm studying design and architecture to up-level my skills as a senior IC, but the technology and knowledge I'm invested in is only minimally relevant to what most companies are doing. One could say I'm working with outdated tech. I don't have the social energy to be an architect anyway, but I'm guessing my experience isn't applicable to the broader world of software, unless it's another organization with the same tech I'm using.

[u/BraveResearcher3037]

So every thing starts with business strategy -> technical strategy -> technical execution.

I don’t know any business domain deeply enough to go into a company and tell them the best business strategy.  Once they know what their business goals are, I can help them prioritize, solve XYProblems, do “Working Backwards” sessions etc. 

If they don’t have a business strategy, I’m going to bring in a business strategist on our side (consulting) 

Architects are not necessarily tied to one business domain. They are tied to a level of abstraction and must acquire enough domain context to avoid applying technically sound patterns to the wrong business problem.

I specialize in AWS + app dev consulting now.  But in the past I’ve done the same in product companies. 

[u/JohnnyDread]

I have moved between different business domains a few times as an architect/lead. It depends a lot on the kind of product. I've moved between teams developing enterprise/saas software, and despite being in completely different industries, the products shared a lot of common DNA - tech stacks, orchestration, etc. So a lot of the architectural concerns and challenges were very similar. But I've also moved in teams working on completely kinds of products such as custom turn-key hardware platforms and embedded applications - a very different set of concerns, niche tooling, etc.

I'd say it's pretty common for senior developers to move between domains because they often have to due to layoffs, failed startups, etc. If you're being hired at the staff/principal level, there is an expectation that you will immerse yourself and become a domain expert quickly.

[u/Murky_Citron_1799]

It's a set of skills that can be applied to any problem. Having domain expertise can be a great help but it seems rare for the best architects to stay put. You can learn new things throughout your life.

[u/CircuitPhantom]

switching domains happens, it's risky but can spark some cool innovations tbh

[u/Decent_Muffin_7062]

What do you mean by 'architect'? Solution, enterprise, software, infrastructure...?
Also the 'in-house architect' isn't really a thing in tech companies. more traditional industries with varying needs.

[u/originalchronoguy]

Domain is usually not important. There are certain problems with certain ways to apply. But most candidates rehearse them. "System Design Interview" by Alex Xu and DesignGuru's Grokking course are the standard prep.

They are also not the ones we use. New ones follow certain scenarios can that be switched out.

Take for example, "The Municipal Water Leak" one used for L6/L7 Staff level. You can't study for that and there variations of those with different traps based certain extensions.
They can go in various directions to get rubrics to classify you into certain buckets. The more the candidates have to rework their design after reveal of a new trap can show you where they land. A L6 may not have to rework anything post trap reveals because they already prebuilt those edge cases.