Jakiś czas temu podczas panelu na jednej z konferencji w której miałem przyjemność uczestniczyć, otrzymałem prośbę o zdefiniowanie największych wyzwań dla zespołów IT w najbliższym czasie. W pierwszych sekundach po pytaniu rodzą się odpowiedzi oczywiste, kreowane przez kilka ostatnich miesięcy w branży IT – generatywna sztuczna inteligencja, bezpieczeństwo, nowe regulacje, etc.
Wyzwaniem dziś nie jest jednak technologia, czy nowe funkcjonalności ustalone przez prawo, a możliwość i szybkość ich adopcji, a to już problem bardziej złożony. Niemniej jednak jednym z wyzwań z którym przyjdzie nam się zmierzyć w nadchodzącym czasie jest wdrożenia pojęcia „tymczasowej architektury IT” jako permanentnego modelu budowania usług biznesowych.
Jak architektura IT wyglądała w przeszłości?
Aby szerzej rozwinąć wyżej zdefiniowane wyzwanie musimy cofnąć się dobre kilka lat i przypomnieć sobie ówczesny sferę technologii i organizacji świata IT. Świat ten był raczej dość przewidywalny i poukładany. Co za tym idzie zmiany, które mogły w jakiś sposób wpływać w architekturę i sposób naszej pracy były rzadkie.
Stosunkowo łatwo było definiować standardy architektoniczne, a jej skalowalność odbywała się raczej wertykalnie niż horyzontalnie. Posiadaliśmy organizację wyspecjalizowaną w obszarach technologii, którą się opiekowała i rozwijała. Z perspektywy czasu mam wrażenie, że głównym zadaniem zespołów IT było dostarczenie jednolitej infrastruktury, instalacja standardowych komponentów aplikacyjnych ich kastomizacja i utrzymanie.
Kiedyś technologia była przygotowana, zunifikowana, a jej stabilność dostarczała zakres końcowego rozwiązania. Dzisiaj, paradoksalnie jest na odwrót. To ostateczne rozwiązanie, czasem wybrane pośrednio przez odbiorcę końcowego, wymusza zmianę architektury IT. Od zespołów IT zależy zaś to, jak szybko – i czy w ogóle – są wstanie dostosować się do dynamicznego otoczenia.
W przypadku potrzeb rozwoju plan ten był zazwyczaj analogiczny. Wyciągaliśmy z szafy dość oklepany plan, prosty model architektury, składający się z kilku elementów, skupiony wokół znanych nam technologii, robiliśmy szacunki – zazwyczaj z buforem – aby za szybko nie martwić się potrzebą skalowania (wertykalnego) i dokładaliśmy kolejne elementy do grupy, którą z czcią pielęgnowaliśmy. Było to synonimem jakości naszej pracy. Sam produkt wytwarzany przez zespoły IT był bardziej technologiczny niż biznesowy. Nie miał zewnętrznego bodźca zmian. Pozwoliło to mu długo rosnąć w niezmienionym modelu.
Jakie czynniki wpłynęły na działy IT?
Co więc się zmieniło, że chcemy o tym teraz dyskutować w kontekście wyzwania nadchodzących czasów? Chyba wszystko. Świat przyśpieszył i to mocno. Przestał być przewidywalny i jednoznaczny, zaczął być złożony i zmienny (VUCA). Do tego stopnia, że trzeba było zaktualizować przykłady definicji czarnego łabędzia.
Zmiana zaczęła gonić zmianę, przyśpieszyliśmy mocno wyścig, niezależnie od branży, ze świata analogowego do cyfrowego. W tym drugim to usługi biznesowe stanowią podstawę naszej działalności. Zaczęliśmy być pierwszym odbiorcą bodźca tych zmian. Trzeba było więcej, szybciej i wszędzie.
Zatarła się granica między światem technologicznym a biznesowy. Dostarczamy więcej w ramach dobrze znanych nam standardów, rozbudowaliśmy, skalowaliśmy. Robimy to, co robiliśmy wcześniej tylko trochę częściej. Część z nas zaczęła już bardziej oficjalnie odpowiadać za rozwój produktów biznesowych. Stanęliśmy na froncie walki, w którym to nie najlepsza technologia, sama w sobie dostarcza wartość końcowemu odbiorcy a zaimplementowana przez nią usługa biznesowa.
Dynamiczna architektura produktu cyfrowego
Pomimo, że po prawdzie zawsze tak było, to ten element architektury produktu cyfrowego nie miał dawniej takiego znaczenia. Technologia była przygotowana, zunifikowana, a jej stabilność dostarczała zakres końcowego rozwiązania. Dzisiaj, paradoksalnie jest na odwrót.To ostateczne rozwiązanie, czasem wybrane pośrednio przez odbiorcę końcowego, wymusza zmianę architektury IT. Od zespołów IT zależy zaś to, jak szybko – i czy w ogóle – są wstanie dostosować się do dynamicznego otoczenia.
Tymczasowa architektura to zestaw rozwiązań: technologicznych, infrastrukturalnych i organizacyjnych, wyspecjalizowanych i powołanych do realizacji określonej funkcji biznesowej, w określonym czasie. Tymczasowości nie określa długości czasu jej trwania. Stałość jej formy jest zależna tylko wyłącznie od jej efektywności dla konkretnego przypadku użycia.
Model architektury, który jest nam znany od lat, który rozwijamy i w którym mamy największe doświadczenie może nie być wystarczający w dostarczaniu najlepszych usług cyfrowych. Duże, opasłe architektury rozwijane przez ostatnie lata i dostosowane do niej organizacje – którym do tej pory poświęcaliśmy czas oraz pieniądze na ich rozwój i utrzymanie – mogą stać się blokerem dalszego rozwoju.
Stało się to, co miało nigdy nie nadejść. Zbudowaliśmy domy na wieki, z których trzeba nam się wyprowadzić i czas uświadomić sobie, że nie po raz ostatni.
Czym więc jest tymczasowa architektura?
To nic innego jak zestaw tymczasowych rozwiązań: technologicznych, infrastrukturalnych i organizacyjnych, wyspecjalizowanych i powołanych do realizacji określonej funkcjibiznesowej, w określonym czasie. Tymczasowości nie określa długości czasu jej trwania.Stałość jej formy jest zależna tylko wyłącznie od jej efektywności dla konkretnego przypadku użycia. Po co to robić?
1. Aby dostarczać i skalować – W szczególności w usługach w których krytyczną rolę odgrywa Time to Market. Jeśli ceną dostarczenia nowej usługi biznesowej jest zmiana architektury, czy organizacji, tymczasowa architektura będzie podatna na taką operację. Nie czekamy, nie przebudowujemy starego modelu. Zamykamy jeden model, aby w jego miejsce powołać drugi – lepiej przystosowany.
2. Aby móc przeciwdziałać niedostępnością usług biznesowych – Ot taki paradoks.Tymczasowa architektura jest bardziej elastyczna w projektowaniu wysoko dostępnych usług biznesowych. Dlaczego? Istotną rolę odgrywa zmiana paradygmatu, który polega na priorytecie utrzymaniu usługi biznesowej, a nie infrastruktury. Redundancja z góry powinna zakładać błędy i awarie, a co za tym idzie pełną tymczasowość wspierającej ją infrastruktury, którą nie tak dawno pielęgnowaliśmy.
3. Aby móc prototypować i wdrażać żywe doświadczenie organizacji przez faktyczną pracę (szybko i relatywnie tanio) – Powoływanie tego typu przedsięwzięć nie powinno pociągać za sobą nakładów inwestycyjnych związanych z rozbudową infrastruktury czy zakupu licencji, oraz narzutu operacyjnego związanego z instalacją czy wytworzeniem funkcjonalności. Budujmy, testujemy, kasujmy – powtarzajmy.
Dziś zatarła się granica między światem technologicznym a biznesowy. Robimy to, co robiliśmy wcześniej tylko trochę częściej. Część z nas zaczęła już bardziej oficjalnie odpowiadać za rozwój produktów biznesowych. Stanęliśmy na froncie walki, w którym to nie najlepsza technologia, sama w sobie dostarcza wartość końcowemu odbiorcy a zaimplementowana przez nią usługa biznesowa.
Co będzie wyzwaniem w tworzeniu tymczasowej architektury?
- Złożoność – To już nie zunifikowany monolit, który był kiedyś odpowiedzią na większość potrzeb biznesu. To dziesiątki, setki lekkich usług, interdyscyplinarne zespołu produktowe, które – powiązane ze sobą – odpowiadają za dostarczanie funkcjonalności biznesowych.
- Kompetencje i zmiana sposobu myślenia – Będziemy musieli nauczyć się porzucać nasze przyzwyczajenia i przywiązanie do raz utworzonych schematów – zarówno technologicznych, jak i organizacyjnych.
- Zarządzanie i bezpieczeństwo – Świat ten może wyglądać jak namiastka chaosu. Ale jak każdy chaos da się okiełznać. Nie twórzmy procedur i sztywnych ram. Strategia i pryncypia powinny wystarczyć.
Co trzeba zrobić jutro?
Na pewno nie rozpoczynać rewolucji. Niemniej jednak warto rozpocząć przygodę i zacząć testować modele tymczasowej architektury. Zarówno z punktu widzenia technologii, jak i organizacji. Nie ma znaczenia czy zaczniemy budować pierwsze mikroserwisy, postawimy na usługi serverless czy powołamy pierwsze zespoły DevOps.
To co pamiętać musimy to fakt, że prędzej czy później będziemy musieli się z tym pożegnać, a koszt tego pożegnania musi być znikomy i nie może wpłynąć na działanie dostarczanych usług biznesowych. Im szybciej i sprawniej, tym łatwiej przyjdzie nam adopcja nowych usług biznesowych a koszt przejścia z obecnego modelu będzie niższy.
Maciej Dzięcielak, Chief IT Architect, Veolia
