By business coupling we might also refer to things like the commercial contracts.
So, we might provide a Techically loosely coupled Web Service, but the only people who can actually use it are our tightly coupled business partners... on whom there are business service contract dependencies (e.g. all orders for in-stock items must be fulfilled in 24 hours, customer must pay in advance, customer must agreed contract), which are not technology contract dependencies (though may be validated by operations in the technology service) So, the service is not reusable just because it is a web service, but can only be reused by service consumers able to satisfy the business contract. Also, we should consider that reuse isn't always the goal. More often the goal is replacement. That is, that loose coupling allows the implementation to be replaced without impacting the service consumer - regardless of whether it is being 'reused' by multiple service consumers. Hence, designing services for reuse should also be seen as enabling them to be replaced. (and vice versa) Lawrence --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > Thus, when we decompose business model > following "business wants tight business coupling at the top", we end > up with relatively tight coupled business autonomous services. I said > 'relatively' because there may be a degree of decoupling but business reuse > based on this decoupling is not that gigantic as early-day SOA promised, > correct?
