Truizmem jest stwierdzenie, że ludzie pracujący w firmie powinni mieć dostęp do danych w niej zgromadzonych, nawet jeśli rezydują na różnych systemach komputerowych. Jednakże, jak pokazuje praktyka, informatycy próbujący zrealizować ten dostęp przez połączenie dwóch lub więcej systemów komputerowych, napotykają na wiele trudności. Wydaje się, że każdemu informatykowi może przydać się krótki zestaw zaleceń, opracowanych przez doświadczonych specjalistów.

Nawet jeśli systemy komputerowe w firmie są połączone jakimś kablem, nie oznacza, że mogą się komunikować między sobą i wymieniać dane znajdujące się na różnych komputerach. Podane poniżej zalecenia czasem wynikają po prostu ze zdrowego rozsądku, czasem zaś nie są tak oczywiste.

Połączenia fizyczne

Jest oczywiste, że dla osiągnięcia nakreślonego we wstępie celu, komputery muszą być połączone przynajmniej przy użyciu kabli. W celu ograniczenia zasięgu pewnych komunikatów i odciążenia sieci zwykle dzieli się ją na segmenty, które mogą komunikować się między sobą za pośrednictwem struktury szkieletowej.

Samo połączenie fizyczne komputerów i stworzenie segmentów nie jest skomplikowane, jako że adaptery sieciowe są tanie a huby (koncentratory) tworzące z grupy komputerów samodzielny segment też dość popularne. Wiele firm (3Com, LANnet, Cabletron, UB Networks, HP) produkuje huby o dużym zakresie właściwości funkcjonalnych, nadające się do tego celu.

Wskazana jest standaryzacja na jednym typie technologii sieciowej. Ułatwi to zarówno konserwację sieci (dzięki wymienności podzespołów) jak też zarządzanie nią. Jeżeli jesteśmy skazani na różnorodne systemy, to problemem staje się wybór mostów, routerów i hubów modułowych, łączących różne technologicznie sieci - Ethernet, Token Ring czy FDDI.

Systemy operacyjne

Interoperability oznacza, że użytkownik będzie w stanie posługiwać się danymi z systemów DOS-owych, Apple Macintosh, IBM OS/400, Unix czy Novell NetWare w taki sposób, w jaki przyzwyczaił go system w którym pracuje. Niedopuszczalne jest bowiem zmuszanie wszystkich użytkowników do przechodzenia na jeden interfejs użytkowy tylko dlatego, że nie potrafimy zapewnić im dostępu do danych na innych komputerach, w sposób zgodny z używaną przez nich aplikacją.

Związane to jest niestety z koniecznością rozwiązania setek problemów. Zaczynając od nazewnictwa plików: DOS dopuszcza jedynie ośmioznakowe nazwy z trójznakowym rozszerzeniem; Macintosh dopuszcza długie nazwy zawierające spacje; niektóre wersje Unixa umożliwiają nadawanie nazw o długości do 255 znaków, zawierających podkreślenia i kropki.

Jeżeli sieciowy system operacyjny nie będzie w stanie poradzić sobie z jednoznacznym odwzorowaniem tych nazw na jednolity standard, to pojawią się spore kłopoty z dostępem do plików.

Nazewnictwo plików jest zresztą jednym z łatwiejszych problemów do rozwiązania. Dużo większe kłopoty pojawiają się w momencie, gdy potrzeba określić prawa dostępu użytkownika do poszczególnych plików, blokować dostęp na poziomie sektora lub bloku dyskowego albo tłumaczyć reprezentację danych (format liczb zmiennoprzecinkowych IEEE, stosowany w PC nie jest zgodny z formatem stosowanym przez IBM w swych dużych komputerach ani przez DEC w VAX-ach; procesory Motorola w Macintoshu zapisują bajty liczby w innej kolejności niż czynią to procesory Intela).

Elementy łączące sieci

Mosty, routery i gatewaye wykonują bardziej skomplikowane prace niż tylko dzielenie sieci na niezależne segmenty. Po pierwsze, pozwalają na posługiwanie się różnymi protokołami sieciowymi w ramach jednej sieci. Istnieje wiele firmowych protokołów sieciowych, ale najpopularniejsze to Internet TCP/IP, Novell SPX/IPX, IBM SNA i Microsoft NetBIOS/NetBEUI. Elementy międzysieciowe muszą filtrować ruch między różnymi segmentami sieci (dzięki czemu maleje ich obciążenie) oraz tłumaczyć na wspólny standard protokoły z różnych segmentów.

Wybór elementów międzysieciowych powinien więc uwzględniać uwarunkowania fizyczne w sieci i umożliwić skuteczną komunikację.

Protokoły komunikacyjne

