Pragmatic Architecture

Pragmatic architecture

Two divergent sets of activities both fall under the term architecture. One type of architecture strives toward higher levels of abstraction that are more portable across platforms and less connected to the messy details of hardware, networks, electrons, and photons. The extreme form of this approach results in the ivory tower.

Ivory tower architecture

A Kubrick-esque clean room inhabited by aloof gurus and decorated with boxes and arrows on every wall – decrees emerge from the ivory tower and descend upon the toiling coders:

• “The middleware shall be JBoss, now and forever!”
• “All UIs shall be constructed with Angular 1.0!”
• “All that is, all that was, and all that shall ever live in Oracle!”
• “Thou shalt not engage in Ruby!”

If you’ve ever gritted your teeth while coding something according to the company standards that would be ten times easier with some other technology, then you’ve been the victim of an ivory-tower architect.

Most probably an architect who doesn’t bother to listen to the coders on the team doesn’t bother listening to the users either. You’ve seen the result: users who cheer when the system crashes because at least then they can stop using it for a while. In contrast, another breed of architect doesn’t just rub shoulders with the coders but is one. This kind of architect does not hesitate to peel back the lid on an abstraction or to jettison one if it doesn’t fit.

This pragmatic architect is more likely to discuss issues such as:

• Memory usage
• CPU requirements
• Bandwidth needs
• Benefits and drawbacks of hyperthreading and CPU binding

Ivory vs. pragmatic architecture

The ivory-tower architect mostly enjoys an end-state vision of ringing crystal perfection, but the pragmatic architect constantly thinks about the dynamics of change.

• “How can we do a deployment without rebooting the world?”
• “What metrics do we need to collect, and how will we analyze them?”
• “What part of the system needs improvement the most?”

Contrast that to the pragmatic architect’s creation, in which each component is good enough for the current stresses and the architect knows which ones need to be replaced depending on how the stress factors change over time.