Tight coupling: Difference between revisions
Amwelladmin (talk | contribs) Created page with "{{a|devil|}}Not to be confused with the related concept in software architecture, tight coupling between two components of a distributed system, means that they are so..." |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
{{a|devil|}}Not to be confused with the related concept in software architecture, [[tight coupling]] between two components of a [[distributed system]], means that they are so closely interconnected or interrelated that the failure of one quickly or inevitably triggers failure of the other so that it is not practicable to shut the system down, isolate the failing component or otherwise reconfigure the wider system to operate safely before the failing components precipitate a catastrophic, system-wide failure. | {{a|devil|}}Not to be confused with the related concept in software architecture, [[tight coupling]] between two components of a [[distributed system]], means that they are so closely interconnected or interrelated that the failure of one quickly or inevitably triggers failure of the other so that it is not practicable to shut the system down, isolate the failing component or otherwise reconfigure the wider system to operate safely before the failing components precipitate a catastrophic, system-wide failure. | ||
Originates from {{author!Charles Perrow}}’s {{br|Normal Accidents}}. | |||
===Features of tight and loose coupling=== | |||
{{tabletop}} | |||
!|Tight coupling | |||
!|Loose coupling | |||
|- style="vertical-align:top;" | |||
| | |||
Production delays not possible<br> | |||
Difficult to stop the component operating <br> | |||
Mandatory sequence of operation<br> | |||
No scope for changing sequence on the fly <br> | |||
Few buffers or redundancy in the system <br> | |||
Existing buffers are hard-wired and inflexible <br> | |||
Little scope for improvisation<br> | |||
| | |||
Processing delays possible<br> | |||
Production sequence can be changed<br> | |||
Redundancy and slack on resources and personnel<br> | |||
Fortuitous buffers and redundancies in the system<br> | |||
Scope for improvision and substitution<br> | |||
{{tablebottom}} | |||
{{sa}} | {{sa}} | ||
*{{author|Charles Perrow}}’s magnificent {{br|Normal Accidents}}, which introduced the concept of [[tight coupling]] in [[Complex system|complex system]]s. | *{{author|Charles Perrow}}’s magnificent {{br|Normal Accidents}}, which introduced the concept of [[tight coupling]] in [[Complex system|complex system]]s. | ||
*[[DEPOSE]] components of a [[distributed system]] | *[[DEPOSE]] components of a [[distributed system]] | ||
Revision as of 17:15, 31 August 2020
|
Not to be confused with the related concept in software architecture, tight coupling between two components of a distributed system, means that they are so closely interconnected or interrelated that the failure of one quickly or inevitably triggers failure of the other so that it is not practicable to shut the system down, isolate the failing component or otherwise reconfigure the wider system to operate safely before the failing components precipitate a catastrophic, system-wide failure.
Originates from Template:Author!Charles Perrow’s Normal Accidents.
Features of tight and loose coupling
| Tight coupling | Loose coupling |
|---|---|
|
Production delays not possible |
Processing delays possible |
See also
- Charles Perrow’s magnificent Normal Accidents, which introduced the concept of tight coupling in complex systems.
- DEPOSE components of a distributed system