A teljes újraírás csábító. De mikor indokolt valójában?

Kevés mondat hangzik olyan megkönnyebbülést ígérően egy nehéz rendszerben, mint ez:

„Ezt inkább írjuk újra."

Teljesen érthető, hogy egy idő után felmerül ez a gondolat.

A régi rendszer nehezen változtatható. A kódot nehéz megérteni. Minden módosítás újabb hibákat hoz magával. A fejlesztők óvatosan nyúlnak hozzá, a vezetőség pedig azt látja, hogy egyre több idő és pénz megy el ugyanarra a problémára.

Az újraírás ilyenkor tiszta lapnak tűnik.

Az elmúlt években azonban azt láttam, hogy a teljes újraírás sok esetben nem a probléma megoldása, hanem a problémától való menekülés vágya.

Néha valóban ez a legjobb út. De ezt nem abból lehet eldönteni, hogy a jelenlegi kód kellemetlen vagy régi.

A régi rendszer általában többet tud, mint amennyi le van írva

Egy működő üzleti rendszer sok év alatt rengeteg szabályt, kivételt és alkalmazkodást gyűjt össze.

Ezek egy része dokumentációban szerepel. Sok más része viszont csak a kódban, az adatbázisban, az integrációkban vagy néhány tapasztalt ember fejében létezik.

Egy újraírás során nemcsak a látható funkciókat kell újra elkészíteni. Meg kell érteni azt is, hogy a rendszer milyen implicit elvárásokat szolgál ki.

Ki használja az egyes adatokat? Melyik partner milyen formátumot vár? Milyen ritka, de fontos kivételek vannak? Mi történik egy sikertelen feldolgozás után? Melyik folyamatnál fogadja el az üzlet a kézi beavatkozást?

Ezek a kérdések általában nem a projekt elején jelennek meg. Hanem akkor, amikor az új rendszer már elkészültnek tűnik, és kiderül, hogy valami fontos még hiányzik belőle.

Amikor az új rendszer mellett még sokáig él a régi

Egy teljes újraírás szinte soha nem azt jelenti, hogy egyik napról a másikra lekapcsoljuk a régi rendszert, és bekapcsoljuk az újat.

A valóságban a két rendszer gyakran hónapokig vagy évekig párhuzamosan működik.

Közben adatokat kell mozgatni, integrációkat kell fenntartani, eltérő működéseket kell összehangolni, és a felhasználóknak egyszerre kell kétféle rendszerhez alkalmazkodniuk.

Ez önmagában nem érv az újraírás ellen. De fontos felismerni, hogy az új rendszer felépítése csak a munka egyik része.

A másik része az átállás: hogyan marad működőképes az üzlet, miközben a háttérben megváltozik a rendszer?

Mikor lehet indokolt a teljes újraírás?

A teljes újraírás akkor lehet ésszerű döntés, ha a jelenlegi rendszer alapvető korlátai már nem kezelhetők célzott változtatásokkal.

Ilyen helyzet lehet például:

• a rendszer alapvető adatmodellje már nem képes támogatni az üzleti működést;
• a biztonsági vagy megfelelőségi követelmények nem teljesíthetők ésszerűen;
• a rendszer olyan technológiai környezetre épül, amelyet már nem lehet biztonságosan üzemeltetni;
• a működés kritikus részei csak egyetlen ember tudásától függenek;
• a teljesítmény- vagy rendelkezésreállási korlátokat nem lehet fokozatosan megszüntetni;
• a rendszer szerkezete miatt minden további változtatás aránytalanul kockázatos;
• a termék üzleti iránya alapvetően megváltozott, és a jelenlegi rendszer már nem illeszkedik hozzá.

Ezekben az esetekben sem az a következő lépés, hogy azonnal elkezdjük újraépíteni a rendszert.

Először azt kell megérteni, hogy valóban a teljes rendszer cseréje szükséges-e, vagy csak egy kritikus részé.

Az újraírás három veszélyes téveszméje

„Az új rendszer gyorsabb lesz"

Lehet, de önmagában az új technológia nem oldja meg a rosszul megértett üzleti szabályokat, a bizonytalan prioritásokat vagy a hiányos tesztelést.

Egy új rendszer ugyanazokat a rossz döntéseket is képes újra létrehozni, csak modernebb eszközökkel.

