I have been doing some limited research recently, spurred on mostly out of curiosity, about how different companies approach software architecture teams and their philosophies behind them. Such as, the decision whether to have a team or not, how big the team is, what the team’s roles and responsibilities are within a company, etc.
From what I’ve found and from my own personal experience it seems that there is a strong correlation between software architects and software architecture teams and the way a company has organized their systems. This seems to support Conway’s Law[1].
In companies where the product or service was monolithic there was either one or relatively few software architects who mostly retained the broad strokes of the system in memory and act as a deciding factor in what and how features will be structured, engineered, etc. In these situations a software architect has more direct control over the software being built. It also doesn’t seem to scale as well.
In companies where the product is distributed, or divided into different domains or micro services, there is either no software architecture team or—like the company I’m at now—an architecture team that has a less well defined role. For instance, at the company I’m and and whose architecture team I’m a member of we have historically taken responsibility for defining how those services interface and communicate with one another and the other “interstitial” spaces between those services. Each team that owns one or more services is better versed in their service architectures than any one of us on the software architecture team could ever be.
The role and responsibilities of the software architecture team that I’m on today have never felt particularly well defined. I’m OK with ambiguity, but I’ve begun wondering recently how other organizations approach this space.
Does you company have a software architecture team? If so I’d love to learn more about how you operate. If you don’t have a software architecture team, I am equally—and maybe even more so—interested in why?
---
[1] https://en.wikipedia.org/wiki/Conway%27s_law
The "old" architecture model is very top-down: architects (who were software devs/sysadmins a long time ago and haven't pushed a commit in >6mo) push top-down designs for large-scale systems that engineers (usually outsourced or entry-level) implement. This model works when most of the "doers" are entry-level but comes with a huge "you don't know what you don't know" disadvantage. It is very easy to read RFCs and docs for protocols and languages (repsectively) and surmise how things should work, but it's a whole other ball game when you _actually have to make them work_.
The "new" model that I've seen come up is closer to internal consulting than "ivory tower." In the new model, architects (who are very much software and/or systems engineers) are "assigned" to teams to help them achieve a particular mission, like migrating them onto a corporate build and release framework or helping them release their greenfield application into "Production". They will either pair with engineers during these missions or they will take items directly from their backlog (at a lower velocity than the devs on the team, of course) and push commits themselves.
I much prefer the "new" model to the "old" model.
John Smith is a great engineer. He does absolutely amazing work and is able to move up the company ladder. He interacts with many teams, has a lot of influence and so has great impact in the company. Eventually he gets promoted to the Architecture team. Once he reaches there, he can 100% focus on putting his great experience to maximize his influence and solve high-level problems. He even has regular 1:1 meetings with some powerful VPs.
The problem is: since John is now part of the Architecture team, he is not really involved in the front line anymore. There's a chance he doesn't even get to write code anymore, all he does is tell people what and how to code, and sometimes he reviews patches. He has that code assignment that he has been trying to finish for a long time, but the higher-priority Architecture Team work is preventing him from putting that time in. He'll probably have to delegate it to the new employee James Jones.
Over the course of the next few years John Smith starts getting more and more out of touch with reality. His ideas start making less sense, some of his suggestions simply don't work because of how we reworked the entire locking infrastructure last year. He doesn't know how to interact with new CI system so he gets misses some important things. John was recently asked to do a tech review on a certain new feature, but he's not up-to-date with the code since that new mega-feature so he put James Jones to do the actual review for him.
All our devs are criticizing John Smith for only having impossible or obsolete ideas, being a stupid proxy architect that does nothing useful to the company. How the hell can he get away with such a huge salary, given he's so incompetent? Did he have to do sexual favors to someone to reach that position?
But James Jones is such a great engineer, we should put him on the Architecture track since I'm sure he will be able to fulfill some of the gaps we have there! Unfortunately there are too many architects already, so we're going to have to wait someone to retire or quit, since no architects ever get fired, all the VPs love them.
What that looks like, practically speaking, varies from company to company. However, you do have to achieve a significant level of size and complexity for this function to make sense. If you're saying that architecture, in some form, doesn't make sense in an organization, I'd challenge whether the size or complexity of that organization has reached the threshold.
We have a lot of business units and each unit is served by a team or teams of engineers. I can't imagine how we can have a cohesive strategy and execute it without architects.
If your company doesn't have that complexity, I don't see why you would need architects.