Vállalati Szoftverfejlesztés: Mit Vásárol Valójában

A vállalati szoftverfejlesztés, ahogy a kifejezést a legtöbb ügynökségi oldalon használják, ugyanazt a munkát jelenti egy nagyobb számmal mellette. A csapat ugyanaz, a folyamat ugyanaz, a bemutató kap egy logófalat, az ár pedig megháromszorozódik. A vevők ezt tudják, és a beszerzési osztályok éppen ezért tanulták meg, hogy a szót figyelmen kívül hagyják, és inkább a szerződéses mellékleteket olvassák.

Alatta mégis van valódi különbség, és az nem a cégmérethez kötődik. Egy negyven fős biztosító futtathat valóban vállalati programot, egy tizenkétezer fős kereskedő pedig megrendelhet olyasmit, ami valójában csak egy weboldal. Ami elválasztja őket, az a kötelezettségek köre, amelyet a rendszer ró arra, aki megépíti: hány másik rendszerrel kell beszélnie, meddig állhat le, ki vétózhat meg egy kiadást, melyik hatóságnak van érdekeltsége benne, és mi történik, ha a szállító távozik.

Az alábbiak ezekkel a kötelezettségekkel határozzák meg a kategóriát, hogy a vevő meg tudja különböztetni azt a szállítót, aki elbírja őket, attól, aki hétköznapi fejlesztést árul vállalati borítólappal.

Mitől lesz egy szoftverprojekt valóban vállalati? Nem a vevő méretétől. Egy projekt akkor vállalati, ha olyan korlátokat hordoz, amilyeneket egy hétköznapi fejlesztés nem: széles integrációs felület, szerződéses rendelkezésre állási és helyreállítási kötelezettség, szabályozói kitettség, több érintetti csoport, amelyek mindegyike megállíthat egy kiadást, olyan adatmennyiség, amely szétveri a naiv terveket, és az az elvárás, hogy együtt éljen olyan rendszerekkel, amelyeket jelenleg senki nem ért. Az architektúrát és a költség nagy részét ezek a korlátok döntik el, nem a funkciólista.

Mitől lesz vállalati egy projekt

A használható próba egy korlátlista, és egy projekt akkor felel meg, ha a többségüket hordozza, nem csupán egyet. Őszintén alkalmazva kizárja annak nagy részét, amit vállalatiként adnak el, és bevonja azt a munkát, amit kis fejlesztésként adtak el, majd épp ezért bukik el.

Az integrációs felület

Számolja meg, hány rendszerrel kell adatot cserélnie az új szoftvernek, majd számolja meg, hány külön csapat vagy szállító birtokolja ezeket a rendszereket. A második szám az, amelyik a költséget előrejelzi. Három integráció egyetlen belső csapat kezében két hét munka. Három integráció három szállító kezében, mindegyiknél saját változtatási ablakkal, saját tesztkörnyezeti elérhetőséggel és saját ügyfélszolgálattal, egy negyedév.

Minden tulajdonos hoz magával egy naptárat, amelyet nem Ön irányít. Az a szállító, akinek a tesztkörnyezete havonta frissül, megszabja az Ön tesztelési ritmusát, és az a fizetési szolgáltató, akinek a minősítése hat hétig tart, megszabja az élesítés dátumát. Egy tucat partnernél az integrációs naptár lesz a projektterv, a fejlesztés pedig a résekbe illeszkedik.

A rendelkezésre állási kötelezettség

A hétköznapi szoftvertől azt várjuk, hogy működjön. A vállalati szoftvernél ehhez az elváráshoz szám tartozik, rendszerint szerződésben, mögötte jóváírással. A szám először az architektúrát változtatja meg, mert egyetlen példányon futó telepítés nem tudja teljesíteni, akármilyen jó is a kód.

A lépés attól a céltól, amely elvisel egy karbantartási ablakot, addig, amelyik nem, a legdrágább egyetlen tétel a legtöbb vállalati költségvetésben, és gyakran olyanok fogadják el, akik sosem látták az árát. A valamit is jelentő rendelkezésre állási SLA-król szóló írásunk bemutatja, hogyan írják meg ezeket a számokat, és milyen rendszeresen írják meg rosszul.

Vétójoggal bíró érintettek

Egy hétköznapi projektnek van egy termékgazdája. Egy vállalati projektnek van termékgazdája, információbiztonsági funkciója, adatvédelmi tisztviselője, beszerzési vezetője, infrastruktúracsapata, amely a hálózatot birtokolja, ügyfélszolgálata, amely örökli a támogatási terhet, és gyakran klinikai, jogi vagy megfelelőségi ellenőre is.

Bármelyikük megállíthat egy kiadást, és egyikük sem annak jelent, aki a munkát fizeti. A döntések ezért olyan naptári időt vesznek igénybe, aminek semmi köze ahhoz, mennyire nehezek, és az a szállító, aki ezzel nem számolt a tervben, a második hónaptól minden határidőt elvét.

A rendszerek, amelyeket már senki nem ért

Minden vállalati rendszerparkban van legalább egy rendszer, amelynek viselkedését csak a kimenete dokumentálja. Akik megírták, elmentek, a specifikáció pedig, ha létezik egyáltalán, egy korábbi változatot ír le. Működik, teherhordó, és a módosítását meggondolatlanságnak tartják.

Az új szoftvernek együtt kell élnie vele, tehát valakinek először meg kell állapítania, mit csinál valójában. Ez régészet, nem fejlesztés: éles adatok olvasása, hívások követése, ellenőrzött kísérletek futtatása egy másolaton, és annak leírása, milyen szabályokat sugall a kód. Egy nagy parkon ez hetekbe telik, és ez az a tétel, amelyet a tárgyaláson a leggyakrabban törölnek, mert nem hoz létre látható funkciót.

