Following the architectural change of the IT system, we easily discover some similarities to the second law of thermodynamics. Following Wikipedia: “Entropy is central to the second law of thermodynamics, “which states that the entropy of an isolated system left to spontaneous evolution cannot decrease with time.”
The same can be applied to IT systems.
The IT system starts with the “big bang” when the system is created and the architecture is uniform and coherent.
Typically the newly created IT system is designed following the current technology stack and construction patterns, so the architectural homogeneity of the system is achieved in every possible domain of the 6+ architectural dimensions (the number depends upon methodology).
The entropy meant as the architectural disorder is almost zero 😊
During the operational phase of the IT system, it changes because:
- The internal non-business drivers apply, i.e cybersecurity considerations force the legacy technologies to be replaced,
- The internal business requirements of the organization grow/change, which changes the system functions (the changes or enhancements may be implemented using the current – not the original technologies and products)
- External – environmental requirements apply i.e. interoperability, law regulations, SaaS opportunities/requirements, etc.
Typically a change in an IT system must be implemented quickly (for numerous objective reasons) and economically. This causes multiple architecture pattern violations/exceptions to occur, which have to be described and managed by the architecture team.
It is theoretically possible to defer i.e. a business-related project because of architectural requirements, i.e. the need to establish new architecture patterns or adopt new modern technology into the operational technology stack. I haven’t experienced such a case. The business, security, or environmental requirements have priority over architectural order.
Over time, the IT system architecture changes from homogenous to heterogenous and incoherent, with every possible technology and pattern involved. The role of the architecture team is changing from “rule executors” to “information managers” (sounds better than “librarians”), keeping up to date every architectural exception on what, why, when, and how (I do love Zachmann).
The entropy of the system grows 😊
One might imagine, that the powerful architecture team following i.e. the TOGAF scenario, might be able to stop the architectural erosion of the managed IT system. I would rather claim, that the architectural entropy is something inevitable over time, and the architecture team, is responsible for slowing down the erosion process and documenting the current state.
The result of growing entropy is the rising cost of development and operation (multiple technologies, heterogeneous data architecture, multiple interfaces, and interface types). The time-to-market grows as well.
Because the system had lost its natural homogeneity in time in a linear way (look at my first post 😊), and the timeframe was large enough (a few or several years), the reflection of the architectural state of the IT system comes relatively late. A good architecture documentation would help, but who can keep it up to date?
When IT cost rise or TTM delay is visible there is a decision to change.
The possible option would be to migrate, to replace the old and expensive system with the new one, which is hopefully homogenous again.
After migration, the entropy of the new system is almost zero, so the story starts again.
A harder case is a need for architectural change on a system, that is too big to be migrated. Such a “change-in-place” attempt is a subject for another post maybe.
Anyway, the IT system architecture does not differ from other systems, it starts with almost zero entropy which grows over time. The entropy increase can be throttled by a powerful architecture team, but the rise is inevitable.
When the entropy is high enough and related entropy management costs are significant, or the TTM is not acceptable anymore, the IT system is concerned about changing. This is the difference to natural systems because it is possible to reduce the entropy level of the system, but it needs extra effort (extra energy).
OK, nice story, but what does it mean for the future? – this is coming in my next post.