IT Doesn’t Matter – Architecture Matters

Data: 2015-03-30
Autor: Sebastian Konkol
IT Doesn’t Matter – Architecture Matters

Od pewnego czasu nawet w tzw. mainstreamowych publikacjach na temat IT pojawiają się wypowiedzi sugerujące, że czasy opłacalności budowy systemów na miarę minęły bezpowrotnie. Dzisiaj to wykorzystanie istniejących rozwiązań tworzy przewagę konkurencyjną, nie zaś budowa „doskonale dopasowanych do potrzeb” systemów. Kilka lat temu krytyczna publikacja “IT Doesn’t Matter” (Nicholas G. Carr) wzbudziła „święte oburzenie” i wywołała długą dyskusję. Po kilku latach wygląda jednak na to, że miał on rację.

Wartość posiadania technologii informacyjnych przenosi się z doskonałego dopasowania wielkich systemów tworzonych na zamówienie w sferę skutecznego wykorzystania tego, co jest. Skutecznego oznacza tu zarówno ekonomicznie uzasadnionego jak i „w akceptowalnym czasie”. Tempo zmian zachodzących w otoczeniu ekonomicznym firm nie pozwala na trwanie w komforcie budowania na miarę – wygrywają te firmy, które umieją skorzystać z gotowych elementów układanki. Trend poszedł już znacznie dalej. Obecnie praktyka architektury korporacyjnej (EA, Enterprise Architecture) definiuje już kompleksowe szablony dla całych branż czy modeli biznesowych. Gotowe komponenty są dostępne, więc wygrywa ten, kto jest sprawniejszy w ich składaniu – jak z klocków Lego.

Jednym z obszarów, w jakich – w mojej ocenie – rola EA jest fundamentalna, jest coś, co nazywam „negocjacją wartości”. Kiedy tylko zarówno IT jak i biznes zrozumieją, że architektura to ich język wzajemnej komunikacji, EA staje się właściwą kanwą dla tworzenia kontraktu między biznesem a IT. Taki kontrakt sformułowany jest jako potrzeby i zobowiązania wyrażone w kategoriach cech wsparcia informatycznego i czynników ryzyka, a proces dochodzenia do porozumienia opiera się na filozofii EA.

Czym jest więc rola architekta? Czym jest architektura? EA jest abstrakcją środowiska technologii informacyjnych, jej roli, powiązań, odpowiedzialności i dużej gamy innych tematów, wyrażoną w sposób umożliwiający „odsączenie” tematyki czysto technologicznej od bezpośrednich dyskusji o jej wartości biznesowej. Ta abstrakcja jest jednak na tyle przejrzysta, że stanowi dla managementu najlepszy sposób na radzenie sobie z technologią informacyjną i komunikacyjną. Ta abstrakcja jest formą pośrednika – mental middleware.

Poświęciłem dekadę swojego życia zawodowego zgłębianiu możliwości tkwiących w EA, bo wierzę głęboko, że – jak matematyka zapewnia możliwości opisu przedmiotów i zjawisk od skali kwantowej po astronomiczną – EA posiada możliwości analogiczne w odniesieniu do dyscypliny zarządzania ICT. Jestem architektem.

 

To już koniec epopei „Co może Architekt?” Przedstawione w tym cyklu przykłady to jedynie możliwości, które udało mi się sprawdzić „w co najmniej jednym boju”. W mojej ocenie – a mam nadzieję, że udało mi się do tego także przekonać choć kilka osób – architekt może znacznie więcej. Choć to więc koniec epopei, to na pewno nie koniec możliwości. Trzymam kciuki!

Pozostaw komentarz