gru
27

Kiedy architekt korporacyjny może być dumny?

Źródło: Andrzej Sobczak
Print Friendly

happyKażdy z nas (może z wyjątkiem polityków ;)), ma potrzebę konstruktywnego działania – czyli tworzenia rzeczy, z których później jest się dumnym. Dotyczy to zarówno działań fizycznych (takich jak budowa domu, remont mieszkania itp…), jak i umysłowych/twórczych (np. fotografia, malarstwo, rzeźba). W przypadku ludzi związanych ze światem IT potrzeba ta jest szczególnie widoczna, bo większość z nas  (w tym również ja) ma wykształcenie inżynierskie – a te studia w szczególnym stopniu rozwijają postawy związane z dostarczaniem różnego rodzaju produktów i rozwiązań. Jak to się objawia w praktyce?

Programista jest szczególnie dumny, jeżeli uda mu się napisać kawałek modułu zapewniający wysoką wydajność całemu systemowi (np. dotyczący przetwarzania dużych wolumenów nieustrukturalizowanych danych). Tester będzie zadowolony, jeżeli wprowadzi mechanizmy automatyzacji testów wydajnościowych i dzięki temu skróci czas testowania złożonej aplikacji n-warstwowej wykorzystującej dodatkowo dziwne protokoły komunikacyjne o 70% (liczone w odniesieniu do testów wykonywanych “na piechotę”). Kierownik projektu IT będzie dumny, że mimo wszystkich przeciwności udało mu się dostarczyć rozwiązanie na czas i w ustalonym zakresie (nawet, jeżeli powstały nadgodziny, za które trzeba ekstra zapłacić). Wreszcie analityk systemowy będzie szczególnie dumny na przygotowanie specyfikacji wymagań – z którą nie miał problemu i programista i tester – a użytkownik biznesowy zobaczył w tej pracy dodatkową wartość.

A kiedy architekt korporacyjny powinien być dumny z efektów swojej pracy?

Czy jest to wówczas, kiedy stworzy bardzo dobre modele architektoniczne (czy to dla stanu bazowego czy też docelowego organizacji)? Ale przecież wiadomo, że sporej części tych modeli nikt nie czyta poza architektami…

Czy jest to wówczas, kiedy doprowadzi do sformułowania bardzo dobrych (tj. spójnych, kompletnych, jednoznacznych) pryncypiów architektonicznych? Ale przecież wiadomo,  że w sporej liczbie organizacji, jest to praca czysto formalna, bo tych pryncypiów nikt później nie przestrzega…

Czy jest to wówczas, kiedy zaprojektuje procesy ładu architektonicznego? Ale przecież wiadomo,  że w znacznej liczbie przypadków, procesy te pozostaną jedynie na papierze, nikt ich później nie próbuje wdrażać w praktyce…

Czy jest to wówczas, kiedy zidentyfikuje miejsca powstawania długu architektonicznego (lub węziej technologicznego)? Ale przecież wiadomo, że część organizacji świadomie tworzy taki dług (dotyczy to zwłaszcza organizacji, które należą do funduszy inwestycyjnych – a te mają perspektywę krótkoterminową, lub góra średnioterminową –  w tym przedziale czasu powstały dług tak mocno nie doskwiera).

Więc kiedy architekt korporacyjny powinien być zadowolony z efektów swojej pracy?

Podczas któregoś ze szkoleń usłyszałem, że architekt korporacyjny bardzo dobrze identyfikuje różnego rodzaju ryzyka (np. związane z aspektami technologicznymi) i ostrzega przed nimi poszczególne komórki organizacyjne. Przy czym w znacznej ilości przypadków, ryzyka te są ignorowane przez organizację (mimo wielokrotnych ostrzeżeń architekta)… bo nie są to stricte ryzyka projektowe (te być może byłyby docenione przez PM), a raczej dotyczą długookresowych konsekwencji pewnych wyborów/decyzji architektonicznych (np. w zakresie integracji, braku standaryzacji itp.). Czyli teoretycznie architekt korporacyjny powinien się cieszyć wówczas, kiedy dobrze zidentyfikował ryzyka – ale o tym dopiero wiadomo, kiedy się one zmaterializują… Ale to chyba nie jest powód do radości…

Przyznam się, że kiedy zastanawiałem się szerzej nad tym zagadnieniem – bardzo ciężko jest jednoznacznie wskazać powód do dumy architekta korporacyjnego. Ale to związane jest z jego rolą (a po części i umocowaniem w organizacji). Najczęściej bowiem architekt korporacyjny nic nie dostarcza (bo jest za nisko w organizacji, bo nie ma budżetu itp…) – architekt bardzo często konsultuje, opiniuje, doradza. A nie zawsze jego głos jest słyszany/brany pod uwagę – tym bardziej, że często architekt “nie kadzi”, a wręcz przeciwnie – zgłasza szereg uwag do przedstawionych mu pomysłów/projektów/planów inicjatyw.

Na koniec przytoczę stary już dowcip, który dotyczył firmy Microsoft:

W szkole na lekcji pani pyta dzieci, gdzie pracują ich tatusiowie.
– Mój tata jest piekarzem – mówi Jacek.
– A mój jest kierowcą – mówi Ola.
– A mój tata jest lekarzem – mówi Małgosia.
– No a twój tata, kim jest? – pyta Pani Jasia.
– No, mój tata… tańczy na rurze – odpowiada Jasiu.
Na przerwie pani podchodzi do Jasia i pyta:
– Jasiu, twój tata naprawdę tańczy na rurze?
– Nie – odpowiada Jasiu – Mój tata pracuje w Microsofcie, ale wstydziłem się powiedzieć.

Oby nasi synowie, za jakiś czas nie musieli się wstydzić, czym zajmują się ich ojcowie i mogli z dumą przyznać, że są architektami korporacyjnymi :).

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

Dyskusja do artykułu “Kiedy architekt korporacyjny może być dumny?

  1. A mnie odpowiedź wydaje się stosunkowo prosta. Architekt wie, że dobrze wykonuje swoją pracę kiedy widzi, że wizja, którą stworzył z zespołem jest realizowana. Dumny może być kiedy widzi, że to co narysował jako ToBe Architecture przemieniło się w AsIs.
    Przy tak zdefiniowanym kryterium sukcesu problemy takie jak umocowanie w strukturze, wpływ na budżet etc. stają się konkretnymi wyzwaniami do pokonania (jak znaleźć się w odpowiednim miejscu strukturze bądź jak zdobyć wpływ na procesy decyzyjne, jak zostać właścicielem/współwłaścicielem budżetu etc)
    Piszę powyższe z perspektywy bardzo dumnego architekta 

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>