Trendy

Architektura IT w burzliwych czasach

W ostatnich latach warunki prowadzenia biznesu i ich zmienność przyśpieszyły na skalę dotąd chyba nie spotykaną. Wynika to z kilku czynników, takich jak:

• nieliniowy, wciąż szybszy wzrost możliwości technologii IT,
• duża zmienność warunków ekonomicznych, w których działa biznes,
• globalizacja i związany z nią dramatyczny wzrost konkurencyjności,
• komunikacja „każdego z każdym” oraz wszechobecność informacji w sieci.

Dodatkowo, w obrębie tych czynników zachodzą jednoczesne zmiany. Dlatego czasem mówimy, że żyjemy w „burzliwych” czasach. „Burzliwy” oznacza, że zmiany są nieprzewidywalne, nabierają charakteru nieomal chaotycznego, a jedyną skuteczną strategią przetrwania staje się strategia ciągłej zmiany.

W takich warunkach przedsiębiorstwo musi posiadać architekturę IT zapewniającą jednocześnie stabilność i elastyczność oraz możliwość rozwoju. Innymi słowy, architekturę wspierającą strategię ciągłej zmiany. W poszukiwaniu odpowiedniego rozwiązania z pomocą może przyjść Architektura Referencyjna.

Jednym z przykładów takiej architektury dla sektora finansowego jest BIAN. Nie jest to platforma technologiczna, lecz raczej architektura wzorcowa, złożona z komponentów realizujących usługi. Na poziomie technicznym jej rozwinięciem jest koncepcja SOA (ang. Service Oriented Architecture). Od strony biznesowej umożliwia ona realizację wizji, w której przedsiębiorstwo poszukuje nowych szans rynkowych w partnerstwach, przejęciach, joint venture, współpracy, integracji i kontaktach z innymi firmami, rekonfigurując swobodnie swoje procesy biznesowe. Wkraczamy w świat portfela przedsięwzięć opartych o małe, zwinne jednostki, szybko wykorzystujące nadarzające się okazje rynkowe.

Stabilne i elastyczne rozwiązanie IT na „burzliwe” lata

Jak opracować architekturę przyszłego rozwiązania, aby była stabilna przez wiele lat, a jednocześnie zapewniała elastyczność i możliwość rozwoju dokonywanego własnymi siłami firmy (w nurcie „nieograniczonej integracji”, inaczej „seamless integration”) oraz w oparciu o partnerów biznesowych i zawarte z nimi alianse taktyczne lub partnerstwo strategiczne? Bezproblemowa integracja opisuje sytuację, w której nowa funkcjonalność aplikacji lub sprzętu, a także zmiany w systemie, obywają się bez negatywnych konsekwencji. Jak wspominałem, możliwość nieograniczonej rozbudowy systemu staje się krytycznie istotna w warunkach obecnej zmienności warunków prowadzenia biznesu.

Warto sobie odpowiedzieć na następujące podstawowe pytania:

• Jak zaplanować architekturę IT w warunkach szybko zmieniających się oczekiwań i potrzeb?
• Jak skutecznie odpowiadać na wyzwania ze strony otoczenia rynkowego?
• Jak jednocześnie obniżać całkowity koszt posiadania platformy technicznej, na której pracują rozwiązania IT?

Odpowiedź na ostatnie pytanie jest stosunkowo prosta – standaryzacja platformy technologicznej zwykle obniża koszty. Skoncentrujmy się zatem na pytaniu podstawowym: jak opracować architekturę rozwiązania odpowiednią dla „burzliwych czasów”?

Architektura IT jako drogowskaz rozwoju firmy

Jeszcze niedawno wystarczyło opracować dobry produkt, np. udany model samochodu lub komputera, aby przez wiele lat czerpać zyski z jego produkcji, tylko nieznacznie go udoskonalając. Dziś to przestało wystarczać. Przykłady Volkswagena czy Apple pokazują, że do uzyskania przewagi potrzebna jest wspólna platforma dla całej gamy modeli lub rozwiązań.

