RegułyChaosu

Podstawą Agile Architecture jest zdolność do użycia rozwiązania lub komponentu na nowe sposoby, nie przewidziane podczas projektowania takiego rozwiązania czy komponentu. Brzmi prawie jak herezja inżynierska – wszak informatyka to nie magiczna różdżka zmieniająca coś bez zmieniania. Jak więc uzyskać zdolność dopasowania rozwiązań informatycznych? Jak sprawić, aby architektura była naprawdę zwinna?

Wiele lat temu propagowałem zwinność (agility) na poziomie architektury, także korporacyjnej. Po latach dochodzę do wniosku, że wtedy było za wcześnie. Gospodarka była wtedy wyrozumiała, konkurencja mniejsza i presja biznesu pozostawiała IT sporo komfortu. Można było wydawać miliony na „zabawy w EA” – próbować metod i narzędzi, weryfikować w boju wizje „odtechnologiczne”. Obecne z warunków otoczenia rynkowego firm usunięto łagodność i pobłażliwość, a biznes stał się do szpiku pragmatyczny.

Przez lata spędzone w bardzo różnych organizacjach przyglądałem się sposobom działania ludzi, którzy na wizytówkach mieli napisane Architekt Korporacyjny (Enterprise Architect). Patrząc na poczynania takich ludzi – nie wszystkich, ale jednak znakomitej większości – można byłoby uznać, że EA (Enterprise Architecture) jest martwe, a podtrzymywanie EA przy życiu doprowadzi do Apokalipsy Zombie. W rzeczywistości jednak nie EA jest złe – to „metodycy od EA” sprowadzają na EA apokalipsę.

Ostatnio zdarzyło mi się przeprowadzić filozoficzną dysputę o wartości Enterprise Architecture. Nasza dysputa dość szybko przeszła w stadium zderzenia przekonań i skończyło się awanturą. Od kilku już lat wiadomo, że EA nie spełnia obietnic. Po ostatniej dyspucie już wiem, dlaczego.

W kilku ostatnich projektach podejmowałem zagadnienia reguł licencjonowania tzw. gotowych rozwiązań informatycznych dostarczanych przez znane, duże firmy z branży. Muszę przyznać, że jestem pod wrażeniem sprytu branży w kształtowaniu tych reguł – sprytu niosącego poważne ryzyko dla kupujących te rozwiązania.

Zawsze byłem wrażliwy na punkcie obsługi klienta. Zarówno jako klient jak i jako tworzący rozwiązania obsługi klienta. Dobre rozwiązania w tej sferze muszą być zintegrowane – przede wszystkim organizacyjnie, dopiero później teleinformatycznie. Wszak celem jest załatwienie sprawy klienta w czasie z nim pierwszego kontaktu, prawda?

O CRM – jako systemie informatycznym i filozofii działania – pisałem już kilkukrotnie. Przydarzył mi się kolejny projekt CRM, w którym pełnię zaszczytną rolę architekta rozwiązania. Jak to architekt, chcę powiązać świat biznesu ze światem technologii. No i jest ciekawie.

W ramach przygotowań do OSAKA 2016 podjąłem dyskusję o wartości architektury korporacyjnej. Kolega po fachu poddał ciekawą myśl, że EA powstało w czasach, kiedy strategia IT była wyznaczana na 5 lat lub więcej, a współcześnie jakoś nie sposób tak daleko „strategować”, przez co EA jakby traci na sensowności. Czy aby na pewno?