Jakiś czas temu popełniłem wpis o natłoku rozwiązań stawiających sobie za cel czynienie naszego życia prostszym (Kiedy dużo to już za dużo? Platformy, aplikacje i inne cuda). Mnogość rozwiązań i planów taryfowych przypomina mi wybór operatora komórkowego sprzed jeszcze kilku czy kilkunastu lat, zanim usługi nie stały się tak tanie, że nie ma to większego znaczenia.

Z technicznego punktu widzenia większość rozwiązań platformowych bazuje na tym samym mechanizmie. Ogromna baza danych w chmurze i interfejs użytkownika w postaci aplikacji mobilnej, przeglądarkowej. Interfejs umożliwia użytkownikowi korzystanie i manipulowanie zasobami bazy danych w ramach posiadanych dostępów i funkcjonalności aplikacji. Baza danych to w gruncie rzeczy ogromna tabela (tabele) , które w kolejnych wierszach zawierają ustrukturyzowaną informację. Aby aplikacja wyświetliła konkretną wartość z komórki bazy danych musi podać (lub w jakiś sposób odfiltrować) identyfikator kolumny i numer wiersza. Tyle teorii.

Zatem tym co odróżnia konkretne rozwiązania to strona użytkowa, bezpieczeństwo, wprowadzone procesy itd. Jednak na koniec dnia to podobne dane. Czy aplikacja dostawcy A może sięgać do bazy producenta B? Jeśli zna strukturę bazy i wie jak się w niej odnaleźć to tak. Wiele osób na pewno się spotkało z możliwościami importu dokumentów z drop boxa, one drive czy innych usług bezpośrednio do jakiegoś oprogramowania czy usługi. To jest właśnie przykład na tego typu sytuację. Żeby to było możliwe, jeden usługodawca musiał zmapować nagłówki kolumn drugiego w swoim systemie. Czy nie byłoby prościej gdyby wszyscy używali tych samych nazw do nazywania tych samych rzeczy? W przypadku BIM częściowym rozwiązaniem systemu jest format IFC, który w uproszczeniu standaryzuje nazewnictwo i strukturę poszczególnych elementów bazy danych jaką jest model. Dzięki temu przeglądarki plików IFC, niezależnie od producenta oprogramowania, w którym model został stworzony, potrafią ten model nam zinterpretować i wyświetlić. Co to ma do digitalizacji? Otóż zakres danych w branży wykracza daleko poza budynek i jego części. Chcąc operować danymi musimy je jakoś skategoryzować.. Pół biedy gdy budujemy lokalne rozwiązanie w ramach działu, czy firmy, gdzie w miarę łatwo jest się dogadać „co jest co”. Gorzej jeśli nasze rozwiązanie ma służyć wielu użytkownikom, lub jest wręcz rozwiązaniem komercyjnym, służącym na przykład zarządzaniu zdjęciami usterek (w uproszczeniu). Tego typu aplikacji jest na rynku sporo. Każda wyjątkowa i najlepsza w swoim rodzaju, a do tego na każdym projekcie inna…. Jeśli jesteśmy podwykonawcą, konsultantem czy innym podmiotem mającym mały wpływ na wybór tego rodzaju platformy to musimy się dostosować. Czy nie lepszym rozwiązaniem byłoby gdyby wszystkie aplikacje tego typu porozumiewałyby się między sobą? I mając wdrożone rozwiązanie firmy X mógłbym podpiąć się pod projekt założony w aplikacji firmy Y? Oczywiście każda z nich konkurując dostarcza nico inne funkcjonalności, ale pewne minimum jest z reguły wspólne, ponieważ na koniec dnia proces budowlany jest jeden. Na dziś wielu dostawców technologii udostępnia tzw. Application Programming Interface, który umożliwia podłączanie się do ich baz danych. Problemem jest jednak mapowanie terminologii pomiędzy dostawcami oprogramowania. Jednak uwspólnianie nazw kategorii danych pozwalałoby na korzystanie z danych po całkiem niskich kosztach. To w końcu temu służy standaryzacja.

