sie
03

Architektura korporacyjna ≠ ograniczenie elastyczności

Źródło: Andrzej Sobczak
Print Friendly

Podczas przedsięwzięć dotyczących wdrażania architektury korporacyjnej bardzo często pojawia się obawa u decydentów, że nastąpi ograniczenie elastyczności w działaniu organizacji. Można spotkać się z poglądem, że  “wszystkie te modele, standardy, pryncypia nie ułatwią, a wręcz przeszkodzą w funkcjonowaniu przedsiębiorstwa/urzędu”. Osoby te zwracają również uwagę, że “przecież wiadomo, że obecnie są czasy trudne i tylko organizacje zwinne przetrwają”.
Aby jednak poprawnie ustosunkować się do tych uwag niezbędne jest zdefiniowane – czym jest elastyczność organizacji.

Może być ona postrzegana przez pryzmat portfela produktów i  usług oferowanych przez organizację, którego zawartość aktywnie reaguje na siły rynkowe. Można ją rozumieć jako wysoce dostosowywalny model biznesowy organizacji. W takich ujęciach architektura korporacyjna zapewnia fundament realizacyjny dla elastyczności. Wiedza  o organizacji (dotycząca zarówno IT jak i biznesu), dostarczana przez procesy architektoniczne stanowi solidną podstawę, na której można budować korporacyjną koncepcję elastyczności.

Jednocześnie część obaw dotyczących ograniczenia elastyczności ma swoje głębokie uzasadnienie. Wynika to m.in. z faktu, że wiele podejść do budowy architektury korporacyjnej usiłuje rozwiązywać różne (żeby nie rzec wszystkie) problemy za jednym zamachem. Z tego względu nieprzerwanie wzrasta stopień ich skomplikowania powodując, że zespoły architektoniczne zmuszone są wchodzić w zbyt wiele szczegółów i skupiać się na mniej istotnych kwestiach. Może to skutkować – co przywołuje Gartner – „paraliżem przez analizę”, doprowadzając zespoły architektoniczne do stanu zapaści.

Należy także zwrócić uwagę, że zespoły zajmujące się architekturą korporacyjną nie powinny funkcjonować jako „policja architektoniczna” ściśle kontrolująca projekty wdrożeniowe  i prawdopodobnie wywołująca „wąskie gardła” w projektach. Zamiast tego zespoły architektoniczne powinny raczej skupiać się na wspomaganiu innych, aby funkcjonować w zgodności z uzgodnionymi pryncypiami architektonicznymi, oraz na zapewnieniu efektywnej komunikacji.

Innym czynnikiem, o który należy dbać, jest unikanie przesady w standaryzacji. Zespoły architektów odpowiedzialne są za definiowanie pryncypiów architektonicznych i standardów – w tym mapy drogowej technologii. Jednakże, wymagania biznesowe, takie jak czas wprowadzania produktu u na rynek (ang. Time-to-market), muszą być cały czas brane pod uwagę, a zgodność z tymi standardami nie może być utrzymywana w sposób dogmatyczny, prowadzący do tego, że interesariusze zaczynają je ignorować (lub w jeszcze gorszym wariancie – tworzyć rozwiązania poza wiedzą zespołów architektonicznych).

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>