Kiedy architekt korporacyjny może być dumny?
Każ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 :).
Komentarze do wpisu
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
Nawet jeśli sprzedaż spada, koszty rosną, a firma nie osiąga celów, które postawili przed nią akcjonariusze?
Dodaj komentarz