It’s time for the fifth SOA principle: service autonomy.
Broadly speaking, this principle states that a service can not contain logic that depends on anything external to the service itself, be it a data model, an information system, or anything else.
The need for this autonomy is largely imposed by reuse. We can not expect a service to be reusable if its logic is coupled in some way to some other artifact external to the service.
As you can see, two principles that we have seen in this series have already appeared: reusability and loose coupling.
But it is also related to the use of standards (first SOA principle). It is this use of standards that provides autonomy to services. The alternative to standards is to use proprietary, tailor-made definitions, and that would depend entirely on a particular implementation, and therefore would greatly hamper that service for future uses.
This SOA principle is surely one of the most elusive, the most difficult to guarantee. It requires a major governance effort, as there are many ways to introduce alleged improvements, evolutive, even corrective assumptions in services, which are actually degrading their autonomy, and therefore the quality of service.
We refer to situations in which, for example, the event provider system requests a service change for a change in its logic, or in its data model … sometimes they present that need as a “business need”, in an attempt to convince the organization of its SOA orientation.
These cases require an important solidity in remaining faithful to the business, only to the business, and not to the technological or functional considerations of any system. Let us not forget that this system provides this service only in a circumstantial way, for that implementation. But that same service may be needed in other scenarios (may be and should be), and will be used by other systems.
Autonomy is fundamental to achieve this level of reuse.
The limits of service autonomy.
Another reflection that we think interesting about the principle of autonomy, refers to its limits. The limits of autonomy are related to the limits of the service, when these are also the limits of the organization.
In situations where a service is triggered from an external organization, it is legitimate (and inevitable) to adapt our interface to that determined by the organization that provides the event.
In these “frontier” situations we have no choice but to ensure that our service meets what the organization to which it belongs states. Hopefully, governance can make that organization align with some of our guidelines, standards, etc. But in general it will depend on each case, and on the hierarchical relationship between the two agencies (for example, two ministries, two regional governments, a ministry and regional counseling, etc.).
Finally, do not forget that services must be able to work together to form composite services (one of the principles still remaining). Without the principle of autonomy, we could not compose services of a greater order, since we would inherit the dependencies of any of the services that we use in the composition.
Without this principle, in fact, we can not even guarantee the operation of our service. I can not think of anything more basic than that.