Concept and architecture of the system
Very often, those who describe the system want to indicate not only the external properties of the system, describe not only the boundaries of the system and its behavior as a black box, but also to specify some details of the internal structure of the system: define the parts of the system (subsystems), point to the process of subsystem interaction. In this case, the system is referred to as a "transparent box," in which certain subsystems, properties, and the behavior of these subsystems can be considered known. This can be considered indications on the system concept: what behavior is expected from the internal parts of the system (the time of their operation, the functions of the subsystems), with which parts of the system construction (the construction of the subsystems) this behavior can be realized; it is also important to consider spatial aspects and aspects of the total cost. The system concept describes the "transparent box" - this is a minimum of four interrelated mandatory types of system descriptions, but most often there are more of these types of descriptions for different subjects of interest.
In any case, let's start with at least two: functional and constructive descriptions in their interrelation. For example, you are preparing to manufacture a door, and suddenly the external project roles say, "the lock in the door must be made of titanium."
The word "must" indicates requirements, not a hypothesis, and this is alarming. What if you find a better material? Why did it suddenly become necessary to indicate what the behavior of the door is afraid of the one who describes this door? What kind of broken telephone worked here, who set the scenario of use, why did this requirement arise? Where did the lock come from in the door at all, because you didn't even suspect that the door should be locked and unlocked: this was not in the usage concept. We understand that this is a description of constraints on the freedom of the developer: one developer:: role indicated to another developer:: role what should be inside the system so that this constraint was taken into account when developing the system concept. Question: where did the developer:: role come from in the external project roles. Sometimes developers of the target system on the payroll of the client organization are called "customer's engineers", and they are paid a salary specifically to create such constraints on the freedom of external developers - so that external developers do not have temptations to oversimplify or complicate the system design.
Usually, the project organization (for example, a team of several teams) agrees with the external customer of the system on the functions/behavior that the target system should perform as a black box, the properties of this black box, i.e. developers agree on the usage concept (often not entirely, but some specific usage scenarios for specific "features" that will be implemented by a specific team), while the system architect agrees on the architectural characteristics and their acceptable values for all developer teams. It is not certain that these hypotheses on the system concept and acceptable architectural characteristics are formulated by the customer! This is joint work with the customer. How the system is structured internally, that is, what functions the subsystems perform and with what physical objects the construction of the system is implemented - this is determined by the project team independently, the customer is usually more interested in the supra system, which is a "transparent box" for him, and the target system is a "black box". Moreover, this is often done not in one go, but for a long time - and continues even after the first version (MVP, minimal viable product) has already been manufactured and put into use. Often the most interesting ideas come from customer agents in their various roles, and ideas from the agents of this order will appear even after the appearance of the MVP, during the subsequent development of the system.
Solutions of the "transparent box" on how the system is divided into constructive parts (modules) and how these modules will interact to keep the values of architectural characteristics within acceptable limits (for example, the system remains easily changeable during improvements) are called architecture. Note: architecture - these are solutions to the organization of the system in terms of structure (modules/constructions and the way they are linked), as well as the system concept - these are also solutions to the organization of the system, but include both functional objects and constructive as affordances for these functional objects, as well as spatial (composition/allocation/location) aspects and reach the full cost of ownership, and may also include some other important aspects (for example, separately identified ethical and legal considerations, or aesthetic and artistic considerations, some specifics may arise in each project).
The system concept is not architecture (although a decade ago it was believed that architects develop the system concept), and the architecture is not the system concept. The functionality of the system in the supra system is determined by solutions in the system concept, but important characteristics such as "system's ability to evolve, ease of making changes in the construction" are determined by architectural solutions.
Architectural decisions/architecture decisions are formalized in various ways, for example, descriptions with a prescribed structure on several pages in the form of architecture decision records. Architectural solutions are presented as a list of such records, or some table with the content of such records. Architecture is absolutely not a "diagram". Diagrams in the project are most often not architectural, and if they are found somewhere in the architectural solution, they are often used purely for illustrative purposes and do not express architectural solutions. Do not confuse system architecture with building architecture, where the emphasis is primarily on the external appearance of the building, and the main skill for an architect is the ability to draw.
More details about architectural solutions and their records are discussed in "Systems Engineering," but for now, the main thing to remember is: you cannot say anything about the "transparent box" (neither discuss the system concept, nor discuss the system architecture) until you find out what is in the "black box," that is, the system's behavior in its environment. If you don't know what a pendulum does, you won't be able to say anything about how it can be structured!
This is the main thing to remember in systems thinking: the very first consideration of the system is the usage concept, not the system concept, not the system architecture. First, we look from the system boundary to the outside world, to the environment, specifically during operation (if you are developing a system, you need to imagine it because the operation will be in the future), and consider the behavior/function of the system. And only then do we start looking at the transparent box. If we start looking at gears in mechanical watches, and then suddenly look at the watch's surroundings, we may see that these are located in a rocket and should count milliseconds, functioning normally with overloads of 30G, as everything vibrates next to the engine, where these watches are installed. From this moment on, you can forget about the gears; it was time wasted! First look around from the system boundary outward at the moment of operation, and then only inside the system at the moment of operation, and then only inside the system at the moment of its creation!
In any case, all these system descriptions (usage concept, system concept, and architectural decisions) are hypotheses, be prepared to change them, negotiate, offer your options, listen carefully to the options offered by external project roles, and be sure to engage in justifications. "I just want it" is not an argument because now I want this, tomorrow I want something else, or "you didn't understand me, I wanted something else," or some other agent in this role will substitute you, and they will want something different - this "want" must be an informed opinion of the role, not just the desire of the agent.