Software architecture is defined as ‘the set of structures necessary to understand a software system’. These include software elements, relationships between elements and properties common to all three elements and relationships.
Good architectural practices aim at predictable product quality, minimising project delays, saving money in the execution, integration and testing phases, and allowing a system to evolve elegantly. They specify the architectural components and relations designed to provide the relevant key qualities, and determine these key qualities, measuring it against quality requirements, and correcting any defect it yields.
Functional Requirements
Functional requirements are unambiguous, measurable descriptions of what a software program must do. They describe its behaviour, the input it gets from other systems, and the output it creates in this one. Functional requirements translate end-user expectations into technical specifications, and guide development and testing activities.
The job requires communicating functional requirements to everyone from non-technical business people to developers cranking out the code. That means their documentation has to be clear – devoid of jargon and, where possible, visual instead. Others will learn better when music is playing; still others will check out when their preferred format isn’t immediately available.
Non-functional requirements, which relate to how a product functions and is used, cover elements such as usability, reliability, scalability, and performance. A good piece of architecture should take all of these aspects into consideration when making design decisions – but to function properly, a system must make engineering tradeoffs. A product’s architecture needs to accept limitations to prioritise those non-functional requirements that are most important to what the product is trying to accomplish – and this is where architecture’s true value lies.
Quality Attributes
Quality attributes of software (such as reliability, security or efficiency) are like functional requirements: we expect them to be measurable and testable, and to be used by architects as the basis for designing systems that meet and maintain the needs of stakeholders.
Nonetheless, quality attributes such as timeliness (typical of real-time systems), modifiability and security are all valid concerns, yet Interdependent and frequently in conflict, they are hard to accomplish all at once: adding security, for example, often requires added bell-and-whistles – controls, for example, or checks – that inherently slow things down.
And it is the role of an architect to determine which attributes to trade-off, and to pick the right tactics to make that happen. This can be achieved in many different ways: a system could be made more secure by adding encryption or password protection, if those changes slowed the performance or degraded usability – a trade-off frequently made by robust architecture design processes; a good place to start such a journey is to gather and prioritise as many quality attribute scenarios as possible from the project’s stakeholders before beginning that task.
Technology Decisions
During a large-scale system’s design, it’s possible that software architects will have to trade off performance against cost and security considerations. Good trade-off analysis supports informed decisions that keep the technical complexities aligned with business needs.
Choosing which technologies would work best meant considering design goals. One of the most important architectural decisions made by Facebook was to make their web layout stateless, meaning that any of their web servers can be requested by any HTTP request thereby increasing web failures.
Architectural decisions can be made using quantitative metrics and foresight. Most architects, however, base their architecture decisions on experience and intuition; improving this process would help architects to make more measured, future-proof choices, such as using a framework to weigh up pros and cons to make sure all angles of an arbitrary chosen solution are taken into consideration.
Evaluation
Their structure should be designed from the start to support business goals, constraints and quality attributes, prompting periodic architectural reviews in a manner not too unlike those that cities use in order to avoid rushing into a building frenzy whose haphazard elements eventually produce slums.
This makes possible an evaluation cycle, to place value on behalf of stakeholders by setting key evaluation benchmarks, and carry them through the lifecycle (including inspection, testing, metrics, and the like services), so defects can be identified and triaged for remediation, an essential component of the value-value loop (make business purposes meet quality goals).
Yet some systematic SA evaluation methods have been studied depending on their scale, ranging from very lightweight to indeed heavyweight. Unfortunately though, present-day industrial practitioners do not make much of them due to this weightiness [8]. Most of the heavyweight methods call for some sort of ‘scenarios’ and ‘multi-stakeholders’ involvement into the SA evaluation — see, for example, the classic SADT approach by Set and Sorucek [2]. One of the notable examples of a metric-based technique is the Software Architecture Analysis Method (SAAM) by Magliacane et al [38]. Intuitively, its substantial foci on ‘metrics’ makes any metric-based technique embedding itself within any other SA approach by mixed approaches only, i.e., not that much of independent power [76]. Finally, the lightweight architectural evaluation methods are indeed our promising way forward.
