Last updated at Mon, 06 Nov 2017 18:50:38 GMT
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 Who Needs an Architect.
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, http://martinfowler.com/articles/designDead.html 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.
Martin Fowler sums up the wrong attitude nicely as “I’m not just a mere programmer – I’m an architect”. Scott Ambler also provides a useful check-list in Table 1 of the above link comparing Common Practice with Agile Practice. I particularly like the entries “Architects are held in high esteem and are often placed, or even worse place themselves, on pedestals” versus “Agile architects have the humility to admit that they don’t walk on water” and “Architecture reviews are held to validate your model(s) before being put into use” vs “Architectures are proved through concrete experiments.”
If these three points are not enough, check out “97 Things Every Software Architect Should Know – The Book”. I particularly like “Simplify essential complexity; diminish accidental complexity” as it makes an important general point, but illustrates with the case of vendor-driven models. I also like “There is no ‘I’ in architecture” as it re-iterates the points above re: humility and collaborative working and “It is all about the data”, which shows the importance of data and not just in a Big Data context. While acknowledging some of the points made regarding the maturity of the industry in “The title of software architect has only lower-case ‘a’s; deal with it”, I will continue to use Software Architect with an upper case A. The range of these 97 items shows that there is not one type of Architect and the right one for you depends on the culture of your company, but they should give you at least 97 ideas on how the role should work in your team(s). I would still suggest, however, that the three items above are required in any Architect role.
Other Influences on the Architect’s Role
The Architect in the Construction Industry
It is possible to build a house or office development without an Architect, but the involvement of a good Architect should mean that it will be a better house or office. He will do this by asking the right questions to identify the client’s requirements and the properties of the site (such as the orientation to maximize sunlight). Then he will provide sketches or more detailed plans of the design bringing in new ideas or using classic designs. He will accept feedback in an iterative approach as the design gets more detailed using the skills of Civil and Structural Engineers as required. He may also identify the materials to use and estimate the scope and cost of the project using the skills of Quantity Surveyors and Project Managers. During the construction phase, the Architect may either manage the project or work with the rest of the construction team to ensure the finished item meets the client’s needs and that the Architect’s design objectives were achieved.
Doesn’t that sound just like how an Architect should work in a software project? So you can build a software product without an Architect, but it should be better if you use a good Architect.
This construction analogy can, however, be misused to justify the Ivory Tower approach, as pointed out by Martin Fowler, but it is valid to describe how the Architect works in a collaborative way with the client and the trades and professions in the construction project. Also, there are Architects who specialize in particular areas such as office projects or passive houses or interiors or follow particular styles and you will select one based on their skills matching the project in question. Similarly, there is scope for Architects in the software industry who specialize in the design of particular systems, e.g. interfaces between components or REST APIs or data processing systems or database design.
The Soccer Playmaker
Another analogy for the Architect’s role was suggested to me by a fellow Architect, whose upcoming book will be available at architectingenterprise.com. Many of the most successful and creative soccer teams often have a player (usually older and experienced) in a linking role in midfield. He may not have the legs for “sprinting” around and chasing opposing players, but he allows the team to be more creative. He uses his experience and ball skills to direct the play with the right interventions, asking the right questions of the opposing team, while using the strengths of his own team. In many cases, the role of such a player only becomes clear when he is not playing and the team just does not seem to play as well.
Again, doesn’t that sound just like how an Architect should work in a software project, where the Architect can help the sprint by providing some key code, ideas or designs. He can also clarify requirements by asking the right questions, e.g. about performance, scalability, security or interface design and he can help to ensure the skills of the developers are used appropriately, while helping to develop their skills and interests.
Conclusion
In summary and in answer to my question in the title, I hope you are now thinking how software companies can benefit from a good Architect when they recognize it is a role that is complementary to the software development team and that should act as a link between clients, developers, managers and the rest of the company… and I hope my own manager agrees with me on how important the role is :-).