Podobną analogią można się posłużyć w obszarze Architektur Korporacyjnych. Truizmem jest stwierdzenie, że współczesna firma nie może istnieć bez systemów IT wspierających jej rozwój. Stworzenie trwałych podstaw wzrostu firmy wymaga zatem opracowania koncepcji architektury IT nie tylko skutecznie wspierającej przyjęty model wzrostu, ale także modyfikowalnej i możliwej do integracji z rozwiązaniami, z których korzystają najważniejsi partnerzy biznesowi lub główni klienci, oraz umożliwiającej wydzielenie i outsourcing części usług świadczonych przez firmę do jej partnerów biznesowych.

Takie koncepcje są wyrażone w formie Architektury Korporacyjnej, która jest spójnym połączeniem strategii rozwoju, architektury biznesowej oraz technologii IT, pracujących razem w celu osiągnięcia maksymalnych korzyści. W najbardziej ogólnej formie, Architektura w formie Diagramu Podstawowego pokazuje, jak biznes i technologia współpracują ze sobą. Przypominam, że słowo „korporacyjna” nie rezerwuje tego typu koncepcji dla wielkich organizacji. Mniejsze firmy mogą bardziej potrzebować koncepcji swojej architektury IT, ponieważ zwykle nie mogą sobie pozwolić na błędy. Różnice w wielkości organizacji odzwierciedlone są w zakresie prac i w kosztach, jakie przedsiębiorstwo może ponieść w związku z opracowaniem Architektury Korporacyjnej.

Modularna Architektura IT dla wykorzystania szans rynkowych

Jakimi cechami powinna się charakteryzować Architektura Korporacyjna, aby mogła stanowić drogowskaz rozwoju firmy? Zaryzykowałbym tezę, że we współczesnym biznesie nie wystarcza już likwidacja „silosów biznesowych”, które skutkują rozwiązaniami ograniczonymi do jednego działu lub obszaru produktowego. Nie wystarcza także ujednolicenie technologii w firmie. Potrzebny jest poziom zaawansowania architektury określany przez badaczy z MIT, J.Ross i J.Weill, jako „modularność biznesu”. Co to oznacza?

Architektura „modularna” charakteryzuje się przede wszystkim jak najszerszym wykorzystaniem komponentów oprogramowania „wielokrotnego użytku”, tzn. takich, które można łatwo rekonfigurować w nowe procesy biznesowe. Komponenty powinny posiadać dobrze określone funkcje oraz zestandaryzowane interfejsy. Umożliwia to szybkie i sprawne wykorzystywanie szans rynkowych czy strategicznych okazji zgodnych z wizją rozwoju firmy. Nie należy jednak tracić z oczu zasadniczych korzyści związanych ze standaryzacją procesów, które leżą u podstaw osiągania doskonałości operacyjnej, a co za tym idzie przewagi kosztowej.

Nowe komponenty powinny powstawać w ramach ogólnego planu i rozwijać go, a nie burzyć. Jako przykład z bliskiej mi branży usług finansowych mógłbym podać uniwersalny komponent wyliczania odsetek dla szerokiej gamy produktów kredytowych lub szybkiej oceny zdolności kredytowej klienta. Nie ma zatem znaczenia, czy wprowadzamy na rynek nowy produkt kredytu konsumenckiego, czy innowacyjną kartę kredytową łączącą w sobie cechy kilku produktów jednocześnie – odpowiedni algorytm jest gotowy i czeka na użycie w projektowanym procesie.

Mało tego, jeśli dział IT w firmie zapewni łatwą integrację pomiędzy komponentami procesu biznesowego, nic nie stoi na przeszkodzie, by ocenę ryzyka klienta zlecić usługodawcy zewnętrznemu, jeśli ten może zrobić to sprawniej od własnego działu. Wyobraźmy sobie, jaką zwinność i sprawność działania osiągnęłaby organizacja posiadająca architekturę korporacyjną o takich cechach, niezależnie od tego, czy mówimy o instytucji z branży finansowej, motoryzacyjnej czy sektora publicznego? Kusząca wizja, prawda?

