mar
01

Kodeks dobrych praktyk architektów korporacyjnych

Źródło: Andrzej Sobczak
Print Friendly

W chwili obecnej w Polsce profesja architekta korporacyjnego zaczyna się dopiero rodzić. Wydaje się, że niezwykle przydatne byłoby stworzenie wytycznych (swego rodzaju kompasu), dla osób zajmujących się (lub chcących w najbliższej przyszłości zajmować się) tą problematyką zawodowo.

Punktem wyjścia do zaproponowanego przeze mnie podejścia była inspiracja spotkaniem, które miało miejsce w lutym 2001 r. w USA, kiedy to odbyło się spotkanie reprezentantów metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. W czasie jego trwania opracowali oni tzw. Manifest Agile. Stanowi on deklarację wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania, takich jak np.: programowanie ekstremalne, Scrum, Adaptive Software Development, Crystal Clear, Feature Driven Development.

Manifest ten był inspiracją dla podejmowania podobnych inicjatyw w innych obszarach informatyki i zarządzania. Powstały m.in. manifesty dotyczące SOA, zarządzania transformacją organizacji, projektowania architektury systemów informatycznych czy wreszcie analizy biznesowej.

Bazując na własnych doświadczeniach, rozmowach z osobami zajmującymi się problematyką architektury korporacyjnej w Polsce i na świecie, prowadzonymi przeze mnie pracami badawczymi pozwoliłem sobie przygotować i poddać pod dyskusję deklarację wspólnych zasad dedykowanych architektom korporacyjnym. Nadałem im miano „Kodeksu dobrych praktyk architektów korporacyjnych”.

Treści zawarte w Kodeksie skierowane są do wszystkich architektów korporacyjnych w Polsce. Ale Kodeks ten ma służyć również kształtowaniu mechanizmów współpracy pomiędzy architektami i przedstawicielami pozostałych części organizacji (począwszy od Zarządu, a skończywszy na zespołach programistycznych i zespołach zajmujących się utrzymaniem rozwiązań IT).

Jako główne cele Kodeksu można wskazać z jednej strony: promocję architektury korporacyjnej w Polsce – jako pewnej 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.

Z tego względu Kodeks został podzielony na dwie części: preambułę, która pokazuje w jakich warunkach już działają, lub za chwilę będą działać architekci korporacyjni oraz zbiór zasad, których przestrzeganie powinno stać się ich codzienną praktyką. Kodeks powinien być postrzegany jako kompas ułatwiający poruszanie się po meandrach wdrożenia i stosowania podejścia architektonicznego w każdej organizacji.

Jeśli macie Państwo do tego tekstu jakieś uwagi, komentarze, czegoś brakuje – zapraszam do kontaktu.

Na koniec, jeśli zgadzacie się Państwo z treścią Kodeksu zachęcam do powoływania się na jego zapisy przy tworzeniu architektury korporacyjnej na potrzeby własnej Organizacji lub Organizacji klienta.

 

Kodeks dobrych praktyk architektów korporacyjnych

Preambuła

Żyjemy w coraz szybciej zmieniającym się świecie, co powoduje że nasze Organizacje muszą być coraz bardziej elastyczne. Jednocześnie poziom ich złożoności i skala działania zaczynają gwałtownie rosnąć. Następuje odmiejscowienie zarówno tworzenia produktów i usług, ale także – dzięki technologiom mobilnym – ich konsumpcji.

Nasi klienci stają się coraz bardziej wymagający i coraz mniej skłonni do wybaczania błędów popełnianych przez naszą Organizację. Chcą oni coraz więcej i coraz szybciej za mniej. Swoje, często bardzo ostre, opinie nt. naszych produktów, usług lub zachowań potrafią błyskawicznie wyartykułować – za pomocą serwisów społecznościowych – w przeciągu bardzo krótkiego czasu tysiącom, a często wręcz setkom tysięcy naszych obecnych lub potencjalnych odbiorców.

Wszystko to powoduje, że jesteśmy pod nieustającą presją – z jednej strony na obniżenie kosztów działania naszych Organizacji, przy jednoczesnym podnoszeniu jakości i innowacyjności produktów i usług dostarczanych przez nas.

Postanowienia Kodeksu

Odpowiedzią na wyzwania, jakie stoją przez współczesnymi Organizacjami, jest architektura korporacyjna. Jako architekci korporacyjni, odpowiedzialni w Organizacji za ten obszar, kierujemy się następującymi zasadami:

0.

O powodzeniu architektury korporacyjnej nie decydują najlepsze nawet modele architektoniczne czy nawet sposób ich realizacji, lecz ludzie. Szanujemy to i respektujemy wagę relacji oraz komunikacji międzyludzkiej.

I.

Zbudowanie i wdrożenie architektury korporacyjnej w Organizacji nie jest celem samym w sobie. Traktujemy ją jako narzędzie wspomagające podejmowanie racjonalnych decyzji, które uwzględniają potrzeby całej Organizacji, a nie partykularne interesy poszczególnych jej części.

II.