A törlése átteszi a munkát az integrációs tesztelésbe, ahol időnyomás alatt fedezik fel olyanok, akik már amúgy is hibákat javítanak. Az a szállító, aki a felderítést külön árazza és meg is védi, valami igazat mond arról, hogyan buknak meg ezek a programok. A régi rendszerek korszerűsítéséről, valamint az újraírás és az átalakítás közötti döntésről szóló jegyzetünk bemutatja, mit talál ez a régészet.

A beszerzés a munka fele

A legtöbb műszaki ember ezt a részt háromszoros szorzóval becsüli alá. Egy valóban vállalati megbízásnál az első beszélgetés és az első kódsor közötti munka tovább tart, mint az első átadott szakasz, és mindkét oldalon vezetői időt emészt fel.

2025. február 24. óta a brit közszféra a Procurement Act 2023 szerint működik, és a közbeszerzésekre pályázó szállítóknak szerepelniük kell a központi digitális platformon, a kibővített Find a Tender szolgáltatáson belül. A magánszektor beszerzésének nincs ezzel egyenértékű egységes bejárata, ami paradox módon lassabbá teszi, mert minden vevő kitalálta a sajátját.

A biztonsági kérdőív

Kapni fog egy táblázatot. Kérdezni fog a fejlesztési életciklusáról, a hozzáférési kontrolljairól, a javítási ütemezéséről, az alvállalkozóiról, az adatai tárolási helyéről, az incidensválaszidőiről és a munkatársak háttérellenőrzéséről. A nagyobb vevők több száz kérdést küldenek, egy bank vagy egy NHS-intézmény pedig még többet.

A kérdések nem nehezek, de csak akkor válaszolhatók meg, ha a válaszok már szabályzatként léteznek. Az a szállító, aki először egy pályázat közben állítja össze őket, négy-hat hetet tölt vele, és többet elront. Aki már csinálta, néhány nap alatt válaszol egy karbantartott válaszkönyvtárból, ami jogos ok arra, hogy őt részesítsék előnyben.

Szállítói regisztráció, biztosítások és pénzügyi ellenőrzés

A regisztráció elkülönül a pályázattól, és gyakran azzal párhuzamosan fut. Számítson rá, hogy igazolnia kell szakmai felelősségbiztosítást és kiberfelelősség-biztosítást a vevő által megadott szinten, munkáltatói felelősségbiztosítást, néha pedig termékfelelősséget is. A vállalati vevők rendszerint olyan kártérítési limiteket kérnek, amelyeket egy kis tanácsadó alapból nem tart, a fedezet emelése pedig a pályázat közepén időbe telik.

Ezután jönnek a pénzügyi ellenőrzések. A vevők lekérik a letétbe helyezett beszámolókat, hitelminősítést futtatnak, nagyobb szerződéseknél pedig vezetői jelentéseket vagy anyavállalati garanciát kérnek. Azt a szállítót, akinek a mérlege nem bírja el a szerződés értékét, műszaki érdemtől függetlenül kizárják, és ezért veszítenek el alkalmas kis cégek olyan pályázatokat, amelyekre valóban ők voltak a helyesek.

Miért tart tovább az értékesítési ciklus az első szakasznál

Tegye egymás mellé a két idővonalat, és a probléma alakja világossá válik. A minősítés, a követelmények, a biztonsági átvizsgálás, a jogi tárgyalás, a biztosítási igazolások és a regisztráció egy több százezer fontos szerződésnél rendszerint négy-kilenc hónapot vesz el. Az első hasznos szoftverszakasz, miután a munka elindul, talán tíz hétig tart.

A ciklus elején írt becslések az aláírásra elavulnak, és az a szállító, aki végig fix árat tart, vagy erősen ráhagy, vagy arra készül, hogy később vitatkozik a hatókörön. A technológiai feltevések is öregszenek, és egy ajánlatkor aktuális verzió az indulásra kifuthat a támogatásból.

Dátumozzon minden becslést, mondja ki a feltevéseit, és az aláíráskor állapodjon meg az újraalapozásról ahelyett, hogy úgy tenne, mintha a szám túlélte volna. Az a vevő, aki ragaszkodik az eredeti összeghez, változtatási kérések sorát vásárolja meg. A hasznos árajánlatokat hozó szoftveres ajánlatkérés megírásáról szóló útmutatónk leírja, minek kell szerepelnie a dokumentumban.

A nem funkcionális követelmények az igazi szállítandó

A funkciólistákat könnyű megírni, és ritkán döntenek el bármit. A nem funkcionális követelmények döntik el az architektúrát, az infrastruktúra számláját, a csapat méretét és a tesztciklus hosszát, a legtöbb vállalati programban mégis két bekezdést tesznek ki egy olyan dokumentumban, amelynek funkciólistája negyven oldal.

Ez az aránytalanság a túllépés legmegbízhatóbb előjele. Az a szállító, aki az első műhelynapot a rendelkezésre állásra, a helyreállításra, a késleltetésre, az átbocsátásra, az auditálhatóságra és a megőrzésre fordítja, nem húzza az időt: az a hat szám kizárja az architekturális lehetőségek nagy részét, késői rögzítésük pedig újraépítést jelent.

Írja meg őket tesztelhető állításként, számmal és feltétellel. A rendszernek magasan rendelkezésre állónak kell lennie nem követelmény. A rendelésszolgáltatásnak havi 99,9 százalékos rendelkezésre állást kell tartania a terheléselosztónál mérve, kivéve egy kétórás ablakot, amelyet öt munkanappal korábban bejelentenek: ez már az, mert egy teszt meg tudja buktatni.

Helyreállítási pont és helyreállítási idő közérthetően