Niełatwo taką koncepcję opracować i bardzo niewiele firm posiada Architekturę Korporacyjną o wymienionych cechach. Tym bardziej, że w „burzliwych czasach”, nowe rozwiązania powinny powstać szybko i sprawnie. Jak to zrobić? Z pomocą może przyjść Architektura Referencyjna.

Co to jest Architektura Referencyjna?

Architektura Referencyjna to pewne wzorcowe podejście do problemu. Można ją rozważać na wielu różnych poziomach szczegółowości. Na poziomie ogólnym może być ukazana jako zestaw wzajemnie powiązanych komponentów biznesowych, z których każdy dostarcza dobrze określony zestaw funkcji. Na niższym poziomie Architektura Referencyjna może prezentować szczegóły techniczne rozwiązania – specyfikacje interfejsów lub interakcje procedur w programie komputerowym.

Architektura Referencyjna dostarcza nie tylko wzorzec, lecz także inne wytyczne, jak: metodologię, zestaw dobrych praktyk, szablony i reguły stworzone w oparciu o zbiór skutecznych, udanych, wdrożonych wcześniej projektów. Przyspiesza to opracowanie rozwiązania poprzez ponowne wykorzystanie sprawdzonych w praktyce narzędzi oraz stanowi podstawę dla zapewnienia spójności i dobrego wykorzystania technologii w firmie.

Architektura Referencyjna jest szczególnie użyteczna na wczesnych etapach formułowania koncepcji i opracowywania architektury rozwiązania – wtedy, gdy dla modelu biznesowego lub wymagań wysokiego poziomu staramy się opracować początkowe rozwiązanie, które następnie wypełnimy detalami. Architektura Referencyjna może także służyć do oceny poprawności już istniejących rozwiązań, a następnie ich poprawy. Inna opcja to szybkie konstruowanie procesów dla nowego biznesu. Zastosowań jest wiele.

Nie oznacza to, że musimy kopiować pomysły innych. Nie trzeba jednak startować od zera. Nawet jeśli w naszym przypadku rozwiązania będą się różnić od tych referencyjnych, będą to odstępstwa świadome, oparte na analizie, a nie tylko na przeczuciu. Budujemy w ten sposób rozwiązania bardziej stabilne, gdyż oparte na doświadczeniach zebranych w praktyce. Co więcej, bazując na standardowych interfejsach pomiędzy usługami, możemy w łatwy sposób wydzielić komponenty naszego rozwiązania i zlecić ich obsługę lub realizację zewnętrznej firmie. W każdym z tych przypadków schemat architektury zostaje dokładnie ten sam.

Przykładem, który Państwu zaprezentuję, jest Architektura Referencyjna dla bankowości opracowana przez BIAN (ang. Banking Industry Architecture Network), organizację non-profit obejmującą ponad 40 banków, dostawców oprogramowania oraz dostawców usług dla sektora finansowego.

Architektura Referencyjna BIAN jest architekturą opartą na komponentach usługowych. Obejmuje ona 48 obszarów biznesowych i opisuje ponad 280 komponentów realizujących usługi biznesowe. BIAN dostarcza także opisy standardowych procesów świadczonych przez jednostki sektora finansowego. Standard jest technologicznie niezależny, tzn. każdy komponent może zostać zaimplementowany w dowolnej technologii.

BIAN jest tylko przykładem Architektury Referencyjnej. Dla innych domen biznesowych istnieją inne modele. Warto, by wyborem użytecznej Architektury Referencyjnej zajął się doświadczony Architekt Rozwiązania. W następnym kroku musimy określić drogę jej realizacji. W przypadku BIAN naturalnym rozwinięciem będzie architektura zorientowana na usługi.

