Having high customer satisfaction 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.[2]
The approach typically involves a cycle with several stages:[2]
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.[2]
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.[2]
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.[2]
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.