Track host: Frank Buschmann, Siemens

Support for flexibility and variability is a key quality attribute of many software architectures, especially of platform and product line architectures, which form the architectural basis for many different software systems or products.

Designing flexible software architectures is a challenge, however. Too little support for flexibility means not meeting all varaibility requirements. Too much flexibility, in contrast, often results in software architectures that are so flexible that it is difficult or even impossible to create a meaningful instance of that architecture. Flexibility in the wrong place or realized with inappropriate design measures can even result in unusable or even inflexible software architecture. And often, flexibility requirements are in conflict with other architecture qualities, such as performance and robustness.

This talk, therefore, explores common patterns and practices that help desinging software architectures that exhibiit the right degree of flexibility: nott to litte, not too much, and always with appropriate measures. In addition, the talk hints at technologies that can help realizing the chosen flexibility design tactics.

Experts never become tired to emphasize that software architectures should meet appropriate qualities to be successful and sustainable, such as flexibility, performance, robustness, and so on. Also, a lot of design tactics, patterns, and practices are known to meet such architecture qualities.

On the other hand, experience shows that most "real" software architectures follow another pattern: the "Big Ball of Mud" (see http://en.wikipedia.org/wiki/Big_ball_of_mud -- Joseph Yoder and Brian Foote), a casually, even haphazardly, structured system, whose organization is dictated more by expediency than design. Such a system works, somehow and for some time, but its maintenance and evolution is a costly nightmare.

How can it be that theory obviously deviates so much from practice? From a pessimistic perspective we can even ask: Do we actually need architecture quality? Isn't architecture quality simply a marketing term, or something a project can try to achieve, but if it does not work out, does not really matter?

On this panel, world-class software architects discuss, whether or not architecture quality is really needed in practice, and based on their position explore the fine balance between too little and too much architecture quality -- to define systems that are good enough!

Patterns have found a place in the toolbox of modern software developers. From their origins in building architecture to their recognition in frameworks, they have proven to be an effective means of capturing design knowledge. They provide a vocabulary for communicating and a platform for reasoning about design. In one sense they are nothing new, but in another there is still a great deal that many in software development can learn. Many developers find themselves constrained by a view of patterns that is anchored in the seminal but early work of the Gang of Four. There are many valuable perspectives on patterns, as well as many patterns. Appreciation and immersion in such perspectives is likely to improve not only understanding of patterns, but also architectural knowledge and design instinct.

This session takes both a broad and detailed look at patterns, embracing a perspective that spans over a decade of the POSA series. Concrete examples of individual patterns, pattern compounds, pattern complements, pattern stories and pattern languages are given, drawn from the various POSA volumes and beyond. This view is complemented with discussion of the concepts and theory behind patterns, a view that has evolved and matured over two decades of pattern usage in software.