I think you may be assuming I'm not familiar with the current application. I am. I've worked on all of them, have access to all the source code, and I'm very go

I think you may be assuming I'm not familiar with the current application. I am. I've worked on all of them, have access to all the source code, and I'm very good at asking questions with the teams. I think you're also assuming a level of depth around these arch documents. Much of it is highly fungible discussion facilitators, not hard design requirements. Call it a 60% architecture. If it's systems I don't know anything about, then I'm going to limit myself to architecture reviews. And the engineers on the team will do the same deal. I'm a higher level engineers so I do cross team reviews a lot. But Them being able to write up fast arch docs helps them with their team and with larger reviews. For existing systems with totally new features it doesn't acutally matter that much what the existing system looks like. All of our applications are mainly micro-services with the same rpc mechanism, using one of just a few data stores, all running in the cloud. There's really not that many different things people can be doing. At the end of the day it's an RPC service that does some business logic and stuffs it in a database, or fetches it, with maybe some asynchronous processing or a workflow engine, and maybe a cache. I may also misunderstand your statement.