2.1Fundamentals of system architecture design

A system architect's first task is to decide, for each function uncovered during requirements definition, who or what will realize it. Automating everything in software is not always the right answer—dedicated hardware can sometimes win on performance and reliability, and an exception path that occurs extremely rarely may be deliberately left as a manual procedure because doing so minimizes the total of development and maintenance cost. This section covers the judgment axes for functional allocation and the practice of selecting an architecture under multiple trade-offs.

2.1.1Functional allocation: hardware, software, manual

• Functional allocation is the design step of deciding whether a required function should be realized in dedicated hardware (fast and highly reliable, but costly to change), software (flexible to change, though sometimes inferior in raw processing performance), or a manual procedure (suited to exception handling that occurs rarely and requires highly situational human judgment).
• Allocation must never be decided on a single axis such as performance alone—realizing a function in hardware boosts performance but can be costly and slow whenever the specification changes, since it requires a redesign and remanufacture. Conversely, leaving everything as a manual procedure risks a surge in human error and processing delay the moment its frequency rises. It is the system architect's role to allocate functions by weighing frequency of occurrence, frequency of change, required performance, and staffing cost together.

2.1.2Judgment axes for method selection

• Method selection typically involves a trade-off among four representative axes: performance (response time, throughput), cost (development, operations, licensing), availability (uptime, blast radius of a failure), and maintainability (ease of change, localized impact). Maximizing one axis often sacrifices another, and it is the system architect's judgment to choose the compromise point that aligns with the requirements' priorities.
• For example, adding redundancy raises availability but increases cost, and splitting functionality into finer units raises maintainability but tends to lower performance due to the communication overhead between calls. Method selection is not about "which option is superior" but a relative evaluation of "given these requirements, what do we prioritize and what do we accept?"

A system architect has been assigned to design a new system that monitors a factory production line. The requirements include two functions: "judge temperature and vibration sensor data in real time at millisecond granularity, and immediately trigger an emergency line stop on anomaly," and "aggregate monthly production results and auto-generate a report for executives." For the former, any delay in judgment directly risks equipment damage or a safety incident, so the communication and OS-scheduling latency of software processing on a general-purpose server cannot be ignored, making it appropriate to allocate the function to dedicated embedded control hardware (such as a PLC or FPGA). Hardware realization raises redesign cost, but this function changes specification rarely and safety is the top priority, so prioritizing performance and reliability over the added cost is a reasonable call. For the latter, monthly aggregation and report generation, real-time behavior is unnecessary and the aggregation logic (adding new metrics, etc.) is expected to change frequently going forward, so it is more appropriate to allocate it to software (batch processing), prioritizing maintainability and ease of change. Furthermore, for the function of "detecting a failure in the sensor itself," which occurs extremely rarely and carries a large impact if misjudged, it is worth considering leaving it as a manual workflow in which on-site staff visually confirm a rare anomaly, rather than spending development cost to automate it. In this way, a system architect assigns different realizations to different functions even within a single system, designing the optimal combination from the multiple axes of frequency of occurrence, frequency of change, required performance, and cost for each.

2.1.3Section summary

• Functional allocation weighs hardware, software, and manual realization together using frequency, change frequency, required performance, and cost
• Method selection is a relative evaluation of trade-offs among performance, cost, availability, and maintainability, never decided on a single axis
• Even within one system, different functions may get different allocations, designed as a combination that follows the requirements' priorities