Agilní architektura – Agilia 2014 reflexe 03

Když přemýšlím o nasazení agilního přístupu do velké organizace typu banka, vždy dojdu k tomu, že změna nebude jednoduchá.

A to nejen kvůli lidem (jak jsem psal v předchozích příspěvcích), ale i díky tomu jak vypadá aplikační architektura velkých firem.

Podle mých zkušeností jde často o shluk rozsáhlých, dlouho vyvíjených, pravidelně „ohýbaných“ aplikací pospojovaných různým způsobem. Většina takových aplikací v sobě sdružuje obrovské množství funkcí pro koncové uživatele a většinou (díky tomu) dospěje do stavu, že jakákoliv změna je drahá a trvá dlouho, často změna v jedné části rozbije část jinou, je třeba nákladných a komplexních testů a většinou systém nedělá žádnou ze svých funkcí k plné spokojenosti svých uživatelů. V posledních letech se pak celý ekosystém, ve jménu znuvupoužitelnosti a flexibility, rozšiřuje o různé procesní a workflow engine, budují se sdílené služby atd. Moje zkušenost je taková, že nasazením těchto systémů se výsledné služby pro koncové uživatele většinou zhorší (systém je pomalejší, častěji nefunguje), vývoj se nezlevní a navíc se do celého procesu zapojí systém, nad kterým nemá nikdo jasnou převahu (poměrně často se tyto systémy chovají jinak, než by měly, a najít někoho kdo umí zjednat nápravu je často velmi složité a drahé). Navíc jsem hluboce přesvědčen o tom, že v dnešní době investovat peníze do něčeho co slibuje, že díky této investici to bude flexibilní a pokryje požadavky i za 5 a více let je nesmysl. Minimálně u všech oblastí, které se dynamicky mění – stačí se podívat jakou změnu přinesly chytré telefony, tablety, sociální sítě…. Jsou samozřejmě oblasti, které se nemění (nebo mění jen velmi pomalu). Tam je samozřejmě potřeba budování prostředí připraveného na změnu výrazně menší a je to i oblast kde často vyhovuje i klasický vodopádový přístup.

Můj pohled na věc je takový, že je třeba budovat řešení, která jsou implementována rychle, levně, plní přesně jeden nebo velmi málo účelů. V případě zásadní změny se aplikace zahodí a napíše nová (stála málo, tak to tolik nebolí). Uživatelé pak mají to, co potřebují, nevzniká technologický dluh, při dodržení jasně stanovených podmínek pro to jak psát, komentovat, dokumentovat kód se aplikace i jednoduše udržují. Zbývá jen zařídit, aby byla chráněna důležitá data a aby uživatelé neměli problém s tím, že používají mnoho aplikací. Jako hlavní kameny architektury chráněné dostatečnou správou pak zůstávají oblasti:

  • master data managementu pro core data – existuje k nim cesta jedině přes Data interface – bez výjimek,
  • coding practices a definition of DONE pro vývoj aplikací tzn. dohoda o tom, jak pracujeme,
  • UIX standardy – dohoda o tom jak se aplikace chovají k uživatelům, jde spíše o logiku používání aplikace než o definici barevného schématu.

Tato domluvená pravidla musí být v podobě minimální potřebné množiny, zato musí být tvrdě vyžadováno jejich naplnění (málo pravidel, málo administrativy, častá kontrola, striktní vyžadování dodržování, žádné výjimky).

Schématický jsem svoji představu shrnul do konceptu „Wheel architecture“ – analogie s představou kola a v angličtině to zní o něco lépe 🙂

 

Wheel architecture

One thought on “Agilní architektura – Agilia 2014 reflexe 03

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit /  Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit /  Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit /  Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit /  Změnit )

w

Připojování k %s