Design Decisions in Systems Architecture

in an actual design of the system, there are decisions that need to be made and discussed. and we can split this decision into seven categories based on their context like the following:

1-Allocation of responsibilities
2-Coordination model
3-Data model
4-Management of resources
5-Mapping among architectural elements
6-Binding time decisions
7-Choice of technology

These categories are not the only way to classify architectural design decisions, but they do provide a rational division of concerns.

So I know at this point you might be wondering what the heck are you talking about, what all of these means. well even me at this point I am not quite sure what all of this means. but by the time I am finished writing this article, a will make sure both of us are satisfied.

1 *Allocation of Responsibilities*

Decisions involving the allocation of responsibilities include the following:
1) Identifying the important responsibilities, including basic system functions, architectural infrastructure, and satisfaction of quality attributes.
2 ) Determining how these responsibilities are allocated to non-runtime and runtime elements (namely, modules, components, and connectors).

2 *Coordination Model*

The software works by having elements interact with each other through designed mechanisms. These mechanisms are collectively referred to as a coordination model. Decisions about the coordination model include these:

1) Identifying the elements of the system that must coordinate, or are prohibited from coordinating.
2) Determining the properties of the coordination, such as timeliness, currency, completeness, correctness, and consistency.
3) Choosing the communication mechanisms (between systems, between our system and external entities, between elements of our system) that realize those properties. Important properties of the communication mechanisms include stateful versus stateless, synchronous versus asynchronous, guaranteed versus nonguaranteed delivery, and performance-related properties such as throughput and latency.

3 *Data Model*

Every system must represent artifacts of system-wide interest data in some internal fashion. The collection of those representations and how to interpret them is referred to as the data model. Decisions about the data model include the following:

1) Choosing the major data abstractions, their operations, and their properties. This includes determining how the data items are created, initialized, accessed, persisted, manipulated, translated, and destroyed.
2) Compiling metadata needed for the consistent interpretation of the data.
3) Organizing the data. This includes determining whether the data is going
to be kept in a relational database, a collection of objects, or both. If both, then the mapping between the two different locations of the data must be determined.

4 *Management of Resources*

An architect may need to arbitrate the use of shared resources in the architecture. These include hard resources e.g. (CPU, memory, battery, hardware buffers, system clock, I/O ports) and soft resources e.g. (system locks, software buffers, thread pools, and non-thread-safe code).
Decisions for management of resources include the following:

1) Identifying the resources that must be managed and determining the limits for each.
2) Determining which system element(s) manage each resource.
3) Determining how resources are shared and the arbitration strategies employed when there is contention.
4) Determining the impact of saturation on different resources. For example, as a CPU becomes more heavily loaded, performance usually just degrades fairly steadily. On the other hand, when you start to run out of memory, at some point you start paging/swapping intensively and your performance suddenly crashes to a halt.

5* Mapping among Architectural Elements*

An architecture must provide two types of mappings. First, there is mapping
between elements in different types of architectural structures, for example, mapping from units of development (modules) to units of execution (threads or processes). Next, there is a mapping between software elements and environment elements, for example, mapping from processes to the specific CPUs where these processes will execute. Useful mappings include these:

1) The mapping of modules and runtime elements to each other that is, the runtime elements that are created from each module, the modules that contain the code for each runtime element.
2) The assignment of runtime elements to processors.
3) The assignment of items in the data model to data stores.
4) The mapping of modules and runtime elements to units of delivery

6 *Binding Time Decisions*

Binding time decisions introduce allowable ranges of variation. This variation
can be bound at different times in the software life cycle by different entities
from design time by a developer to runtime by an end-user. A binding time decision establishes the scope, the point in the life cycle, and the mechanism for achieving the variation. The decisions in the other six categories have an associated binding time decision. Examples of such binding time decisions include the following:

1) For allocation of responsibilities, you can have a build-time selection of modules via a parameterized makefile.
2) For a choice of coordination model, you can design runtime negotiation of protocols.
3) For resource management, you can design a system to accept new peripheral devices plugged in at runtime, after which the system recognizes them and downloads and installs the right drivers automatically.
4) For a choice of technology, you can build an app store for a smartphone that
automatically downloads the version of the app appropriate for the phone of
the customer buying the app.

7 *Choice of Technology*

Sometimes the technology selection is made by others before the intentional architecture design process begins. In this case, the chosen technology becomes a constraint on decisions in each of our seven categories. In other cases, the architect must choose a suitable technology to realize a decision in every one of the categories. Choice of technology decisions involve the following:

1) Deciding which technologies are available to realize the decisions made in the other categories.
2) Determining whether the available tools to support this technology choice
(IDEs, simulators, testing tools, etc.) are adequate for development to proceed.
3) Determining the extent of internal familiarity as well as the degree of external support available for the technology (such as courses, tutorials, examples) and deciding whether this is adequate to proceed.
4) Determining the side effects of choosing a technology, such as a required coordination model or constrained resource management opportunities.
5) Determining whether a new technology is compatible with the existing technology stack. For example, can the new technology run on top of or alongside the existing technology stack? Can it communicate with the existing technology stack?.

Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be canceled. — Eoin Woods [145]