Ez a két szám jobban tolja a költséget, mint bármelyik funkció, és rendszeresen olyanok idézik őket, akik felcserélték a jelentésüket. A helyreállítási pont célértéke az, mennyi adatot hajlandó elveszíteni: az egyórás RPO azt jelenti, hogy elfogadja, hogy egy katasztrófa után akár egy órányi tranzakció eltűnhet, és a mentési vagy replikációs megoldásának ennél rosszabbat nem szabad garantálnia. A helyreállítási idő célértéke az, meddig hajlandó leállva lenni, tehát a négyórás RTO azt jelenti, hogy a szolgáltatás az incidens kezdetétől számított négy órán belül újra forgalmat szolgál ki.

Mindkét szám közvetlenül architektúrára fordul. Az AWS négy nagy stratégiát ír le a katasztrófa utáni helyreállítási útmutatójában: mentés és visszaállítás, őrláng, meleg tartalék, valamint többtelephelyes aktív/aktív. Az olcsó és lassú végponttól a drága és szinte azonnaliig tartanak, és a választás megtörténik Ön helyett, amint a két célérték megvan.

Ne fogadjon el agresszív számokat csak azért, mert felelősségteljesen hangzanak. A nulla RPO perces RTO mellett folyamatos replikációt és egy második éles környezetet jelent, ami nagyjából megduplázza az infrastruktúra számláját. A kis szoftvercsapatok katasztrófa utáni helyreállításáról szóló elemzésünk megmutatja, mit vesznek meg az olcsóbb szintek.

A rendelkezésre állás számtana és amit egy SLA valójában megvesz

A rendelkezésre állási százalékok egy tizedesvessző mögé rejtik a jelentésüket. Egy harminc napos hónapban a 99,9 százalék körülbelül 43 perc leállást enged meg, a 99,95 százalék körülbelül 22 percet, a 99,99 százalék pedig körülbelül 4 percet. Ez az egész hónap kerete, beleértve a telepítéseket, a tanúsítványmegújításokat és azt az adatbázis-átállást, amely a vártnál tovább tartott.

Havi négy perc nem érhető el olyan csapattal, amely munkaidőben telepít, és egyetlen mérnököt riaszt. Minden rétegben redundancia kell hozzá, automatikus átállás, forgalmat meg nem szakító telepítések és valaki, aki hajnali háromkor ébren van. Ez az utolsó tétel általában többe kerül, mint az infrastruktúra, és szinte sosem szerepel az eredeti költségvetésben. Rögzítse a mérési pontot is a szerződésben, mert a terheléselosztónál olvasott rendelkezésre állás és a valós felhasználói telemetriából olvasott rendelkezésre állás ugyanannál az incidensnél nagyságrenddel eltérhet.

Késleltetés, átbocsátás és a terhelés, amelyet senki nem mért meg

A késleltetési célokhoz percentilis és hatókör kell, mert az átlagok elrejtik a hibákat. A fizetési végponton a 95. percentilisen megadott 200 milliszekundumos cél másodpercenként 400 kérés mellett tesztelhető. A gyorsaság mint cél nem az, és az átlag sem, hiszen a 200 milliszekundumos átlag összefér azzal, hogy húsz felhasználóból egy négy másodpercet vár.

Az átbocsátáshoz csúcs kell, nem középérték. A kereskedők a karácsony előtti péntekre méreteznek, a bérszámfejtő rendszerek a hónap utolsó munkanapjára, a közszolgáltatások pedig a kiküldött levélben szereplő határidőre. Az éves átlagra méretezés az a mód, ahogy egy indulás elbukik az első forgalmas órájában. A csúcsot vegye ki a meglévő rendszer naplóiból, ahol a tíz az egyhez arányok gyakoriak, mert ez az arány dönti el, kell-e a tervbe sor.

Auditálhatóság és megőrzés

A szabályozott vevőknek, és egyre inkább a nem szabályozottaknak is, évekkel később meg kell tudniuk válaszolni, ki mit és mikor változtatott. Ez tervezési követelmény, nem naplózási beállítás: az a rendszer, amely felülírja a sorokat, nem tud rá válaszolni, a válasznak pedig annyi ideig kell fennmaradnia, ameddig a megőrzési szabályzat előírja.

Három dolgot döntsön el korán. Mely események auditálhatók, rendszerint a jogi vagy pénzügyi jelentőségű rekordok állapotváltozásai, nem minden HTTP-kérés. Meddig őrzik meg az egyes rekordosztályokat, ami jogi kérdés adatvédelmi korláttal, hiszen a személyes adatok a szükségesnél hosszabb tárolása önmagában jogsértés. És ki olvashatja a nyomvonalat, mert az az auditnapló, amelyet a rendszergazdák szerkeszthetnek, semmit nem bizonyít. A megőrzés és a törléshez való jog itt ütközik, a feszültséget pedig a séma oldja fel, nem a szabályzat.

A tanúsítványok, amelyeket a vevő kérni fog

Három bukkan fel újra és újra, ezeket állandóan összekeverik, és különböző dolgokat bizonyítanak. Az a szállító, aki nem tudja elmagyarázni a különbséget, nem rendelkezik velük.

Cyber Essentials és Cyber Essentials Plus

A Cyber Essentials a brit kormány által támogatott alapszint, amelyet az NCSC dolgozott ki, és amelyet az IASME mint hivatalos végrehajtó partner nyújt. Öt technikai kontrollt fed le: tűzfalak, biztonságos konfiguráció, biztonsági frissítések kezelése, felhasználói hozzáférés-kezelés és kártevővédelem. Az alapszint egy önértékelő kérdőív, amelyet függetlenül átnéznek, az NCSC pedig a szervezet méretétől függően GBP 320 plusz áfa árszinttől ad meg díjakat.

A Cyber Essentials Plus ugyanaz az öt kontroll, csak független műszaki audittal igazolva, nem pedig állítva. Az értékelő belső és külső sérülékenységvizsgálatot futtat, és mintát vesz a felhasználói eszközökből, az internetes átjárókból és az internet felől elérhető kiszolgálókból. A Plus auditot az alaptanúsítástól számított három hónapon belül le kell zárni, és mindkét tanúsítvány tizenkét hónapig érvényes.

