RegułyChaosu

Od ponad dwóch dekad rozwiązuję zagadki ze świata informatyki praktycznej, sfery nazywanej w literaturze “Enterprise Information Systems”, posługując się warsztatem i narzędziami architekta. Wraz ze wzrostem doświadczenia rośnie we mnie przekonanie, że najważniejszą klasą narzędzi architekta są wzorce architektury, wszak po co za każdym razem na nowo wymyślać koło, skoro już wiemy, jak ma wyglądać? Z drugiej strony jednak stosowanie wzorców staje się coraz trudniejsze, wymaga coraz większego wysiłku, napotyka na coraz więcej przeszkód. Coś jest nie tak ze wzorcami? Problemy są tak specyficzne dla każdego przypadku? Myślę, że nie, a prawdziwa zagadka jest w nieco innym miejscu.

Wiele lat temu, kiedy miałem rozpocząć studia, uczestniczyłem w wykładzie inauguracyjnym w temacie paradoksów rozwoju technologii, szczególnie ujawniających się cyklicznością zachodzących zmian. Wykładowca utrzymywał, że proces rozwoju technologii nie jest procesem liniowym – meandruje, gdyż ludzie budują zrozumienie metodą prób i błędów. Wykładowca twierdził, że – jako ludzie – jesteśmy całkiem nieźli w próbkowaniu, jednak umyka nam systematycznie zrozumienie cechy tego procesu, która czyni go wrażliwym.

Jestem fanem zwinności – nie tylko w rozwoju oprogramowania, ale w zarządzaniu projektami, a przede wszystkim w architekturze rozwiązań informatycznych, na każdym poziomie. Rozumiem jednak także ograniczenia podejścia agile. Wdrażając podejście zwinne w nieprzygotowanym środowisku nie tylko dramatycznie obniża szanse na sukces, ale także deprecjonuje to podejście i na dłuższy czas tworzy konotację agile = porażka. Zanim więc wybierzesz podejście zwinne upewnij się, że środowisko działania ma szanse je przyjąć i wspierać. Jak to zrobić?

W ramach moich poszukiwań sfer stosowania technologii teleinformatycznych „przez chwilę” udzielałem się w środowisku Smart City. Dzieje się tam wiele bardzo, ale to bardzo ciekawych rzeczy. Jest to jednak obszar działań, który przeżywa „najazd” technologii.

Gdyby Straton z Sardes żył współcześnie, nie zaś prawe dwa tysiące lat temu, mógłby zmienić swój epigram. Rzecz o RPA (ang. Robotic Process Automation), najnowszym trzyliterowym skrócie, którym – jak chyba każdym nowym, trzyliterowym skrótem – zachwyca się część branży „informatycznej”, zachwytem napędzanym budżetami marketingowymi uznanych dostawców technologii. Fajna, nośna koncepcja, tylko to wykonanie…

Na dzisiaj mamy już ogólne pojęcie, czym jest privacy by design i czym może zaskoczyć, jednak – pragmatycznie – na czym powinniśmy się skupić, być świadomymi podczas prac projektowych, być wyczulonymi lub wręcz podejrzliwymi? Innymi słowy, jak odnaleźć te dane, które powinniśmy traktować ze szczególną pieczołowitością?

Miałem przyjemność uczestniczyć niedawno w Warsaw Alfresco Day, w czasie którego George Parapadakis snuł opowieści o przygotowaniach do RODO – na przykładach. Zaczął od „ankiety” wśród uczestników, na ile – w ich opinii – reprezentowane przez nich firmy są przygotowane i będą do 25 maja 2018 r. Moim zdaniem w tej ankiecie zabrakło jednego pytania: „Ile osób spośród państwa uważa, że absolutnie nikt nie będzie gotowy do RODO?” Mimo badań twierdzących inaczej, w odpowiedzi na takie pytanie ja podniósłbym rękę. Dlaczego tak uważam na przykładzie jednego z wymagań stawianych przez RODO / GDPR, Privacy by Design.

Zaznajomieni z tematem RODO / GDPR wiedzą, że jednym z wymogów formalnych wprowadzanych przez tę legislację jest obowiązek stosowania privacy by design i privacy by default. Legislacja nie określa jednak, czym są te terminy. Rzecz jasna, Internet oferuje wiele stron odnoszących się do tych terminów, ale na pytanie „to co mam konkretnie zrobić?” bezpośredniej odpowiedzi raczej brak. Ja potrzebowałem takich odpowiedzi. Jak więc podejść do privacy by design z perspektywy architektury?