„Mennyibe fog kerülni a COBOL-ról való átállás?" ez az első kérdés, amit minden igazgatóság feltesz, és az őszinte válasz az, hogy többtől függ, mint a kódbázis mérete. Ez az útmutató lebontja, hogy valójában mitől függ a COBOL migráció költsége az Egyesült Királyságban, milyen reális büdzsé- és ütemtervsávok vannak, és milyen kockázatok fordítanak egy jól megtervezett projektet túllépésbe.
TL;DR
- Egy közepes méretű brit COBOL migráció jellemzően 200 000 és 800 000 font sterling közé esik, és egy-két évig tart; a teljes nagygépes leszerelések milliókba és több évbe kerülnek
- A költséget sokkal inkább a kódbázis komplexitása, a dokumentálatlan üzleti logika és az adathozzáférési réteg újratervezése hajtja, mint a puszta sorszám
- A célnyelv és a migrációs megközelítés megválasztása érdemben megváltoztatja a büdzsét
- A túllépések leggyakoribb oka a hatókör alábecslése, különösen a dokumentálatlan üzleti szabályoké és az adathozzáférési rétegé
Mi hajtja valójában a COBOL migráció költségét
A sorszám a főcím-szám, de önmagában gyenge előrejelző. A valódi költségtényezők:
A komplexitás, nem csupán a méret. Egy 100 000 soros, tiszta kötegelt programokból álló rendszert olcsóbb migrálni, mint egy 50 000 soros rendszert, amely sűrűn tele van EXEC CICS-szel, dinamikus CALL-okkal és bonyolult REDEFINES-okkal. A tranzakciófeldolgozó rendszerek többe kerülnek, mint az azonos méretű kötegelt rendszerek.
A dokumentálatlan üzleti logika. A COBOL-rendszerek gyakran 30-40 év üzleti szabályát hordozzák a kódba ágyazva, külső dokumentáció nélkül. E szabályok újrafelfedezése és validálása gyakran a legnagyobb és legkevésbé kiszámítható tétel.
Az adathozzáférési réteg. A DB2 elleni EXEC SQL és a VSAM fájlkezelés ritkán konvertálódik automatikusan. Ezeket a célplatform adathozzáférési technológiájára kell újratervezni, és ez az üzleti logika felfedezése után gyakran a legnagyobb munkatétel.
Az adatformátum-konverzió. A csomagolt decimális (COMP-3), az EBCDIC kódolás és a fix szélességű elrendezések mindegyike explicit leképezést és valós adatokkal végzett tesztelést igényel.
A célnyelv és a megközelítés. Ezek kiszámítható módon tolják el a büdzsét (lásd lentebb).
Tesztelés és éles átállás. Egy olyan regressziós tesztkészlet felépítése, amely bizonyítja a kimeneti egyezést, valamint egy biztonságos, visszaállítható éles átállás végrehajtása valódi, nem triviális erőfeszítés, amelyet a tapasztalatlan becslések kihagynak.
Irányadó költség- és ütemtervsávok (UK)
Ezek a sávok lefedik az elemzést, a migrációt, a tesztelést és az élesítési támogatást. Nem tartalmazzák a folyamatos üzemeltetési költségeket, a képzést és a projekt közepén gyakran felszínre kerülő downstream integrációs munkát.
| Rendszerméret | Megközelítés | Becsült költség | Jellemző ütemterv |
|---|---|---|---|
| Kicsi (< 50 000 sor) | Párhuzamos újraírás | 80 000 – 200 000 font sterling | 3–9 hónap |
| Közepes (50 000 – 500 000 sor) | Strangler fig | 200 000 – 800 000 font sterling | 12–24 hónap |
| Nagy (500 000+ sor) | Automatizált + inkrementális refaktorálás | 500 000 – 2 000 000+ font sterling | 2–4 év |
| Legacy nagygép leszerelése | Teljes program | 1 000 000 – 10 000 000+ font sterling | 3–5 év+ |
Kezelje ezeket tervezési sávokként, ne árajánlatokként. A megfelelő becsléshez kódfelmérés kell; az egyes sávokon belüli szórást a fenti komplexitási tényezők határozzák meg.
Hogyan befolyásolja a költséget a célnyelv
A célnyelv megváltoztatja mind a ráfordítási profilt, mind a hosszú távú birtoklási költséget. Nagy vonalakban:
- Python természetesen leképeződik a COBOL procedurális stílusára, és rendelkezik a legnagyobb fejlesztői bázissal, ami hajlamos csökkenteni a konverziós és a hosszú távú karbantartási költséget.
- C# hatékony a már .NET és Azure stacken lévő szervezeteknek, és natív
decimaltípusa csökkenti a pénzügyi pontosság helyes eltalálásának erőfeszítését. - Java a JVM-alapú vállalatoknak felel meg; a
BigDecimalhelyesen kezeli a pontosságot, de némi bőbeszédűséget ad hozzá. - Go hatékonyan építhető és telepíthető, de a natív decimális típus hiánya többlet ellenőrzési erőfeszítést ad a pénzügyi mezőkhöz.
- Rust minden méretsáv felső végéhez hajlik, mert az ownership-modellje előzetes tervezési erőfeszítést ad hozzá.
A COBOL migrációs áttekintés mind a hat célnyelvet egymás mellett hasonlítja össze, hogy segítsen a választásban.
Hogyan befolyásolja a költséget a migrációs megközelítés
- Az automatizált konverzió csökkenti a mechanikus fordítási erőfeszítést, de sosem állít elő kész rendszert; tervezze be a kézi munkát, amit az eszközök megjelölnek (beágyazott SQL, CICS, dinamikus hívások, decimális pontosság).
- A párhuzamos újraírás nagyjából megkétszerezi az üzemeltetési költséget az átmenet alatt, mert két rendszer fut egyszerre, de minimalizálja a folytonossági kockázatot. A kisebb, üzletileg kritikus rendszerekhez illik.
- Az inkrementális (strangler fig ) időben elosztja a költséget és csökkenti a big-bang kockázatot, egy hosszabb hibrid időszak áráért. Ez a leggyakoribb megközelítés a nagy brit vállalati rendszerekhez.
A legtöbb valós projekt vegyíti az automatizált konverziót az inkrementális bevezetéssel.
A túllépéseket okozó kockázatok
A migrációk kiszámítható okokból lépik túl a keretet. Az öt nagy:
- Alábecsült üzleti logika felfedezése. A szabályok a kódban vannak, nem egy dokumentumban. Tervezzen be explicit felfedezési időt.
- Az adathozzáférés újratervezése. A DB2- és VSAM-hozzáférés nem portolódik automatikusan. Kezelje saját munkafolyamként.
- Elégtelen regressziós tesztelés. Valós adatokon végzett kimeneti egyezés tesztelése nélkül nem tudja bizonyítani, hogy a migráció helyes. Építse fel a tesztkészletet, mielőtt a migráció elkezdődik.
- Decimális pontossági hibák. A lebegőpontos típusokra leképezett pénzügyi mezők csendben megrontják a pénzt. Képezze le a célnyelv helyes decimális típusára.
- Éles átállás kudarca. Az éles rendszerre való átváltás a legnagyobb kockázatú pillanat. Egy részletes, visszaállítást és egyeztetést tartalmazó átállási terv kötelező.
Hogyan kapjon pontos becslést
A megbízható szám kódfelmérésből származik, nem sorszámlálásból. Egy jó felmérés leltárba veszi a programokat és copybookokat, azonosítja az EXEC SQL / EXEC CICS / dinamikus hívás gócpontokat, méri az üzleti logika sűrűségét, és feltérképezi az adathozzáférési felületet. A Mecanik COBOL migrációs szolgáltatás
brit vállalati felméréseket és teljes körű migrációt biztosít; IBM z/OS-en futó nagygépes állományokhoz a legacy nagygépes migrációs szolgáltatás
a kód mellett az infrastruktúra leszerelését is lefedi.
Fő tanulságok
- Egy közepes méretű brit COBOL migráció jellemzően 200 000 és 800 000 font sterling közé esik egy-két év alatt; a nagygépes leszerelések milliókba kerülnek.
- A komplexitás, a dokumentálatlan üzleti logika és az adathozzáférés újratervezése sokkal inkább hajtja a költséget, mint a sorszám.
- A célnyelv és a migrációs megközelítés egyaránt kiszámítható módon mozdítja a büdzsét.
- A túllépések a felfedezés, a tesztelés és az éles átállás alábecsléséből származnak; a megfelelő kódfelmérés az egyetlen megbízható alap egy árajánlathoz.
Kapcsolódó bejegyzések: Mainframe-modernizáció: rewrite, refactor vagy replatform , COBOL-Java migráció - Vállalati útmutató (UK) .
Gyakran ismételt kérdések (GYIK)
Mennyibe kerül egy COBOL migráció az Egyesült Királyságban? Egy kis rendszer jellemzően 80 000 – 200 000 font sterlingbe kerül, egy közepes rendszer 200 000 – 800 000 font sterlingbe, a nagy rendszerek pedig 500 000-től felfelé. A teljes nagygépes leszerelési programok 1 000 000-tól a több tízmillióig terjednek. A komplexitás, nem a sorszám dönti el, hol helyezkedik el a sávon belül.
Meddig tart egy COBOL migráció? A kicsi, jól dokumentált rendszerek három – kilenc hónapig tartanak. A közepes méretű vállalati rendszerek tizenkét – huszonnégy hónapig futnak. A nagy nagygépes programok három – öt évig vagy tovább tartanak a teljes leszerelésig.
Miért ingadoznak ennyire a COBOL migráció költségei? Mert a komplexitás óriási mértékben változik. A dokumentálatlan üzleti logika, a beágyazott SQL és CICS, az adatformátum-konverzió, a célnyelv és a migrációs megközelítés mind eltolja a költséget. Két azonos sorszámú rendszer nagyságrendekkel eltérhet.
Csökkenti-e a költséget az automatizált konverzió? Csökkenti a mechanikus fordítási erőfeszítést, de egyetlen eszköz sem állít elő kész rendszert. Továbbra is be kell terveznie az adathozzáférési réteget, a decimális pontossági döntéseket, a tesztelést és az éles átállást, amelyeket az eszközök kézi munkára jelölnek meg.
Mi a COBOL migrációs túllépések legnagyobb oka? A hatókör alábecslése, különösen a dokumentálatlan üzleti logikáé és az adathozzáférés újratervezéséé. Egy kimeneti egyezésre szolgáló regressziós tesztkészlet felépítése a migráció megkezdése előtt a leghatékonyabb módja e kockázat kezelésének.
Hozzászólások