Is software architecture the same as source-code organization?

No. File layout can reflect some decisions, but runtime interactions and deployment dependencies also matter.

Must every component run on a different machine?

No. Logical components can share a process or run separately; that deployment choice should serve the requirements.

Does a good AI model guarantee a good architecture?

No. A capable model still needs appropriate input handling, integration, monitoring, and operational responsibilities around it.

AI Glossary / Graphs and symbolic AI / Intermediate

Software architecture

Definition

Software architecture is the organization of a software system's major parts, their responsibilities, and the ways they interact. It also includes important design decisions that shape the system's behavior and ability to change. In the supplied AI glossary, the term appears in robotics, where perception, planning, execution, and control must work together rather than merely exist as separate algorithms.

What it means

An algorithm explains how to perform a particular computation. Architecture explains where that computation belongs, what information it receives, what its outputs mean, and how other parts depend on it. Two systems can use the same planning algorithm yet behave very differently because of their timing, communication, and failure-handling arrangements.
Architecture is more than a picture of boxes. The connections need meaning: a request, a continuous stream of observations, a command, or a shared state update. A useful description also records assumptions, such as which component owns a decision and what happens when an expected result does not arrive.

How it works

Start with the responsibilities and operational requirements. Divide the system into components with clear interfaces, then describe their interactions over time. Examine the design against concrete scenarios such as a delayed input, a changed model, or an unavailable dependency.
In a robotic hybrid architecture, deliberative planning can select longer-term actions while reactive control handles faster feedback. An executive layer can coordinate their execution. A pipeline instead emphasizes successive transformations from sensing through perception and planning to commands. These are organizing ideas, not guarantees that every system must have the same number of components or the same deployment arrangement.

Three practical examples

A mobile-robot design can separate route planning from frequent motor-control updates, with an explicit mechanism for accepting or rejecting new plans.
A document-analysis application can distinguish file intake, model inference, result review, and storage so that each interface has a defined meaning.
A forecasting service can make model replacement a planned architectural operation, including versioned inputs and a clear route for comparing outputs.

Think of it this way

Think of a restaurant's arrangement of ordering, cooking, checking, and delivery. Individual recipes resemble algorithms, while the handoffs and responsibilities resemble architecture. The analogy is limited because software interactions require precise data and timing contracts; informal coordination that works among people may fail between independently running components.

Worked example

Consider an original timing illustration for a simulated robot. A proposed serial loop performs sensing in 10 milliseconds, perception in 30 milliseconds, route planning in 120 milliseconds, and control computation in 5 milliseconds. Ignore communication overhead and assume these durations are fixed.
One complete pass takes 10 + 30 + 120 + 5 = 165 milliseconds. That is about 6.06 passes per second. Suppose the design requirement says control updates should occur every 20 milliseconds, or 50 times per second. Placing all four activities in this serial loop cannot meet that requirement under the stated assumptions.
A revised architecture lets route planning run independently while a controller updates every 20 milliseconds using an accepted reference and current local measurements. This separation removes the need to wait for a fresh 120-millisecond plan before every control computation. It does not by itself prove that the implementation meets the deadline: processor scheduling, communication, and measurement availability still matter.
The interface must also define freshness. If a plan created at time 0 reaches the executive at 150 milliseconds and the stipulated acceptance limit is 100 milliseconds, the executive rejects it as stale. Merely delivering the plan reliably is insufficient. The example shows how component arrangement and interface rules affect behavior even when the planning algorithm itself is unchanged.

Illustrative case study

In a fictional inspection-robot project, the team initially draws one arrow from a planner to a controller. During a design walkthrough, they discover that the arrow leaves several questions unanswered: whether a plan can be replaced mid-execution, how cancellation is acknowledged, and which component handles an expired plan.
They document those interactions and create simulation scenarios before integrating the components. This case illustrates architectural clarification, not a measured commercial success. A clearer design still requires implementation checks and evidence that the robot behaves as intended under realistic conditions.

Common misconceptions and mistakes

A list of technologies is not a complete architecture. Choosing a messaging framework does not define component responsibilities or resolve timing requirements. Likewise, using multiple processes does not automatically create good modularity.
Do not confuse a neural network's internal architecture with the architecture of the application that uses it. More services or layers do not necessarily improve a system; they can introduce additional handoffs and dependencies. Finally, an architecture diagram describes an intention unless the implemented system is checked against it.

Business use

For an AI project, architecture connects model capability with reliable operation and future change. It helps a team identify where data enters, who consumes predictions, how revisions are introduced, and which dependencies can prevent useful service.
A productive review uses concrete scenarios instead of vague labels such as scalable or flexible. For example, describe what must happen when an inference component takes twice as long, or when an input schema changes. The response reveals whether important responsibilities and assumptions are actually specified.

Check your understanding

A planner needs 200 milliseconds per result, while a controller must update every 10 milliseconds. Can a serial loop that waits for every new plan satisfy that control period?

Answer: No, under those stated timings. The design must change the timing relationship or the requirement; simply drawing separate boxes does not remove the wait.

Related terms

Hybrid architecture
Reactive control
Pipeline
Executive layer
Deliberative planning
Interface
Component
System integration

Learn next

Next, draw a small AI application's component diagram and label every arrow with its data, direction, and timing expectations. Then walk through a delayed-result scenario. For the worked example, add 15 milliseconds of communication overhead to the serial pass: it becomes 180 milliseconds, about 5.56 passes per second, still far below 50.

Sources

AIMA original glossary sentences, Robotic Software Architectures: https://raw.githubusercontent.com/aimacode/aima-glossary/master/sentences.txt Carnegie Mellon Software Engineering Institute, Software Architecture: https://www.sei.cmu.edu/software-architecture/ ROS 2 official documentation source, Nodes: https://raw.githubusercontent.com/ros2/ros2_documentation/rolling/source/ROS-Framework/About-Nodes.rst

Previous: Software agent Next: Software mining