Ściśle związane z elementami sieciowymi i międzysieciowymi. Zwykle okazuje się, że w przedsiębiorstwie nie jest możliwe posługiwanie się jednym protokołem komunikacyjnym, gdyż oprócz sieci Novell konieczne jest zainstalowanie stacji roboczych IBM, HP lub SUN, działających pod kontrolą Unixa i posługujących się protokołem TCP/IP.

Jednakże ogólna zasada mówi, że im mniej protokołów komunikacyjnych i mniej sieciowych systemów operacyjnych, tym lepsze szanse dobrego zarządzania siecią. Sieć zawierająca więcej niż 5 różnych systemów operacyjnych lub posługująca się podobną liczbą protokołów komunikacyjnych nie da się zarządzać za pomocą dostępnych narzędzi!

Poczta elektroniczna

W każdym sieciowym systemie operacyjnym występuje specyficzna dla niego metoda obsługi komunikatów, stanowiąca podstawę systemu poczty elektronicznej. Jeżeli więc mamy więcej niż jeden system poczty, to niestety konieczne jest tworzenie gateway'a poczty, tłumaczącego komunikaty na formaty właściwe dla danego systemu. Zwykle możliwe jest zakupienie takiej poczty, która dostępna jest na stosowanych platformach.

Współpraca aplikacji

W tej dziedzinie dzieje się najwięcej. Standard wymiany danych w Windows OLE i DDE (NetDDE w Windows for Workgroups) pozwala na wymianę danych jedynie w ramach jednego zestawu aplikacji, działających w środowisku Windows. Nowe opracowania (SunSoft WABI i Insignia SoftWindows), pozwalające na uruchamianie aplikacji z Windows na systemach unixowych nie dają jednak możliwości wymiany danych z aplikacjami z tych systemów. Jest to więc odizolowany świat Windows na komputerze Unix, który nie przyczynia się więc w żaden sposób do współpracy aplikacji.

Nowy standard wymiany danych OpenDoc, wspierany przez wiele firm (Apple, IBM, Taligent i in.) ma w zasadzie umożliwić międzyplatformową wymianę danych, jednakże na razie jest jeszcze daleko od fazy powszechnej akceptacji i implementacji.

Z faktu, że ze stacji DOSowej w sieci heterogenicznej Novell/Unix jesteśmy w stanie otworzyć plik bazy danych na Unixie nie wynika, że możemy tych danych użyć w aplikacji DOS-u.

Jednolity interfejs użytkowy

Pracownik w firmie powinien móc korzystać z aplikacji opartej na jednakowym interfejsie, niezależnie do tego z jakiego komputera korzysta. Obecnie coraz częściej standardem jest interfejs graficzny Windows lub X Windows. I z tego powodu coraz rzadziej korzysta się z terminali znakowych, coraz częściej z PC jako końcówki graficznej systemu. Istnieją także narzędzia pozwalające na opracowanie części frontowej aplikacji dla wielu platform, o takim samym wyglądzie i właściwościach na każdej z platform.

Opracowanie aplikacji dla wielu platform

Przenośność aplikacji i przetwarzanie klient/serwer dyktują potrzebę takiego opracowania aplikacji, aby równie dobrze działały w środowisku Unix z procesorami RISC i Intel, jak w środowisku Novell NetWare z klientami DOS, Windows czy Macintosh.

Wiele z dostępnych narzędzi pozwala na elastyczny podział aplikacji na część uruchamianą na serwerze sieciowym (serwerze bazy danych) i na część frontową, uruchamianą na PC klienta. Większość środowisk programistycznych do opracowania wieloplatformowych aplikacji z baz danych daje takie same aplikacje na obsługiwanych platformach na podstawie kodu z jednej platformy.

Konwersacja między platformami

Dobrze dobrany zestaw funkcji API (Application Programming Interface) ułatwia pisanie aplikacji posługujących się danymi z różnych platform. Ukrywają one przed programistą skomplikowane szczegóły związane z protokołami sieciowymi i różnymi formatami danych na różnych platformach. W wypadku używania PC jako stacji roboczej użytkownika takim standardem dostępu do baz danych staje się zestaw funkcji API ODBC i związanych z nimi sterowników do różnych baz.

Ta część oprogramowania, stanowiąca warstwę pośrednią między systemem zarządzania bazami danych a aplikacjami nosi nazwę middleware i jest najszybciej rozwijającą się dziedziną oprogramowania w niejednorodnym świecie komputerowym.

Szkolenie użytkowników

Bez współpracy użytkowników nawet najlepszy system jest bezużyteczny. Jeżeli użytkownicy nie rozumieją celu działań, nie uda się osiągnąć zamierzonych efektów. Informacja że program XXX pozwala na dostęp do aplikacji i programów Unixa z PC nie daje żadnych korzyści, jeżeli użytkownicy nie znają Unixa i nie potrafią się nim posługiwać.