Dear all, Just some precisions about the reason and role of Logical architecture in Arcadia: In some (mainly software oriented) modelling approaches, what is called a “logical” architecture is a definition of (software) components and assembly rules, while “physical” architecture is a description of one or more deployments of instances of these components, on execution nodes and communication means. This is not the case in Arcadia: the major reason for logical architecture (LA) has nothing to see with software dominant systems : its purpose is to manage complexity, by defining first a conceptual, high level view of system architecture and components, without taking care of design details, implementation constraints, and technological concerns - provided that these issues do not influence architectural breakdown at this level of detail. As an example, for a hybrid car, LA would show the design decisions regarding role of combustion and electric engines, whether they are expected to work together or not… For first level decisions, no need to describe how the transmission is built; this will be detailled in Physical Architecture. By this way, major orientations of architecture can be defined and shared, while hiding part of the final complexity of the design, and without dependency on technologies. As an example, some system models have one single, common logical architecture for several projects or product variations (and several physical architectures). In fact, logical architecture should have been named ‘notional architecture’, or ‘conceptual architecture’, but we had to meet existing internal denominations. Physical architecture (PA) describes the final solution, including what has not been taken into account at LA level, ready to sub-contract, purchase or develop, and to integrate. So all configuration items, parts and assemblies, software components if any, hardware devices… should be defined here (or later), but not before. In the car example, PA could go up to listing major parts of the transmission (if subject to System Engineering/architecture design decisions), in order to fully characterize and subcontract them. As you can imagine, then, for one logical component, we can often find several physical components, relation is one to many. Similarly, functional description of component is notional in LA, and detailled enough in PA so as to sub-contract it. So Logical Architecture is recommended in Arcadia method, because it eases the bridge between Need and Solution, without needing to dive into full details. However, the deployment of the method can be adapted if necessary: we already have examples of operational units skipping Logical Architecture… and some (but not all) of these units decided later to create a LA a posteriori, because their context made it useful. Capella already allows to work without LA, although it is a bit tricky, and could be improved. Some of you might be interrested in adding this capability .