Najczęściej procesy wymiany danych są wzajemnie zależne i zsynchronizowane, co oznacza, że obowiązuje określona sekwencja. Podsystem A przekazuje dane do podsystemu B, a z niego z kolei czerpie C. Jeśli pośrodku tego łańcucha przekazywania informacji nastąpi dowolnego rodzaju awaria, wszystkie zstępne w tej hierarchii gałęzie będą pozbawione zasilania danymi. Awaria jest swojego rodzaju nieprzewidywalnym zrządzeniem losu i trudno jej zapobiegać. Natomiast istnieje szereg innych zagrożeń, w konsekwencji objawiających się w skutkach podobnie do awarii, pomimo że wcale nie zaistniały z nieprzewidywalnych powodów.

Bardzo często podsystemy załatwiają sprawę wymiany danych poprzez buforowe tabele. Jest to metoda wygodna i w większości przypadków godna polecenia. Ma jeszcze tę pozytywną cechę, że łatwo komunikują się w ten sposób heterogeniczne - w zakresie technologii - systemy. Nie jest też rzadkością, że każde z ogniw jest innego autorstwa, a integrujące interfejsy baz danych wykonano za wspólnym uzgodnieniem. Bywa też tak, że z pewnych powodów jedno z ogniw działającego łańcucha wymiany podlega refaktoringowi kodu lub nawet całkowitej reinżynierii. Zdarza się bardzo często, że przy okazji zmianie ulega format danych lub przynajmniej zmieniane są procedury odpowiedzialne za ich walidację. I wówczas okazuje się, że jeden system przepuszcza dane, których drugi system nie może przyjąć. Dzieje się tak za sprawą braku synchronizacji reguł w całej kaskadzie przepływu danych. Takie zjawiska, jak przekroczenie zakresu liczby lub pojawienie się, do tej pory niedozwolonej, wartości pustej, są najbardziej trywialnymi przykładami zachwiania - na skutek zmian programowych - stabilności platformy wymiany. To co uprzednio działało bez zarzutu, teraz zaczyna od czasu do czasu stroić fochy. Czas więc, aby ponownie zestroić systemy. W tym miejscu pada zwyczajowe pytanie kto, za ile i dlaczego.

Jeśli zdarzają się takie sytuacje, to oznacza, że cały projekt potraktowano wycinkowo, nie rozpatrując jego interferencji z pozostałymi komponentami. W związku z tym nie przewidziano w budżecie środków na "wygładzenie krawędzi", co teraz szorstko daje znać o sobie. Można powiedzieć, że zmiana środkowego segmentu wymiany danych powinna być przeprowadzona w sposób bezbolesny, to znaczy taki, aby nie naruszono stabilności współpracy między ogniwami. Jest to jednak założenie teoretyczne i często nie może zostać dotrzymane z różnych przyczyn. Powoduje to zatem, że nawet jeden drobny wyjątek potrafi zaburzyć cały proces wymiany danych.

Integracja systemów poprzez wspólne dane jest zawsze godna polecenia. Przede wszystkim odgórnie wymusza pewne uporządkowanie, zmniejszając redundancję danych i zwiększając ich spójność. Jednakże przy jakichkolwiek zmianach w kodzie programu lub strukturach danych, zawsze należy brać pod uwagę, że nie jest to produkt działający samodzielnie. I to jest między innymi powód, dla którego lepiej mieć jeden zintegrowany system niż kilka programów różnego pochodzenia.