Rekomendacja D KNF - szansa czy zagrożenie dla EA?

W styczniu 2013 r. przyjęta została jednogłośnie przez Komisję Nadzoru Finansowego (KNF) nowa wersji rekomendacji “D”, która dotyczy zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach. Poprzednia wersja tej rekomendacji została opublikowana w roku 2002 – czyli bez mała 11 lat temu (dla “świata IT w bankach” to przecież epoka – proszę zwrócić uwagę na stan bankowości internetowej (nie mówiąc o mobilnej) wówczas i w chwili obecnej). Co się zmieniło w stosunku do poprzedniej wersji? Najczęściej wskazuj się tutaj na:

• sformalizowanie reguł współpracy obszarów biznesowych oraz  IT;
• sformalizowanie reguł dotyczących bezpieczeństwa środowiska teleinformatycznego;
• sformalizowanie reguł dotyczących zarządzania infrastrukturą teleinformatyczną;
• sformalizowanie reguł związanych z przetwarzaniem danych – w szczególności w obszarze dostępu do danych oraz systemów informatycznych odpowiedzialnych za przetwarzanie tych danych.

Zgodnie z przyjętym harmonogramem wdrażania tej rekomendacji do czerwca 2013 roku należało przygotować tzw. “analizę luk” (skądinąd pojęcie to znane jest każdemu TOGAFowcowi jako “gap analysis” ;) ) i przesłać do KNF harmonogramu działań mających za zadanie zniwelowanie tych luk. Druga połowa 2013 r. to czas możliwych inspekcji, weryfikujących harmonogram i podejście do realizacji zapisów rekomendacji. Na realizację projektów likwidujących zidentyfikowane luki banki mają czas nie później niż do 31 grudnia 2014 r.

Sama rekomendacja “D” liczy łącznie 61 stron, i zawiera 22 wytyczne (rekomendacje szczegółowe). Są one podzielona na cztery obszary – tj.:

• Strategia i organizacja obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego.
• Rozwój środowiska teleinformatycznego.
• Utrzymanie i eksploatacja środowiska teleinformatycznego.
• Zarządzanie bezpieczeństwem środowiska teleinformatycznego.

Od strony zarządzania architekturą (korporacyjną) rekomendacja D stanowi istotny przełom, gdyż chyba po raz pierwszy w oficjalnym dokumencie (rekomendację można przecież uznać za tzw. “soft-law”) skierowanym do banków mówi się o potrzebie podejścia architektonicznego (w rekomendacji 9 razy pada słowo “architektura” – z czego 2 razy w spisie treści). Co prawda KNF nie odnosi się wprost do koncepcji architektury korporacyjnej, ale wskazuje się bezpośrednio na dwie z czterech domen  – tj. domenę danych oraz domenę techniczną (infrastruktury technicznej). Jednocześnie warto wskazać, że za wdrożenie rekomendacji D ponosi Zarząd banku  – a to daje szansę (często jest to pierwszy raz) na zwrócenie uwagi na kwestie architektoniczne decydentom tak wysokiej rangi.

W tym miejscu warto przytoczyć poszczególne zapisy dotyczące aspektów architektonicznych.

W rekomendacji szczegółowej nr 7 napisane jest:

Dobrą praktyką jest określenie stosowanych standardów w zakresie rozwoju oprogramowania, w tym:  standardów architektonicznych, w tym wykorzystywanych platform, technologii, mechanizmów integracji itp. [KNF podkreśla, że powinno mieć to miejsce, w przypadku własnego dewelopmentu systemów informatycznych przez bank]

W rekomendacji szczegółowej nr 8 napisane jest:

“Bank powinien posiadać sformalizowane zasady zarządzania danymi wykorzystywanymi w ramach prowadzonej działalności, obejmujące w szczególności zarządzanie architekturą oraz jakością danych i zapewniające właściwe wsparcie działalności banku.” 

KNF zwraca uwagę, że każdy bank powinien dysponować wiedzą dotyczącą tego, jakie dane przetwarzane są w  ramach prowadzonej przez niego działalności, jakie są ich źródła (w tym z określeniem, czy są to źródła wewnętrzne, czy zewnętrzne) oraz w jakich jednostkach, procesach i systemach realizowane jest to przetwarzanie. Co więcej KNF rekomenduje rozważenie przez bank  wprowadzenia elektronicznego repozytorium (jak dla mnie jest to repozytorium architektoniczne – przypis A.S.), w którym zawarte będą “modele tych danych, opisujące m.in. zależności pomiędzy ich poszczególnymi  elementami oraz przepływy pomiędzy systemami informatycznymi, jak również posiadać  odpowiednie zasady (polityki, standardy, procedury itp.) przetwarzania tych danych.”

W rekomendacja szczegółowej nr 9 napisane jest:

