Business Case dla Enterprise Architecture

Data: 2014-09-03
Autor: Sebastian Konkol
Business Case dla Enterprise Architecture

Wiele razy – na wystąpieniach, konferencjach i w czasie prac dla moich klientów – byłem świadkiem opowieści o uzasadnieniu biznesowym dla poniesienia kosztów przygotowania, wdrożenia i „użytkowania” podejścia architektonicznego (EA, Enterprise Architecture) do kształtowania i rozwoju systemów teleinformatycznych, szczególnie w sferze strategicznej. W przytłaczającej większości przypadków takie uzasadnienia opierały się na założeniach, które określam jako naiwne – oszczędnościach uzyskanych dzięki nierobieniu tych samych rzeczy wielokrotnie. Siła wpływu EA jest jednak znacznie większa, a potencjał korzyści – wyrażony w kategoriach finansowych – o rzędy wielkości większy, niż wynikający z tych naiwnych wyliczeń.

Powszechnie wartość monetarna EA utożsamiana jest ze zdolnością do identyfikacji „tego, co już mamy” oraz łatwością ponownego wykorzystania tych elementów. Naiwność takiego spojrzenia polega jednak na tym, że – dla niemal każdego systemu informatycznego – funkcje dostępne w każdym systemie (np. uwierzytelnienie, którego usunięcie ma zapewnić SSO) są tam po prostu dostępne, a w rzeczywistości ich „centralizacja” podnosi koszty. Dostawca systemu musi bowiem dokonać integracji, „wpasowując się” w logikę działania takich funkcji współdzielonych. Jeśli już bezpośrednie oszczędności mają być podstawą dla uzasadnienia biznesowego EA, to pole do popisu jest znacznie szersze. Nie tyle zdolność wytworzenia usług współdzielonych powinna być wyznacznikiem uzasadnienia, ale – znacznie szerzej:

  • zdolność do standaryzacji i konsolidacji – od poziomu infrastruktury po reguły automatyzacji procesów biznesowych;
  • zdolność do świadomego zarządzania cyklem życia technologii – przede wszystkim identyfikacji momentu w czasie, w którym przejście z technologii starzejącej się na nową jest optymalne kosztowo;
  • umiejętność wyliczania długu technologicznego i ryzyka związanego z posiadaniem technologii i zależności od niej – minimalizacja tego ryzyka wyrażana w bardzo twardych, finansowych kategoriach;
  • interoperacyjność, łatwość uzyskania potencjału niezagrożonej współpracy systemów pomimo zmian zachodzących w ich otoczeniu i ich samych – minimalizacja kosztów dostosowywania do zachodzących zmian.

Nawet takie, czysto finansowe spojrzenie na potencjał strategiczny EA traktuję jednak jako najpłytszy, rzekłbym nawet strywializowany poziom wyznaczenia wartości dostarczanej przez Enterprise Architecture.

Bardzo ciekawym podejściem do wyrażania strategicznej wartości EA jest oparcie na niej bezpieczeństwa środowiska informatycznego pod względem zależności od dostawców:

  • kontrola zasięgu wpływu poszczególnych dostawców tak, aby firma nie uzależniała się w zbyt dużym stopniu od żadnego z nich i aby żaden z nich nie uzyskał „pozamerytorycznych” argumentów w czasie „przeróżnych dyskusji”.

Uzasadnienie opiera się na minimalizacji zasięgu wpływu pojedynczego dostawcy (sprzęt, licencje, systemy na zamówienie, usługi utrzymania, usługi doradcze, kumulacja wiedzy „wyciekającej” i traconej przez firmę) tak, aby firma nie pozbawiła się zdolności do korzystania z zalet konkurencyjności rynku dostawców. Realizacje, w których uczestniczyłem, opierały się na przykład na oddzielaniu stabilnych procesów podstawowych (tzw. core) i zmiennych procesów „buforujących” (tzw. front-end) oraz na takim „rozdzieleniu” rozwoju wsparcia informatycznego, aby żaden z dostawców nie obejmował kilku współzależnych procesów core, ani też łańcucha procesów core i buforujących.

Kolejnym ciekawym podejściem do uzasadnienia jest zdolność wykorzystania istniejących już – choć mało się o tym mówi – wzorców architektury dla realizacji modeli biznesowych. W zależności na przykład od przyjętego podejścia do wzrostu firmy (np. akwizycja vs. rozwój organiczny) można dobrać wzorzec całego środowiska informatycznego, trybów integracji komponentów, zasad ich współpracy, jaki najlepiej wspiera taki właśnie model. Uzasadnieniem jest tu więc:

Wiele branż – badając wiele zróżnicowane modele organizacyjne, a nawet strategie ekspansji biznesowych – dopracowało się stosunkowo precyzyjnych i spójnych definicji sposobu kształtowania środowiska informatycznego firm. Można korzystać z istniejącej mądrości, zamiast wymyślać koło od początku, ponosząc koszty nauki i nieuniknionego popełniania błędów.

Na deser jedna z moich ulubionych wizji wykorzystania EA do kształtowania środowiska informatycznego firm, czyli sandbox. O współczesnym biznesie można powiedzieć wiele – na pewno także to, że dynamika rynków falsyfikuje większość ze zdolności przewidywania zachowań odbiorców produktów i usług. Skuteczność badań marketingowych jest już kwestionowana tak powszechnie, że mój szacunek dla firm, którym udaje się ciągle z tego żyć, rośnie z każdym dniem. Jak tu może pomóc EA:

  • konstrukcja środowiska, w którym za podstawową cechę uznaje się zdolność do eksperymentowania, separowania eksperymentalnych procesów, produktów od mainstreamowych, bez konieczności budowy oddzielnych rozwiązań dla każdego z eksperymentów.

Koncepcja taka jest technologicznie (np. BlueGreenDeployment, Martin Fowler) i organizacyjnie przejrzysta, a jej korzyści dla firm o dynamicznym charakterze oferty – bezsprzeczna. Tutaj wyliczenia uzasadnienia opierać się powinny na obniżeniu kosztów wprowadzania nowego produktu, zwiększeniu przychodów z lepiej dopracowanych produktów i minimalizacji ryzyka nietrafienia w potrzeby klientów po istotnej inwestycji.

 

Enterprise Architecture to filozofia opisu i kształtowania rozwiązań informatycznych, o potężnej potencjalnej sile wyrazu, w większości niedocenianej lub wręcz niedostrzeganej. Jest to jednak tylko narzędzie i – jak w przypadku każdego narzędzia – potencjał narzędzia może być wykorzystany lub nie. Spektrum możliwości, w jakich EA może wzbogacić zrozumienie biznesu i zapewnić właściwe dla niego wsparcie, jest tożsame z niemalże całym modelem biznesowym. Uzasadnienie biznesowe dla EA obejmuje więc cały model biznesowy.

Pozostaw komentarz