RegułyChaosu

Wartość architekta

W ramach przygotowań do OSAKA 2016 podjąłem dyskusję o wartości architektury korporacyjnej. Kolega po fachu poddał ciekawą myśl, że EA powstało w czasach, kiedy strategia IT była wyznaczana na 5 lat lub więcej, a współcześnie jakoś nie sposób tak daleko „strategować”, przez co EA jakby traci na sensowności. Czy aby na pewno?

Już w samej tej myśli tkwi problem. Skrócenie czasu tworzenia strategii (biznesowej, marketingowej, produktowej, czy IT – bez znaczenia) wynika z charakteru współczesnego biznesu. W większości branż w dzisiejszych realiach nie sposób odpowiedzialnie przewidywać przyszłości w dłuższym horyzoncie. Nie zmienia to jednak faktu, że IT musi być traktowane jak inwestycja – musi się zwracać. Poza bardzo wyjątkowymi sytuacjami jednak trudno wynajdywać projekty informatyczne o istotnej wartości biznesowej, które zwracałyby się w okresie krótszym, niż dwa lata. Albo więc traktujemy IT jako koszt „zła koniecznego”, albo próbujemy sięgnąć poza horyzont zdarzeń strategii, bo tam należy szukać zwrotu z inwestycji. Od pewnego już czasu uznaję sformułowania „robimy architekturę tak, bo tak jest w strategii” za równoważne „a po nas choćby potop”. Wartość architekta objawia się zdolnością do sięgnięcia poza horyzont strategii IT – zaczepionej zwykle „na sztywno” w strategii biznesowej – i przygotowania architektury na możliwe „strategiczne wiraże”. Posiadanie takiej zdolności odróżnia mistrzów architektury korporacyjnej od architektów-rzemieślników.

Podobnie rzecz się ma w sferze architektury rozwiązania. Zbyt wiele już razy oglądałem sytuacje, w których architekt rozwiązania zachowywał się jak projektant. Zamiast doszukiwać się wymiarów elastyczności i zdolności sprostania przyszłym wyzwaniom spoczywał na laurach spełniania wymagań. Zamiast dociekać usztywnień w rozwiązaniu, projektował interfejsy. Zamiast syntezować, analizował… Działalność każdego architekta wymaga wyjścia poza ramy wymagań i zrozumienia wyzwań, który będzie musiała sprostać architektura „później”. Im lepszy architekt, tym łatwiejsze sprostanie wyzwaniom nieznanym na etapie tworzenia architektury. To dostaje się w genach i doskonali latami doświadczeń. To jest sposób myślenia o rozwiązaniu. Specjalista przygotowujący rozwiązanie pod wymagania to projektant i nie powinien się nazywać architektem.

Ostatnio dużo „robię w danych”, więc nasunął mi się także przykład z tego podwórka. Jest takie bardzo znaczące powiedzenie: systemy informatyczne się zmieniają, ale dane pozostają. Proste, ale niezwykle trafne. Na prostym przykładnie, reguły legislacji wymagają, aby dane o operacjach finansowych były przechowywane przez okres kilku lat – dla jednych rodzajów danych to 5 lat, a dla innych może być nawet 20. Bez względu na to, ile generacji systemów ERP firma wymieni w takim czasie, ciągłość danych musi być zachowana. Każde rozwiązanie musi więc powstawać z myślą o jego podmianie, a ważne dane tego systemu muszą być tak „zaprojektowane”, aby służyć po wyłączeniu systemu. Dokładnie tak, po wyłączeniu. Znów objawia się konieczność działania architektonicznego, a nie projektanckiego. Proste, prawda?

W mojej ocenie wartość architektury korporacyjnej powinna, obiektywnie, wzrastać. Nie wzrasta, ale nie z powodu filozofii architektury korporacyjnej, lecz z powodu podejścia architektów, którzy na wizytówkach mają „korporacyjny”. Większość z takich specjalistów, jakich spotkałem na profesjonalnej drodze, po prostu błędnie pojmuje swoją rolę. W efekcie zaiste sprowadzają swoją pracę do oderwania od biznesu, technologii i rzeczywistości w ogóle. Szanowni Architekci Korporacyjni w Wieżach, nie tędy droga – jeśli nie umiecie inaczej, nie psujcie chociaż bardzo już nadwątlonej wiary w architekturę korporacyjną, proszę.