Stanowimy pomost pomiędzy światem biznesu i IT. Dzień po dniu spotykamy się i słuchamy jednej i drugiej strony. Jesteśmy otwarci na ich racjonalne argumenty, ale nie oznacza to, że idziemy na skróty przy projektowaniu architektury korporacyjnej Organizacji. Jednocześnie mamy świadomość, że ostateczne decyzje w kluczowych sprawach, uwzględniając uwarunkowania biznesowe, będzie podejmowało ciało nadzorujące nasze prace.

III.

Pomimo, że – jako architekci korporacyjni – nie zawsze jesteśmy umocowani w centrum Organizacji (chociaż budując dojrzałość architektoniczną wśród pracowników dążymy do tego), staramy się, aby podejmowane (lub rekomendowane) przez nas decyzje architektoniczne były przejrzyste i miały swoje uzasadnienie w jej misji oraz strategii. Jednocześnie próbujemy pokazać jak innowacyjne rozwiązania informatyczne mogą pomóc naszej Organizacji.

IV.

Przy projektowaniu architektury korporacyjnej kierujemy się następującymi wytycznymi:

a. pomagamy w identyfikowaniu problemów Organizacji (biznesowych i związanych z IT) i próbujemy znaleźć i uzgodnić najlepsze możliwe podejście do ich rozwiązania, uwzględniając przy tym pryncypia biznesowe i architektoniczne naszej Organizacji;

b. projektujemy możliwie najprostszą architekturę, ale nie prostszą (uwzględniając wszędzie tam, gdzie jest to uzasadnione komponenty reużywalne);

c. staramy się, aby tworzenie modeli architektonicznych w obszarze IT poprzedzone było utworzeniem architektonicznych modeli biznesowych – co pozwoli na lepsze dopasowanie rozwiązań IT do potrzeb Organizacji;

d. wszędzie tam, gdzie jest to możliwe stosujemy sprawdzone gdzie indziej wzorce architektoniczne oraz modele referencyjne;

e. każdy tworzony artefakt architektoniczny ma swoje uzasadnienie w rzeczywistych, wcześniej odkrytych przez nas, potrzebach interesariuszy;

f. dobieramy sposób wyrażenia modeli architektonicznych do oczekiwań interesariuszy – ale wszędzie tam, gdzie jest to możliwe stosujemy uznane standardy modelowania;

g. tworzymy modele architektoniczne iteracyjnie, przy ścisłej współpracy z interesariuszami – nie staramy się od razu zaprojektować stanu idealnego, wiemy bowiem, że wymaga to czasu;

h. doceniamy korzyści płynące z posiadania uporządkowanej wiedzy o sposobach działania (obecnych i planowanych) naszej Organizacji, ale w szczegółowe ich aspekty wchodzimy tylko tam, gdzie jest to niezbędne – interesuje nas bowiem przede wszystkim całościowe spojrzenie na Organizację.

V.

Stoimy na straży jakości architektury korporacyjnej i wynikających z niej rozwiązań, ale rozumiemy także, że w praktyce mogą wystąpić ograniczenia realizacyjne – natury zarówno biznesowej jak i technicznej. Z tego względu dopuszczamy możliwość czasowych odstępstw od zaprojektowanej przez nas architektury.

VI.

Doceniamy uznane i sprawdzone podejścia metodyczne i ramy architektoniczne – ale ich stosowanie nie może stanowić celu samego w sobie. Dlatego też zawsze staramy się wprowadzić równowagę pomiędzy standardami architektonicznymi a zdrowym rozsądkiem i rzeczywistymi potrzebami Organizacji.

VII.

Wdrożenie nawet najlepszego narzędzia informatycznego do zarządzania architekturą korporacyjną nie może być utożsamiane ze zbudowaniem praktyki architektonicznej w Organizacji. Będziemy mogli mówić, że nam się to udało, w momencie, w którym Organizacja sama będzie chciała działać zgodnie z zasadami architektonicznymi.

VIII.

Praktyka architektoniczna nie jest samotną wyspą w Organizacji. Dlatego współpracujemy m.in. zarówno z zespołem ds. strategii, biurem projektów i programów, analitykami biznesowymi, architektami rozwiązań i programistami, działem utrzymania systemów jak również działem zakupów oraz działem controllingu.

IX.

Wdrożenie architektury korporacyjnej należy rozpatrywać jako ciągłą podróż, a nie osiągnięcie stanu docelowego. Dlatego ciągle doskonalimy samą architekturę jak i mechanizmy zarządzania nią (dokonując systematycznie pomiaru poziomu dojrzałości architektonicznej). Jeżeli widzimy, że wprowadzone przez nas modele, procesy, procedury, standardy są nieskuteczne lub nieefektywne – zmieniamy je, robimy to jednak w sposób kontrolowany i pokazując całościowe konsekwencje tych zmian – uwzględniając zarówno skutki organizacyjno-finansowe jak i informatyczne.

X.

Propagujemy wiedzę o architekturze korporacyjnej w Organizacji – zarówno wśród ludzi z komórek biznesowych jak i IT. Przekonujemy ich do podejścia architektonicznego, pokazując korzyści jakie może ono przynieść dla całej Organizacji. Jednocześnie sami uczymy się aspektów merytorycznych działania naszej Organizacji, aby móc być pełnoprawnym partnerem w rozmowach z biznesem.

Kodeks dobrych praktyk architektów korporacyjnych

 

Zapraszam również do pobrania Kodeksu w formie plakatu.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>