“Bank powinien posiadać sformalizowane zasady dotyczące zarządzania infrastrukturą teleinformatyczną, w tym jej architekturą, poszczególnymi komponentami, wydajnością i pojemnością oraz dokumentacją, zapewniające właściwe wsparcie działalności banku oraz bezpieczeństwo przetwarzanych danych.” 

KNF rekomenduje utrzymywanie rejestru komponentów infrastruktury informatycznej wraz z podstawowymi informacjami na temat ich rodzaju i konfiguracji. Dyskusyjne jest to, czy taki rejestr to już CMDB (Configuration Management DataBase) czy jeszcze jego rolę może pełnić odpowiednio przygotowane repozytorium architektoniczne.

Tyle, jeżeli chodzi o literalne odniesienie się do architektury. Stawiam jednak tezę, że w samej rekomendacji D istnieje o wiele szersza możliwość wykorzystania wybranych koncepcji architektonicznych (proszę np. zwrócić na zapis “Bank powinien podejmować działania mające na celu minimalizację ryzyka związanego z ewentualnym odejściem z pracy kluczowych pracowników obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego” – przecież aż prosi, aby był to “driver” pozwalający na szerszą skalę wykorzystać zarządzanie architekturą korporacyjną i wdrożenia repozytorium architektonicznego) – i o tym będę starał przekonać Państwa w kolejnych wpisach.

Czy ta rekomendacja może stanowić zagrożenie dla upowszechniania się koncepcji architektonicznej w bankach? Pozwolę sobie sformułować to tak: Same zapisy rekomendacji są jak najbardziej właściwe. Wszystko zależy od sposobu ich realizacji. Gdzie widzę ryzyka dla “spalenia” podejścia architektonicznego. Po pierwsze, jeżeli banki będą chciały podejść do  rekomendacji literalnie (czyli odnosząc się wprost do poszczególnych zapisów bez próby uchwycenia “ducha” zaleceń) – może to spowodować powstanie bardzo nieżyciowych konstrukcji organizacyjnych. Innym ryzykiem może być nadmierne przeformalizowanie zarządzania architekturą (do takiego stanu mogą doprowadzić zapędy niektórych departamentów zajmujących się compilance w bankach) – co departamenty biznesowe mogą odebrać bardzo niekorzystnie (architektura zamiast pomagać stanie się “stoperem” działań biznesowych).

Prowadząc dokładniejszą analizę rekomendacji zauważa się, że ma ona w banku wielu interesariuszy. Oprócz oczywistego interesariusza, jakim jest departament IT, wskazać można: zarząd banku i radę nadzorczą, departament odpowiedzialny za bezpieczeństwo, departament odpowiedzialny za audyt i compliance, departament prawny, departament HR, departament  operacyjny, departament sprzedaży. Daje to szansę, na rozpropagowanie przynajmniej pewnych kwestii architektonicznych bardzo szerokiemu gronu (może się to odbywać na zasadzie: jak do tej pory nie chcieliście słuchać, to teraz MUSICIE, bo jest przymus regulacyjny ;)).

Wprowadzenie tej rekomendacji obudziło duże nadzieje, wśród firm – zarówno doradczych (które za wszelką cenę chcą sprzedać swoje usługi bankom) jak również dostawców rozwiązań IT (zaistniała szansa na nowe deal’e sprzedażowe).

Teraz wszystko zależy od banków – jaką przyjmą one postawę wobec tej rekomendacji. Co obecnie można już zaobserwować? Część banków twierdzi, że od dawna spełnia przedstawione rekomendacje szczegółowe – bo jest to zbiór dobrych praktyk, które są w powszechnym użytku. Część z banków zauważa, że nie spełnia tych wytycznych, ale chce do ich realizacji podejść jak  do kolejnych reguł, które trzeba uwzględniać i nic więcej – wiąże się to z możliwą minimalizacją kosztów ponoszonych na implementację tej rekomendacji (a przynajmniej nie wydawanie więcej niż średnia branżowa) i re-użycie już istniejących rozwiązań (w tym rozwiązań organizacyjnych). Chyba tylko niewielka część banków patrzy na tą rekomendację – jako na szansę wprowadzenie nowoczesnego zarządzania architekturą (zwiększenia stopnia dojrzałości architektonicznej). I dla tych instytucji mam propozycję :).

Będę starał się na serwisie ArchitekturaKorporacyjna.pl publikować uwagi metodyczne – jak można podejść do pewnych zapisów tejże rekomendacji. Na pewno zacznę od metamodelu architektonicznego, który według mnie będzie wyczerpywał zapisy tej rekomendacji (będę go tworzył w języku ArchiMate 2.0). Mam nadzieję, że przygotowane przez mnie materiały uznacie Państwa za użyteczne. Oczywiście z góry dziękuję za Państwa sugestie i uwagi.