It was comforting to see that a low ceremony approach (based on CRC cards, spoons, and some dried vegetation!) to understanding the system requirements allowed us to come up with a testable (almost literally) 'strawman' system model fairly rapidly. The resulting architecture was testable in the sense of allowing us to play around with different physical partitioning and allocation of object responsibilities, looking specifically for the effect on the non-functional properties of the system. It was noticeable that objects came before components, ie looking for components as part of the analysis would not be as a useful exercise as they are related to deployment architecture and the latter stages of the lifecycle.

Generally, what seems to missing is a way to both arrive at and proceed from the architecture prototyping stage with a little more confidence. There are many successful practices that skillful developers follow in developing distributed systems, and there is also a lot of sound theory. However, in the majority of cases these are not tied together and packaged in a form that most developers can readily grasp. In short, effective patterns that tie together practice with rationale, creating a language or languages suitable for developing either specific types of or, more ambitiously, general distributed object systems.

In the same way that, for example, database developers have the concept of normalisation that is grounded in theory but easily articulated and put into practice as rules of thumb, we need some equivalent for distributed object systems. "Interface normalisation", as we might call it (the interface, the whole interface and nothing but the interface), deals with reducing coupling and increasing cohesion of interfaces (eg Role Decoupling and Dependency Inversion). We might also consider the idea of "temporal normalisation" to capture the way that an interface is used over time, ie the dynamic rather than the static view which at a simple level leads to the Combined Operation and Batch Operation idioms.

Can we take these ideas further? Documenting successful practices at all levels of granularity, establishing how they relate to one another, and then empirically validating them in workshops and on real projects?