A séma üzletileg is annyira számít, mint műszakilag. A PPN 014, amely 2025. február 24. óta hatályos a központi kormányzati tárcáknál, ügynökségeiknél, a nem minisztériumi közintézményeknél és az NHS szervezeteinél, tanúsítást ír elő, ha a szállítók állampolgárok személyes adatait, kormányzati alkalmazottak személyes adatait vagy OFFICIAL szintű adatokat feldolgozó informatikai rendszereket kezelnek.

ISO/IEC 27001

Az ISO/IEC 27001 az információbiztonsági irányítási rendszer nemzetközi szabványa, amelyet az ISO és az IEC ad ki. A jelenlegi kiadás az ISO/IEC 27001:2022, amelyhez a 2024-es 1. módosítás klímavédelmi megfogalmazást fűz a környezeti szakaszokhoz, összhangban egy olyan változtatással, amelyet az ISO valamennyi irányításirendszer-szabványán átvezettek.

Irányítási rendszer szabványa, és a vevők épp ezt a részét olvassák félre. Nem ír elő rögzített kontrollkészletet, amelyet minden tanúsított szervezet bevezetett volna. Azt írja elő, hogy a szervezet határozza meg a hatókörét, mérje fel a kockázatait, válasszon kontrollokat, és futtasson dokumentált felülvizsgálati és fejlesztési ciklust. A tanúsítást akkreditált tanúsító szervezet adja ki audit után, nem maga az ISO.

A hasznos kérdés ezért sosem az, hogy egy szállító rendelkezik-e vele, hanem hogy mit fed le a tanúsítványon szereplő hatóköri nyilatkozat. A központi iroda egyik funkciójára korlátozott hatókör semmit nem mond arról a csapatról, amely az Ön forráskódját és éles hozzáféréseit kezeli. Kérje el a tanúsítványt, és olvassa el a hatókört.

SOC 2

A SOC 2 amerikai, és más természetű. Az AICPA úgy határozza meg, mint jelentést egy szolgáltatásnyújtó szervezet kontrolljairól, amelyek a biztonság, a rendelkezésre állás, a feldolgozás integritása, a bizalmasság vagy az adatvédelem szempontjából lényegesek, és amelyet a saját bizalmi szolgáltatási kritériumai szerint készítenek. Könyvvizsgáló cég által készített tanúsító jelentés, nem tanúsítvány, és nincs sem ponthatár, sem kirakható embléma.

A lényeges különbség a típus. Az 1. típusú jelentés leírja a kontrollokat, és értékeli, hogy egy adott időpontban megfelelően vannak-e kialakítva. A 2. típusú jelentés azt vizsgálja, hogy egy időszakon át hatékonyan működtek-e, rendszerint hat vagy tizenkét hónapon át. Az 1. típus fénykép, a 2. típus film, és az a vevő, aki az 1. típust egyenértékűnek fogadja el, sokkal kevesebbet fogad el, mint gondolja.

Olvassa el a jelentést, ne a borítóját. A kivételek szakasza, ahol az auditor rögzíti azokat a kontrollokat, amelyek nem a leírás szerint működtek, hordozza az információt, és ez az a rész, amelyről a szállítók remélik, hogy átugorja.

Amit egyikük sem bizonyít

A három közül egyik sem tanúsítja, hogy az Ön szoftvere biztonságos. A Cyber Essentials az infrastruktúra higiéniájának alapszintjét fedi le. Az ISO 27001 azt fedi le, hogy a szervezet folyamatként kezeli-e a biztonságot. A SOC 2 azt fedi le, hogy a megnevezett kontrollok működtek-e egy időszakon át. Mindhárom a szállítóra vonatkozik, nem a termékre.

Az alkalmazásbiztonság külön szakterület, külön bizonyítékokkal. A tanúsítványfal helyett kérje el a legutóbbi behatolásteszt jelentését és a javítások állapotát, és nézze meg, ki készítette és milyen hatókörre. Ez az érdemi tartalom a behatolástesztelési szolgáltatásaink mögött.

Szabályozói kitettség ágazatonként

A szabályozás az a pont, ahol az általános vállalati tanácsok veszélyessé válnak. Az alábbiak ellenőrizhető kötelezettségeket neveznek meg, és megállnak a jogi tanácsadás előtt, amelyet szakképzett tanácsadótól érdemes kérni.

UK GDPR, amely majdnem mindenkire vonatkozik

Ha a rendszer személyes adatot érint, az UK GDPR 32. cikke az adatkezelőre és az adatfeldolgozóra egyaránt vonatkozik. Megfelelő technikai és szervezési intézkedéseket követel, és négyet meg is nevez: az álnevesítést és a titkosítást, a feldolgozó rendszerek folyamatos bizalmasságát, sértetlenségét, rendelkezésre állását és ellenálló képességét, azt a képességet, hogy egy incidens után a személyes adatok rendelkezésre állását és az azokhoz való hozzáférést kellő időben helyre lehessen állítani, valamint az intézkedések hatékonyságának rendszeres tesztelésére és értékelésére szolgáló eljárást.

Olvassa el újra a harmadikat, mert az a katasztrófa utáni helyreállítást adatvédelmi kötelezettséggé teszi, nem üzemeltetési ízléskérdéssé. Az ICO adatbiztonsági útmutatója a Cyber Essentialsre mint hasznos alapszintre mutat, egyúttal világosan kimondva, hogy az csak alapvető kontrollkészlet, és nem fedi le minden szervezet körülményeit, sem minden adatkezelési művelet kockázatait.

Pénzügyi szolgáltatások és egészségügy, röviden és óvatosan