Architektura zorientowana na usługi

BIAN od strony technicznej najpełniej wspiera koncepcja SOA (ang. Service Oriented Architecture) – architektura IT zorientowana na usługi. SOA ułatwia tworzenie elastycznych komponentów wielokrotnego użytku, umożliwiających budowę rozwiązań biznesowych typu end-to-end (tzn. obejmujących proces biznesowy w całości, od początku, do końca), a przez to zwiększenie elastyczności, zdolności adaptacji i, w rezultacie, ogólnej efektywności technologii informatycznej.

Firmy coraz częściej przyjmują zasady i techniki związane z SOA w różnego typów projektach, w wielu branżach na całym świecie. Czy zatem ta techniczna koncepcja jest również wspierana przez Architekturę Referencyjną? Okazuje się, że tak. Jednym ze standardów na poziomie technicznym jest Architektura Referencyjna SOA (SOA RA) publikowana i wspierana prze organizację The Open Group, będącą m.in. właścicielem metodologii TOGAF (ang. The Open Group Architecture Framework). Specyfikacja SOA RA zawiera wytyczne i opcje opracowywania architektury rozwiązania IT, projektowania i podejmowania decyzji podczas jego wdrażania.

SOA RA dostarcza także ogólny plan tworzenia i oceny architektury budowanej wokół modelu SOA. Dodatkowo, zapewnia też wzorce i bloki konstrukcyjne dla integrowania podstawowych elementów SOA do postaci kompletnego rozwiązania lub na potrzeby budowy i wdrażania Architektury Korporacyjnej.

Mniej formalnie, celem SOA RA jest udzielenie odpowiedzi na najczęściej zadawane pytania, takie jak:

• Jakie są aspekty, bloki i warstwy SOA, które trzeba wziąć pod uwagę przy projektowaniu rozwiązań lub tworzenia Architektury Korporacyjnej?
• Jakie są wytyczne do oceny architektury zorientowanej na usługi?
• Jakie są niektóre z kluczowych decyzji architektonicznych, które należy podjąć przy projektowaniu rozwiązania, które opiera się na zasadach architektury zorientowanej na usługi?
• W jaki sposób można zwiększyć szanse na uzyskanie korzyści z zastosowania SOA? Jak to wykorzystać w firmie podczas wędrówki na wyższe poziomy dojrzałości architektonicznej?

SOA pozwala biznesowi oraz IT na daleko idącą zbieżność interesów poprzez zawarcie kontraktu na dostawę uzgodnionych z biznesem zestawu usług – np. w przypadku sektora finansowego wynikających z modelu referencyjnego BIAN – które wspólnie obsługują procesy biznesowe organizacji oraz umożliwiają organizacji osiągnięcie celów biznesowych. W architekturze SOA nie jest już istotne, kto jest dostawcą usługi, ważne, żeby nie było zmian na poziomie interfejsu specyfikacji tego, jak usługa komunikuje się ze swoimi konsumentami.

Przyszłość: „dynamiczne przedsięwzięcie”

Naukowcy z MIT przewidują kolejny poziom rozwoju architektury – poziom „dynamicznego przedsięwzięcia”. Koncepcja dynamicznego przedsięwzięcia wykracza poza koncepcje modułów wielokrotnego użytku, które umożliwiają przedsiębiorstwu szybką i skuteczną rekonfigurację portfela prowadzonych przedsięwzięć. „Dynamiczne przedsięwzięcie” oparte jest na podstawowych procesach realizowanych w firmie, która będzie szukała nowych szans rynkowych w partnerstwach, przejęciach, joint venture, współpracy, integracji i kontaktach z innymi firmami.

Patrząc w skali makro, firma będzie starała się obsadzić każdą ważną pozycję w łańcuchu wartości możliwie najlepszym graczem, aby wykorzystać rysujące się okazje rynkowe. Strategie biznesowe mogą zatem koncentrować się na dynamicznych relacjach nawiązywanych pomiędzy różnymi przedsiębiorstwami.

