Rather than creating a .NET or Java API as they would have in the past, teams now simply create a Web Service API. Unfortunately, since these services are not being created with a broader picture in mind, there is no focus put on schema development or reuse, namespace management, consistency or versioning, WS-I compliance, top-down design or interoperability.
Essentially what these teams are doing is adding more complexity to their system then they would have had if they created a typical interface. Furthermore they are adding latency and reducing the performance of their system while not getting any of the other added benefits of a more managed service oriented approach.
Additionally, because these projects contain all the traditional tiers (Data, Business Logic and Presentation) they are also responsible for consuming the very web service they are creating. Simultaneous development of a service and its consumer is very difficult without a structured and planned approach. There is no single correct way but typically it involves a defined, solidified interface and a dummy implementation. This allows the consumer development to proceed unimpeded by the service development. The service team can then “release” operations individually and do integration testing on a smaller scale allowing the system to gradually take shape rather than going for the "big bang" integration approach.
Many companies are on this path. Those that have no centralized or organized SOA effort are inadequately prepared to change this behavior. Those that do (yes, even companies who have great SOA stories fall victim to this) need to ensure that NO web service gets created without the SOA team's knowledge and influence. If nothing else, the SOA team needs to be aware of the project and either help the project team align their services with the broader vision or prepare (and plan) for a refactoring effort later on.
