Random Acts of Architecture

Of course, a software architect individual needs to know the product’s languages, frameworks and tools – it is one of the main things that separates him or her from a business analyst or program manager. If they have previously been a senior developer on the team, that helps with credibility. However, your best developers are not always the best architects. Promoting one of them to an architect position means they are not working with the code day-to-day and this may not be what either the developer or the team wants. A software architect is more interested in the what and why rather than how.

The most important skill a software architect can have is good communication skills. This is not just because they need to talk to a variety of audiences. They need to sell the vision and high level design to non-technical business managers and VPs and build confidence and credibility. They need to impart critical decisions to senior and junior developers and QAs. They need to gather requirements from product managers or customer advocates and demonstrate to them their vision and design meets those requirements. They need to help documentation writers, UI designers and localizers contribute effectively to the product. A software architect may also need to defend implementation decisions to other products’ architects or agree on product interactions and integrations. These are topics I will deal with in later posts.

Software architects need good communication skills because they are responsible for creating a vision and high level design of a product and, if the software architect’s vision and design cannot be communicated to those implementing it, the software architect has no vision or design. Holding the implementors responsible  for understanding and implementing the architect’s vision is like holding patients responsible when they do not forewarn their doctor of them being sick. If developers or QA have misunderstood requirements, the software architect is in the best position to identify and correct that.

Second, a software architect must be able to recognise a good vision, design or decision. Yes the architect should be able to produce a good vision and design but there will always be cases where someone has a better idea or solution. As Helmuth von Moltke said, “no battle plan ever survives contact with the enemy” and this is true of anything an architect produces. The key point is accepting and incorporating good ideas from others.

Indeed, having the confidence to accept changes from vocal stakeholders or implementors can make them feel like they own the product. The design and vision ceases being just the architect’s and starts being the group’s and this collective ownership is not to be underestimated.  The job of an architect is not to produce the best vision or design but to ensure the product gets the best vision and design.

Third, a software architect should be motivated to learn as much about customers as possible. Product managers and other customer advocates can help with this but it is no substitute for original research and experience, such as attending conferences or reading magazines. The difficulty here is doing this effectively. For example, attending support calls may be easy but often give a vision skewed toward vocal and important rather than typical customers.

Last, a software architect has to be willing to roll up his or her sleeves and do “grunt work” when required. For example, if the architect is recommending a third-party library, the architect has to fill out the forms and attend the meetings with the legal department to get this approved. If the development team has daily or regular meetings, the architect should attend these, even if just to listen. If the development team is going in the wrong direction (“We’ll never need indexes on that table containing millions of rows!”), the architect may need to create a proof of concept showing a better one. After all, the architect is just as responsible as the rest of the team for shipping a good product.