„Most már tudjuk, mit kell építeni"

Gyakran éppen az újraírás közben derül ki, hogy még nem tudjuk pontosan.

A régi rendszer hibái és korlátai láthatóak, de attól még nem biztos, hogy világos, milyen működésre van szüksége az üzletnek öt év múlva.

Ha a követelmények folyamatosan változnak, akkor egy nagy, hosszú projekt különösen kockázatossá válik.

„Majd az új rendszerben minden jobb lesz"

Ez inkább kívánság, mint terv.

Az új rendszer akkor lesz jobb, ha előre meghatározzuk, mit jelent a jobb: gyorsabb kiadásokat, kevesebb hibát, könnyebb üzemeltetést, jobb skálázhatóságot vagy egyszerűbb integrációkat.

Ha ezek nincsenek kimondva és mérhetővé téve, akkor az új rendszer értékelése könnyen csak benyomások alapján történik.

Az inkrementális modernizáció gyakran kisebb kockázatú

Sok esetben nem kell egyszerre lecserélni mindent.

Lehet, hogy érdemes:

• egy kritikus modult különválasztani;
• egy régi integrációt fokozatosan lecserélni;
• a legfontosabb üzleti folyamatot új tesztekkel lefedni;
• egy új felületet a régi rendszerre építve kialakítani;
• az adatbázis egy részét lépésenként átalakítani;
• a kiadási és megfigyelhetőségi folyamatot először rendbe tenni.

Ezek a változtatások nem mindig olyan látványosak, mint egy teljes új platform bejelentése.

Cserébe gyorsabban adhatnak visszajelzést, kisebb üzleti kockázattal járnak, és közben segítenek jobban megérteni, milyen irányban érdemes továbbmenni.

Több olyan helyzettel találkoztam, ahol az első célzott változtatás után vált világossá, hogy a teljes újraírás egyáltalán nem szükséges. Máskor éppen egy fokozatos modernizáció mutatta meg, hogy a rendszer egy bizonyos része valóban nem menthető ésszerű ráfordítással.

A sorrend fontos.

Négy kérdés az újraírás előtt

Mielőtt egy vezetőség teljes újraírás mellett dönt, érdemes választ adni négy kérdésre.

Mi az a konkrét üzleti probléma, amelyet az új rendszernek meg kell oldania?

Ha erre csak annyit tudunk mondani, hogy „a régi rendszer rossz", akkor még nincs meg a megfelelő kiindulópont.

Melyik korlátot nem lehet célzott változtatással megszüntetni?

Nem az egész rendszernek kell feltétlenül rossznak lennie. Lehet, hogy csak egy alapvető szerkezeti probléma akadályozza a működést.

Hogyan marad működőképes az üzlet az átállás alatt?

A migráció, az adatkezelés, az integrációk és a visszaállási lehetőségek nem későbbi részletek. Már a döntés részei.

Miből fogjuk tudni, hogy az új rendszer valóban jobb lett?

A „modernebb" önmagában nem eredmény. Meg kell határozni, milyen üzleti és technikai mutatók javulását várjuk.

Nem a régi rendszert kell megvédeni

A teljes újraírás elutasítása nem jelenti azt, hogy minden régi rendszert védeni kell.

Vannak rendszerek, amelyek már nem szolgálják megfelelően az üzletet, és a javítgatásuk csak tovább növeli a költséget és a kockázatot.

A kérdés nem az, hogy régi vagy új a rendszer.

A kérdés az, hogy:

• mi akadályozza most a működést;
• mely korlátok kezelhetők;
• milyen kockázattal jár a változtatás;
• és melyik út adja a legjobb eredményt a rendelkezésre álló idő és erőforrás mellett.

Én ezért a teljes újraírásról sem technológiai, sem érzelmi alapon nem szeretek dönteni.

Először meg kell érteni a jelenlegi rendszert, az üzleti működést és a valódi korlátokat. Ezután lehet eldönteni, hogy célzott modernizációra, fokozatos cserére vagy valóban egy új rendszerre van szükség.

A teljes újraírás néha a legjobb döntés.

De csak akkor, ha nem azért választjuk, mert a jelenlegi rendszerrel nehéz dolgozni, hanem azért, mert bizonyíthatóan ez jelenti a legkisebb kockázatú és legjobb megtérülésű utat.