Tu chcę wskazać na inicjatywę podjętą przez RICS, nazywaną RICS Data Standard, która stawia sobie za cel unifikację nazewnictwa szeregu standardów RICS i międzynarodowych obejmujących pomiary nieruchomości, wycenę, należytą staranność, rachunek kosztów cyklu życia, pośrednictwo, leasing i pomiary budowlane.

Poza możliwością wymiany ujednoliconych danych między różnymi aplikacjami zyskujemy zupełnie nowe możliwości ich analizy w celu podejmowania decyzji biznesowych bez konieczności ponoszenia kosztów unifikacji przed analizą. Czy ta utopia ma szansę zaistnieć? Producenci już dziś udostępniają dane swoich rozwiązań umożliwiając tworzeni na ich bazie aplikacji samym użytkownikom. Standaryzacja na miarę IFC i RICS Data Standard jest kluczem do masowej digitalizacji procesów nieograniczonej mnogością rozwiązań na rynku. Jeśli osoby digitalizujące proces lokalny w ramach narzędzi pakietu biurowego M365 zastosują uniwersalną standardową konwencję to rozbudowa takiego systemu, to współpraca z innymi podmiotami, nawet w postaci wymiany plików Excel będzie dużo prostsza.

Natomiast obniżone koszty tworzenia aplikacji operujących wystandaryzowanymi danymi mogą stanowić prawdziwe pole do konkurencji na funkcjonalności i wartość dostarczaną użytkownikom, a nie na ograniczanie im swobody wyboru, bo skoro już wdrożyli jakieś rozwiązanie to są do niego przywiązani choćby ze względu na zgromadzone w nim dane.

Okazuje się, że jest to kierunek myślenia i wdrożeń promowany na świecie. Inicjatywa openCDE uruchomiona przez buildingSMART wpisuje się w ten koloryt. Żeby było śmieszniej, inicjatywa ta jest sponsorowana przez największych dostawców softu. Już słyszę teorie spiskowe, że są tam, żeby blokować i kontrolować, żeby za szybko się nie rozwinęło. Z drugiej strony programiści open source muszą z czegoś żyć. Zatem, lepiej być optymistą.

Żeby było ciekawiej niedawno do naszej społeczności Discord-owej dołączył Grzegorz, twórca bloga Let’s construct IT!. Grzegorz w jednym z postów na swoim blogu wskazuje na całkiem rewolucyjne podejście do wykorzystania GitHub-a jako środowiska CDE dla modelu, a Bartek (nieco starszy uczestnik naszych rozmów) podrzucił dyskusję o praktycznym wykorzystaniu tej platformy do kolaboracji przy tworzeniu modeli.

Jeden, by wszystkimi rządzić, Jeden, by wszystkie odnaleźć, Jeden, by wszystkie zgromadzić i w ciemności związać.

Co zatem począć? Digitalizować, czy czekać, aż branża dojdzie do jakiegoś konsensusu nazewniczego? Wydaje mi się, że czekanie to strata czasu. Warto poszerzać wiedzę i eksperymentować na taką skalę na jaką nas stać. Ważne, żeby tworzone przez nas bazy danych osadzać w jakimś kontekście. Na przykład korzystać z nazewnictwa bazującego na IFC. Ułatwi to przyszłe integracje i wymianę informacji. Ponadto jeśli tego typu działanie oddolne zostanie podjęte przez jakiegoś producenta, to jest większa szansa na upowszechnienie jego pomysłu w branży czy sektorze. I w ten sposób małymi kroczkami dojdziemy do krainy wspólnego słownika pojęć opisujących wszystko czego potrzebujemy do przeprowadzenia sprawnego procesu inwestycyjnego.

Na sam koniec jeszcze jedna ciekawostka, którą znalazłem na GitHub. Jest to zestaw wielu różnych klasyfikacji elementów budynków takich jak Uniclass, Omniclass, NRM etc. w postaci pliku XML. Doskonały początek do budowy bazy danych.