Dimensions of change, architecture and micro services
Software development and change are interconnected by default. In the past systems and software were expected to be designed and implemented once and used and maintained afterwards for the foreseeable future. For that reason solutions were architected in a way that should make them resilient to change. But every few years a redesign was still nessecary and we started to design and build a new system that did not have the limitations the current system has. When designing the original system, we though of a lot ways in which change might happen, but we obviously did not think of the change that made it nessecary to rebuild the system. You might think of that in terms of dimensions of change. E.g. process, scalability, protocol independence etc. In some dimensions the system is very resiliant to change in other dimension it is not.
The first question is of course: Is it possible to foresee in what dimension change is happening in only a few years? The short answer to that is: Apparantly not. The second question is: Is it really nessecary to cater for all dimensions of change when architecting a system, couldn’t we just redesign and build the system as soon as a new requirement is coming up? Not taking change into account when designing a system certainly would bring down the initial costs and time to market. On the otherhand reuse of parts for which the requirements have not changed would also make a good business case when maintaining the system. The architectural answer to the challenges is of course componentization. Componentization is the process of atomizing (breaking down) resources into separate reusable packages that can be easily recombined. Resiliance to change arises from the possibility to recombine existing and new components to a new solution. New components are easy to design because the do not have to take future change into account.
An modern implementation of this mechanism is (micro) services. The key here is to have a close relationship between services and business process steps. Ideally for each process step there is a separate service. Let’s leave the discussion what granularity to use here (in other words, how big is a process step) out of the discussion for now. The catch in this approach is how services communicate in terms of data being exchanged. Ideally we would like all services to use the same data model or at least use a data model that can be mapped to a common canonical data model. But what if that canonical data model changes? After all, changes in the canonical data model are just another dimension of change. We usually counter that by assuming that if the data model changes and we can not map the data model of a service to the canonical data model any more, we have to redesign that service.