The first part of being a good architect is to observe. That means listening to others, using the existing products, inspecting some of the code, or getting involved in some. Unless there is a very specific technical problem you’re faced with day one, applying you’re technical skills day one is probably a mistake.
The second part is to identify needs. A key part of an architect’s position is to identify the needs that development teams didn’t know they had. Sometimes they do know these needs, but aren’t quite willing to admit it. It’s important to be careful in how you use that information. If you run out in to the office and shout out your findings, it’s unlikely you’ll meet the future steps with much cooperation from the development teams. I have to admit, I’ve had that lesson reinforced the hard way more than once.
The truth is that while you may be correct about those needs, the damage to trust is real, and justified since it’s likely upper management will see your declaration as a critique on the competence of the development teams. It’s not impossible that your discoveries are valid criticisms of the development teams, but it’s more likely there are historical reasons behind them. Deadlines, an unpredictable shift in technology, or an encumbrance that predates their time are some of the many possible root causes.
At the same time, it’s necessary to be providing solutions to the needs the teams already know. Sometimes those questions have uncomfortable answers. For example, they may be having problems with performance due to chatty communications. The answer they are hoping for is a super compression algorithm, but no compression algorithm can fix chatty communications. An architect is responsible for more than just solutions, an architect is responsible for mentoring developers and helping them understand why solution A cannot fix their problem and how to avoid ending up in the same trap in the future.
In the other direction, toward executives, an architect’s role involves setting expectations, and building support for the needs of development. Of course as well, there is much listening involved, because an architect must use information on product plans to determine what long term needs exist in development that have not yet been identified, and to evaluate the priority of those that have. Maybe there is a need to support a different platform, or a different device. Those needs would advocate more attention paid to how the user interface and model are separated.
Setting expectations not only covers the obvious, underestimation of effort and duration, but also the highlighting those areas where changes in software or hardware have opened new opportunities.
Since it’s common for development managers to have aggressive schedules, an architect often needs to be the voice advocating for a little more time here or there to get the fundamentals right. These efforts should pay off later, but since those benefits may be outside the project itself, organizational, or just longer term, it may be counter to the incentives given to other managers.
That conflict of priorities, and how to handle it, is often a greater challenge than the technical problems themselves. It would be appealing to see what would happen if an architecture department had an allocation of some kind such that it could internally compensate development teams for the extra efforts architectural initiatives may introduce to their product cycle. In my experience though, the main credit of an architect is trust. Cultivating trust among development teams and executives, making sure executives understand the benefits to overall development architecture brings. In addition, making sure executives understand the constraints of the development teams will win you trust among the development teams.