Co powinno zostać po dobrym projekcie ontologicznym

Projekt ontologiczny ma jeden stan końcowy, który bardzo łatwo odebrać: diagram, słownik pojęć i dobrze uargumentowany dokument. Wygląda jak wynik, przechodzi przez komitet sterujący i pasuje do kryteriów odbioru.

Pół roku później nic z niego nie korzysta, definicje rozjechały się z rzeczywistością, a następny projekt zaczyna od początku — często z tym samym diagramem w załączniku.

Dlaczego dokument tak łatwo przechodzi odbiór

Kryteria odbioru pisze się zwykle jako listę produktów: model, słownik, dokumentacja. Każdy z nich da się sprawdzić, otwierając plik. Trudniej sprawdzić, czy coś działa na modelu i czy ktoś będzie go utrzymywał, więc tych kryteriów w umowie zwykle nie ma.

A to właśnie one rozstrzygają, czy ontologia żyje. Model, którego nic nie konsumuje, jest dokumentem — i psuje się jak dokument, po cichu i bez daty.

Co powinno zostać

Coś, co z modelu korzysta. Najważniejsze kryterium: wyszukiwanie, agent albo raport działa na modelu, zanim projekt się skończy. To jedyny dowód, że definicje przetrwały kontakt z prawdziwymi danymi.

Reguły tożsamości. Jak rozpoznać tego samego klienta w trzech systemach. To zwykle najtrudniejsza i najcenniejsza część; jeśli nie ma jej w odbiorze, dostaliście słownik, a nie ontologię.

Mapowania razem z lukami. Jak każdy system źródłowy odwzorowuje się na model, łącznie z miejscami, gdzie się nie da, i tym, co się gubi. Mapowanie bez ani jednej luki jest podejrzane.

Przenośna forma. Model zapisany w standardowej formie — dla ontologii są nią na przykład standardy W3C, RDF i OWL — a nie uwięziony w jednym produkcie. Magazyn danych to osobna decyzja inżynierska i może się jeszcze zmienić.

Nadzór. Właściciel każdej definicji i opisana ścieżka zgłaszania zmian. Bez tego model jest trafny przez jeden kwartał.

Infografika

Co zostaje po dobrym projekcie ontologicznym

1. 01Coś, co korzystaWyszukiwanie, agent albo raport działający na modelu w ciągu tygodni.
2. 02NadzórWłaściciel każdej definicji i ścieżka zgłaszania zmian.
3. 03Mapowania i lukiJak każdy system odwzorowuje się na model i co się gubi.
4. 04Wdrożony modelEncje, relacje, ograniczenia i reguły tożsamości w przenośnej formie.
5. 05Uzgodnione definicjePojęcia, na których stoi firma, ze sporami rozstrzygniętymi, a nie uśrednionymi.

Sygnały ostrzegawcze w ofercie

Zakres „całe przedsiębiorstwo”. Kompletna ontologia przedsiębiorstwa zajmuje lata i zwykle nigdy się nie kończy. Oferta, która ją obiecuje, sprzedaje dobrze znany tryb porażki.

Narzędzie przed modelem. Jeśli pierwszą pozycją jest zakup bazy grafowej albo platformy, decyzja inżynierska zapadła przed zrozumieniem problemu. Wiele ontologii dobrze obsługuje baza relacyjna z warstwą semantyczną.

Brak przypadku użycia. Bez jednego albo dwóch konkretnych zastosowań nie wiadomo, które pojęcia modelować, więc modeluje się wszystkie.

Nikt po Waszej stronie nie jest wskazany. Oferta, która nie pyta, kto będzie rozstrzygał spory i kto będzie właścicielem definicji, zakłada, że dostawca zrobi jedno i drugie. Nie zrobi.

Odbiór na podstawie dokumentu. Jeśli kryterium odbioru to zaakceptowany diagram, dokładnie to dostaniecie. Kryteria odbioru pisze się na początku projektu, a nie na końcu — wtedy jeszcze da się je zmienić bez renegocjacji.

Co zostaje po Waszej stronie

Dobry projekt ontologiczny nie kończy się zależnością od dostawcy, ale nie kończy się też bez pracy po Waszej stronie. Warto wiedzieć z góry, jakiej.

Wnioski o zmianę. Firma się zmienia: nowa linia produktów, przejęcie, nowy kanał sprzedaży. Każda taka zmiana dotyka definicji, a właściciel definicji musi mieć czas, żeby wniosek rozpatrzyć, zanim systemy zaczną się rozjeżdżać.

Nowe systemy. Każdy wdrażany system powinien zostać zmapowany na model, zanim zacznie produkować dane. To znacznie tańsze niż mapowanie go po roku, gdy jego konwencje zdążą się rozpowszechnić.

Przegląd luk. Co jakiś czas warto wrócić do listy rzeczy, które gubią się przy mapowaniu, i sprawdzić, czy któraś nie zaczęła kosztować.

To niewielki wysiłek, ale musi być czyimś zadaniem. Model bez opiekuna wraca do stanu dokumentu w ciągu kilku kwartałów.

Pytanie kontrolne przy odbiorze

Poproście o dwie rzeczy. Pokażcie, jak system rozpoznaje, że te dwa rekordy z różnych systemów to ten sam klient. I powiedzcie, kto zmieni tę regułę, jeśli okaże się błędna.

Jeśli obie odpowiedzi padają szybko i konkretnie — z działającym przykładem i nazwiskiem — projekt zostawił coś żywego. Jeśli pierwsza wymaga otwarcia dokumentu, a druga zwołania spotkania, dostaliście opis.

Użyteczny rdzeń modelu dla jednego albo dwóch przypadków użycia to w projektowaniu i inżynierii ontologii zwykle cztery do ośmiu tygodni razem z wdrożeniem — i kończy się czymś, co z modelu już korzysta, a nie samym modelem.