Home Microservices What are Independent Systems Architecture concepts?

What are Independent Systems Architecture concepts?


In this article, we’ll discuss about Independent Systems Architecture’s nine fundamentals.


Should be used for values when they completely have to be adhered to.

It should describe concepts which have many benefits but which do not have to be strictly practiced. We’re going to explore each theory now. The ISA concepts are not only a strong guideline for developing microservices, but they also clarify why macro and micro architectures are so relevant.

Concept 1: The system must be divided into modules(Independent Systems Architecture)

The system must be separated into modules providing interfaces. Accessing modules can only be achieved through these interfaces. Modules may also not rely explicitly on the specifics of the implementation of another application, such as the data model in the database.

The first ISA principle states that the system must be based on modules. Well, that’s common knowledge.

The system must be divided into modules

Concept 2: Two separate levels of architectural decisions(Independent Systems Architecture)

The structure must have two distinct levels of design decisions:

  • Macro architecture requires decisions concerning all components. All other concepts are part of the micro-architecture.
  • Microarchitecture requires choices that can be taken differently for each particular module.

The second concept distinguishes two architectural levels: macro and micro architecture.

Concept 3: Modules must be separate processes/containers/VMs(Independent Systems Architecture)

Modules must be independent processes, containers or virtual machines to optimize their independence.

In the implementation monolith, most choices will be on the macro architecture basis. For example, a deployment would be written in one programming language, so the programming language would be a choice on the macro architecture level. The same refers to systems and most other innovations.

In order to make further choices on the level of micro-architecture, each module must be put in a separate container, as described in this theory. ISA insists that the reason why microservices operate in containers is the additional technical freedom that cannot be accomplished in a deployment monolith. Microservices thus bring more flexibility and decoupling to the architecture.

An strategy where each microservice is a WAR and all run together in a single Java application server does not agree with this concept. In fact, the balance on the free option between technologies and robustness is so high that this strategy does not typically make a lot of sense.
Since decoupling is so necessary, ISA and microservices are already making profound changes to modularization.

Concept 4 : Standardized integration & communication(Independent Systems Architecture)

The range of integration and communication choices for the device must be minimal and standardized.

  • Integration may be achieved for synchronous or asynchronous communication, and/or on the stage of the UI.
  • Communication must use a small range of protocols such as RESTful HTTP or texting. It could make sense to use only one protocol for each integration option.

While the aim of ISA is to build a minimal macro architecture, some decisions do need to be taken at the macro stage. That’s what the rest of the values clarify. Principle four specifies, at the outset, that integration and correspondence must be structured.

Concept 5 : Standardized metadata

Metadata, for example, must be standardized for authentication. Otherwise, the user will have to log in to each microservice separately.

  • This could be accomplished by transferring a token with each call/request.
  • A trace ID may be used to monitor a call and its related calls via microservices, for example.

According to this concept, metadata for tracing and authentication must be standardized. Such metadata must be transferred between microservices and, as a result, must be used in the macro architecture. This course does not include the security features of microservices, such as authentication metadata.

Concept 6 : Independent continuous delivery pipelines

Each module must have its own continuous delivery pipeline. Since tests are part of the continuous delivery pipeline, the module tests must also be autonomous.

This theory builds on the premise of independent deployment as a microservices description.

Concept 7: Operations should be standardized

Standardization of operations is needed. If a module has very clear specifications, there may be exceptions to the specification. These activities include:

  • configuration
  • deployment
  • log analysis
  • tracing
  • monitoring
  • alarms

Concept 8 : Standardized interface

On the interface level, requirements for processes, integration, and communication should be implemented.

  • For example, the communication protocol and data structures could be standardized to a specific JSON payload format exchanged using HTTP, but every module should be free to use a different REST library/implementation.

Concept 9 : Modules have to be resilient

Modules have to be resilient. This means that:

  • They may not fail when other modules are unavailable or when communication problems occur.
  • They must be able to shut down without losing data or state.
  • It must be possible to move them to other environments (server, networks, configurations, and so on) without the module failing.



Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Exit mobile version