Standardized Service Contracts
The first thing I would like to point out from this principle is the term Contract.
Do not make the mistake of thinking about the WSDL of web services. These contracts are located at the technological level. The SOA Service Contract is a design document, and collects all business and functional information that delimits its scope and use cases, the structure of the message it uses, the detail of the information that must travel in each node of the message , Its sequence diagram, which illustrates the typical communication pattern for that service (synchrony, asynchrony, sequence of events / messages, etc.), the functional errors that may occur, and as many references as necessary to the design rules established by the Governance Office.
The second thing we are going to comment on is just the latter: the design rules.
Service Contracts should not include any design rule. Notice that we have said that the Service Contract must include “as many references as necessary to the design rules”, but not the rules themselves.
All these rules and policies should be set out in a single separate document, which as a white paper constitutes the single binding reference of compulsory use by each and every one of the actors involved in interoperability projects. Often this rules set is known as the Normative Catalog.
The Governance Office is the one who must maintain these norms and who must watch over their compliance. But not only in the Service Contracts, as this SOA principle indicates, but also must ensure their compliance by the teams responsible for the systems that provide and / or consume the service subject of the Contract. This is the hard part.
The third important term to highlight in this principle is the standard.
As we have said in previous entries in this blog, the use of standards guarantees the interoperability and reusability of services. But the use of standards must be a correct use, which implies precision. Ambiguity is one of the enemies of the definition of Service Contracts, and is a very slippery enemy.
That said, what this principle comes to emphasize is that, in the same Services Catalog, all services (their Design Contracts) must comply with the same policies and design rules marked by the SOA Governance Office. The use of standards and compliance with established policies makes the governance of the Catalogue possible, this is evident. Just think that the absence of common standards and norms is one of the main causes of the spaghetti architectures that abound in companies and public bodies, where the control and coordination of integration systems maps involve practically impossible tasks .
As a conclusion, this first SOA principle is aimed directly at allowing Governance, which as we have said here several times, is the fundamental engine of the SOA strategy.
What do you think?