Słaby plan modernizacji traktuje kontrolę dostępu jak zestaw ekranów CRUD. Dodaj posiadacza, edytuj kartę, przypisz czytnik, eksportuj raport. Tak nie zachowuje się ryzyko operacyjne.
W WebKD decyzje dostępowe łączą osoby, karty, urządzenia, grupy, harmonogramy, zdarzenia, raporty i uprawnienia operatorów. Zmiana jednego pojęcia może dotknąć efektywnego dostępu, reloadów czytników, raportów obecności i widoczności operatora przy analizie zdarzenia.
Dlatego CloudFloo zaczyna od modelu domeny. Posiadacze PKD, karty KAD, czytniki i kontrolery TKD, serwery RCP, struktury GLC, grupy, harmonogramy, sekwencje, zdarzenia i raporty muszą mieć nazwy, zanim można je bezpiecznie zmieniać.
Model rozdziela też uprawnienia funkcjonalne i data permissions. Operator może mieć dostęp do funkcji, ale być ograniczony do konkretnych posiadaczy, urządzeń, grup lub zakresów organizacyjnych.
To rozdzielenie ma znaczenie dla UX. Ekran, który chowa domenę za generycznymi etykietami, zmusza operatorów do pamiętania niewidzialnych reguł. Ekran zgodny z domeną pomaga rozumieć, dlaczego uprawnienie istnieje i co zmiana może naruszyć.
Dla engineeringu ten sam model staje się strategią testów. Przeliczanie uprawnień, flow zdarzeń, raporty i aktualizacje czytników można testować wokół zachowania domeny, a nie tylko wokół endpointów.
Lekcja SEO też jest praktyczna: poważny opis projektu powinien nazywać domenę. "Modernizacja platformy enterprise" jest słabe. "Uprawnienia kontroli dostępu przez PKD, KAD, TKD, RCP, grupy, harmonogramy i raporty" mówi właściwemu kupującemu, że rozumiesz jego świat.