Many authors are claiming that architecture of (software) systems is abstract – a good example is ISO standard on systems architecture description (see ISO 42010) (where it is also added that “architecture is … not an artifact”).

According to the Cambridge Dictionary abstract, being an opposite of concrete, means “existing as idea, feeling, or quality, not a material object” (see Cambridge Dictionary : abstract). One of the important characteristic of the abstract things is that these are considered non-causal (see Stanford Encyclopedia of Philosophy) – that is, abstract things cannot be cause of anything.

If we follow the rather largely accepted definition of (software) systems architecture (for various definitions, see for example CMU SEI), according to which the architecture has been defined as consisting of following three parts:

• a set of the components (or elements) of the software system,
• a set of the connections (or relationships) between the components themselves, and between the components of the software system and its environment,
• a set of rules and principles guiding the design and evolution of the software system (incl. rules what kind of components, and what kind of connections the software system can contain).

Then we cannot always treat the architecture of (software) systems as abstract, because architecture of an existing (software) system is embedded in the structure of that system (at least this part of the architecture that is consisting of the elements and relationships), and therefore it is real/concrete in the same way that given system is real/concrete.

Architecture of a (software) system exists “within” the (software) system, and can be observed and recaptured/recovered from the (software) system after it is built, even if the specific description of the architecture, which was used during the building of that (software) system is lost.

We can have different perceptions or conceptions of architecture of a (software) system, and we can describe these perceptions or conceptions in different ways from different viewpoints and on different levels of detail, but that does not make the architecture itself abstract.

But because the (software) systems architecture is based on the ideas and principles that define how to divide the system into the components and connections, then we can say that (software) systems architecture is always conceptual (according to Cambridge Dictionary, conceptual means “based on the ideas or principles”, see Cambridge Dictionary : conceptual).

Only in the case when the actual (software) system is not yet built (i.e., not yet existing), the architecture of such (software) system, described in the plans and design documents, can be considered abstract (i.e., existing only as an idea).

The important implication of (software) system architecture not being just an abstract, but a real/concrete thing, is that:

• architecture influences the actual qualities and behavior of the (software) system, that is (software) system architecture can be cause of certain things (but, as we saw above, abstract things are considered as non-causal, see Stanford Encyclopedia of Philosophy), and
• architecture is something that can be acted upon – it would be possible through the changes of the (software) system, change the architecture of that (software) system.