Loading ...
Sorry, an error occurred while loading the content.

Re: [service-orientated-architecture] [ZapFlash] The Seven Levels of Loose Coupling

Expand Messages
  • Nick Gall
    A few observations: 1. In deciding where to apply loose coupling and what aspects to apply it to, keep the following rule of thumb in mind: Since the goal of
    Message 1 of 6 , Dec 3, 2007
    • 0 Attachment
      A few observations:
      1. In deciding where to apply loose coupling and what aspects to apply it to, keep the following rule of thumb in mind: Since the goal of loose coupling is to enable independent change among interacting systems, only loosen couplings between aspects of interacting systems that are likely to change independently, ie at different rates from one another. Systems that are highly likely to always change together do not need to be loosely coupled.
      2. The list below is definitely a list of "aspects" (as Ron mentions) NOT "levels", because they are largely independent of one another, eg, you don't have to achieve implementation loose coupling to achieve semantic loose coupling and vice versa. I think it is misleading to think of the aspects below as levels; but it makes for a better headline.
      3. You can NEVER achieve "complete decoupling" of two interacting systems: to interact in any way, there must be SOME dependencies (coupling) between the two systems. If you don't believe me, read Herbert Simon's "Sciences of the Artificial", where he discusses "decomposable systems", and makes the same point.
      4. This list leaves out the most important aspect of loose coupling: ubiquity. If I and only one other partner adopt the world's most dynamically reconfigurable middleware architecture then he and I are tightly bound to one another. Imagine the two of us dreamed up our own custom variation of WS-*; let's call it WS-Silo. Then between the two of us, we could do all sorts of nifty changes on one side to the interface without disrupting the other side; but we can't interoperate with ANYONE else.
      Item (4) is an extreme example of the problem WS-* has run into. Because of the complexity of the specs, vendor deviations from the specs, variations allowed be the specs, etc., only small numbers of participants can successfully interoperate with WS-*. Almost every deployment of WS-* is effectively WS-Silo:inside the Silo all systems are loosely-coupled, but only to a small number of other systems.

      The advantage of HTTP/REST is that, although I lose some implementation loose coupling (since I'm now tied to HTTP) I gain the mature interoperability of HTTP, so I can  interact with anyone on the Internet. This is why you see so little WS-* outside the firewall and so much inside.

      Bottom Line: When in doubt, choose an interoperability architecture that is somewhat more tightly coupled, but vastly more ubiquitous, over a somewhat more loosely coupled interop architecture that is comparatively rare.

      -- Nick

      On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:

       ZapThink

      The Seven Levels of Loose Coupling

      Document ID: ZAPFLASH-20071128 | Document Type: ZapFlash
      By: Ronald Schmelzer
      Posted: Nov. 28, 2007

      When ZapThink talks about Service-Oriented Architecture (SOA), we generally try to avoid semantic arguments about what is and what isn't SOA, but rather try to focus on specific characteristics that identify Service-oriented systems and the benefits they provide organizations that adopt the architectural approach. In particular, we like to focus on three core tenets: loose coupling of Service consumers and providers, composability at a variety of levels of granularity, and event-driven, asynchronous styles of interaction that allow for a wide range of usage scenarios.

      While these characteristics might seem distinct, they are in fact related to each other. The ability to compose arbitrary Services in environments of long-running transactions requires a certain measure of loose coupling. However, architects seem to grapple with the term "loose coupling". Some erroneously think that systems are either loosely coupled or tightly coupled as if the determination of coupling is a binary evaluation. The reality is that the concept of coupling, like that of granularity, is a relative term. Something is more loosely coupled than something else if it allows for a greater degree of variability and freedom for that particular aspect. Simply put, coupling is a measure of dependency and commonality required by a Service consumer and provider to be able to achieve a result.

      In that light, loose coupling is a spectrum. A system can be tightly coupled in one aspect while being loosely coupled in another. Many architects say that they want complete decoupling of systems so that any variation in the system can be handled without having to reimplement any of the Service consumers or providers. As we've discussed in past ZapFlashes, complete decoupling is incredibly difficult and expensive, if not impossible. So, what architects should be aiming for is achieving the right level of loose coupling to facilitate business agility without imposing huge costs.

      As such, what ZapThink has seen is that there are really seven levels, or perhaps aspects, of loose coupling that architects should consider in their SOA initiatives. The more degrees and levels of loose coupling they add to their SOA efforts, the greater those systems can deal with change.

      Loose Coupling the Implementation
      One of the most fundamental promises of SOA is that Service consumers are blind to the implementation technology used by the Service providers, and vice-versa. Indeed, the whole idea of the Service abstraction is that technology implementations are hidden. This most basic of SOA characteristics is realized using standards-based, interoperable specifications or protocols that provide a contract-based interaction between Service consumers and providers. Web Services certainly fits the bill as does REST and other styles of Service implementation. Indeed, it's not the choice of interoperable specification (whether XML based or not) that enables this level of loose coupling, but rather the Service contract. A properly written Service contract will allow Service consumers to bind to a wide range of Service provider implementations without have to know at all whether the Service implementation is done in Java, .NET, PHP, C++, or Basic. All SOA implementations must be at least loosely coupled at the implementation level, but clearly this is not enough to guarantee the sort of complete loose coupling so desired by the business.

      Loose Coupling the Service Contract
      XML, Web Services, REST, and other specifications hide the implementation of the Service such that when the Service implementation changes, the Service consumer does not need to be the wiser about it. However, what happens when the Service contract itself changes? A simple change to acceptable inputs or functional behavior of the system can have profound impact on Service consumers. As such, architects that want to progress their SOA initiatives beyond simply Web Service integration need to address Service contract change management in such a way that contract changes don't cause Service consumer breakage.

      This might seem to be a difficult proposition, but there are plenty of best practices, architectural approaches, and technologies to facilitate this level of loose coupling. First, a proper Service contract that is interface-neutral will alleviate much of the problem of Service contract change management. The Service Description Framework (SDF) shared by ZapThink in our Licensed ZapThink Architect (LZA) boot camps is one of those technology-neutral Service contract templates. In those approaches, new Service contracts don't simply replace old ones. Old contracts are never deprecated unless a transition path is provided for Service consumers. This can be as simple as a transformation or as complex as a Service-oriented process that is triggered when Service consumers request old (and deprecated) versions of the Service contract. As such, contract change must be handled as a matter of policy. Who gets what version of a Service should be controlled via metadata, not programmatically or via configuration of tightly-coupled infrastructure.

      Active management and Service intermediaries further simplify the Service contract change management issue by providing exception management and handling of Service contract differences. And of course, SOA Governance plays a huge role here in helping to manage the sort of change and versioning issues that arise. But probably the best practice in this arena is the use of late-binding approaches that leverage run-time registries and contract-based binding to abstract the binding specifics of Service consumers and keep Service contract changes from propagating. The topic of late binding is itself a deep conversation that requires rethinking the way that Service consumers bind to Service providers, and one too long for this ZapFlash.

      Loose Coupling the Service Policy
      So, putting into play Service contracts that abstract implementations and late-binding, intermediary-enabled, registry-based systems that allow for Service contract change without breakage enables a great degree of variability in the system, but we're still far from done. Indeed, even if the Service contract stays stable, a small change to a Service policy can have tremendous repercussions, as discussed in our Butterfly Effect ZapFlash.

      Companies looking to address Service variability should handle changes to policy the same way they handle changes to Service contract: late-binding, Service intermediary-enabled, registry-based, and governed. A policy is a form of metadata, as are contracts, and in fact, the only difference between a Service policy and a contract is that a policy can apply to any number of Services. Because policies control many aspects of the non-functional parts of a Service, architects need to include in their architectural plans methods and practices for dealing with Service policy versioning and deprecation as well as policy versioning that leverages the technologies and practices established for Service contracts. Companies need to test policies just as they test Service implementations, and manage policies as rigorously as they manage Services. Doing so not only makes the system as a whole more reliable, but enables one more level of loose coupling.

      Loose Coupling the Process
      Of course, loosely coupling the Service consumer from a Service provider only provides agility if the Services aren't composed together. Once you have a business process that composes a bunch of Services together, we have another area of potential tight coupling. What happens when the process changes? Ideally, a Service consumer should not have to know at all when a process is reconfigured. Fortunately, achieving that level of loose coupling is fairly straightforward.

      The movement in the SOA and BPM markets has been towards separating the process definition layer from the underlying implementation. By defining processes in metadata and exposing those processes using Service contracts (the recursive vision of process compose of Service and exposed as Service) abstracts the implementation of the process from the Service consumer. In fact, in such a scenario, a business process is really a form of Service implementation. And just as Service contracts provide loose coupling of Service implementations, they provide loose coupling of Service-oriented processes.

      Loose Coupling the Data Schema
      If we've enabled all the loose coupling levels defined above, companies should be able to make arbitrary changes to their Service implementations, contracts, policies, and processes without breaking a thing (or a sweat). Yet, that's not sufficient to handle the changing needs of the business. What happens when the underlying data schema changes? If a Service consumer and provider need to have a common understanding about that in order to have a conversation, we have tight coupling as defined above. Therefore, organizations need to further their loose coupling goals by enabling dynamic and heterogeneous change to the data schema shared between Service consumers and providers.

      To some, this might seem to be a very complicated task. Computers aren't people, after all, and so they can't process any changes to the format or definition of data. Yet, not all hope is lost here. First, Services aren't really interoperable unless they can understand and process data in common. This means that while there might be semantic dependencies between them (which we will address shortly), there does not need to be structural data dependencies between them. Schemas are key to Service data interoperability. However, what happens when Schemas change? One key approach is to address information and schema management in the same way you approach Service metadata management. Data schema can be treated as a form of metadata and the use of exception management, transformations, Service intermediaries, and Data Services (described in more detail here) are all key to enabling loose coupling of data structure. Implementing a Data Services layer introduces loose coupling in a way that provides a separation of concerns, so that underlying data infrastructure changes are insulated from the business Services above.

      Furthermore, companies need to align the efforts of those maintaining the data schema with those maintaining the Service metadata. Why is it that the folks who maintain the schema are not part of the architectural team? Schema are no different than Service contracts. They represent a form of metadata that encodes business requirements. As such, we frequently admonish companies to bring their data and information architect teams into their enterprise architect fold. The simple act of this alignment and the establishment of metadata-enabled change management will allow for loose coupling of data schema and structure.

      Loose Coupling the Infrastructure
      Before we try to slay the last dragon of loose coupling, it's important to note that all these levels of loose coupling doesn't matter a whit if it all depends on a single vendor's implementation. Too many times we interact with architects who claim that their systems are loosely coupled, but if they move their implementation from one Enterprise Service Bus (ESB) or Service infrastructure to another then all hell will break loose. How can they truly say their implementations are loosely coupled with such a huge dependency in mind? Enterprise architects worth a grain of salt will demand that their Service implementations be infrastructure neutral. That means that at any time, the company can change their infrastructure without having to rebuild all the Service consumers and providers.

      Many vendors promise this sort of interchangeability, but few deliver. In fact, the industry as a whole seems to be moving towards single-vendor SOA platforms that will keep many SOA initiatives tightly coupled at this layer. This ZapFlash serves as warning to firms that want to achieve high degrees of loose coupling: keep your implementation infrastructure neutral and you will be successful. Otherwise, your SOA initiatives will only enable partial business agility.

      Loose Coupling at the Semantic Layer
      The final level of loose coupling is the most challenging of all. Even if a company is enabled to make all the changes it wants to Service implementation, contract, policy, process, infrastructure, and data structure, problems still arise whenever there is change to semantics. As we detailed in our Semantic Integration: Loosely Coupling the Meaning of Data ZapFlash, if we impose the data structures of Service providers on Service requesters, the result is every bit as tightly coupled as previous architectural approaches. In order to provide the promise of seamless data integration, we must transcend simply loosely coupling the application interface and in addition provide loose coupling at the semantic level.

      As we detailed those ZapFlashes, in order to achieve the sort of semantic data integration we are seeking, we must implement dynamic service definitions. In essence, the definition of the Service interface must change based on the context of the Service requester. As a result, a Service can change its contract between invocations. For example, the fact that a Service provider requires first names to be no longer than 40 characters should not require the requester to know that fact. The contracted Service interface is supposed to provide that isolation. Service interfaces must therefore become much smarter. Instead of having to know ahead of time what specific data requirements are needed by a Service, the Service requester should be able to dynamically discover a Service interface that can not only provide the needed functionality, but also understand the information payload.

      The ZapThink Take
      SOA as a whole is an exercise in loosening the coupling of heterogeneous systems that have to cooperate to meet the needs of the business. As such, as companies seek to mature their SOA initiatives, they should be seeking to iteratively loosen the coupling of their systems at the various levels described above. The most amazing part of this loose coupling exercise is that the greater the degree of variability that can be tolerated by the system, the greater agility that you've enabled for the business. Even more so, if companies can manage to address all seven layers of loose coupling while maintaining a flat cost of architecture, then we've reached the desired state of the IT-Business relationship: IT can implement every requirement and desired outcome expressed by the business without imposing any additional time or cost impedance.

      To be specific, in a system that is enabled with all seven layers of loose coupling, changes to Service implementations, business processes, Service contracts, Service policies, runtime infrastructure, data schema, and semantics won't break the system. Can you think of any requirement by business not addressed in those levels of loose coupling? This vision of agility is precisely the aim of SOA, and it clearly requires much broader understanding of SOA than simply loose coupling of the implementation, which is the only capability provided by Web Services.





      --
      Nick Gall
      Phone: +1.781.608.5871
      AOL IM: Nicholas Gall
      Yahoo IM: nick_gall_1117
      MSN IM: (same as email)
      Google Talk: (same as email)
      Email: nick.gall AT-SIGN gmail DOT com
      Weblog: http://ironick.typepad.com/ironick/
      Furl: http://www.furl.net/members/ngall
    • jeffrschneider
      A big +1 on ubiquity. Nick - here is the paper I mentioned to you. It s now 4 years old and could use an update...
      Message 2 of 6 , Dec 8, 2007
      • 0 Attachment
        A big +1 on ubiquity.

        Nick - here is the paper I mentioned to you. It's now 4 years old and
        could use an update...
        http://schneider.blogspot.com/couplingindex.htm

        As SOA consultants, we realize that there is no 'right' formula for
        coupling - we just needed guidance...

        Jeff


        --- In service-orientated-architecture@yahoogroups.com, "Nick Gall"
        <nick.gall@...> wrote:
        >
        > A few observations:
        >
        > 1. In deciding where to apply loose coupling and what aspects to
        apply
        > it to, keep the following rule of thumb in mind: Since the goal
        of loose
        > coupling is to enable independent change among interacting
        systems, only
        > loosen couplings between aspects of interacting systems that are
        likely to
        > change independently, ie at different rates from one another.
        Systems that
        > are highly likely to always change together do not need to be
        loosely
        > coupled.
        > 2. The list below is definitely a list of "aspects" (as Ron
        mentions)
        > NOT "levels", because they are largely independent of one
        another, eg, you
        > don't have to achieve implementation loose coupling to achieve
        semantic
        > loose coupling and vice versa. I think it is misleading to think
        of the
        > aspects below as levels; but it makes for a better headline.
        > 3. You can NEVER achieve "complete decoupling" of two interacting
        > systems: to interact in any way, there must be SOME dependencies
        (coupling)
        > between the two systems. If you don't believe me, read Herbert
        Simon's
        > "Sciences of the Artificial", where he discusses "decomposable
        systems", and
        > makes the same point.
        > 4. This list leaves out the most important aspect of loose
        coupling:
        > ubiquity. If I and only one other partner adopt the world's most
        dynamically
        > reconfigurable middleware architecture then he and I are tightly
        bound to
        > one another. Imagine the two of us dreamed up our own custom
        variation of
        > WS-*; let's call it WS-Silo. Then between the two of us, we
        could do all
        > sorts of nifty changes on one side to the interface without
        disrupting the
        > other side; but we can't interoperate with ANYONE else.
        >
        > Item (4) is an extreme example of the problem WS-* has run into.
        Because of
        > the complexity of the specs, vendor deviations from the specs,
        variations
        > allowed be the specs, etc., only small numbers of participants can
        > successfully interoperate with WS-*. Almost every deployment of WS-
        * is
        > effectively WS-Silo:inside the Silo all systems are loosely-
        coupled, but
        > only to a small number of other systems.
        >
        > The advantage of HTTP/REST is that, although I lose some
        implementation
        > loose coupling (since I'm now tied to HTTP) I gain the mature
        > interoperability of HTTP, so I can interact with anyone on the
        Internet.
        > This is why you see so little WS-* outside the firewall and so much
        inside.
        >
        > Bottom Line: When in doubt, choose an interoperability architecture
        that is
        > somewhat more tightly coupled, but vastly more ubiquitous, over a
        somewhat
        > more loosely coupled interop architecture that is comparatively
        rare.
        >
        > -- Nick
        >
        > On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:
        >
        > > [image: ZapThink]
        > > The Seven Levels of Loose Coupling Document ID: ZAPFLASH-
        20071128 |
        > > Document Type: ZapFlash
        > > *By: Ronald Schmelzer*
        > > Posted: Nov. 28, 2007
        > >
        > > When ZapThink talks about Service-Oriented Architecture (SOA), we
        > > generally try to avoid semantic arguments about what is and what
        isn't SOA,
        > > but rather try to focus on specific characteristics that identify
        > > Service-oriented systems and the benefits they provide
        organizations that
        > > adopt the architectural approach. In particular, we like to focus
        on three
        > > core tenets: loose coupling of Service consumers and providers,
        > > composability at a variety of levels of granularity, and event-
        driven,
        > > asynchronous styles of interaction that allow for a wide range of
        usage
        > > scenarios.
        > >
        > > While these characteristics might seem distinct, they are in fact
        related
        > > to each other. The ability to compose arbitrary Services in
        environments of
        > > long-running transactions requires a certain measure of loose
        coupling.
        > > However, architects seem to grapple with the term "loose
        coupling". Some
        > > erroneously think that systems are either loosely coupled or
        tightly coupled
        > > as if the determination of coupling is a binary evaluation. The
        reality is
        > > that the concept of coupling, like that of granularity, is a
        relative term.
        > > Something is more loosely coupled than something else if it
        allows for a
        > > greater degree of variability and freedom for that particular
        aspect. Simply
        > > put, coupling is a measure of dependency and commonality required
        by a
        > > Service consumer and provider to be able to achieve a result.
        > >
        > > In that light, loose coupling is a spectrum. A system can be
        tightly
        > > coupled in one aspect while being loosely coupled in another. Many
        > > architects say that they want complete decoupling of systems so
        that any
        > > variation in the system can be handled without having to
        reimplement any of
        > > the Service consumers or providers. As we've discussed in
        past<http://www.zapthink.com/report.html?id=ZAPFLASH-09292004>
        > > ZapFlashes <http://www.zapthink.com/report.html?id=ZAPFLASH-
        2006519>,
        > > complete decoupling is incredibly difficult and expensive, if not
        > > impossible. So, what architects should be aiming for is achieving
        the right
        > > level of loose coupling<http://www.zapthink.com/report.html?
        id=ZAPFLASH-05282004>to facilitate business agility without imposing
        huge costs.
        > >
        > > As such, what ZapThink has seen is that there are really seven
        levels, or
        > > perhaps aspects, of loose coupling that architects should
        consider in their
        > > SOA initiatives. The more degrees and levels of loose coupling
        they add to
        > > their SOA efforts, the greater those systems can deal with change.
        > >
        > > *Loose Coupling the Implementation*
        > > One of the most fundamental promises of SOA is that Service
        consumers are
        > > blind to the implementation technology used by the Service
        providers, and
        > > vice-versa. Indeed, the whole idea of the Service abstraction is
        that
        > > technology implementations are hidden. This most basic of SOA
        > > characteristics is realized using standards-based, interoperable
        > > specifications or protocols that provide a contract-based
        interaction
        > > between Service consumers and providers. Web Services certainly
        fits the
        > > bill as does REST and other styles of Service implementation.
        Indeed, it's
        > > not the choice of interoperable specification (whether XML based
        or not)
        > > that enables this level of loose coupling, but rather the Service
        contract.
        > > A properly written Service contract will allow Service consumers
        to bind to
        > > a wide range of Service provider implementations without have to
        know at all
        > > whether the Service implementation is done in Java, .NET, PHP,
        C++, or
        > > Basic. All SOA implementations must be at least loosely coupled
        at the
        > > implementation level, but clearly this is not enough to guarantee
        the sort
        > > of complete loose coupling so desired by the business.
        > >
        > > *Loose Coupling the Service Contract*
        > > XML, Web Services, REST, and other specifications hide the
        implementation
        > > of the Service such that when the Service implementation changes,
        the
        > > Service consumer does not need to be the wiser about it. However,
        what
        > > happens when the Service contract itself changes? A simple change
        to
        > > acceptable inputs or functional behavior of the system can have
        profound
        > > impact on Service consumers. As such, architects that want to
        progress their
        > > SOA initiatives beyond simply Web Service integration need to
        address
        > > Service contract change management in such a way that contract
        changes don't
        > > cause Service consumer breakage.
        > >
        > > This might seem to be a difficult proposition, but there are
        plenty of
        > > best practices, architectural approaches, and technologies to
        facilitate
        > > this level of loose coupling. First, a proper Service contract
        that is
        > > interface-neutral will alleviate much of the problem of Service
        contract
        > > change management. The Service Description Framework (SDF) shared
        by
        > > ZapThink in our Licensed ZapThink Architect (LZA) boot camps is
        one of those
        > > technology-neutral Service contract templates. In those
        approaches, new
        > > Service contracts don't simply replace old ones. Old contracts
        are never
        > > deprecated unless a transition path is provided for Service
        consumers. This
        > > can be as simple as a transformation or as complex as a Service-
        oriented
        > > process that is triggered when Service consumers request old (and
        > > deprecated) versions of the Service contract. As such, contract
        change must
        > > be handled as a matter of policy. Who gets what version of a
        Service should
        > > be controlled via metadata, not programmatically or via
        configuration of
        > > tightly-coupled infrastructure.
        > >
        > > Active management and Service intermediaries further simplify the
        Service
        > > contract change management issue by providing exception
        management and
        > > handling of Service contract differences. And of course, SOA
        Governance
        > > plays a huge role here in helping to manage the sort of change and
        > > versioning issues that arise. But probably the best practice in
        this arena
        > > is the use of late-binding approaches that leverage run-time
        registries and
        > > contract-based binding to abstract the binding specifics of
        Service
        > > consumers and keep Service contract changes from propagating. The
        topic of
        > > late binding is itself a deep conversation that requires
        rethinking the way
        > > that Service consumers bind to Service providers, and one too
        long for this
        > > ZapFlash.
        > >
        > > *Loose Coupling the Service Policy*
        > > So, putting into play Service contracts that abstract
        implementations and
        > > late-binding, intermediary-enabled, registry-based systems that
        allow for
        > > Service contract change without breakage enables a great degree of
        > > variability in the system, but we're still far from done. Indeed,
        even if
        > > the Service contract stays stable, a small change to a Service
        policy can
        > > have tremendous repercussions, as discussed in our Butterfly
        Effect
        > > ZapFlash <http://www.zapthink.com/report.html?id=ZAPFLASH-
        2006124>.
        > >
        > > Companies looking to address Service variability should handle
        changes to
        > > policy the same way they handle changes to Service contract: late-
        binding,
        > > Service intermediary-enabled, registry-based, and governed. A
        policy is a
        > > form of metadata, as are contracts, and in fact, the only
        difference between
        > > a Service policy and a contract is that a policy can apply to any
        number of
        > > Services. Because policies control many aspects of the non-
        functional parts
        > > of a Service, architects need to include in their architectural
        plans
        > > methods and practices for dealing with Service policy versioning
        and
        > > deprecation as well as policy versioning that leverages the
        technologies and
        > > practices established for Service contracts. Companies need to
        test policies
        > > just as they test Service implementations, and manage policies as
        rigorously
        > > as they manage Services. Doing so not only makes the system as a
        whole more
        > > reliable, but enables one more level of loose coupling.
        > >
        > > *Loose Coupling the Process*
        > > Of course, loosely coupling the Service consumer from a Service
        provider
        > > only provides agility if the Services aren't composed together.
        Once you
        > > have a business process that composes a bunch of Services
        together, we have
        > > another area of potential tight coupling. What happens when the
        process
        > > changes? Ideally, a Service consumer should not have to know at
        all when a
        > > process is reconfigured. Fortunately, achieving that level of
        loose coupling
        > > is fairly straightforward.
        > >
        > > The movement in the SOA and BPM markets has been towards
        separating the
        > > process definition layer from the underlying implementation. By
        defining
        > > processes in metadata and exposing those processes using Service
        contracts
        > > (the recursive vision of process compose of Service and exposed
        as Service)
        > > abstracts the implementation of the process from the Service
        consumer. In
        > > fact, in such a scenario, a business process is really a form of
        Service
        > > implementation. And just as Service contracts provide loose
        coupling of
        > > Service implementations, they provide loose coupling of Service-
        oriented
        > > processes.
        > >
        > > *Loose Coupling the Data Schema*
        > > If we've enabled all the loose coupling levels defined above,
        companies
        > > should be able to make arbitrary changes to their Service
        implementations,
        > > contracts, policies, and processes without breaking a thing (or a
        sweat).
        > > Yet, that's not sufficient to handle the changing needs of the
        business.
        > > What happens when the underlying data schema changes? If a
        Service consumer
        > > and provider need to have a common understanding about that in
        order to have
        > > a conversation, we have tight coupling as defined above.
        Therefore,
        > > organizations need to further their loose coupling goals by
        enabling dynamic
        > > and heterogeneous change to the data schema shared between
        Service consumers
        > > and providers.
        > >
        > > To some, this might seem to be a very complicated task. Computers
        aren't
        > > people, after all, and so they can't process any changes to the
        format or
        > > definition of data. Yet, not all hope is lost here. First,
        Services aren't
        > > really interoperable unless they can understand and process data
        in common.
        > > This means that while there might be semantic dependencies
        between them
        > > (which we will address shortly), there does not need to be
        structural data
        > > dependencies between them. Schemas are key to Service data
        interoperability.
        > > However, what happens when Schemas change? One key approach is to
        address
        > > information and schema management in the same way you approach
        Service
        > > metadata management. Data schema can be treated as a form of
        metadata and
        > > the use of exception management, transformations, Service
        intermediaries,
        > > and Data Services (described in more detail
        here<http://www.zapthink.com/report.html?id=ZAPFLASH-2006103>)
        > > are all key to enabling loose coupling of data structure.
        Implementing a
        > > Data Services layer introduces loose coupling in a way that
        provides a
        > > separation of concerns, so that underlying data infrastructure
        changes are
        > > insulated from the business Services above.
        > >
        > > Furthermore, companies need to align the efforts of those
        maintaining the
        > > data schema with those maintaining the Service metadata. Why is
        it that the
        > > folks who maintain the schema are not part of the architectural
        team? Schema
        > > are no different than Service contracts. They represent a form of
        metadata
        > > that encodes business requirements. As such, we frequently
        admonish
        > > companies to bring their data and information architect teams
        into their
        > > enterprise architect fold<http://www.zapthink.com/report.html?
        id=ZAPFLASH-10222003>.
        > > The simple act of this alignment and the establishment of
        metadata-enabled
        > > change management will allow for loose coupling of data schema and
        > > structure.
        > >
        > > *Loose Coupling the Infrastructure*
        > > Before we try to slay the last dragon of loose coupling, it's
        important to
        > > note that all these levels of loose coupling doesn't matter a
        whit if it all
        > > depends on a single vendor's implementation. Too many times we
        interact with
        > > architects who claim that their systems are loosely coupled, but
        if they
        > > move their implementation from one Enterprise Service Bus (ESB)
        or Service
        > > infrastructure to another then all hell will break loose. How can
        they truly
        > > say their implementations are loosely coupled with such a huge
        dependency in
        > > mind? Enterprise architects worth a grain of salt will demand
        that their
        > > Service implementations be infrastructure neutral. That means
        that at any
        > > time, the company can change their infrastructure without having
        to rebuild
        > > all the Service consumers and providers.
        > >
        > > Many vendors promise this sort of interchangeability, but few
        deliver. In
        > > fact, the industry as a whole seems to be moving towards single-
        vendor SOA
        > > platforms that will keep many SOA initiatives tightly coupled at
        this layer.
        > > This ZapFlash serves as warning to firms that want to achieve
        high degrees
        > > of loose coupling: keep your implementation infrastructure
        neutral and you
        > > will be successful. Otherwise, your SOA initiatives will only
        enable partial
        > > business agility.
        > >
        > > *Loose Coupling at the Semantic Layer*
        > > The final level of loose coupling is the most challenging of all.
        Even if
        > > a company is enabled to make all the changes it wants to Service
        > > implementation, contract, policy, process, infrastructure, and
        data
        > > structure, problems still arise whenever there is change to
        semantics. As we
        > > detailed in our Semantic Integration: Loosely Coupling the
        Meaning of Data
        > > ZapFlash <http://www.zapthink.com/report.html?id=ZapFlash-
        08082003>, if we
        > > impose the data structures of Service providers on Service
        requesters, the
        > > result is every bit as tightly coupled as previous architectural
        approaches.
        > > In order to provide the promise of seamless data integration, we
        must
        > > transcend simply loosely coupling the application interface and
        in addition
        > > provide loose coupling at the semantic
        level<http://www.zapthink.com/report.html?id=ZAPFLASH-2005217>.
        > >
        > >
        > > As we detailed those ZapFlashes, in order to achieve the sort of
        semantic
        > > data integration we are seeking, we must implement *dynamic*
        service
        > > definitions. In essence, the definition of the Service interface
        must change
        > > based on the context of the Service requester. As a result, a
        Service can
        > > change its contract between invocations. For example, the fact
        that a
        > > Service provider requires first names to be no longer than 40
        characters
        > > should not require the requester to know that fact. The
        contracted Service
        > > interface is supposed to provide that isolation. Service
        interfaces must
        > > therefore become much smarter. Instead of having to know ahead of
        time what
        > > specific data requirements are needed by a Service, the Service
        requester
        > > should be able to dynamically discover a Service interface that
        can not only
        > > provide the needed functionality, but also understand the
        information
        > > payload.
        > >
        > > *The ZapThink Take*
        > > SOA as a whole is an exercise in *loosening the coupling* of
        heterogeneous
        > > systems that have to cooperate to meet the needs of the business.
        As such,
        > > as companies seek to mature their SOA initiatives, they should be
        seeking to
        > > iteratively loosen the coupling of their systems at the various
        levels
        > > described above. The most amazing part of this loose coupling
        exercise is
        > > that the greater the degree of variability that can be tolerated
        by the
        > > system, the greater agility that you've enabled for the business.
        Even more
        > > so, if companies can manage to address all seven layers of loose
        coupling
        > > while maintaining a flat cost of architecture, then we've reached
        the
        > > desired state of the IT-Business relationship: IT can implement
        every
        > > requirement and desired outcome expressed by the business without
        imposing
        > > any additional time or cost impedance.
        > >
        > > To be specific, in a system that is enabled with all seven layers
        of loose
        > > coupling, changes to Service implementations, business processes,
        Service
        > > contracts, Service policies, runtime infrastructure, data schema,
        and
        > > semantics won't break the system. Can you think of any
        requirement by
        > > business not addressed in those levels of loose coupling? This
        vision of
        > > agility is precisely the aim of SOA, and it clearly requires much
        broader
        > > understanding of SOA than simply loose coupling of the
        implementation, which
        > > is the only capability provided by Web Services.
        > >
        > > **
        > >
        > >
        >
        >
        >
        > --
        > Nick Gall
        > Phone: +1.781.608.5871
        > AOL IM: Nicholas Gall
        > Yahoo IM: nick_gall_1117
        > MSN IM: (same as email)
        > Google Talk: (same as email)
        > Email: nick.gall AT-SIGN gmail DOT com
        > Weblog: http://ironick.typepad.com/ironick/
        > Furl: http://www.furl.net/members/ngall
        >
      • Steve Jones
        +1 on that +1 The phrase I like to use is appropriate coupling . I ve sadly seen systems built with a more religious intent that have excessive levels of
        Message 3 of 6 , Dec 9, 2007
        • 0 Attachment
          +1 on that +1

          The phrase I like to use is "appropriate coupling".  I've sadly seen systems built with a more religious intent that have excessive levels of "loose" coupling in areas where it just makes absolutely zero sense.  Often over a period of a year or so the developers realise this so they start using the same Java/C# stuff at either end so in effect you have XML as a marshalling construct only.

          Loose coupling is great when it is needed and an expensive waste of time where it isn't.

          Steve


          On 08/12/2007, jeffrschneider < jeffrschneider@...> wrote:

          A big +1 on ubiquity.

          Nick - here is the paper I mentioned to you. It's now 4 years old and
          could use an update...
          http://schneider.blogspot.com/couplingindex.htm

          As SOA consultants, we realize that there is no 'right' formula for
          coupling - we just needed guidance...

          Jeff

          --- In service-orientated-architecture@yahoogroups.com, "Nick Gall"
          <nick.gall@...> wrote:
          >
          > A few observations:
          >
          > 1. In deciding where to apply loose coupling and what aspects to


          apply
          > it to, keep the following rule of thumb in mind: Since the goal
          of loose
          > coupling is to enable independent change among interacting
          systems, only
          > loosen couplings between aspects of interacting systems that are
          likely to
          > change independently, ie at different rates from one another.
          Systems that
          > are highly likely to always change together do not need to be
          loosely
          > coupled.
          > 2. The list below is definitely a list of "aspects" (as Ron
          mentions)
          > NOT "levels", because they are largely independent of one
          another, eg, you
          > don't have to achieve implementation loose coupling to achieve
          semantic
          > loose coupling and vice versa. I think it is misleading to think
          of the
          > aspects below as levels; but it makes for a better headline.
          > 3. You can NEVER achieve "complete decoupling" of two interacting
          > systems: to interact in any way, there must be SOME dependencies
          (coupling)
          > between the two systems. If you don't believe me, read Herbert
          Simon's
          > "Sciences of the Artificial", where he discusses "decomposable
          systems", and
          > makes the same point.
          > 4. This list leaves out the most important aspect of loose
          coupling:
          > ubiquity. If I and only one other partner adopt the world's most
          dynamically
          > reconfigurable middleware architecture then he and I are tightly
          bound to
          > one another. Imagine the two of us dreamed up our own custom
          variation of
          > WS-*; let's call it WS-Silo. Then between the two of us, we
          could do all
          > sorts of nifty changes on one side to the interface without
          disrupting the
          > other side; but we can't interoperate with ANYONE else.
          >
          > Item (4) is an extreme example of the problem WS-* has run into.
          Because of
          > the complexity of the specs, vendor deviations from the specs,
          variations
          > allowed be the specs, etc., only small numbers of participants can
          > successfully interoperate with WS-*. Almost every deployment of WS-
          * is
          > effectively WS-Silo:inside the Silo all systems are loosely-
          coupled, but
          > only to a small number of other systems.
          >
          > The advantage of HTTP/REST is that, although I lose some
          implementation
          > loose coupling (since I'm now tied to HTTP) I gain the mature
          > interoperability of HTTP, so I can interact with anyone on the
          Internet.
          > This is why you see so little WS-* outside the firewall and so much
          inside.
          >
          > Bottom Line: When in doubt, choose an interoperability architecture
          that is
          > somewhat more tightly coupled, but vastly more ubiquitous, over a
          somewhat
          > more loosely coupled interop architecture that is comparatively
          rare.
          >
          > -- Nick
          >
          > On Nov 30, 2007 5:34 AM, Gervas Douglas <gervas.douglas@...> wrote:
          >
          > > [image: ZapThink]

          > > The Seven Levels of Loose Coupling Document ID: ZAPFLASH-
          20071128 |
          > > Document Type: ZapFlash
          > > *By: Ronald Schmelzer*
          > > Posted: Nov. 28, 2007
          > >
          > > When ZapThink talks about Service-Oriented Architecture (SOA), we
          > > generally try to avoid semantic arguments about what is and what
          isn't SOA,
          > > but rather try to focus on specific characteristics that identify
          > > Service-oriented systems and the benefits they provide
          organizations that
          > > adopt the architectural approach. In particular, we like to focus
          on three
          > > core tenets: loose coupling of Service consumers and providers,
          > > composability at a variety of levels of granularity, and event-
          driven,
          > > asynchronous styles of interaction that allow for a wide range of
          usage
          > > scenarios.
          > >
          > > While these characteristics might seem distinct, they are in fact
          related
          > > to each other. The ability to compose arbitrary Services in
          environments of
          > > long-running transactions requires a certain measure of loose
          coupling.
          > > However, architects seem to grapple with the term "loose
          coupling". Some
          > > erroneously think that systems are either loosely coupled or
          tightly coupled
          > > as if the determination of coupling is a binary evaluation. The
          reality is
          > > that the concept of coupling, like that of granularity, is a
          relative term.
          > > Something is more loosely coupled than something else if it
          allows for a
          > > greater degree of variability and freedom for that particular
          aspect. Simply
          > > put, coupling is a measure of dependency and commonality required
          by a
          > > Service consumer and provider to be able to achieve a result.
          > >
          > > In that light, loose coupling is a spectrum. A system can be
          tightly
          > > coupled in one aspect while being loosely coupled in another. Many
          > > architects say that they want complete decoupling of systems so
          that any
          > > variation in the system can be handled without having to
          reimplement any of
          > > the Service consumers or providers. As we've discussed in
          past<http://www.zapthink.com/report.html?id=ZAPFLASH-09292004>
          > > ZapFlashes <http://www.zapthink.com/report.html?id=ZAPFLASH-
          2006519>,
          > > complete decoupling is incredibly difficult and expensive, if not
          > > impossible. So, what architects should be aiming for is achieving
          the right
          > > level of loose coupling<http://www.zapthink.com/report.html?
          id=ZAPFLASH-05282004>to facilitate business agility without imposing

          huge costs.
          > >
          > > As such, what ZapThink has seen is that there are really seven
          levels, or
          > > perhaps aspects, of loose coupling that architects should
          consider in their
          > > SOA initiatives. The more degrees and levels of loose coupling
          they add to
          > > their SOA efforts, the greater those systems can deal with change.
          > >
          > > *Loose Coupling the Implementation*
          > > One of the most fundamental promises of SOA is that Service
          consumers are
          > > blind to the implementation technology used by the Service
          providers, and
          > > vice-versa. Indeed, the whole idea of the Service abstraction is
          that
          > > technology implementations are hidden. This most basic of SOA
          > > characteristics is realized using standards-based, interoperable
          > > specifications or protocols that provide a contract-based
          interaction
          > > between Service consumers and providers. Web Services certainly
          fits the
          > > bill as does REST and other styles of Service implementation.
          Indeed, it's
          > > not the choice of interoperable specification (whether XML based
          or not)
          > > that enables this level of loose coupling, but rather the Service
          contract.
          > > A properly written Service contract will allow Service consumers
          to bind to
          > > a wide range of Service provider implementations without have to
          know at all
          > > whether the Service implementation is done in Java, .NET, PHP,
          C++, or
          > > Basic. All SOA implementations must be at least loosely coupled
          at the
          > > implementation level, but clearly this is not enough to guarantee
          the sort
          > > of complete loose coupling so desired by the business.
          > >
          > > *Loose Coupling the Service Contract*
          > > XML, Web Services, REST, and other specifications hide the
          implementation
          > > of the Service such that when the Service implementation changes,
          the
          > > Service consumer does not need to be the wiser about it. However,
          what
          > > happens when the Service contract itself changes? A simple change
          to
          > > acceptable inputs or functional behavior of the system can have
          profound
          > > impact on Service consumers. As such, architects that want to
          progress their
          > > SOA initiatives beyond simply Web Service integration need to
          address
          > > Service contract change management in such a way that contract
          changes don't
          > > cause Service consumer breakage.
          > >
          > > This might seem to be a difficult proposition, but there are
          plenty of
          > > best practices, architectural approaches, and technologies to
          facilitate
          > > this level of loose coupling. First, a proper Service contract
          that is
          > > interface-neutral will alleviate much of the problem of Service
          contract
          > > change management. The Service Description Framework (SDF) shared
          by
          > > ZapThink in our Licensed ZapThink Architect (LZA) boot camps is
          one of those
          > > technology-neutral Service contract templates. In those
          approaches, new
          > > Service contracts don't simply replace old ones. Old contracts
          are never
          > > deprecated unless a transition path is provided for Service
          consumers. This
          > > can be as simple as a transformation or as complex as a Service-
          oriented
          > > process that is triggered when Service consumers request old (and
          > > deprecated) versions of the Service contract. As such, contract
          change must
          > > be handled as a matter of policy. Who gets what version of a
          Service should
          > > be controlled via metadata, not programmatically or via
          configuration of
          > > tightly-coupled infrastructure.
          > >
          > > Active management and Service intermediaries further simplify the
          Service
          > > contract change management issue by providing exception
          management and
          > > handling of Service contract differences. And of course, SOA
          Governance
          > > plays a huge role here in helping to manage the sort of change and
          > > versioning issues that arise. But probably the best practice in
          this arena
          > > is the use of late-binding approaches that leverage run-time
          registries and
          > > contract-based binding to abstract the binding specifics of
          Service
          > > consumers and keep Service contract changes from propagating. The
          topic of
          > > late binding is itself a deep conversation that requires
          rethinking the way
          > > that Service consumers bind to Service providers, and one too
          long for this
          > > ZapFlash.
          > >
          > > *Loose Coupling the Service Policy*
          > > So, putting into play Service contracts that abstract
          implementations and
          > > late-binding, intermediary-enabled, registry-based systems that
          allow for
          > > Service contract change without breakage enables a great degree of
          > > variability in the system, but we're still far from done. Indeed,
          even if
          > > the Service contract stays stable, a small change to a Service
          policy can
          > > have tremendous repercussions, as discussed in our Butterfly
          Effect
          > > ZapFlash <http://www.zapthink.com/report.html?id=ZAPFLASH-
          2006124>.

          > >
          > > Companies looking to address Service variability should handle
          changes to
          > > policy the same way they handle changes to Service contract: late-
          binding,
          > > Service intermediary-enabled, registry-based, and governed. A
          policy is a
          > > form of metadata, as are contracts, and in fact, the only
          difference between
          > > a Service policy and a contract is that a policy can apply to any
          number of
          > > Services. Because policies control many aspects of the non-
          functional parts
          > > of a Service, architects need to include in their architectural
          plans
          > > methods and practices for dealing with Service policy versioning
          and
          > > deprecation as well as policy versioning that leverages the
          technologies and
          > > practices established for Service contracts. Companies need to
          test policies
          > > just as they test Service implementations, and manage policies as
          rigorously
          > > as they manage Services. Doing so not only makes the system as a
          whole more
          > > reliable, but enables one more level of loose coupling.
          > >
          > > *Loose Coupling the Process*
          > > Of course, loosely coupling the Service consumer from a Service
          provider
          > > only provides agility if the Services aren't composed together.
          Once you
          > > have a business process that composes a bunch of Services
          together, we have
          > > another area of potential tight coupling. What happens when the
          process
          > > changes? Ideally, a Service consumer should not have to know at
          all when a
          > > process is reconfigured. Fortunately, achieving that level of
          loose coupling
          > > is fairly straightforward.
          > >
          > > The movement in the SOA and BPM markets has been towards
          separating the
          > > process definition layer from the underlying implementation. By
          defining
          > > processes in metadata and exposing those processes using Service
          contracts
          > > (the recursive vision of process compose of Service and exposed
          as Service)
          > > abstracts the implementation of the process from the Service
          consumer. In
          > > fact, in such a scenario, a business process is really a form of
          Service
          > > implementation. And just as Service contracts provide loose
          coupling of
          > > Service implementations, they provide loose coupling of Service-
          oriented
          > > processes.
          > >
          > > *Loose Coupling the Data Schema*
          > > If we've enabled all the loose coupling levels defined above,
          companies
          > > should be able to make arbitrary changes to their Service
          implementations,
          > > contracts, policies, and processes without breaking a thing (or a
          sweat).
          > > Yet, that's not sufficient to handle the changing needs of the
          business.
          > > What happens when the underlying data schema changes? If a
          Service consumer
          > > and provider need to have a common understanding about that in
          order to have
          > > a conversation, we have tight coupling as defined above.
          Therefore,
          > > organizations need to further their loose coupling goals by
          enabling dynamic
          > > and heterogeneous change to the data schema shared between
          Service consumers
          > > and providers.
          > >
          > > To some, this might seem to be a very complicated task. Computers
          aren't
          > > people, after all, and so they can't process any changes to the
          format or
          > > definition of data. Yet, not all hope is lost here. First,
          Services aren't
          > > really interoperable unless they can understand and process data
          in common.
          > > This means that while there might be semantic dependencies
          between them
          > > (which we will address shortly), there does not need to be
          structural data
          > > dependencies between them. Schemas are key to Service data
          interoperability.
          > > However, what happens when Schemas change? One key approach is to
          address
          > > information and schema management in the same way you approach
          Service
          > > metadata management. Data schema can be treated as a form of
          metadata and
          > > the use of exception management, transformations, Service
          intermediaries,
          > > and Data Services (described in more detail
          here<http://www.zapthink.com/report.html?id=ZAPFLASH-2006103>)
          > > are all key to enabling loose coupling of data structure.
          Implementing a
          > > Data Services layer introduces loose coupling in a way that
          provides a
          > > separation of concerns, so that underlying data infrastructure
          changes are
          > > insulated from the business Services above.
          > >
          > > Furthermore, companies need to align the efforts of those
          maintaining the
          > > data schema with those maintaining the Service metadata. Why is
          it that the
          > > folks who maintain the schema are not part of the architectural
          team? Schema
          > > are no different than Service contracts. They represent a form of
          metadata
          > > that encodes business requirements. As such, we frequently
          admonish
          > > companies to bring their data and information architect teams
          into their
          > > enterprise architect fold<http://www.zapthink.com/report.html?
          id=ZAPFLASH-10222003>.

          > > The simple act of this alignment and the establishment of
          metadata-enabled
          > > change management will allow for loose coupling of data schema and
          > > structure.
          > >
          > > *Loose Coupling the Infrastructure*
          > > Before we try to slay the last dragon of loose coupling, it's
          important to
          > > note that all these levels of loose coupling doesn't matter a
          whit if it all
          > > depends on a single vendor's implementation. Too many times we
          interact with
          > > architects who claim that their systems are loosely coupled, but
          if they
          > > move their implementation from one Enterprise Service Bus (ESB)
          or Service
          > > infrastructure to another then all hell will break loose. How can
          they truly
          > > say their implementations are loosely coupled with such a huge
          dependency in
          > > mind? Enterprise architects worth a grain of salt will demand
          that their
          > > Service implementations be infrastructure neutral. That means
          that at any
          > > time, the company can change their infrastructure without having
          to rebuild
          > > all the Service consumers and providers.
          > >
          > > Many vendors promise this sort of interchangeability, but few
          deliver. In
          > > fact, the industry as a whole seems to be moving towards single-
          vendor SOA
          > > platforms that will keep many SOA initiatives tightly coupled at
          this layer.
          > > This ZapFlash serves as warning to firms that want to achieve
          high degrees
          > > of loose coupling: keep your implementation infrastructure
          neutral and you
          > > will be successful. Otherwise, your SOA initiatives will only
          enable partial
          > > business agility.
          > >
          > > *Loose Coupling at the Semantic Layer*
          > > The final level of loose coupling is the most challenging of all.
          Even if
          > > a company is enabled to make all the changes it wants to Service
          > > implementation, contract, policy, process, infrastructure, and
          data
          > > structure, problems still arise whenever there is change to
          semantics. As we
          > > detailed in our Semantic Integration: Loosely Coupling the
          Meaning of Data
          > > ZapFlash <http://www.zapthink.com/report.html?id=ZapFlash-
          08082003>, if we
          > > impose the data structures of Service providers on Service
          requesters, the
          > > result is every bit as tightly coupled as previous architectural
          approaches.
          > > In order to provide the promise of seamless data integration, we
          must
          > > transcend simply loosely coupling the application interface and
          in addition
          > > provide loose coupling at the semantic
          level<http://www.zapthink.com/report.html?id=ZAPFLASH-2005217>.

          > >
          > >
          > > As we detailed those ZapFlashes, in order to achieve the sort of
          semantic
          > > data integration we are seeking, we must implement *dynamic*
          service
          > > definitions. In essence, the definition of the Service interface
          must change
          > > based on the context of the Service requester. As a result, a
          Service can
          > > change its contract between invocations. For example, the fact
          that a
          > > Service provider requires first names to be no longer than 40
          characters
          > > should not require the requester to know that fact. The
          contracted Service
          > > interface is supposed to provide that isolation. Service
          interfaces must
          > > therefore become much smarter. Instead of having to know ahead of
          time what
          > > specific data requirements are needed by a Service, the Service
          requester
          > > should be able to dynamically discover a Service interface that
          can not only
          > > provide the needed functionality, but also understand the
          information
          > > payload.
          > >
          > > *The ZapThink Take*
          > > SOA as a whole is an exercise in *loosening the coupling* of
          heterogeneous
          > > systems that have to cooperate to meet the needs of the business.
          As such,
          > > as companies seek to mature their SOA initiatives, they should be
          seeking to
          > > iteratively loosen the coupling of their systems at the various
          levels
          > > described above. The most amazing part of this loose coupling
          exercise is
          > > that the greater the degree of variability that can be tolerated
          by the
          > > system, the greater agility that you've enabled for the business.
          Even more
          > > so, if companies can manage to address all seven layers of loose
          coupling
          > > while maintaining a flat cost of architecture, then we've reached
          the
          > > desired state of the IT-Business relationship: IT can implement
          every
          > > requirement and desired outcome expressed by the business without
          imposing
          > > any additional time or cost impedance.
          > >
          > > To be specific, in a system that is enabled with all seven layers
          of loose
          > > coupling, changes to Service implementations, business processes,
          Service
          > > contracts, Service policies, runtime infrastructure, data schema,
          and
          > > semantics won't break the system. Can you think of any
          requirement by
          > > business not addressed in those levels of loose coupling? This
          vision of
          > > agility is precisely the aim of SOA, and it clearly requires much
          broader
          > > understanding of SOA than simply loose coupling of the
          implementation, which
          > > is the only capability provided by Web Services.
          > >
          > > **
          > >
          > >
          >
          >
          >
          > --
          > Nick Gall
          > Phone: +1.781.608.5871
          > AOL IM: Nicholas Gall
          > Yahoo IM: nick_gall_1117
          > MSN IM: (same as email)
          > Google Talk: (same as email)
          > Email: nick.gall AT-SIGN gmail DOT com
          > Weblog: http://ironick.typepad.com/ironick/
          > Furl: http://www.furl.net/members/ngall
          >


        Your message has been successfully submitted and would be delivered to recipients shortly.