| layout | title | description |
|---|---|---|
default |
ISA: Independent Systems Architecture - Non Principles |
Independent Systems Architecture (ISA) leaves some principles out - why? |
ISA (Independent Systems Architecture) is a collection of best practices. However, it does not define the complete architecture. This page explains additional principles that are not part of ISA and why they were left out.
-
ISA defines the technical aspects of modules. How the system is split into modules is beyond the scope of this website. Domain-driven Design and Bounded Context are good guidelines. But sometimes technical modules are needed and separation for reasons like scalability might also be important. Getting the right split into modules is hard and therefore cannot easily be put in a few principles.
-
This architecture can have a huge organizational and culture impact. The approach allows for better separated modules which allow for independent, self-organized teams. Conway's Law states that software architecture reflects the social boundaries in the team so there is strong relation between the organization and the architecture. However, ISA works without adjusting the organization so the idea is more broadly applicable in this way.
-
ISA does not give a preference for communication protocols or operations technologies. It states general principles, not concrete technological decisions.
-
Following the principles provides benefits like independent scalability, load balancing and high availability. However, these benefits are results of following the principles and not principles by themselves. So they are not explicitly mentioned.
-
The principles present problems like inconsistent data. These are fundamental challenges of distributed systems and need to be dealt with. This is beyond the definition of ISA.