The SOA principles from a strategic vision

by

With this post we are going to start a series of posts where we will comment on the SOA principles, trying to break them down from the strategic point of view, providing our experience. In short, sharing our point of view.

 

Unfortunately, there is no single international body that leads the specifications of SOA, its fundamentals, principles, etc. In fact, if you search “SOA principles” in the internet, you will find about six million entries. So, as with the definition of SOA, we have to choose.

 

SOA Design Principles must always be present in an SOA strategy

 

 

The site that I recommend is in the corresponding section of this blog. In this series we will cover the SOA principles proposed by Thomas Erl and his work group, and we will work on them.

 

But before, I will contribute my bit to the list of SOA principles, and I will take this introductory entry to the series to raise an idea that I often use as “initial” or “fundamental” SOA principle. Its statement is often effective in helping to shift focus to professionals accustomed to traditional methods of integration, so far removed from the SOA strategy.

 

This SOA principle can be stated as follows:

 

No Information System integrates with other systems, but only with the Organization, through its SOA Services Catalog

 

For those of us who are accustomed to service orientation, this principle is quite evident, but in forums where there is little or no SOA experience, accustomed to traditional systems integration approaches, this principle says a lot.

 

Regarding the classic requirement “system A integrates with system B”, this SOA principle says that:

  • System A does not have to talk to another provider, the system B, to exchange information about the format of the data or the message to be exchanged.
  • Instead, it has to do what the organization determines in its interoperability rules and in its Services Catalog, in short, what determines the Governance office.
  • On the technology side, which is usually the closest to traditional approaches, its communication point for sending and receiving messaging is the organization’s ESB, not system B.

 

In fact, the very statement of the requirement is already incorrect: under this principle it makes no sense to speak of “system A integrates with system B”. The correct statement should be “system A needs to use (consume) these services”, or “system B must provide these services”.

 

The point here is: who provides the services that A consumes, or who consumes the services provided by B, is completely irrelevant to both of them.

 

What really matters is the business, the possibility of reusing an existing service and the requirements of performance, traffic, etc. that it raises in each use case.

Te puede interesar

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Follow me on social media

Share This