The composition paradox in software architecture

One of the most prominent activities in software architecture design is the partitioning of systems into parts, resulting in architectures decomposed into elements and their relations. This decomposition is important to manage increasingly complex systems. However, complex designs largely driven by decomposition lead to elements with many complex and varied interconnections. The resulting highly coupled structures are harmful for systems that have to be composed from parts with isolated interfaces. Decomposition and composition are complementary activities in software architecture design and equally important to balance cohesion and coupling. Consequently, explicit focus is needed to compose elements into a working system as well as to decompose systems into smaller elements and relations to manage their complexity. Software architectures only designed with decomposition in mind lead to monolithic systems and thus achieve the opposite of what was originally intended. We named this nonintuitive side-effect of realizing systems the composition paradox. Addressing this composition paradox will lead software architects to decisions that will strike a better balance between partitioning and integrating both monolithic and componentized structures. We explain the composition paradox along the design and assembly of a security system. key words: asset constraint, composition, composition paradox, decomposition, prediction, quality attributes, software architecture, view