Adaptability

Here I am at the end of Michael Nygard’s jolt cola award winning book Release It! The final chapter is about adaptability and sums up the core underlying lessons taught in the book. As it turns out much of what Nygard espouses in his system designs and processes turns out to be a mirror of the types of software practices that I have come to adopt. Adaptability in systems includes dependency injection, always being ready to release, and extensibility to name a few. These overarching agile principles should be used throughout an entire system. Nygard also provides specific suggestions for maintaining an adaptable enterprise architecture which I would like to enumerate here.

Systems should be built in a loose cluster so that losing any piece of a system has very few repercussions. The members of a cluster should never need to know about the identities of other members in the cluster. This also goes for dependencies between systems and the cure for this is to add an interface. In the system world this interface will most likely end up being a protocol. The protocol (interface) should then be designed so that neither side cares if the other side of the protocol changes. Another dependency between systems could be the database. Keeping an emphasis on encapsulation and information hiding is the key here. He suggests “taking it up a level, wrapping a web service around the database then making the web service redundant and accessed through a virtual IP.”

Releases should follow the same agile principles used to implement the smaller parts of a system. Most importantly a release should be a painless exercise. A system should be able to be released trivially and quickly at any time. A release should be inexpensive while causing no downtime as the expansion of a system should ideally be able to coexist with the previous version of a system. This is accomplished by breaking deployment into phases.

Nygard introduces three phases in a release: Expansion, Rollout, and Cleanup (Figure 51).

Expansion is the addition of new stuff, rollout is the code being unpacked onto servers, and cleanup is removing any bridge between the previous two steps. Expansion conflicts can arise from URL-based resources, protocols, or more commonly, databases. URL-based resources should have a new URL with each expansion while protocols should have version identifiers to handle expansion. Schema changes should be met with hesitation and be carefully considered but this is where ORM tools come in handy. Rollout should be trivial if the expansion is dealt with properly. This means rollout can happen anytime and with zero cost. Cleanup also falls in line given that you take care of the previous two steps in an adaptable manner.

Software should be soft, malleable, and adaptable. The same goes for system design and architecture. Keeping things flexible and easily changeable with a tight feedback loop makes the design and architecture process much smoother. By making systems adaptable we gain the same benefits we get from making our components more adaptable.