|
I've been in software architect roles on and off during my career (currently I'm on) and I feel like I've read similar discussions to the ones in the comments many times over the years. But no matter how you cut it, you can't escape software architecture when doing software development. One may call the architects principal engineers, gremlins or senior developers, the role may be covered by one person or multiple and the end result may be better or worse, documented or undocumented - in the end someone worked on the software architecture. Depending on the organization and its needs, the role may be strongly focused on technical aspects or straddling engineering and product management. A company with very specialized roles will want architects to take care of the architecture, whereas one with more flexibility might require that they also work on requirements, talk to customers, mentor developers, manage a product, etc. Some of these combinations are less than ideal. Every time I did application architecture I was also writing code, but that's not easy and may be an anti-pattern. Typically architecture tasks (especially the documentation) are neglected under time pressure and the people revert to doing what they know best, which is coding.
Application architects should be very familiar with their application domain, applicable algorithms, idoms and patterns, etc because they're essentially part of the development team. Now I'm closer to the "architect that doesn't code" stereotype, doing systems architecture. And indeed, I do not write any code besides small applications I use to validate my assumptions or evaluate and analyze solutions. I don't remember writing one line of production code in the past years and this is neither unusual nor problematic.
I work with several development teams, ensuring that their components stay technically coherent and fulfill the requirements of the system. I start by translating business requirements into technical requirements and then work together with each team observing their progress, iterating over our solutions until we are feature complete. Specifically this involves intra-component interface design, software design (in my case - how components behave and interact with each-other and the platform), architecture documentation, application architecture review, code review, etc. And meetings, tons and tons of meetings with development teams, POs, project managers, testers, lead architects, etc. I do find that working close to the metal grounds you as an architect. Whenever I do too much diagramming and abstract concept design I feel like I'm losing something important and this is where testing your concepts comes in.
But there's no general rule about what developers expect from architects. I've had teams in the same projects expect a finished concept while others were happy to implement something by themselves with minimal to no input from me as long as the external preconditions were being met. |