MOTIVATIONThe engineering of Business Systems is under the increasing pressure to come up with software solutions that allow companies to face very volatile and turbulent environments (as in the telecommunications domain [3]). This means that the complexity of software has definitely shifted from construction to evolution, and that new methods and technologies are required.Most often, the nature of changes that occur in the business are not at the level of the components that model business entities, but at the level of the business rules that regulate the interactions between the entities. Therefore, we believe that sucessful methodologies and technologies will have to provide abstractions that reflect the architecture of such systems by supporting a clear separation between computation, as performed by the core business components, and coordination, as prescribed by business rules. This separation should help in localising change in the system, both in terms of identifying what needs to be changed in the system and circumscribing the effects of those changes.In our opinion, the lack of abstractions for supporting the modelling of interactions and architectures explains why componentbased and object-oriented approaches have not been able to deliver their full promise regarding system evolution. Usually, interactions are coded in the way messages are passed, features are called, and objects are composed, leading to intricate spaghetti-like structures that are difficult to understand, let alone change. Moreover, new behaviour is often introduced through new subclasses which do not derive from the "logic" of the business domain, widening the gap between specification and design.The approach we have been developing [1] builds on previous work on coordination models and languages, software architecture, and parallel program design languages. Instead of delegation we use explicit architectural connectors that encapsulate coordination aspects: this makes a clear separation between computations and interactions and externalises the architecture of the system. Instead of subclassing we advocate superposition as a structuring principle:Copyright is held by the author/owner. OOPSLA'02, November 4-8, 2002, Seattle, Washington, USA. ACM 1-58113-626-9/02/0011.interactions are superposed on components in a non-intrusive and incremental way, allowing evolution through reconfiguration, even at run-time.The main advantages of our approach are adequacy and flexibility. The former is achieved by having a strict separation of computation, coordination, and configuration, with one primitive for each concept, stating clearly the pre-conditions for each coordination and reconfiguration rule. As for flexibility, interactions among components can be easily altered at run-time through (un)plugging of coordination rules, and it is possible to state exactly which coordination rules are in effect for which components, and which configuration policies apply to which parts of the system.In the following sections we briefly summafise our approa...