Over-Generalized Interfaces
Another interesting trap is over-generalized interfaces. This trap has two popular incarnations: CRUD (Create-Read-Update-Delete) and vertical industry standards.

CRUD Web services describe generic operations over objects instead of specific business operations. CRUD interfaces are born out of the good intention to provide a single unified interface to all clients. CRUD operations also make it possible to generate a large part of the implementation skeleton using code generation tools.

To illustrate problems of CRUD interfaces, let's consider the case of a bank account. There could be operations to set account properties in a particular balance. A property might be updated only by an authorized request sender. While the CRUD approach looks very generic, it is difficult for implementation, use, and more importantly, security:

• On one hand, it is difficult to implement such a service. Security requirements are usually expressed for high-level operations. For example, some clients are permitted to deposit money, some to check an account, and others to withdraw. To check if a client is authorized to perform a low-level operation or update business data, the service has to guess what a high-level business action is and which is actually intended to be performed. Because authorization decisions are done inside methods, it is difficult to understand security policy without examining the operations implementation.
• On the other hand, the service is inconvenient for use by clients. They need to formulate high-level business operations in terms of low-level business data update operations. This also increases functional coupling between client and server, because the client has to know how the business operations affect business data. If the data schema is radically re-factored, it will be very difficult to write a proxy for the old interface. It is likely that all clients will have to be updated.

Of course, sometimes CRUD interfaces are adequate. For example, they could be used for communication between JavaScript code executed on a client and server side logic. Here, tight coupling between these two parts of the solution is rather natural. However, using CRUD interfaces for Web services is often the wrong idea.

Vertical Industry Standards
A less radical variant of the previous trap is the use of a standard XML schema for business domain messages. Pertinent examples of specifications here are OASIS Universal Business Language and ACORD P&C. It may seem that such standards reduce coupling between systems, but actually, their effect on this aspect is not considerable or absent at all.

Often these standards declare a quite generic and flexible XML language that is able to accommodate different business requirements. However, the target service is usually able to understand only a subset of this rich language. Some constructs are valid for such a language and can be rejected by a Web service because they contain unsupported fields or miss required fields. UBL developers have noticed the problem and offered a partial solution in the form of customization guidelines.

If the schemata are used as is, implementation of both clients and servers is more complex. Servers are required to perform extra validation checks. Developers of clients are forced to check each step with additional guidelines to ensure that requests will be valid, instead of just relying on the respective API.

Although vertical industry standards can decrease documentation and interface development efforts, they often do little to reduce coupling of systems. Moreover, naive implementation of these standards can conceal existing coupling problems instead of solving them.

Fine-Grained Interfaces
There is a lure to make a system too fine-grained, i.e., more fine-grained than actual business operations. The primary motivation for this anti-pattern is to increase the flexibility of the system and to reduce the volume of the traffic. The system allows different invocation sequences, depending on what is required by clients, so that a client's costs are proportional to his needs.

This is a well-known bad practice that was understood as anti-pattern even during CORBA days. A typical example is expressing a high-level update operation as a sequence of property update operations. However, it still periodically surfaces because it falls into the exposing the application "as is" trap. The problem becomes a latency and perrequest cost of network operations that consume more resources than local operations.

When a business function is split into too-small pieces, the coupling also becomes higher because the business operation becomes implemented by client applications rather than by the server logic. This also leads to security problems similar to ones already discussed above in over-generalized interfaces.

Coarse-Grained Interfaces
There is an opposite lure to make a system too coarse-grained, when several different business functions are associated, because they are implemented by one system.

ACORD P&C 1.x.x specification is an example of a specification in the domain of insurance. A single request can contain a number of business requests that create and update different business objects (claims, polices, etc). It is also possible to check the status of previous requests and pull results of completed operations. This is done to reduce the amount of interactions between clients and servers. Such an approach results in complex logic for request processing, and this complexity is caused not by the business domain of the specification, but by technical decisions to create a coarse-grained interface on the system and specify processing models for requests. As the result, the technical coupling in the system is increased since both clients and servers have to support the specified processing models.

Conclusion
RFC1925 says: "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away" (http://ietf.org/rfc/rfc1925.txt). Humans naturally strive for perfection. However, in the rush of adding new application functionality and integrating existing applications, this desire often stays unrealized. And to reach perfection, it is required that managers, analysts, domain experts, and system architects closely and confidingly work together because each of these roles deals with only a piece of the whole puzzle.

Management is aware about the mission and the structure of their organization. Knowing needs, goals, and rules is the essential part of any change within an enterprise. Analysts and domain experts can elaborate these goals and rules to software requirements. Architects know how to bring these requirements to the life.

Coupling is an interesting and complex problem, which is created by decisions on many different levels. High coupling on the level of real business processes is often caused by management decisions. High functional coupling is often caused by the way requirements are distributed among applications, and it is mostly the responsibility of analysts and domain experts. High technological coupling is often caused by decisions made by architects.

While sometimes it is possible to partially compensate a problem of one level on other levels, it is still better to solve it on the level that it belongs to. RFC 1925 also says: "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead."

There are tools and methodologies that help to reduce coupling on each level. However human intelligence and creativity are still the best and indispensable tools.