|
Software architecture is difficult to define. Ask five different developers their definition of software architecture, and you'll likely get five different answers. Arguably though, we can agree that software architecture represents the significant technical decisions spanning the breadth of the system. For instance, managing the dependencies between modules is a significant aspect of software architecture. Developing application frameworks that promote consistency across use cases is architecturally significant. Identifying application layers and the behavioral granularity of those layers is architecturally significant, as well. As Booch so eloquently states:
Architecture is design, but not all design is architecture. Rather, architecture focuses upon significant decisions, where significant is measured by the impact of changing that decision. For this reason, architectural decisions tend to concentrate upon identifying and controlling the seams in a system, which are described in terms of interfaces and mechanisms and so typically mark the units of change in the system.
Essentially, we differentiate between architecture and design based on the impact of change. How easy is it to modify system modules if dependencies are not carefully managed? How difficult is it to change the dependency structure? How easy is it to reuse software components or services if the behavioral granularity is incorrect? How easy is it to refactor behavioral granularity? 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 siginificance of change by crafting software that can easily adapt to change. In practice, developing agile architecture is much more difficult. There are two simple truths we must be willing to accept.
- First, software architecture is organic. The architectural goals you set to achieve early in the lifecycle differ from those you'll need to satisfy late in the lifecycle. Architecture is the product of many factors, including not only the technical environment, but also the skills of the development team, and the organizational culture. As any of these change, the architecture must shift, as well.
- Second, software architecture is only as good as the source code it's built upon. Shoddy source yields shoddy architecture. Therefore architecture must emphasize building the highest quality and structurally sound source code possible.
So how do agile practices promote agile architecture? To briefly paint a picture of agile architecture, we'll explore a development scenario examining system growth and evolution.
Early in the lifecycle, change is rampant as new features are under development. An architectural vision that guides developers should be established that aligns technology adoption and implementation with business objectives. Developers should stress closure by bundling code into larger modules, avoiding the unpredictability associated with complex implementation issues such as module granularity and transactionality spanning module boundaries. As the system grows, change and discovery occur less frequently. Modules should be broken apart, emphasizing independent deployment and reuse. Smaller, self-contained modules are wired together via interfaces, further decoupling the structural relationships between modules. Throughout the lifecycle, as business objectives change or new objectives discovered, the architectural vision evolves, serving as the guide to implementation. Agile architecture is manifest as modules with minimal dependencies, concise behaviors, and clear points of extensibility. This drives architecture down to the class and code level, making the quality of your source code, and the coupling and cohesion of your classes, a critical factor in the resiliency of your architecture.
Agile practices play a critical role in agile architecture. Test-driven development lends you the courage to undergo architectural evolution. An Automated and Repeatable build process accommodates architectural shifts by ensuring issues encountered through architectural refactoring are identified and corrected quickly. Supplementing your up-front design approach with an emergent strategy emphasizing spikes or proofs helps verify the architectural vision. Developing a robust infrastructure supporting incremental delivery allows your team to experience and identify architectural deficiencies related to performance, failover, usability, and more. Early and frequent discovery of architectural deficiencies provides the team with the time necessary to make architectural adjustments.
Shifts in architecture exists in a world beneath the trendy technologies du jour. It exists in a world separate from your decision to use Hibernate or JDO as the persistence framework. You won't rely on SOA as a revolutionary architectural model. These are important decisions, but with agile architecture, they become less significant. Instead, services are composed of existing system modules. If you fear Hibernate or JDO will not suffice long-term, you'll design an abstraction layer above the persistence mechanism to enable swapping out one for the other. Crafting a robust architecture is not easy, but is at least possible if you allow architecture to evolve, and refactor as architecture must shift. Agile practices enable agile architecture.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Blogs 