Dzięki standardowym interfejsom oraz w miarę możliwości zestandaryzowanym usługom, komponenty dosłownie każdego przedsiębiorstwa będą mogły w dynamiczny sposób łączyć się z komponentami innego – oczywiście za zgodą i przy zachowaniu reguł bezpieczeństwa. Programy typu „inteligentny agent” pomogą w poszukiwaniu okazji rynkowych, przy negocjacjach ceny za usługę i automatycznym lub półautomatycznym zawieraniu transakcji zgodnie z wcześniej ustalonymi regułami. Pewnym przykładem takich rozwiązań są „web crawlers”, czyli oprogramowanie wyszukujące dane w sieci lub gromadzące dane z logów, stron internetowych oraz innych – dostępnych – źródeł informacji.

Budując solidną firmę oraz leżącą u jej podstaw stabilną i długofalową Architekturę Korporacyjną (zawierającą też model operacyjny firmy), myślmy zatem o dynamicznych połączeniach pomiędzy różnymi graczami na rynku. Jestem przekonany, że logicznym następstwem elastycznej i modularnej architektury wewnątrz firmy może być koncepcja portfela przedsiębiorstw, które w dynamiczny sposób będzie można łączyć ze sobą na zasadzie aliansów, w oparciu o specyficzne możliwości oferowane przez ich (poszczególne) komponenty.

Są Państwo zainteresowani zastosowaniem przedstawionych koncepcji w Państwa branży? Zapraszam do zadawania, pytań, komentowania, formułowania wątpliwości – słowem, do dyskusji.

Na co zwracać uwagę budując spójną, stabilną i elastyczną platformę IT w organizacji?

Na przykładzie branży finansowej i odpowiednich dla niej standardów BIAN i SOA wydaje się, że prawdziwe są poniższe wytyczne:

• Buduj wszystkie własne nowe rozwiązania w oparciu o koncepcje SOA.
• Biorąc pod uwagę wartość inwestycji w SOA, rozważ korzyści i koszty aktywnego członkostwa w społeczności BIAN, a zwłaszcza zadecyduj, czy korzystanie z usług opisanych przez BIAN – w celu uporządkowania wewnętrznych inicjatyw i wyboru rozwiązań dostawców – jest priorytetem dla firmy.
• Dokonaj oceny zgodności posiadanych rozwiązań z BIAN. Gdzie funkcjonalności się powielają? Gdzie są luki?
• Dostosuj wszystkie własne komponenty do wymagań wynikających z mapy serwisów BIAN, używając jej jako punktu odniesienia. Uprości to integrację rozwiązań tworzonych w ramach odrębnych inicjatyw oraz dopasowania rozwiązań dostarczanych przez zewnętrznych dostawców.
• Potraktuj Architekturę Referencyjną BIAN jako punkt wyjścia do modelowania interfejsów pomiędzy rozwiązaniami.
• Przy ocenie aplikacji i usług bankowych dostarczanych przez dostawców zewnętrznych jako jedno z kryteriów dodaj standard BIAN razem z oceną podstawowej funkcjonalności rozwiązania i rentowności producenta; nadaj nowemu kryterium średni priorytet.
• Naciskaj na swoich preferowanych dostawców narzędzi SOA oraz dostawców i integratorów systemów, aby aktywnie wspierali standard BIAN.
• Jeśli aktualnie wykorzystujesz lub planujesz wykorzystać standardy BIAN, powinieneś lobbować za jak najszerszym stosowaniem BIAN. Naciskaj na certyfikowane przez BIAN organizacje, aby dostarczyły certyfikat BIAN.

W innych branżach BIAN Architekturą Referencyjną odpowiednią dla nich, jednak co do zasady wszystkie wytyczne pozostaną takie same.

Dariusz Koncewicz