Technoplasticity refers to the ease or difficulty of changes to software systems.
Whether it’s something as simple as changing the behavior of a feature or as complex as redesigning the data storage for a business object, we’ve all run up against situations where the consternation of peeling away at layers of code (usually someone else’s, but our own as well), even when well documented, fills us with dread.
With this pain in mind, we can choose to design systems not only for cost and performance efficiency, but for mutability.
Taken to the extreme, in a microservice environment where individual business components are loosely coupled, there is no reason why independent containerized subsystems can’t chain together seamlessly to fulfill feature requirements with multiple subsystem designs, data stores, and even languages and frameworks.
Not limited to microservice based systems.
Let’s postulate that we can take proactive steps to increase plasticity for federated, and even monolithic, system design. And this philosophy should apply equally in any software system where rapid iteration is a key differentiator.
Microservices
Given the level of loose coupling required for this approach, it should be inherently straighforward to mutate individual features without affecting the whole.
Monoliths
Using a thin proxy / balancer, one can direct traffic based on request patterns to different subsystems. With this approach, you can progressively replace feature implementation from an old design to a new one.
Federations
Using a combination of the microservice and federated approach, a team could divy up the work first along the federated system lines, then within each system down to the feature.