Why is software so difficult to change? When you establish your initial vision for the software’s design and architecture, you imagine a system that is easy to modify, extend, and maintain. Unfortunately, as time passes, changes trickle in that exercise your design in unexpected ways. Unlike what you had anticipated, each change begins to resemble nothing more than another hack, until finally the system becomes a tangled web of code that few developers care to venture through. Eventually, modifications to the software intended to improve the system have the opposite affect of breaking other parts of the system. The software is beginning to rot.

The most common cause of rotting software is tightly coupled code with a heavy dependency graph. This session explores the most common symptoms of rotting design, examine their root cause, and present techniques and patterns that have been used on a number of real world projects to help manage dependencies across classes, packages, and the binary units of deployment.

Traditionally, we attempt to make the right architectural decisions early due to the significant anticipated cost affiliated with making incorrect decisions. But this contradicts agile practices which have taught us to embrace change. So how do agile and architecture come together? Conceptually, the goal of agile architecture must be to eliminate the architectural significance of change by crafting software that can easily adapt to change. In practice, developing agile architecture is much more difficult.

Software architecture is organic. The architectural goals you set to achieve early in the development effort differ from those you'll need to satisfy later. Change occurring throughout the software development lifecycle impacts architecture. The ability to accommodate shifts in architecture is directly related to the dependencies between software modules. In this session, we examine patterns and principles that lead to agile architecture. Extensive discussion is devoted to modularizing units of deployment, and how code can be created and organized to create more flexible, reusable, maintainable, extensible, and testable software components. Topics of discussion range from coupling between classes to the dependency structure between your modules of deployment. Examples gleaned from real world J2EE development effort will be used in a pragmatic case study that examines the evolution of a system from its initial deployment through a number of refactorings that positively influenced the architectural resiliency of the final product.allow you to apply many of these concepts immediately.