Na styku biznesu i informatyki
-
- Andrzej Sobczak,
- 31.05.2012
Opracowanie architektury korporacyjnej nie jest przedsięwzięciem IT, a architekt korporacyjny to nie informatyk. Sensem podejścia architektonicznego jest całościowe spojrzenie na firmę.
Mało kto zdaje sobie sprawę, że w tym roku obchodzimy jubileusz koncepcji będącej fundamentem architektury korporacyjnej. Wszystko zaczęło się 25 lat temu, kiedy John Zachman (wówczas pracownik firmy IBM) opublikował w czasopiśmie "IBM Systems Journal" artykuł pt. "A Framework for Information Systems Architecture". Zauważył w nim, że podejście architektoniczne jest używane przy tworzeniu systemów informacyjnych, ale w zależności od etapu prac dzieje się to w różny sposób i z różnym natężeniem. W celu uczynienia z architektury systemu centralnego punktu odniesienia dla wszystkich działań, zaproponował sposób klasyfikacji powstających modeli/artefaktów architektonicznych. Koncepcje zawarte w opracowaniu były w kilku następnych latach rozwijane przez samego J. Zachmana, aby w latach 90. przybrać postać, znaną powszechnie jako siatka Zachmana (Zachman Framework for Enterprise Architecture).
Głównym celem "Kodeksu dobrych praktyk architektów korporacyjnych" jest promocja architektury korporacyjnej w Polsce jako koncepcji i zarazem profesji zawodowej z nią związanej. Drugim, równie istotnym, aspektem jest określenie zasad, które stanowiłyby wzorzec pożądanych zachowań architekta korporacyjnego i pozwoliły mu dostarczać wysokiej jakości usługi na potrzeby organizacji, w której pracuje. Z pełną wersją kodeksu można zapoznać się na stronie Polskiego Forum Architektury Korporacyjnej: www.architekturakorporacyjna.pl/kodeks.
Na trudności terminologiczne nakładają się dyskusje, jaką rolę powinien pełnić architekt korporacyjny w organizacji, gdzie powinien być umocowany, do kogo powinien raportować i jakie umiejętności powinien posiadać. W ramach prac Polskiego Forum Architektury Korporacyjnej zauważono, że przydatne byłoby opracowanie wytycznych dla osób zajmujących się (lub chcących się zajmować) tą problematyką profesjonalnie. W wyniku przeprowadzonych dyskusji przygotowano deklarację wspólnych zasad dedykowanych architektom korporacyjnym. Nadano im miano "Kodeksu dobrych praktyk architektów korporacyjnych". Oficjalna premiera kodeksu odbyła się w Warszawie, podczas II Forum Architektów IT, zorganizowanego w kwietniu br. przez redakcję Computerworld.
Budowniczy konsensusu
Treści zawarte w kodeksie skierowane są do wszystkich architektów korporacyjnych w Polsce (bądź osób aspirujących do tej roli). Kodeks ma służyć kształtowaniu mechanizmów współpracy pomiędzy architektami i przedstawicielami pozostałych części organizacji.
Kodeks został podzielony na dwie części: preambułę, która pokazuje, w jakich warunkach już działają lub będą działać architekci korporacyjni, oraz zbiór zasad, których przestrzeganie powinno stać się ich codzienną praktyką. Nie aspiruje on do roli zastępującej TOGAF czy inne podejścia architektoniczne. Raczej wskazuje, na co należy zwrócić szczególną uwagę przy budowie praktyki architektonicznej - aby uniknąć błędów, które już w 2009 r. sygnalizowała firma Gartner (por. ramka).
Najważniejszą rzeczą, na którą warto zwrócić uwagę w kodeksie, jest podkreślenie, że opracowanie architektury korporacyjnej nie może być postrzegane jako przedsięwzięcie IT, a architekt korporacyjny nie może być odbierany jako informatyk. Jest to bowiem osoba, która musi balansować pomiędzy dwoma światami: IT i biznesu. Jego zadaniem powinno być wspomaganie kierownictwa firmy/instytucji publicznej w podejmowaniu racjonalnych decyzji (często o charakterze strategicznym), które uwzględniają potrzeby całej organizacji, a nie partykularne interesy jednostek. Powinien on podlegać pod członka zarządu/dyrektora generalnego, a nie być umiejscowiony wewnątrz departamentu IT.
Co więcej, umiejętność budowania relacji i sojuszy oraz komunikacja międzyludzka decydują o powodzeniu wdrożenia koncepcji architektury korporacyjnej o wiele bardziej niż najlepsze nawet modele architektoniczne i sposoby ich realizacji. Dlatego też architekt korporacyjny powinien być budowniczym konsensusu, a nie projektantem systemów IT.
Musi stać on na straży jakości architektury korporacyjnej i wynikających z niej rozwiązań. Powinien rozumieć ograniczenia realizacyjne. Z tego względu w dobrze uzasadnionych przypadkach powinien dopuszczać możliwość czasowych odstępstw od opracowanych modeli.
Wytyczne i obszary
Przy projektowaniu architektury korporacyjnej zespół odpowiedzialny za te prace powinien kierować się następującymi wytycznymi:
- pomagać w identyfikowaniu problemów organizacji i próbować znaleźć oraz uzgodnić najlepsze ich rozwiązanie, uwzględniając pryncypia biznesowe i architektoniczne organizacji;
- projektować najprostszą architekturę, ale nie nazbyt uproszczoną (uwzględniając, gdzie jest to uzasadnione, komponenty reużywalne); należy pamiętać, by nie stosować doraźnych uproszczeń;
- starać się, aby tworzenie modeli architektonicznych w obszarze IT poprzedzone było opracowaniem architektonicznych modeli biznesowych, co pozwoli na lepsze dopasowanie rozwiązań IT do potrzeb organizacji;
- wszędzie, gdzie jest to uzasadnione, stosować sprawdzone wzorce architektoniczne oraz modele referencyjne;
- każdy artefakt architektoniczny powinien mieć swoje uzasadnienie we wcześniej odkrytych i zweryfikowanych potrzebach interesariuszy;
- dobierać sposób wyrażenia modeli do potrzeb interesariuszy - ale gdzie to możliwe, stosować uznane standardy modelowania;
- tworzyć modele architektoniczne iteracyjnie, przy ścisłej współpracy z interesariuszami;
- w szczegółowe aspekty funkcjonowania organizacji wchodzić tylko tam, gdzie jest to niezbędne.
Ponadto praktyka architektoniczna nie może być postrzegana jako samotna wyspa w organizacji. Koncepcja musi harmonijnie współistnieć z innymi obszarami firmy (por. wykres). Zwłaszcza należy wskazać relacje występujące na linii:
- architektury korporacyjnej i planowania strategicznego;
- architektury korporacyjnej i zarządzania portfelem projektów i programów;
- architektury korporacyjnej i budowy oprogramowania;
- architektury korporacyjnej i utrzymania systemów IT.
Do mniej rozpoznawalnych (co nie znaczy, że mniej istotnych) związków zaliczyć można relacje na styku:
- architektury korporacyjnej i zarządzania ryzykiem/ciągłością działania na poziomie całej organizacji
- architektury korporacyjnej i procesów zakupowych.
Zasady, a nie narzędzia
"Kodeks dobrych praktyk architektów korporacyjnych" podkreśla, że wdrożenie nawet najlepszego narzędzia IT do zarządzania architekturą korporacyjną nie może być utożsamiane ze zbudowaniem praktyki architektonicznej w organizacji (chociaż repozytorium architektoniczne powinno stanowić źródło aktualnej wiedzy o organizacji). Architekt korporacyjny będzie mógł mówić o sukcesie, kiedy ludzie będą rutynowo stosowali zasady architektoniczne.
Prof. dr hab. Andrzej Sobczak - kierownik Zakładu Systemów Informacyjnych w Katedrze Informatyki Gospodarczej SGH. Ekspert ds. architektury korporacyjnej/TOGAF oraz strategicznego zarządzania IT. Redaktor serwisu ArchitekturaKorporacyjna.pl. Kontakt: [email protected].
1. Nieodpowiednio dobrany główny architekt, który często jest mało efektywnym liderem. Może on dobrze znać się na metodycznych aspektach architektury korporacyjnej, ale nie ma umiejętności przywódczych. Ich brak nie może być przezwyciężony przez dobrą strukturę organizacyjną i wysokie umiejętności personelu.
2. Niedostateczne zrozumienie i wsparcie od interesariuszy. Występuje, gdy pracownicy spoza zespołu architektonicznego nie uczestniczą w przedsięwzięciu dotyczącym budowy modeli architektury korporacyjnej, wiedza architektoniczna nie jest wykorzystywana w projektach, a kierownictwo kwestionuje jej wartość.
3. Brak angażowania ludzi z zespołów biznesowych. Występuje to, kiedy architekci zamykają się w wieży z kości słoniowej i nie słuchają biznesu.
4. Tworzenie architektury jedynie na poziomie domeny IT (pomija się domenę architektury biznesowej).
5. Koncentrowanie się na opisie stanu obecnego (as-is). Dobrze przemyślana architektura korporacyjna powinna dostarczać wytyczne na przyszłość.
6. Zespół architektoniczny wykonuje większość prac. Paradoksalne jest to pułapka, ponieważ architektura korporacyjna jest zwykle niepełna z powodu braku informacji od ludzi po stronie biznesowej, nie ma także z ich strony poparcia dla prac.
7. Brak pomiaru efektów prac architektonicznych i nieupowszechnianie informacji o wpływie architektury na działalność organizacji. Wartość ze stosowania architektury korporacyjnej jest zwykle pośrednia.
8. Tworzenie architektur dla poszczególnych jednostek biznesowych. Bez architektury strategicznej (obejmującej całość organizacji) takie podejście powoduje powstanie rozwiązań suboptymalnych i petryfikuje stan obecny.
9. Nieustanawianie efektywnego ładu architektonicznego na wczesnym etapie prac. Architekci korporacyjni muszą opierać się pokusie tworzenia świetnych modeli architektonicznych przed ustaleniem procesów zarządzania i stosowania tych modeli.
10. Nieprzeznaczanie wystarczającej ilości czasu na komunikację. Kluczowe komunikaty na temat architektury korporacyjnej nie są dla większości odbiorców oczywiste.
