HOME

TheInfoList



OR:

A software architect is a
software engineer Software engineering is a branch of both computer science and engineering focused on designing, developing, testing, and maintaining software applications. It involves applying engineering principles and computer programming expertise to develop ...
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 satisfaction Customer satisfaction is a term frequently used in marketing to evaluate customer experience. It is a measure of how products and services supplied by a company meet or surpass customer expectation. Customer satisfaction is defined as "the number ...
s requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system. * Doing
mergers and acquisitions Mergers and acquisitions (M&A) are business transactions in which the ownership of a company, business organization, or one of their operating units is transferred to or consolidated with another entity. They may happen through direct absorpt ...
(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-pattern An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer An ...
s 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 architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements a ...
*
Software engineering Software engineering is a branch of both computer science and engineering focused on designing, developing, testing, and maintaining Application software, software applications. It involves applying engineering design process, engineering principl ...
* List of software architecture styles and patterns


References


External links


International Association of Software Architects (IASA)
{{DEFAULTSORT:Software architect