A pénzügyi szolgáltatásokban az FCA működési ellenállóképességi rendszere előírja az érintett cégeknek, hogy azonosítsák a fontos üzleti szolgáltatásokat, állapítsanak meg hozzájuk hatástűrési határokat, és súlyos, de valószerű fennakadás esetén is maradjanak e határokon belül. Az átmeneti időszak 2025. március 31-én lezárult, tehát a kötelezettség él, és meghatározza, mit kell igazolnia egy ilyen cégeket kiszolgáló szállítónak.

Az egészségügyben és a gondozásban egy egészségügyi informatikai rendszer az NHS England klinikai kockázatkezelési szabványai alá esik: a DCB0129 a gyártókra, a DCB0160 pedig a rendszert bevezető szervezetekre vonatkozik. Mindkettő országos felülvizsgálat alatt áll, 2026. június 29-től 2026. szeptember 11-ig tartó nyilvános konzultációval, tehát ellenőrizze a jelenlegi állapotot, mielőtt bármely összefoglalóra támaszkodna, beleértve ezt is.

Ha az Ön ágazata nem szerepel itt, kezelje a kötelezettséget általánosan: azonosítsa a szabályozó hatóságot, olvassa el annak saját közzétett követelményeit, és a szállítóval azokra kérjen bizonyítékot, ne általános biztosítási narratívát.

Az integrációs architektúra az, ahová a pénz megy

A vállalati költség a rendszerek közötti illesztéseknél sűrűsödik, nem a rendszereken belül. A funkciók általában jól érthetők. Hat olyan rendszert egyetértésre bírni, amelyeknek eltérő az adatmodellje és eltérő fogalma van arról, mi az ügyfél, ott megy el az ütemterv.

Pont-pont vagy közvetítő

A pont-pont az alapértelmezés, mert az első integráció valóban egyszerűbb így. A költség kombinatorikus: n közvetlenül egymással beszélő rendszernél n a négyzeten kapcsolat felé tart, mindegyik saját újrapróbálkozási logikával, hitelesítő adatokkal és felügyelettel. Négy rendszernél ez rendben van. Tizenötnél már karbantarthatatlan.

Egy közvetítő vagy eseménybusz megfordítja ezt a görbét. Hozzáad egy komponenst, üzemeltetési terhet és egy egyedi hibapontot, amellyel a tervben számolni kell, és nagyjából a hatodik vagy nyolcadik résztvevőnél térül meg. A hiba mindkét irányba megvan: a kis parkok olyan integrációs platformot vesznek, amelyre nincs szükségük, a nagyok pedig addig halogatják, amíg a háló el nem meszesedik.

Szinkron vagy eseményvezérelt

A szinkron hívás könnyen átlátható, és összekapcsolja a rendelkezésre állást. Ha a szolgáltatása négy rendszert hív soron belül, és mindegyik az idő 99,9 százalékában elérhető, a saját felső korlátja nagyjából 99,6 százalék, még mielőtt bármilyen hibát írt volna. Minden szinkron függőség a saját rendelkezésre állásának egy szelete, amelyet átad valaki más üzemeltetési csapatának.

Az eseményvezérelt tervek ezt szétválasztják, a végső konzisztencia és a jóval nehezebb hibakeresés árán. Tartsa meg a szinkron hívásokat arra az útra, ahol a felhasználó vár, és ahol egy elavult válasz elfogadhatatlan, mindent mást pedig tegyen át eseményekre. Ezt interakciónként döntse el, ne házi stílusként.

Idempotencia, visszajátszás és egyeztetés

Az elosztott rendszerek egynél többször kézbesítik az üzeneteket, és néha el is veszítik őket, ezért minden határon átnyúló írási útnak biztonságosan ismételhetőnek kell lennie. A bevett minta az ügyfél által előállított idempotenciakulcs. A Stripe megvalósítása elmenti egy adott kulcshoz tartozó első kérés státuszkódját és törzsét, újrapróbálkozáskor ugyanazt az eredményt adja vissza, legalább 24 óra után törli a kulcsokat, és hibát jelez, ha ugyanaz a kulcs eltérő paraméterekkel érkezik.

A visszajátszás ugyanennek a gondolatnak az üzemeltetési fele. Miután egy alsóbb rendszer hat órán át elérhetetlen volt, valakinek át kell tolnia az elmaradt üzeneteket, ami csak akkor biztonságos, ha a fogyasztók idempotensek, és az üzeneteket megőrizték. A megőrzési ablakot és a visszajátszási mechanizmust a boldog úttal együtt tervezze meg, mert utólagos beépítésük minden fogyasztó módosítását jelenti.

Az egyeztetést utógondolatként kezelik, pedig nem szabadna. Ütemezett feladat, amely két olyan rendszer állapotát hasonlítja össze, amelyeknek egyezniük kellene, jelenti az eltéréseket, és vagy javítja őket, vagy embernek adja tovább. Nélküle egy pénzügyi rendszertől való csendes eltérést hónapokkal később talál meg egy auditor. Tervezze be elsőrangú szállítandóként, felelőssel és riasztási útvonallal, ne olyan szkriptként, amelyet valaki a végén megír.

Együttélés a régi rendszerrel és a fojtófüge

Egy működő rendszer teljes cseréje a legkockázatosabb elérhető lehetőség, és sokkal gyakrabban választják, mint kellene. A fokozatos alternatívát a Microsoft fojtófüge mintaként dokumentálja: tegyen egy homlokzatot a régi rendszer elé, irányítsa rajta át a kéréseket, és mozgassa át a funkciókat darabonként, amíg a régi rendszernek nem marad forgalma, és ki nem kapcsolható.

Minden szakasz önmagában értékes és önmagában visszafordítható: ha a harmadik szelet rosszul sül el, visszairányítja. A Microsoft világosan megmondja, hol nem alkalmazható, nevezetesen ha a háttérrendszerhez érkező kérések nem foghatók el, ha a régi forráskódot nem lehet módosítani, vagy ha a rendszer elég kicsi ahhoz, hogy a közvetlen csere egyszerűbb legyen.

