Kirk Knoernschild

By Kirk Knoernschild

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.

By Kirk Knoernschild

Agile processes such as XP and RUP advocate continuous integration, where shorter iterations produce an incremental and functional growth of the system. The fundamental component of any Continuous Integration strategy is an automated and repeatable build. In addition to ensuring your application is always in a functional state, a robust build strategy enables a number of other important lifecycle activities.

This session explores the important characteristics of Continuous Integration, including the development of an automated and repeatable build, and numerous other utilities that enrich the build process. We will also explore the important long term of Continuous Integration by examining it's use on a real world project. Multiple examples using CruiseControl, Ant, and other third party utilities will be shown, and tales from a project experienced in CI will be shared.

By Kirk Knoernschild

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.

By Kirk Knoernschild

Design Patterns are proven and powerful techniques that can help improve the resiliency, maintainability, and extensibility of your applications. However, overusing or misapplying patterns is a common mistake often times resulting in applications that are over-architected, and resemble a tangled web of classes. How can patterns be applied to achieve the goal of better software?

This session offers a gentle introduction to design patterns by examining a small, yet very usable framework designed using 7 common GOF patterns. We?ll examine the framework, and explore how each pattern is used as well as how each pattern emerged based on real, instead of perceived need. Less flexible alternatives to the chosen patterns will also be discussed. To conclude, we?ll examine how the patterns are applied in conjunction with each other, forming more complex compound patterns. Each pattern will be presented with accompanying source code, and all examples are gleaned from real world scenarios.

By Kirk Knoernschild

Agile processes promise to speed software delivery and increase software quality while embracing change throughout the development lifecycle. Yet transitioning from traditional software methods to a new way of working can be difficult, painful, and risky. While the team is consumed with understanding and improving their new approach, they also face the pressure of looming project deadlines. Overwhelmed teams feel forced to compromise, believing they can deliver the solution more quickly by reverting to traditional methods. Unfortunately, this is not the case.

In lieu of adopting an Agile software development process, such as Scrum, XP, or Crystal, this session presents practices that developers can inject into their existing software development efforts to increase agility. The practices discussed take a very narrow view. All activities performed and artifacts created must emphasize the creation, growth, and verification of the source code, from initial project inception through final solution delivery. If teams are able to develop a codebase that is malleable, fully tested, and frequently deployed, they possess the inherent ability to measure, adapt, and deliver. To realize the greatest benefit from these practices, we will also discuss how these practices must adapt based on the constraints, attitude, and culture of your social and technology environment.

By Kirk Knoernschild

A fad in the 90's, the promise of Component Based Development was never fully realized. A decade later, however, the dynamic module system for Java, codenamed OSGi, is exciting the development community by redefining delivery of component based systems developed in Java.

Initially focused on embedded systems and networked devices, OSGi technology is gaining significant momentum within the enterprise. In this introductory session, we'll provide insight to OSGi technology for enterprise software development, and compare and contrast work done by the OSGi Alliance and the Java Community Process. Additionally, this session will introduce two OSGi implementations ? Apache Felix and Server-Side Equinox, briefly explore Spring-OSGi, and discuss major vendor support for OSGi. To conclude, we will provide insight to how OSGi blends with the world of SOA and Web Services. Through numerous examples, we will discuss how OSGi technology stands to change the landscape of how Java business applications are architected, designed, and delivered.