The latest issue (Journal 15) has the theme of "The Role of an Architect". Under this umbrella there are several articles that explore the nature of the architect role, and highlight some of the challenges involved in being an architect.
The first article is "We Don't Need No Architects" by Joseph Hofstader. It is an interesting article identifying the role to be played by architects in projects, and distinguishing the architect role from the role of developers. It makes a number of critical points about the skills that an architect needs such as the ability to think abstractly and conceptually, and the ability to understand and leverage patterns. However in my opinion it only answers a small part of the question; everything that the article states is quite true, but it only represents a small part of the architect's role.
The article does not distinguish between solution architect and enterprise architect, but implicitly it refers to solution architects. Within the solution architect role critical to success are the soft skills. For example:
- People - in anything other than the smallest organisation, a solution architect needs to work in a cooperative, consensual manner, ensuring buy-in for the solution architecture from all key stakeholders. Without this buy-in there can be no confidence that the solution as implemented will match the solution architecture.
- Politics - related to the previous point, there is an element of organisational politics that solution architects need to be aware of; I'm not suggesting that solution architects need to be Machiavellian and manipulative, but all organisations have politics and if a solution architecture is to be accepted by key stakeholders these political pressures and drivers need to be understood.
- Commercial - in principle commercial drivers should be captured as solution requirements that drive the solution architecture. The reality in my experience is that commercial drivers are never documented in that sense (and an organisation may not want to document such drivers) so a solution architect needs to be aware of these drivers when making architectural decisions. For example a difficult commercial relationship with a particular supplier might mean that an abstraction layer should be placed around that supplier's API to insulate the solution from a future change of supplier