Két részlet dönti el, működik-e. A homlokzat nem válhat szűk keresztmetszetté vagy egyedi hibaponttá, ezért ugyanolyan rendelkezésre állási tervezést igényel, mint a mögötte lévő szolgáltatások. Az átmenet alatti rendszerek közötti hívásokhoz pedig korrupciógátló réteg kell, hogy a régi jelentéstartalom ne szivárogjon be az új tervbe. Az adat nehezebb, mint a forgalom: egy tartomány tábláinak kiemelése kezdeti betöltést, változásrögzítő adatfolyamot és olyan validációs szakaszt jelent, amelyben mindkét tárolóba írnak és összehasonlítanak, és csak azután jön az átállás, visszaállítási lehetőséggel addig, amíg a régi objektumokat el nem dobják.

Tesztelés vállalati léptékben

A tesztelés egy vállalati programban legalább annyira logisztikai feladat, mint mérnöki, és itt halnak meg az optimista tervek.

Környezetek

Többre lesz szüksége, mint amennyit betervezett: fejlesztés, egy integrációs környezet a partnerek tesztkörnyezeteihez kötve, egy teljesítménykörnyezet, amely elég közel áll az éleshez ahhoz, hogy a számai jelentsenek valamit, egy elfogadási környezet, amely elég stabil elfoglalt, nem műszaki emberek számára, és az éles. Mindegyiknek van infrastruktúraköltsége, frissítési folyamata és felelőse. Amelyik mindig csúszik, az a teljesítménykörnyezet, kihagyása pedig azt jelenti, hogy éles rendszeren terhel.

Tesztadat és a személyes adatok problémája

A vállalati rendszereknek élethű adat kell a teszteléshez, az élethű adat pedig az éles adat, amely személyes információt tartalmaz. Tesztkörnyezetbe másolása adatkezelés az UK GDPR értelmében, és a 32. cikk kötelezettségei odáig követik, beleértve a hozzáférés-kezelést és az azt tároló környezet biztonságát.

A védhető válaszok az anonimizálás, amelynek visszafordíthatatlannak kell lennie ahhoz, hogy az adat kikerüljön a rendelet hatálya alól, vagy az álnevesítés, amely csökkenti a kockázatot, de a hatályon belül tartja. Mindkettő mérnöki munkát igényel, hogy megmaradjon az a statisztikai alak, amitől az adat hasznos, és dokumentált folyamatot is. Egy éles adatbázis közös tesztkörnyezetbe való visszatöltése gyakori, sok konfigurációban jogszerűtlen, és pontosan az, amit egy szállítói értékelés felszínre hivatott hozni.

Teljesítménytesztelés

A teljesítménytesztelés arra válaszol, eléri-e a rendszer a korábban megállapodott átbocsátási és késleltetési számokat, tehát csak akkor létezhet, ha ezeket a számokat leírták. A csúcsprofilt tesztelje az átlag helyett, és vegye bele a csúcs alakját is, mert a tíz percen át felfutó és az egy másodperc alatt ugró terhelés más hibamódokat feszít.

Futtassa éles adatmennyiségeken. Az a lekérdezés, amely 10 000 soron azonnali, 40 millión pedig használhatatlan, a leggyakoribb teljesítményhiba a vállalati szoftverben, és kis adathalmazon láthatatlan.

Elfogadási tesztelés olyanokkal, akiknek más munkájuk is van

Az elfogadási tesztelést kéthetes ablakra tervezik, és ez az a szakasz, amely a legmegbízhatóbban csúszik túl, mert a tesztelők az üzleti szakértők, az üzletnek pedig továbbra is szüksége van rájuk. Heti néhány órát adnak Önnek, és az elérhetőségük hónap végén összeomlik.

Nevezze meg a teszteket a szerződésben, állapodjon meg a heti óraszámban, írja meg előre a forgatókönyveket ahelyett, hogy felfedezésre kérné az embereket, és a hibaválogatást közös ülésként vezesse, ne jegylistaként. Az a szállító, aki két hét elfogadási tesztelést árazik megnevezett résztvevők nélkül, még sosem vezetett le egyet sem.

Szállítási modell és irányítás

A működő csapatforma kicsi és állandó, nem nagy és cserélődő: egy műszaki vezető, aki a teljes program architektúráját viszi, három-hat mérnök, egy szállítási vezető, aki a partnerek naptárát kezeli, és megosztott hozzáférés egy minőségmérnökhöz és egy infrastruktúra-szakértőhöz. Menet közben embereket hozzáadni megbízhatóan lassítja a programot, mert a korlát a kontextus, nem a kézpár.

Írja le a döntési felelősséget az első sprint előtt. Nevezzen meg egy embert, aki jóváhagyhatja a hatókörváltozásokat, egyet, aki jóváhagyhatja az architekturális kompromisszumokat, és egyet, aki átvehet egy kiadást. Ha ez három név, a döntések napokig tartanak. Ha bizottságok, hetekig, és a terv fikció.

Az irányítási ütem tartja őszinten a hosszú programot: kéthetente szállítási áttekintés a munkacsoporttal, havonta irányítóbizottság a költségvetésgazdával és a vétójoggal bírókkal egy szobában, valamint írásos állapotjelentés az eredeti alapvonalhoz mérve, nem a múlt havi felülvizsgálthoz. Az a szállító, akinek az állapota tartósan zöld, nem kezeli a kockázatot, hanem elrejti.

Üzleti modellek és ki viseli a kockázatot

Négy modell szinte mindent lefed, és mindegyik máshová teszi a kockázatot. A kérdés nem az, melyik a legjobb, hanem az, melyik fél van jobb helyzetben ahhoz, hogy elbírja az Ön előtt álló bizonytalanságot.

