The majority of architects agree on the contract first approach. But who is actually responsible for the contract definition and who owns it? Is it the developer, the architect or the business analyst? Being responsible for the contract implies understanding the contract. Given the fact that service boundaries are defined by Web Services technologies, the contract consists at least of some data types and messages defined as XSDs and some port types and bindings, both being described using WSDL. By looking at these technologies, it’s most likely that developers will have the required skills to define such contracts. But are they involved in the bigger picture of an organization? Since this is part of the architect’s responsibility, usually not. If the architect would define the contract, he would be capable of making sure that service contracts are consistent across the organization. But to do so, he has to understand the implications of certain technical decisions, such as message encoding or versioning. On the other hand he had to know the business in order to define useful contracts. Again, this is usually not the case. What about the business analyst? He definitely understands the problem domain but does he understand the technology model? How can we solve this paradox situation? The following is a possible solution to it:
The goal should be to describe this mapping with metadata. Once the technology constraints and their mappings are defined, the business analyst is capable of defining its contracts without any further help from the developer or the architect. My proposed answer to the initial question “Who is responsible for a service contract?” is the following:
Yet, the developer, the architect and the business analyst have to define the contract. But the goal should be to move the ownership to the business analyst. Then, Developers and architects are responsible for defining policies and technology mappings only.