Tensile Strength
Software Architecture lessons from Materials Engineering
A long time ago, before I dove into software development, I was a Materials Engineering student at the University of Toronto. Having gloriously arrived on a scholarship out of high school, I was unceremoniously kicked out 18 months or so later for ridiculously bad performance (I think my average was below 40). Nonetheless, while occasionally showing up for class, I learned a few things from one of the few professors who knew how to teach. Almost 20 years later, I draw value from those lessons when thinking about software architecture.
Purposeful Diversity
Iron is transformed into steel by adding new elements. This seemingly contrarian step adds strength by reducing purity. Steel Engineers are careful in choosing the right combination of complementary elements to craft a material far greater than its parts.
At large organization we often find a focus on a single language and its related infrastructure. Most web applications run in a same type of environment, with the same type of technology stack — from programming language, operating system, web server, database, and firewall.
The short term gain is that companies can leverage economies of scale and build highly expert teams. The disadvantage is that change is hard to introduce into the organization.
As Nassim Nicholas Taleb quibs, fragile systems will fail. These software monoculture look strong like trees, but will be felled by a sufficiently strong storm. As such they are conceptually fragile. As Nassim Nicholas Taleb quibs, fragile systems will fail. Grass and coakaroaches on the other hand are anti-fragile.
Similarly building an enterprise strategy to support a variety of software stacks and technologies — not just vendor based, but open source stacks as well — forces corporations to be nimble. Change and adjusting become the norm. Digital Transformation becomes just another day at work.
Alignment without coupling
Single crystal elements (diamonds) are generally stronger than multi-grained elements (steel). But, steel bends under stress, while diamonds will eventually shatter. In that sense, diamonds, that seem stronger, are actually fragile.
But the best elements are engineered for narrow grain boundaries. These are elements where the grains are strongly aligned, but the gain boundary decouples them from each other. These boundaries act as stress sinks, absorbing shock energy, preventing shattering even under extreme conditions.
RESTful services are a good example of alignment without coupling, while JMS or RPC type solutions extend that alignment to coupling. Services bound using the http protocols with service contracts advocate alignment in the sense that teams are able to transparently use other team’s efforts to complete their own tasks. But they should not extend to coupling that requires both teams to develop in the same language, or require the same operating system.
Both of these concepts are exemplified by Microservices. Share nothing microservices are an edge case but the idea of building independent services is a philosophy that embraces loose coupling, close alignment, and technological diversity. But this service oriented architecture needs to extend beyond individually developed services and needs to integrate into an API strategy that turns every application into an interface.