Az idő és anyag valóban bizonytalan munkához illik: felderítés, régi rendszerek régészete, vagy integráció egy rosszul dokumentált partnerrel. A vevő viseli a kockázatot, és teljes rugalmasságot kap, ami bizalmat és olyan ráfordítási ütemet kíván, amelyet tényleg figyel valaki.

A maximált idő és anyag felső korlátot ad hozzá, és ez a szokásos ésszerű kompromisszum, így építjük fel a legtöbb szoftverfejlesztési szolgáltatásunkat. A szállító elnyeli a korlát fölötti túllépést, a vevő alatta csak a felhasználtat fizeti, és mindkét fél őszintén tartja a hatókört. Számítson arra, hogy a korlát tizenöt-huszonöt százalék tartalékot hordoz, mert az a szállító, aki a várt költségre korlátoz, vagy téved, vagy változtatási kérésre készül.

A fix ár csak ott működik, ahol a hatókör valóban rögzített, ami egy vállalati programban egy szakaszra igaz, nem az egészre. A hat-tíz hetes fix áras szakaszok, amelyek mindegyikét az előző leszállítása után méretezik, költségvetési bizonyosságot adnak anélkül, hogy úgy tennénk, mintha bárki tizennyolc hónapot előre meg tudna adni.

A menedzselt szolgáltatás a helyes forma, ha a rendszer már él: havi díj, amely fedezi a támogatást, a javításokat, a felügyeletet és egy meghatározott változtatási keretet, és amelyet az építési költség évi százalékában áraznak, nem fejenként. A szolgáltatásleírás nevezze meg a válaszidőket és az eszkalációs utat.

Vállalati szoftverfejlesztés: mi hajtja a költséget

Költségtényezők hatás szerint

A sorrend meglepő, mert a funkciók jönnek utoljára. Az integrációs felület az első, mégpedig a külső tulajdonosok száma, nem a végpontoké. A nem funkcionális célok a másodikak, mert az a lépés, amikor egy szolgáltatás már nem vehet ki karbantartási ablakot, a terv minden rétegét megváltoztatja.

A harmadik a bizonyítási és szabályozói teher: ajánlati idő, bizonyítékok előállítása, auditok támogatása és lassabb kiadási folyamat a szerződés teljes idejére. A negyedik az adatmigráció és az egyeztetés, amelyet következetesen alábecsülnek, mert a nehézség a régi adat minőségében lakik, nem a mennyiségben. Az ötödik az érintetti csoportok száma, amely megszabja a döntési késleltetést. A hatodik a környezetek száma. A funkcionális hatókör a hetedik, és rendszerint ez az egyetlen, ami az eredeti költségvetésben szerepel.

Tájékoztató brit árszintek

Az alábbi sávok házon belüli becslések brit megbízásokból, első éves költségként kifejezve, amely tartalmazza a felderítést, az építést, a tesztelést és az élesítést, de nem a vevő saját munkatársainak idejét. Tájékoztató jellegűek, nem ajánlatok, és a sávok azért szélesek, mert a fenti tényezők mozgatják őket.

A táblázat nélkül elmondva: egy egyetlen szolgáltatás két vagy három integrációval, belső felhasználókkal és 99,5 százalékos céllal az első évében GBP 120 000 és GBP 250 000 közé esik. Egy ügyfél felé forduló osztályszintű rendszer öt-nyolc integrációval, 99,9 százalékon, GBP 300 000 és GBP 700 000 között mozog. Egy régi rendszert leváltó központi platform tíz-húsz integrációval és 99,95 százalékos céllal GBP 900 000 és GBP 2,5 millió között mozog. Egy szabályozott, több entitást átfogó program 99,99 százalékon nagyjából GBP 2,5 millió körül indul, és onnan emelkedik.

Az üzemeltetési költség, amely nincs a költségvetésben

Adja hozzá az éves üzemeltetési költséget, amely az építési költség évi tizenöt és huszonöt százaléka közé esik, ha a támogatás, a hosztolás, a javítás, a biztonsági munka és egy szerény változtatási keret is benne van. Az a költségvetés, amely az építést finanszírozza, az üzemeltetést nem, olyan rendszert eredményez, amely a második évében láthatóan romlik, és a szoftverkarbantartás költségéről szóló bontásunk megmutatja, hová megy ez a pénz.

Kilépés és folytonosság

Az a szállító, akit nem tud otthagyni, kockázat a mérlegében, és ez az a záradék, amelyet a leggyakrabban hagynak a tárgyalás végére, amikor már senki nem figyel. Négy dolog teszi lehetővé a kilépést.

A forráskód és annak története olyan tárolóba tartozik, amelyet a vevő birtokol, vagy felmondási idővel átvehet, az összeállítási folyamattal és az infrastruktúra-definíciókkal együtt. A kód az őt összeállító folyamat nélkül archívum, nem működő vagyontárgy.

A dokumentációnak lehetővé kell tennie, hogy egy hozzáértő harmadik fél üzemeltesse a rendszert: architektúra, integrációs szerződések, üzemeltetési leírások a ténylegesen előfordult hibamódokra, és a hozzáférések leltára. A ténylegesen elolvasott műszaki dokumentációról szóló írásunk bemutatja, mi éli túl az átadást.

A letét azt fedi le, ha a szállító elbukik, nem azt, ha távozik, azáltal hogy a forráskódot harmadik félnél helyezik el, meghatározott események esetén történő kiadásra. Érdemes ott, ahol a szállító kicsi a szerződéshez képest, és érdemes figyelmesen elolvasni, mert egy ellenőrizetlen letét olyan kódot ad ki, amely nem áll össze. Azt, hogy mikor indokolt, a szoftverletétről és arról, kinek van rá tényleg szüksége szóló írásunkban néztük meg.

Végül árazza be az átadást a szerződésben. A tudásátadás megnevezett napszáma megállapodott díjszabáson, felmondásra indulva, vitából számlát csinál. Ugyanez a fegyelem vonatkozik a beszállítói beszállítóira is, amelyről a szoftverellátási lánc biztonságáról szóló jegyzetünk szól.

