Software architect

A software architect is a software engineer responsible for high-level design choices related to overall system structure and behavior.

It's software architect's responsibility to match architectural characteristics (aka non-functional requirements) with business requirements. For example:

• Having a high customer satisfactions requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system.
• Doing mergers and acquisitions (M&A) requires extensibility, scalability, adaptability, and interoperability
• Constrained budget and time requires feasibility and simplicity
• Faster time-to-market requires maintainability, testability and deployability.

Strategies for Software Architects to Handle Uncertainty

Software architecture and, subsequently, software architects inherently deal with uncertainties. It is the software architect's job to decide the size of architectural components, which can significantly influence a system's outcomes, both positively and negatively. Neal Ford and Mark Richards propose an iterative approach to address the challenge of identifying and right-sizing components. This method emphasizes continuous refinement as teams develop a more nuanced understanding of system behavior and requirements.

The approach typically involves a cycle with several stages:

• A high-level partitioning strategy is established, often categorized as technical or domain-based. Guidelines for the smallest meaningful deployable unit, referred to as "quanta," are defined. While these foundational decisions are made early, they may be revisited later in the cycle if necessary.
• Initial components are identified based on the established strategy.
• Requirements are assigned to the identified components.
• The roles and responsibilities of each component are analyzed to ensure clarity and minimize overlap.
• Architectural characteristics, such as scalability, fault tolerance, and maintainability, are evaluated.
• Components may be restructured based on feedback from development teams.

This cycle serves as a general framework and can be adapted to different domains.

Anti-patterns

The following architectural anti-patterns can arise when architects make decisions. These anti-patterns often follow a progressive sequence, where resolving one may lead to the emergence of another.

• An architect may delay or avoid making architectural decisions due to the fear of choosing incorrectly. To address this, ongoing and close collaboration with the development team is often necessary, with architectural choices being adjusted based on their feedback. Additionally, decisions are typically made at the "last responsible moment," ensuring there is enough information to justify and validate the decision, while avoiding unnecessary delays that could lead to analysis paralysis and hinder the team's progress.
• Another anti-pattern can arise when architectural decisions are forgotten, not documented, or not understood, leading to repeated discussions without resolution. This often occurs when email is used to communicate architectural decisions. To address these challenges, architects typically provide both technical and business justifications (often related to cost, user satisfaction, and time to market) in a single record of the architectural decision (usually an Architecture Decision Record). This record can be maintained in an accessible repository, such as a wiki. Communication via email focuses on the nature and context of the change and is directed only to relevant stakeholders, with a link to the centralized record. This ensures there is always a single updated source of truth. Additionally, if an architectural decision does not offer tangible business value, or if the business value is misaligned with business stakeholders, it may need to be reconsidered.

See also

• Software architecture
• Software engineering
• List of software architecture styles and patterns

External links

• International Association of Software Architects (IASA)