Release It! - 18.3 Adaptable Enterprise Architecture

Architectures that are inspired by biology and ecology might be less efficient but very robust. The most useful criterion for evaluating architectures is this: “Does it make IT better at responding to its users’ needs?” Most enterprise architectures are not constructed with this goal in mind. Rather, they are constructed with the needs of the IT group in mind.

Dependencies Within a System
Systems should exhibit loose clustering. In a loose cluster, the loss of an individual is no more significant to the larger entity than the loss of a single tree in a forest. The members of a loose cluster can be brought up or down independently of each other. There should be no time-ordering requirements for the activation of the members of the cluster. The members of one cluster or tier should have no specific dependencies—or knowledge of—the individual members of another tier. The dependencies should be on a virtual IP address or service name that represents the cluster as a whole. Direct member-to-member dependencies create hard linkages that prevent the endpoints from changing independently. The members of a cluster should never need to know the identities of every other member in the cluster. Broadcast notifications, such as cache invalidation messages, should go through a publish/subscribe topic or command queue.

Dependencies Between Systems: Protocols
No matter the protocol, both ends of the interface must both speak and understand the same language. Sooner or later, the language will inevitably need to change. Using protocol versioning can help.  For a time, a system can speak multiple versions of the protocol in order to give collaborating systems time to migrate to the newer version.  Use your Test Harness to ensure multi-version compatibility.  Placing version information in file formats is also a good idea.    

Dependencies Between Systems: Databases
Do not use databases just for integrating between systems.  Use a higher level abstraction, such as a web service, instead.  Using a db for integration violates encapsulation and is too highly coupled.  Most use cases do not require up-to-the-second accurate data so using an hour-old snapshot might be ok.  Use ETL tools to pull data out of production so that reports can be done without impacting production.