Architect Company

This may be a dangerous question to ask for someone whose role is that of an Architect, but I think it is a valid question for an Architect to ask. This is particularly true in the software industry where the role is interpreted in many different ways. In some cases, an Architect may work in an established enterprise company and hand down instructions on technology stacks to the developers. At the other extreme an Agile development team may work without the involvement of an Architect. Neither extreme is desirable, as the former ends up with a disempowered development team, is slow to adopt new technologies and produces designs that have to be reworked significantly in development owing to the lack of developer input. On the other hand, the latter approach may sometimes lead to a “code and fix” mentality resulting in spaghetti-like software suffering from a lack of initial problem definition, modeling or appropriate abstractions. As a result there will be ongoing major changes in design and bug fixing (as opposed to appropriate design iterations as more knowledge is gained during development). This question is also nicely addressed in Martin Fowler’s article

The Role of an Architect

Three Key Aspects

So how should an Architect work to avoid either of these extremes? In my opinion, the answer lies in three key aspects of the role that allow an Architect to identify the fundamental elements required in a design while still working as part of the project team:

1. An Architect must be involved in an envisioning and modeling phase as part of the Agile process. This recognizes the need to interact with clients, product managers and developers in order to provide initial models and designs that can be built on in an iterative manner. It is also a good place to encourage the team to be creative in the solutions considered. Indeed, if your Agile process does not include such a phase, then I suggest you reconsider your process. I like Scott Ambler’s ideas for how architecture and architecture modeling, with humility, should be considered throughout the lifecycle and not in an ivory tower, front-heavy process.

In the area of design, I recommend reading pretty much anything on Martin Fowler’s blog and his other writings. As an example, includes a nicely provocative section titled “Do you wanna be an Architect when you grow up?”. It puts into context the role of design in figuring out the big design issues up front in a strategic manner, the purely tactical “code and fix” approach and ways to balance planned design with extreme programming’s test, code, refactor approach. Another example of how to do Architecture well can be found in the RESTful Architectural Style and the principles it is based on. Note that REST is often described as just an API using HTTP verbs, but it is in fact an Architectural Style with principles, abstractions and key roles identified.

2. An Architect must have the required technical skills with the appropriate domain knowledge and experience. This should include Computer Science or Engineering fundamentals relevant to the area in question, e.g key algorithms, relevant design patterns, related standards, current/emerging technologies or business models in the domain. This usually requires hands-on work in terms of developing prototypes, contributing code or evaluating technologies and meeting potential or current customers. Another aspect of this is to be comfortable reviewing the code to ensure the quality of the design by avoiding complexity, advocating clarity and to do this with the team (it’s not just the Architect who should be concerned about this, even if he may be responsible).

3. A collaborative working style with a degree of humility and providing mentoring as required. This immediately rules out the Ivory Tower approach and stresses the importance of people skills as well as technical skills. The collaborative working style is key to enabling feedback from others in the process such as developers and product managers and in order to understand what the client needs and wants. Such collaboration also allows the Architect to become familiar with the skills and interests in the team and to share their knowledge with the rest of the team. Humility is required to ensure that all the team is listened to, as they may have more specific experience or knowledge for the problem at hand. This does not mean that the Architect is not strong enough to make recommendations in the event of disagreement, i.e. just the right degree of humility, but that the recommendation may not be the one he initially presented. It also means that he is willing to change any decisions made as new knowledge is gained during the project iterations.