Architects are responsible for providing the framework, or blue-print if you will – hence the title – of software applications and systems. This not only requires both a deep and a wide technical competency, but ideally a very good understanding of the problem domain that the software is attempting to address.
As enterprise level software does not operate in isolation, there will be overlap between a purely software architecture role and a systems architecture role. Since the architect is responsible both for ensuring that their design meets real-world requirements, and that it integrates as seamlessly as possible with existing systems and tools, this will require an understanding of how various components operate together as part of a larger whole.
Depending on the size and requirements of the organisation or software systems, these two roles could well be – and often are – provided by a single individual. In larger, more complex environments, these roles could be handled by separate people. However, they would then need to work closely together to ensure a robust, extensible and as risk averse as feasible solution.
Outside of the technical and problem domain knowledge, it is imperative that a software architect has good communication skills. It won’t matter how good the design is; if no-one else is on the same page, the software will quickly degrade into a disorganised mess. This requires an ability to communicate across the enterprise, from intern developers all the way up to senior management, directors and even clients where relevant.
It’s up to the architect to ensure that management and clients understand the architecture to the level of detail required. Often this will not just be about communicating decisions made, but motivating and pushing for acceptance of those ideas.
Clients – whether internal or external – ultimately have a fiduciary responsibility to ensure their IT budget is allocated as effectively as possible. If, as the architect, you are proposing a refactor of a working system, the client could reasonably be expected to push back on this, wanting to allocate expensive resources where it sees a greater priority. That’s why an architect needs to be able to effectively articulate their requirements and clearly map out the cost/benefit ratio of proposed designs.
And internally the architect is equally responsible for ensuring that design decisions are clearly communicated down into the development teams. This requires that the architecture is well defined and documented to ease its acceptance. Once the design is communicated and accepted, the architect is additionally responsible for ensuring that teams adhere to the defined architecture and standards.
All of the above, from technical and problem domain competencies, to the ability to communicate and drive adherence to architecture and standards, ultimately addresses the quality of code produced by a software development team.
If the architect has defined a competent and relevant architecture, has been able to clearly communicate it to all stakeholders, and is ensuring adherence to standards defined across consistent toolsets, then they should be able to commit to an agreed level of code and systems quality.
Although not directly within the domain of the architect themselves, successful architecture brings a host of tangible and intangible benefits to the development process.
Unified processes and consistent toolsets mean less scope for undue complexity and bugs. This has a direct impact on the throughput, or velocity, of development teams. A less complex system will have a reduced learning curve, meaning adding developers is less time consuming and they become productive much quicker. Furthermore, consistency also enables cross-team migration, since integrating a member from another team no longer has this overly expensive learning curve.
In addition to the roles and responsibilities outlined above, a good architect will do well to keep an eye on emerging technologies. This will enable them to proactively adapt their architecture to changing technology in the marketplace.
A proper understanding of how external changes may effect existing systems, enables an architect to identify areas of risk for the business, and to mitigate these risks by taking corrective action earlier rather than later.
So, to answer the original question, ‘What is a software architect?’, the answer would appear to be; someone with excellent technical knowledge and extensive real-world experience who is a good communicator, invested in staying abreast of emerging technologies.