Acknowledgement: Some ideas in this article resemble ideas shared by Mark Richard.
The responsibilities of a software architect encompass technical ability, soft skills, operational awareness, and much more. Architecture is not limited to diagrams or technology choices. It combines system structure, architecture characteristics, architecture decisions, and design principles.
- Structure refers to the architecture styles used in the system.
- Architecture characteristics are the qualities, often called the “-ilities,” that the system must support.
- Architecture decisions are rules that govern how the system is constructed.
- Design principles are guidelines that help teams construct the system consistently.
Expectations of an Architect
Make Architecture Decisions
An architect should guide teams with constraints and desired outcomes instead of prescribing every implementation detail. For example, an architect might direct a team to use a reactive framework for frontend web development while allowing the team to evaluate Angular, Elm, React, Vue, or another suitable option.
Continually Analyse the Architecture
Architecture must evolve with the system. Architects continually assess whether current decisions still satisfy business goals, operational needs, and architecture characteristics.
Keep Current With Technology Trends
Architects need enough awareness of emerging tools and practices to recognise useful changes without adopting technology only because it is new.
Ensure Compliance With Decisions
Architecture decisions are valuable only when teams understand and follow them. Architects help establish lightweight ways to verify that implementations remain aligned with agreed constraints and principles.
Build Diverse Experience
Exposure to different technologies, systems, and delivery environments strengthens architectural judgement. Broad experience helps architects identify patterns and avoid treating one familiar technology as the answer to every problem.
Understand the Business Domain
Technical decisions must serve business needs. Domain knowledge enables an architect to translate business priorities, constraints, and risks into appropriate system qualities and technical choices.
Develop Interpersonal Skills
Architects influence more often than they command. Communication, facilitation, mentoring, and negotiation are essential for helping teams reach sound decisions.
Understand and Navigate Organisational Politics
Architecture decisions affect budgets, ownership, delivery commitments, and team boundaries. Architects need to understand these forces and navigate them without losing sight of technical and business outcomes.
Technical Breadth
An architect needs sufficient breadth to understand how decisions affect the whole system. This includes application design, data, integration, security, infrastructure, operations, delivery, and business domains. The goal is not mastery of every technology. It is the ability to ask informed questions, recognise trade-offs, and bring in deeper expertise when required.
Architecture Characteristics
Architecture characteristics describe the qualities a system must exhibit beyond its functional requirements. They shape structure, influence technology choices, and frequently compete with one another. The architect’s responsibility is to identify the characteristics that matter most and make their trade-offs explicit.
Operational Architecture Characteristics
| Characteristic | Definition |
|---|---|
| Availability | How long the system must remain available. A 24/7 requirement demands measures that allow rapid recovery from failures. |
| Continuity | The system’s disaster recovery capability. |
| Performance | Stress testing, peak-load analysis, usage frequency, capacity, and response-time expectations. Performance acceptance may require a substantial programme of testing. |
| Recoverability | How quickly the system must return online after a disaster. This affects backup strategy, redundancy, and infrastructure requirements. |
| Reliability and safety | Whether the system must be fail-safe or is mission-critical because failure could affect lives or cause significant financial loss. |
| Robustness | The ability to handle errors and boundary conditions, including network, power, and hardware failures. |
| Scalability | The ability to continue operating effectively as users, requests, or data volumes increase. |
Structural Architecture Characteristics
| Characteristic | Definition |
|---|---|
| Configurability | The ability for users or operators to change appropriate aspects of the system through usable interfaces. |
| Extensibility | The ease with which new functionality can be added. |
| Installability | The ease of installing the system on all required platforms. |
| Leverageability and reuse | The ability to share common components across multiple products or capabilities. |
| Localisation | Support for languages, character sets, units of measure, currencies, and regional formats. |
| Maintainability | The ease with which the system can be changed, corrected, and enhanced. |
| Portability | The ability to run the system on more than one platform or infrastructure environment. |
| Upgradeability | The ease and speed of moving servers and clients from one version to another. |
Cross-Cutting Architecture Characteristics
| Characteristic | Definition |
|---|---|
| Accessibility | The ability for all users, including people with disabilities, to use the system effectively. |
| Archivability | Rules for retaining, archiving, marking obsolete, or deleting data after a defined period. |
| Authentication | Security controls that verify users are who they claim to be. |
| Authorisation | Security controls that restrict users to permitted functions, data, and operations. |
| Legal | Legislative, regulatory, and contractual constraints governing how the system is built, operated, and deployed. |
| Privacy | Protection that prevents unauthorised parties, including internal personnel, from viewing sensitive data or transactions. |
| Security | Requirements for protecting data at rest and in transit, as well as controlling remote access. |
| Supportability | The logging, diagnostics, documentation, and support capabilities needed to operate and troubleshoot the system. |
| Usability | The effort and training users require to achieve their goals. Usability should be treated as seriously as any other architecture concern. |
Translating Domain Concerns Into Architecture Characteristics
Business language and architecture language are not always the same. Architects must translate broad domain concerns into characteristics that can guide design and evaluation.
| Domain concern | Relevant architecture characteristics |
|---|---|
| Mergers and acquisitions | Interoperability, scalability, adaptability, extensibility |
| Time to market | Agility, testability, deployability |
| User satisfaction | Performance, availability, fault tolerance, testability, deployability, agility, security |
| Competitive advantage | Agility, testability, deployability, scalability, availability, fault tolerance |
| Time and budget | Simplicity, feasibility |
These mappings are starting points rather than fixed formulas. The significance of each characteristic depends on the organisation, system, users, and constraints.
Team Building
The architect’s leadership approach should reflect the team’s composition and the nature of the project. A new or inexperienced team may need more direct guidance, while a small, experienced team working on a simple and short project may benefit from greater autonomy.
The following example illustrates a simple way to assess those factors:
| Factor | Value | Rating | Indication |
|---|---|---|---|
| Team familiarity | New team members | +20 | More hands-on guidance may be useful |
| Team size | Small, four members | -20 | Favour team autonomy |
| Overall experience | All experienced | -20 | Favour team autonomy |
| Project complexity | Relatively simple | -20 | Favour team autonomy |
| Project duration | Two months | -20 | Favour team autonomy |
| Accumulated score | -60 | Armchair architect |
In this example, the negative score suggests an armchair architect approach: remain available, set direction and constraints, and allow the experienced team to make most implementation decisions. At the opposite extreme, a controlling approach can become a bottleneck and prevent the team from developing its own architectural judgement.
The score is not a universal formula. Its value is in prompting deliberate consideration of how much guidance a particular team and project actually need.
Bringing the Responsibilities Together
Software architecture sits at the intersection of technology, operations, business, and people. An effective architect identifies the characteristics that matter, makes decisions and trade-offs visible, maintains enough technical breadth to understand system-wide consequences, and adapts leadership to the needs of the team.