Egy szállító vállalati hitelességének megítélése egyetlen tárgyaláson

Öt kérdés ebből a legtöbbet tisztázza egy óra alatt, és a habozás annyit mond, mint a válasz.

Kérdezze meg, milyen rendelkezésre állási és helyreállítási célok mellett szállítottak, és hogyan mérték a rendelkezésre állást. Az a szállító, aki 99,95 százalékos kötelezettséget vitt, kérdés nélkül megnevezi a mérési pontot és a készenléti rendet. Aki nem, az általánosságban beszél a redundanciáról.

Kérje el az ISO 27001 tanúsítványuk hatóköri nyilatkozatát, vagy a 2. típusú SOC 2 jelentésük kivételek szakaszát. Mindkettő hétköznapi kérés annak a szállítónak, aki rendelkezik velük, és kínos annak, akinek csak emblémája van. Utána kérdezze meg, hogyan kezeltek egy egyeztetési eltérést élesben, amire elméletből senki nem tud válaszolni.

Kérdezze meg, mennyivel lépte túl a keretet az utolsó három programjuk, és miért. Mindenki túllép, és az informatív rész az, tudják-e a számot. Utána kérdezze meg, hogyan néz ki a kilépési folyamatuk, napokban és szállítandókban. Az a szállító, aki ezt leírta, számít rá, hogy ez alapján ítélik meg.

Hol hagyja ez a vevőt

Az enterprise szónak kötelezettségeket kellene leírnia, nem árkategóriát. Amint leírják az integrációs felületet, a rendelkezésre állási és helyreállítási célokat, a szabályozói kitettséget és a kilépési feltételeket, a szűkített lista magától rendeződik, mert a legtöbb szállító erre a négy pontra nem tud bizonyítékot hozni.

A Mecanik ezen az elköteleződési formán a szoftverfejlesztési szolgáltatásainkon keresztül dolgozik, a bizonyítási oldalon pedig a behatolástesztelési szolgáltatásainkon keresztül. Ha inkább a követelményt állítja össze, mint a szűkített listát, a műszaki átvilágítási ellenőrzőlista ésszerű kezdet, és a nem funkcionális számokról érdemes először vitatkozni.

Gyakran ismételt kérdések

Mi számít vállalati szoftverfejlesztésnek? A vállalati jelleget korlátok határozzák meg, nem a vevő mérete. Egy projekt akkor felel meg, ha széles, több fél által birtokolt integrációs felülete van, szerződéses rendelkezésre állási és helyreállítási kötelezettsége, szabályozói kitettsége, több érintetti csoportja, amelyek mindegyike megállíthat egy kiadást, olyan adatmennyisége, amely szétveri a naiv terveket, és együtt kell élnie olyan régi rendszerekkel, amelyeket senki nem ért teljesen. Egy nagy cég is rendelhet hétköznapi fejlesztést, egy kis szabályozott cég pedig valóban vállalatit.

Mennyibe kerül egy vállalati szoftverprogram az Egyesült Királyságban? Brit megbízásokból származó házon belüli becslésként egy egyetlen szolgáltatás két vagy három integrációval és 99,5 százalékos rendelkezésre állási céllal az első évében GBP 120 000 és GBP 250 000 között mozog. Egy ügyfél felé forduló osztályszintű rendszer 99,9 százalékon GBP 300 000 és GBP 700 000 között mozog. Egy régi rendszert leváltó központi platform GBP 900 000 és GBP 2,5 millió között mozog. Adjon hozzá évente az építési költség tizenöt-huszonöt százalékát üzemeltetésre és támogatásra.

Kell egy vállalati szállítónak ISO 27001, Cyber Essentials vagy SOC 2? Különböző dolgokat bizonyítanak. A Cyber Essentials a brit kormány által támogatott, öt technikai kontrollból álló alapszint, Plus fokozattal, amelyet független műszaki audit igazol, és amelyet a PPN 014 sok közszférás szerződéshez előír. Az ISO/IEC 27001:2022 információbiztonsági irányítási rendszert tanúsít, ezért a tanúsítványon szereplő hatóköri nyilatkozat többet számít, mint maga a tanúsítvány. A SOC 2 amerikai, könyvvizsgáló cég által készített tanúsító jelentés, és csak a 2. típus vizsgálja, működtek-e a kontrollok egy időszakon át.

Mi a helyreállítási pont és a helyreállítási idő célértéke? A helyreállítási pont célértéke az, mennyi adat elvesztését fogadja el egy katasztrófa után, tehát az egyórás RPO azt jelenti, hogy akár egy órányi tranzakció eltűnhet. A helyreállítási idő célértéke az, meddig fogadja el, hogy nem elérhető, tehát a négyórás RTO azt jelenti, hogy a szolgáltatásnak négy órán belül újra forgalmat kell kiszolgálnia. Mindkettő jobban hajtja az architektúrát és a költséget, mint bármelyik funkció, mert ezek választanak a mentés és visszaállítás, az őrláng, a meleg tartalék és a többtelephelyes aktív/aktív között.

Mit kell tartalmaznia egy vállalati szoftverszerződésnek a kilépésről? Négy dolgot. Tulajdonjogot vagy átruházható hozzáférést a forráskódtárhoz, az összeállítási folyamathoz és az infrastruktúra-definíciókhoz. Elegendő dokumentációt ahhoz, hogy egy hozzáértő harmadik fél üzemeltesse a rendszert, beleértve az üzemeltetési leírásokat és a hozzáférések leltárát. Forráskódletétet ott, ahol a szállító kicsi a szerződés értékéhez képest, ellenőrzött, nem pedig ellenőrizetlen letétekkel. És beárazott átadási záradékot, amely megnevezi a tudásátadás napjait és a díjszabást, hogy a távozás számla legyen, ne jogvita.