To reiterate, an aspirant architect should have in-depth knowledge in either one of the application, data or infrastructure domains. Just has having at least one pillar to support the roof of a house is essential, an IT architect needs depth in at least one of the domains to support a solution architecture “roof”.
A critical related concept is architect depth. Having depth in one of the domains is important, but it is not necessary, or advisable, to act as the SME for that domain. Architect depth loosely means that, that at most, the role requires only the level of expertise and input required to develop and communicate architecture-level information. For example, an architect who was a software developer in a former job should understand that at architect depth, there is no need to get into detail design decisions. Provide breadth and depth, but do not step on the toes of the developer team in the process. A good architect should always include the developer’s point of view in a proposed solution; as it is important for that person, normally the SME for that system or application, to buy into its planned implementation. That is because those selfsame developers will be the ones implementing and supporting it. Although this example comes from the application development world, the same concept applies to business, data, and infrastructure domains. Navigating this process can sometimes be difficult. When an architect’s specialized skills coincide with the application or system on which he or she is working, there can sometimes be a temptation to dive into the details and to take control of the entire depth. Inevitably, this leads to frustration for other members of the team, who have trouble determining where their expertise begins and the architect’s expertise ends.
Reference: How to Become an IT Architect, Cristian Bojinca, Artech House, ISBN: 9781630811464