Dezvoltare Software Enterprise: Ce Cumpărați De Fapt

Dezvoltarea de software enterprise, așa cum este folosită expresia pe majoritatea site-urilor de agenție, înseamnă aceeași muncă cu un număr mai mare alături. Echipa este aceeași, procesul este același, prezentarea capătă un zid de logouri, iar prețul se triplează. Cumpărătorii știu asta, motiv pentru care departamentele de achiziții au învățat să ignore cuvântul și să citească anexele.

Dedesubt există totuși o distincție reală, și ea nu ține de mărimea companiei. Un asigurător cu patruzeci de oameni poate conduce un program cu adevărat enterprise, iar un retailer cu douăsprezece mii de oameni poate comanda ceva care în realitate este doar un site. Ceea ce le separă sunt obligațiile pe care sistemul le impune celui care îl construiește: cu câte alte sisteme trebuie să vorbească, cât timp are voie să fie oprit, cine poate bloca o lansare, ce autoritate de reglementare are un interes și ce se întâmplă dacă furnizorul pleacă.

Ce urmează definește categoria prin aceste obligații, ca un cumpărător să deosebească un furnizor care le poate duce de unul care vinde un proiect obișnuit cu o copertă enterprise.

Ce face cu adevărat enterprise un proiect software? Nu mărimea cumpărătorului. Un proiect este enterprise atunci când poartă constrângeri pe care un proiect obișnuit nu le are: o suprafață largă de integrare, o obligație contractuală de disponibilitate și de restabilire, expunere la reglementare, mai multe grupuri de părți interesate care pot bloca fiecare o lansare, volume de date care rup proiectările naive și cerința de a coexista cu sisteme pe care astăzi nu le înțelege nimeni. Acele constrângeri, nu lista de funcționalități, decid arhitectura și cea mai mare parte a costului.

Ce face un proiect să fie enterprise

Testul util este o listă de constrângeri, iar un proiect se califică atunci când le poartă pe cele mai multe, nu doar una. Aplicat cinstit, el descalifică mult din ceea ce se vinde drept enterprise și califică lucrări vândute ca proiecte mici, care apoi eșuează tocmai pentru că au fost dimensionate așa.

Suprafața de integrare

Numărați sistemele cu care noul vostru software trebuie să schimbe date, apoi numărați câte echipe sau furnizori distincți dețin acele sisteme. Al doilea număr este cel care prezice costul. Trei integrări deținute de o singură echipă internă înseamnă două săptămâni de muncă. Trei integrări deținute de trei furnizori, fiecare cu fereastra lui de schimbare, cu disponibilitatea lui de mediu de test și cu suportul lui, înseamnă un trimestru.

Fiecare proprietar aduce un calendar pe care nu îl controlați. Un furnizor al cărui mediu de test se împrospătează lunar vă impune ritmul de testare, iar un procesator de plăți a cărui certificare durează șase săptămâni vă fixează data intrării în funcțiune. Cu o duzină de contrapărți, calendarul integrărilor devine planul de proiect, iar dezvoltarea se strecoară în golurile rămase.

Obligația de disponibilitate

De la un software obișnuit se așteaptă să funcționeze. Software-ul enterprise are un număr atașat acelei așteptări, de regulă într-un contract cu o penalizare în spate. Numărul schimbă mai întâi arhitectura, pentru că o instalare pe o singură instanță nu îl poate onora, oricât de bun ar fi codul.

Pasul de la o țintă care tolerează o fereastră de mentenanță la una care nu o tolerează este cea mai scumpă linie din majoritatea bugetelor enterprise și este adesea convenită de oameni care nu i-au văzut niciodată prețul. Articolul nostru despre SLA-urile de disponibilitate care înseamnă ceva arată cum se scriu acele numere și cât de des sunt scrise prost.

Părți interesate cu drept de veto

Un proiect obișnuit are un product owner. Un proiect enterprise are un product owner, o funcție de securitate a informației, un responsabil cu protecția datelor, un responsabil de achiziții, o echipă de infrastructură care deține rețeaua, un service desk care va moșteni sarcina de suport și adesea un evaluator clinic, juridic sau de conformitate.

Oricare dintre ei poate opri o lansare și niciunul nu răspunde în fața persoanei care plătește lucrarea. Deciziile consumă așadar timp de calendar fără legătură cu dificultatea lor, iar un furnizor care nu a pus asta în plan ratează fiecare termen din a doua lună încolo.

Sistemele pe care nu le mai înțelege nimeni

Orice parc aplicativ enterprise conține cel puțin un sistem al cărui comportament este documentat doar prin ceea ce produce. Oamenii care l-au scris au plecat, iar specificația, dacă există, descrie o versiune anterioară. Funcționează, este de rezistență, iar modificarea lui este considerată nechibzuită.

Software-ul nou trebuie să coexiste cu el, așa că mai întâi cineva trebuie să stabilească ce face de fapt. Asta este arheologie, nu dezvoltare: citirea datelor de producție, urmărirea apelurilor, rularea unor experimente controlate pe o copie și scrierea regulilor pe care codul le implică. Pe un parc mare înseamnă săptămâni de muncă și este poziția cel mai des ștearsă în negociere, pentru că nu produce nicio funcționalitate vizibilă.

Ștergerea ei mută munca în testarea de integrare, unde este descoperită sub presiune de oameni care repară deja defecte. Un furnizor care cotează separat faza de descoperire și o apără vă spune ceva adevărat despre felul în care eșuează aceste programe. Nota noastră despre modernizarea sistemelor vechi și alegerea între rescriere și refactorizare arată ce găsește acea arheologie.

Achizițiile sunt jumătate din muncă

Majoritatea tehnicienilor subestimează această parte de trei ori. Într-un angajament cu adevărat enterprise, munca dintre prima conversație și prima linie de cod durează mai mult decât primul increment livrat și consumă timp de conducere de ambele părți.

De la 24 februarie 2025 sectorul public britanic funcționează după Procurement Act 2023, iar furnizorii care licitează pentru contracte publice trebuie să fie înregistrați pe platforma digitală centrală din serviciul extins Find a Tender. Achizițiile private nu au o poartă unică echivalentă, ceea ce în mod paradoxal le face mai lente, pentru că fiecare cumpărător și-a inventat-o pe a lui.

Chestionarul de securitate

Vi se va trimite un tabel. Va întreba despre ciclul vostru de dezvoltare, controalele de acces, ritmul de aplicare a corecțiilor, subcontractanții, rezidența datelor, timpii de răspuns la incidente și verificările de fond ale angajaților. Cumpărătorii mari trimit câteva sute de întrebări, iar o bancă sau o unitate NHS trimite mai multe.

Întrebările nu sunt grele, dar au răspuns doar dacă răspunsurile există deja ca politică. Un furnizor care le asamblează prima dată în timpul unei licitații are nevoie de patru până la șase săptămâni și greșește la câteva. Cine a mai făcut-o răspunde în câteva zile dintr-o bibliotecă de răspunsuri întreținută, ceea ce este un motiv legitim să îl preferați.

Înrolarea furnizorului, asigurările și verificările financiare

Înrolarea este separată de licitație și rulează adesea în paralel cu ea. Așteptați-vă să dovediți o asigurare de răspundere civilă profesională și una de răspundere cibernetică la nivelul cerut de cumpărător, o acoperire de răspundere față de angajați și uneori una de răspundere pentru produs. Cumpărătorii enterprise cer în mod obișnuit limite pe care o firmă mică de consultanță nu le are implicit, iar ridicarea acoperirii în mijlocul licitației cere timp.

Urmează verificările financiare. Cumpărătorii extrag situațiile financiare depuse, cer un scor de credit și, la contracte mari, situații de gestiune sau o garanție a companiei-mamă. Un furnizor al cărui bilanț nu susține valoarea contractului este exclus indiferent de meritul tehnic, și de aceea firme mici și capabile pierd licitații care li se potriveau.

De ce ciclul de vânzare durează mai mult decât primul increment

Puneți cele două cronologii una lângă alta și forma problemei devine limpede. Calificarea, cerințele, evaluarea de securitate, negocierea juridică, dovezile de asigurare și înrolarea ocupă în mod obișnuit patru până la nouă luni pe un contract de câteva sute de mii de lire. Primul increment util de software, odată începută munca, poate dura zece săptămâni.

Estimările scrise la începutul acelui ciclu sunt depășite la semnare, iar un furnizor care ține un preț fix peste tot intervalul fie adaugă mult, fie plănuiește să se certe pe scop mai târziu. Și ipotezele tehnologice îmbătrânesc, iar o versiune curentă la ofertare poate fi ieșită din suport la demarare.

Datează fiecare estimare, spuneți ipotezele ei și conveniți o rebazare la semnare, în loc să pretindeți că numărul a supraviețuit. Cumpărătorii care insistă că cifra inițială rămâne valabilă cumpără o coadă de cereri de modificare. Ghidul nostru despre scrierea unei cereri de ofertă software care aduce cotații utile arată ce trebuie să conțină documentul.

Cerințele nefuncționale sunt livrabilul adevărat

Listele de funcționalități sunt ușor de scris și decid rareori ceva. Cerințele nefuncționale decid arhitectura, factura de infrastructură, mărimea echipei și durata ciclului de testare, iar în majoritatea programelor enterprise ele au două paragrafe într-un document în care lista de funcționalități are patruzeci de pagini.

Acest dezechilibru este cel mai sigur semn al unei depășiri. Un furnizor care dedică primul atelier disponibilității, restabilirii, latenței, debitului, auditabilității și păstrării nu tergiversează: acele șase numere elimină cele mai multe opțiuni de arhitectură, iar fixarea lor târzie înseamnă reconstrucție.

Scrieți-le ca afirmații testabile, cu un număr și o condiție. Sistemul trebuie să fie foarte disponibil nu este o cerință. Serviciul de comenzi trebuie să susțină o disponibilitate lunară de 99,9 la sută măsurată la echilibrorul de sarcină, exceptând o fereastră de două ore anunțată cu cinci zile lucrătoare înainte: aceasta este o cerință, pentru că un test o poate pica.

Punctul de restabilire și timpul de restabilire pe înțelesul tuturor

Două dintre aceste numere împing costul mai mult decât orice funcționalitate și sunt citate constant de oameni care le-au schimbat între ele înțelesul. Obiectivul punctului de restabilire este cât de multe date sunteți dispuși să pierdeți: un RPO de o oră înseamnă că acceptați ca după un dezastru să dispară până la o oră de tranzacții, iar schema voastră de copii de siguranță sau de replicare nu are voie să facă mai rău. Obiectivul timpului de restabilire este cât de mult sunteți dispuși să fiți opriți, așa că un RTO de patru ore înseamnă că serviciul deservește din nou trafic în patru ore de la începutul incidentului.

Ambele numere se traduc direct în arhitectură. AWS prezintă patru strategii largi în ghidul său de restabilire după dezastru: copie și restaurare, pilot light, warm standby și multi-sit activ/activ. Ele merg de la ieftin și lent la scump și aproape instantaneu, iar alegerea este făcută în locul vostru de îndată ce cele două obiective sunt convenite.

Evitați să conveniți numere agresive pentru că sună responsabil. Un RPO zero cu un RTO de minute înseamnă replicare continuă și un al doilea mediu activ, ceea ce dublează aproximativ factura de infrastructură. Materialul nostru despre restabilirea după dezastru pentru echipe mici de software arată ce cumpără treptele mai ieftine.

Aritmetica disponibilității și ce cumpără de fapt un SLA

Procentele de disponibilitate își ascund înțelesul în spatele unei virgule. Într-o lună de 30 de zile, 99,9 la sută permit circa 43 de minute de oprire, 99,95 la sută circa 22 de minute, iar 99,99 la sută circa 4 minute. Acela este bugetul întregii luni, incluzând lansările, reînnoirile de certificate și comutarea bazei de date care a durat mai mult decât se aștepta.

Patru minute pe lună nu sunt realizabile de o echipă care lansează în program de birou și cheamă un singur inginer. Este nevoie de redundanță pe fiecare nivel, de comutare automată, de lansări care nu întrerup traficul și de cineva treaz la trei dimineața. Ultimul punct costă de obicei mai mult decât infrastructura și aproape niciodată nu se află în bugetul inițial. Fixați în contract și punctul de măsurare, pentru că disponibilitatea citită la echilibrorul de sarcină și cea citită din telemetria reală a utilizatorilor pot diferi cu un ordin de mărime la același incident.

Latență, debit și sarcina pe care nu a măsurat-o nimeni

Țintele de latență au nevoie de o percentilă și de un domeniu, pentru că mediile ascund eșecurile. O țintă declarată de 200 de milisecunde la percentila 95 pentru punctul final de plată, sub 400 de cereri pe secundă, este testabilă. O țintă de rapiditate nu este, și nici o medie, de vreme ce o medie de 200 de milisecunde este compatibilă cu un utilizator din douăzeci care așteaptă patru secunde.

Debitul are nevoie de un vârf, nu de o medie. Retailerii dimensionează pentru vinerea dinaintea Crăciunului, sistemele de salarizare pentru ultima zi lucrătoare a lunii, iar serviciile publice pentru termenul din scrisoarea trimisă. Dimensionarea pe media anuală este felul în care o lansare cade în prima ei oră aglomerată. Luați vârful din jurnalele sistemului existent, unde rapoartele de zece la unu sunt obișnuite, pentru că acel raport decide dacă proiectarea are nevoie de o coadă.

Auditabilitate și păstrare

Cumpărătorii reglementați, și tot mai des și cei nereglementați, trebuie să poată răspunde ani mai târziu cine ce a schimbat și când. Aceasta este o cerință de proiectare, nu o configurare de jurnalizare: un sistem care suprascrie rândurile nu poate răspunde, iar răspunsul trebuie să supraviețuiască atâta timp cât spune politica de păstrare.

Decideți trei lucruri devreme. Care evenimente sunt auditabile, de regulă schimbările de stare ale înregistrărilor cu semnificație juridică sau financiară, nu fiecare cerere HTTP. Cât timp se păstrează fiecare clasă de înregistrări, o întrebare juridică cu o constrângere de protecție a datelor atașată, de vreme ce păstrarea datelor personale mai mult decât este necesar este ea însăși o încălcare. Și cine poate citi urma, pentru că un jurnal de audit pe care administratorii îl pot edita nu dovedește nimic. Păstrarea și dreptul la ștergere se ciocnesc aici, iar tensiunea se rezolvă în schemă, nu în politică.

Certificările pe care le va cere un cumpărător

Trei revin mereu, sunt confundate în permanență și dovedesc lucruri diferite. Un furnizor care nu poate explica diferența nu le deține.

Cyber Essentials și Cyber Essentials Plus

Cyber Essentials este linia de bază susținută de guvernul britanic, dezvoltată de NCSC și livrată prin IASME ca partener oficial de implementare. Acoperă cinci controale tehnice: firewall, configurare sigură, gestionarea actualizărilor de securitate, controlul accesului utilizatorilor și protecția împotriva programelor malware. Nivelul de bază este un chestionar de autoevaluare revizuit independent, iar NCSC indică prețuri de la GBP 320 plus TVA, în funcție de mărimea organizației.

Cyber Essentials Plus înseamnă aceleași cinci controale, verificate printr-un audit tehnic independent în loc să fie doar declarate. Evaluatorul rulează scanări interne și externe de vulnerabilități și testează un eșantion de dispozitive ale utilizatorilor, de porți de acces la internet și de servere expuse pe internet. Auditul Plus trebuie încheiat în trei luni de la certificarea de bază, iar ambele certificate durează douăsprezece luni.

Schema contează comercial la fel de mult ca tehnic. PPN 014, în vigoare de la 24 februarie 2025 în ministerele centrale, agențiile lor, organismele publice neministeriale și entitățile NHS, cere certificarea atunci când furnizorii manevrează date personale ale cetățenilor, date personale ale angajaților guvernamentali sau sisteme informatice care prelucrează date de nivel OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 este standardul internațional pentru un sistem de management al securității informației, publicat de ISO și IEC. Ediția curentă este ISO/IEC 27001:2022, cu amendamentul 1 din 2024 care adaugă în clauzele de context o formulare despre acțiunea climatică, în linie cu o modificare aplicată tuturor standardelor ISO de sisteme de management.

Este un standard de sistem de management, și exact această parte o citesc greșit cumpărătorii. Nu prescrie un set fix de controale pe care fiecare organizație certificată le-ar fi implementat. Cere ca organizația să își definească domeniul, să își evalueze riscurile, să selecteze controale și să ruleze un ciclu documentat de analiză și îmbunătățire. Certificarea este emisă de un organism de certificare acreditat după un audit, nu de ISO însuși.

Așadar întrebarea utilă nu este niciodată dacă un furnizor îl deține, ci ce acoperă declarația de domeniu de pe certificat. Un domeniu limitat la o funcție de sediu central nu vă spune nimic despre echipa care ține codul vostru sursă și acreditările de producție. Cereți certificatul și citiți domeniul.

SOC 2

SOC 2 este american și de altă natură. AICPA îl definește ca un raport asupra controalelor dintr-o organizație de servicii relevante pentru securitate, disponibilitate, integritatea prelucrării, confidențialitate sau viață privată, realizat după criteriile sale privind serviciile de încredere. Este un raport de atestare produs de o firmă de audit financiar, nu un certificat, și nu există nici prag de trecere, nici siglă de afișat.

Distincția care contează este tipul. Un raport de tip 1 descrie controalele și evaluează dacă sunt proiectate potrivit la un moment dat. Un raport de tip 2 testează dacă au funcționat efectiv de-a lungul unei perioade, de regulă șase sau douăsprezece luni. Tipul 1 este o fotografie, tipul 2 este un film, iar cumpărătorii care acceptă un tip 1 ca echivalent acceptă mult mai puțin decât cred.

Citiți raportul, nu coperta. Secțiunea excepțiilor, unde auditorul consemnează controalele care nu au funcționat așa cum sunt descrise, poartă informația, și este partea pe care furnizorii speră să o săriți.

Ce nu dovedește niciunul dintre ele

Niciunul dintre cele trei nu certifică faptul că software-ul vostru este sigur. Cyber Essentials acoperă o linie de bază de igienă a infrastructurii. ISO 27001 acoperă dacă organizația gestionează securitatea ca proces. SOC 2 acoperă dacă niște controale declarate au funcționat de-a lungul unei perioade. Toate trei privesc furnizorul, nu produsul.

Securitatea aplicației este o disciplină separată, cu dovezi separate. Cereți ultimul raport de test de penetrare și stadiul remedierii, nu peretele de certificate, și verificați cine l-a făcut și pe ce domeniu. Aceasta este substanța din spatele serviciilor noastre de testare de penetrare.

Expunerea la reglementare, pe sectoare

Reglementarea este locul unde sfaturile generice despre enterprise devin nesigure. Ce urmează numește obligații verificabile și se oprește înainte de consultanța juridică, pe care ar trebui să o luați de la un consilier calificat.

UK GDPR, care se aplică aproape tuturor

Dacă sistemul atinge date personale, articolul 32 din UK GDPR se aplică atât operatorului, cât și persoanei împuternicite. El cere măsuri tehnice și organizatorice adecvate și numește patru: pseudonimizarea și criptarea, confidențialitatea, integritatea, disponibilitatea și rezistența continue ale sistemelor de prelucrare, capacitatea de a restabili în timp util disponibilitatea datelor personale și accesul la acestea după un incident, și un proces de testare și evaluare periodică a eficacității acelor măsuri.

Recitiți a treia, pentru că ea face din restabilirea după dezastru o obligație de protecție a datelor, nu o preferință operațională. Ghidul ICO privind securitatea datelor indică Cyber Essentials ca linie de bază utilă, spunând totodată limpede că este doar un set de bază de controale și că nu va acoperi situația fiecărei organizații și nici riscurile fiecărei operațiuni de prelucrare.

Servicii financiare și sănătate, pe scurt și cu grijă

În serviciile financiare, regimul de reziliență operațională al FCA cere firmelor vizate să identifice serviciile de afaceri importante, să stabilească toleranțe de impact pentru ele și să poată rămâne în acele toleranțe pe durata unei perturbări grave, dar plauzibile. Perioada de tranziție s-a încheiat la 31 martie 2025, așa că obligația este activă și modelează ce trebuie să dovedească un furnizor al acestor firme.

În sănătate și îngrijire, un sistem informatic medical intră sub standardele de management al riscului clinic ale NHS England: DCB0129 pentru producători și DCB0160 pentru organizațiile care îl implementează. Ambele sunt în revizuire națională, cu o consultare publică deschisă între 29 iunie 2026 și 11 septembrie 2026, așa că verificați poziția curentă înainte să vă bazați pe orice rezumat, inclusiv pe acesta.

Dacă sectorul vostru nu este numit aici, tratați obligația generic: identificați autoritatea de reglementare, citiți cerințele publicate de ea și cereți furnizorului dovezi față de acelea, nu o narațiune generală de asigurare.

Arhitectura de integrare este locul unde se duc banii

Costul enterprise se concentrează în cusăturile dintre sisteme, nu în interiorul lor. Funcționalitățile sunt de obicei bine înțelese. Să faci șase sisteme cu modele de date diferite și noțiuni diferite despre ce este un client să cadă de acord, acolo se duce calendarul.

Punct la punct sau un broker

Punctul la punct este alegerea implicită pentru că prima integrare chiar este mai simplă așa. Costul este combinatoriu: cu n sisteme care vorbesc direct între ele, vă îndreptați spre n la pătrat conexiuni, fiecare cu logica ei de reîncercare, cu acreditările ei și cu monitorizarea ei. La patru sisteme este în regulă. La cincisprezece nu mai poate fi întreținut.

Un broker sau o magistrală de evenimente inversează acea curbă. Adaugă o componentă, o sarcină de operare și un punct unic de defectare de care trebuie ținut cont în proiectare, și se amortizează în jurul celui de-al șaselea sau al optulea participant. Greșeala se face în ambele sensuri: parcurile mici cumpără o platformă de integrare de care nu au nevoie, iar cele mari o amână până când țesătura s-a calcifiat.

Sincron sau condus de evenimente

Un apel sincron este ușor de urmărit cu mintea și cuplează disponibilitatea. Dacă serviciul vostru apelează patru sisteme în linie și fiecare este disponibil 99,9 la sută din timp, plafonul vostru este de circa 99,6 la sută înainte să fi scris vreo eroare. Fiecare dependență sincronă este o cotă din disponibilitatea voastră predată echipei de operare a altcuiva.

Proiectările conduse de evenimente decuplează asta, cu prețul consistenței eventuale și al unei depanări mult mai grele. Păstrați apelurile sincrone pentru drumul pe care utilizatorul așteaptă și un răspuns vechi este inacceptabil, și mutați tot restul pe evenimente. Decideți asta pentru fiecare interacțiune, nu ca stil al casei.

Idempotență, reluare și reconciliere

Sistemele distribuite livrează mesajele de mai multe ori și ocazional le pierd, așa că orice drum de scriere care trece o graniță trebuie să poată fi repetat în siguranță. Modelul consacrat este o cheie de idempotență generată de client. Implementarea Stripe salvează codul de stare și corpul primei cereri pentru o cheie dată, întoarce același rezultat la reîncercări, curăță cheile după cel puțin 24 de ore și semnalează o eroare dacă aceeași cheie sosește cu alți parametri.

Reluarea este jumătatea operațională a aceleiași idei. După ce un sistem din aval a fost indisponibil șase ore, cineva trebuie să împingă mesajele ratate, ceea ce este sigur doar dacă consumatorii sunt idempotenți și mesajele au fost păstrate. Proiectați fereastra de păstrare și mecanismul de reluare odată cu drumul fericit, pentru că adăugarea lor ulterioară înseamnă modificarea fiecărui consumator.

Reconcilierea este tratată ca un gând de final și nu ar trebui să fie. Este o sarcină programată care compară starea a două sisteme presupuse a fi de acord, raportează diferențele și fie le corectează, fie le ridică pentru un om. Fără ea, o divergență tăcută față de un sistem financiar este găsită luni mai târziu de un auditor. Bugetați-o ca livrabil de primă clasă, cu un responsabil și o rută de alertă, nu ca un script pe care îl scrie cineva la sfârșit.

Coexistența cu sistemele vechi și smochinul strangulator

Înlocuirea integrală a unui sistem care funcționează este cea mai riscantă opțiune disponibilă și este aleasă mult mai des decât ar trebui. Alternativa incrementală este documentată de Microsoft ca modelul smochinului strangulator: puneți o fațadă în fața sistemului vechi, dirijați cererile prin ea și mutați funcționalitatea bucată cu bucată până când sistemul vechi nu mai are trafic și poate fi oprit.

Fiecare increment are valoare de sine stătător și este reversibil de sine stătător: dacă a treia felie merge prost, o dirijați înapoi. Microsoft spune limpede unde modelul nu se aplică, anume când cererile către sistemul din spate nu pot fi interceptate, când nu puteți modifica sursa veche sau când sistemul este destul de mic încât înlocuirea directă să fie mai simplă.

Două detalii decid dacă funcționează. Fațada nu trebuie să devină nici gât de sticlă, nici punct unic de defectare, deci are nevoie de aceeași inginerie de disponibilitate ca serviciile din spatele ei. Iar apelurile între sisteme din timpul tranziției au nevoie de un strat anticorupție, ca semantica veche să nu se scurgă în noua proiectare. Datele sunt mai grele decât traficul: scoaterea tabelelor unui domeniu înseamnă o încărcare inițială, un flux de captare a modificărilor, o perioadă de validare în care ambele depozite sunt scrise și comparate, și abia apoi comutarea, cu revenire posibilă până când obiectele vechi sunt șterse.

Testarea la scară enterprise

Testarea într-un program enterprise este la fel de mult o problemă de logistică pe cât este una de inginerie, și acolo mor planurile optimiste.

Medii

Veți avea nevoie de mai multe decât ați bugetat: dezvoltare, un mediu de integrare legat la mediile de test ale contrapărților, un mediu de performanță destul de apropiat de producție încât numerele lui să însemne ceva, un mediu de acceptanță destul de stabil pentru oameni netehnici și ocupați, și producția. Fiecare are cost de infrastructură, un proces de împrospătare și un responsabil. Cel care alunecă mereu este cel de performanță, iar sărirea lui înseamnă testare de sarcină în producție.

Datele de test și problema datelor personale

Sistemele enterprise au nevoie de date realiste pe care să testeze, iar datele realiste sunt datele de producție, care conțin informații personale. Copierea lor într-un mediu de test este prelucrare în sensul UK GDPR, iar obligațiile articolului 32 le urmează acolo, inclusiv controlul accesului și securitatea mediului care le ține.

Răspunsurile apărabile sunt anonimizarea, care trebuie să fie ireversibilă pentru a scoate datele din regulament, sau pseudonimizarea, care reduce riscul dar le ține înăuntru. Ambele cer muncă de inginerie pentru a păstra forma statistică ce face datele utile, și un proces documentat. Restaurarea unei baze de date de producție într-un mediu de test comun este obișnuită, ilegală în multe configurații și exact ceea ce o evaluare de furnizor este menită să scoată la iveală.

Testarea de performanță

Testarea de performanță răspunde dacă sistemul atinge numerele de debit și latență convenite mai devreme, deci poate exista doar dacă acele numere au fost scrise. Testați profilul de vârf, nu media, și includeți forma vârfului, pentru că o rampă pe zece minute și o treaptă într-o secundă solicită moduri de defectare diferite.

Rulați-o pe volume de date de producție. O interogare instantanee pe 10.000 de rânduri și inutilizabilă pe 40 de milioane este cel mai frecvent defect de performanță din software-ul enterprise și este invizibilă pe un set mic de date.

Testarea de acceptanță cu oameni care au alte treburi

Testarea de acceptanță este planificată pe o fereastră de două săptămâni și este faza care depășește cel mai constant, pentru că testerii sunt experții de business, iar businessul are în continuare nevoie de ei. Vă vor da câteva ore pe săptămână, iar disponibilitatea lor se prăbușește la sfârșit de lună.

Numiți testerii în contract, conveniți orele pe săptămână, scrieți scenariile din timp în loc să cereți oamenilor să exploreze și conduceți trierea defectelor ca ședință comună, nu ca listă de tichete. Un furnizor care cotează două săptămâni de acceptanță fără participanți numiți nu a condus niciodată una.

Modelul de livrare și guvernanța

Forma de echipă care funcționează este mică și stabilă, nu mare și rotativă: un lead tehnic care deține arhitectura întregului program, trei până la șase ingineri, un lead de livrare care ține calendarul contrapărților și acces partajat la un inginer de calitate și la un specialist de infrastructură. Adăugarea de oameni din mers încetinește constant un program, pentru că restricția este contextul, nu brațele.

Scrieți deținerea deciziilor înainte de primul sprint. Numiți o persoană care poate aproba schimbările de scop, una care poate aproba compromisurile de arhitectură și una care poate accepta o lansare. Dacă sunt trei nume, deciziile durează zile. Dacă sunt comitete, durează săptămâni și planul este ficțiune.

Cadența de coordonare ține cinstit un program lung: analiză de livrare la două săptămâni cu grupul de lucru, comitet lunar cu deținătorul bugetului și cu deținătorii dreptului de veto în aceeași cameră și un raport scris de stare față de linia de bază inițială, nu față de cea revizuită de luna trecută. Un furnizor al cărui stadiu este permanent verde nu gestionează riscul, îl ascunde.

Modele comerciale și cine duce riscul

Patru modele acoperă aproape tot, și fiecare pune riscul în altă parte. Întrebarea nu este care este cel mai bun, ci care parte este mai potrivită să ducă incertitudinea din fața voastră.

Timpul și materialele se potrivesc muncii cu adevărat incerte: descoperire, arheologie pe sisteme vechi sau o integrare cu o contraparte prost documentată. Cumpărătorul duce riscul și primește flexibilitate deplină, ceea ce cere încredere și un ritm de consum pe care chiar îl urmărește cineva.

Timpul și materialele cu plafon adaugă o limită superioară și este compromisul rezonabil obișnuit, așa cum ne structurăm cele mai multe servicii de dezvoltare software. Furnizorul absoarbe depășirea peste plafon, cumpărătorul plătește sub el doar ce se consumă, iar ambele părți țin scopul cinstit. Așteptați-vă ca plafonul să poarte între cincisprezece și douăzeci și cinci la sută rezervă, pentru că un furnizor care plafonează la costul așteptat fie se înșală, fie pregătește o cerere de modificare.

Prețul fix funcționează doar acolo unde scopul este cu adevărat fix, ceea ce într-un program enterprise este adevărat pentru un increment, nu pentru întreg. Incremente cu preț fix de șase până la zece săptămâni, fiecare dimensionat după ce a aterizat cel anterior, dau certitudine bugetară fără să pretindă că cineva poate specifica optsprezece luni în avans.

Serviciul administrat este forma potrivită odată ce sistemul este în funcțiune: o taxă lunară care acoperă suport, corecții, monitorizare și un plafon definit de modificări, tarifată ca procent anual din costul construcției, nu după numărul de oameni. Faceți ca definiția serviciului să numească timpii de răspuns și calea de escaladare.

Dezvoltarea de software enterprise: ce împinge costul

Factorii de cost în ordinea impactului

Ordinea surprinde, pentru că funcționalitățile vin ultimele. Suprafața de integrare este prima, și anume numărul de proprietari externi, nu numărul de puncte finale. Țintele nefuncționale sunt a doua, pentru că pasul de la un serviciu care poate lua o fereastră de mentenanță la unul care nu poate schimbă fiecare strat al proiectării.

A treia este sarcina de asigurare și reglementare: timpul de ofertare, producerea de dovezi, sprijinul pentru audituri și un proces de lansare mai lent pe toată durata contractului. A patra este migrarea datelor cu reconcilierea, subestimată constant pentru că dificultatea stă în calitatea datelor vechi, nu în volum. A cincea este numărul de grupuri de părți interesate, care fixează latența deciziei. A șasea este numărul de medii. Scopul funcțional este al șaptelea și este de obicei singurul lucru din bugetul inițial.

Intervale de preț orientative în Regatul Unit

Intervalele de mai jos sunt estimări interne din angajamente britanice, exprimate ca preț al primului an incluzând descoperirea, construcția, testarea și intrarea în funcțiune, dar fără timpul propriului personal al cumpărătorului. Sunt orientative, nu cotații, iar intervalele sunt largi pentru că factorii de mai sus le mișcă.

Spus fără tabel: un serviciu unic cu două sau trei integrări, utilizatori interni și o țintă de 99,5 la sută se așază între GBP 120.000 și GBP 250.000 în primul an. Un sistem departamental orientat spre client, cu cinci până la opt integrări la 99,9 la sută, ajunge de la GBP 300.000 la GBP 700.000. O platformă centrală care înlocuiește un sistem vechi, cu zece până la douăzeci de integrări și o țintă de 99,95 la sută, ajunge de la GBP 900.000 la GBP 2,5 milioane. Un program reglementat cu mai multe entități la 99,99 la sută pornește de la circa GBP 2,5 milioane și urcă.

Costul de funcționare care nu este în buget

Adăugați deasupra costul anual de funcționare, care se așază între cincisprezece și douăzeci și cinci la sută din costul construcției pe an, odată incluse suportul, găzduirea, corecțiile, munca de securitate și un plafon modest de modificări. Un buget care finanțează construcția și nu funcționarea produce un sistem care se degradează vizibil în al doilea an, iar defalcarea noastră a costului de mentenanță software arată unde se duc acei bani.

Ieșire și continuitate

Un furnizor pe care nu îl puteți părăsi este un risc așezat în bilanțul vostru și este clauza cel mai des lăsată la finalul negocierii, când nu mai este nimeni atent. Patru lucruri fac posibilă o ieșire.

Codul sursă și istoricul lui aparțin unui depozit pe care cumpărătorul îl deține sau îl poate prelua cu preaviz, împreună cu lanțul de construcție și cu definițiile de infrastructură. Codul fără lanțul care îl construiește este o arhivă, nu un bun funcțional.

Documentația ar trebui să permită unui terț competent să opereze sistemul: arhitectură, contracte de integrare, proceduri pentru modurile de defectare care chiar s-au întâmplat și inventarul acreditărilor. Articolul nostru despre documentația tehnică pe care oamenii chiar o citesc arată ce supraviețuiește unei predări.

Depozitul fiduciar acoperă cazul în care furnizorul cade, nu cel în care pleacă, prin depunerea sursei la un terț pentru eliberare la declanșatoare definite. Merită acolo unde furnizorul este mic față de contract și merită citit cu atenție, pentru că un depozit neverificat eliberează cod care nu se compilează. Am analizat când se justifică în depozitul fiduciar de software, cine chiar are nevoie de el.

În fine, puneți un preț predării în contract. Un număr precizat de zile de transfer de cunoștințe la un tarif convenit, declanșat cu preaviz, transformă o ceartă într-o factură. Aceeași disciplină se aplică furnizorilor furnizorilor voștri, tratată în nota noastră despre securitatea lanțului de aprovizionare software.

Cum judeci credibilitatea enterprise a unui furnizor într-o singură întâlnire

Cinci întrebări stabilesc cea mai mare parte a acestor lucruri într-o oră, iar ezitarea vă spune la fel de mult ca răspunsul.

Întrebați față de ce obiective de disponibilitate și restabilire au livrat și cum era măsurată disponibilitatea. Un furnizor care a dus o obligație de 99,95 la sută numește punctul de măsurare și organizarea gărzii fără să fie întrebat. Cine nu a făcut-o vorbește despre redundanță în termeni generali.

Cereți să vedeți declarația de domeniu de pe certificatul lor ISO 27001 sau secțiunea excepțiilor din raportul lor SOC 2 de tip 2. Ambele sunt cereri obișnuite pentru un furnizor care le deține și stânjenitoare pentru unul care are doar o siglă. Apoi întrebați cum au tratat o ruptură de reconciliere în producție, lucru la care nimeni nu poate răspunde din teorie.

Întrebați cu cât au depășit ultimele lor trei programe și de ce. Toată lumea depășește, iar partea informativă este dacă știu numărul. Apoi întrebați cum arată procesul lor de ieșire, în zile și livrabile. Un furnizor care l-a scris se așteaptă să fie judecat după el.

Unde îl lasă asta pe cumpărător

Cuvântul enterprise ar trebui să descrie obligații, nu o clasă de preț. Odată scrise suprafața de integrare, obiectivele de disponibilitate și de restabilire, expunerea la reglementare și condițiile de ieșire, lista scurtă se aranjează singură, pentru că cei mai mulți furnizori nu pot aduce dovezi față de acele patru puncte.

Mecanik lucrează pe această formă de angajament prin serviciile noastre de dezvoltare software, iar pe partea de asigurare prin serviciile de testare de penetrare. Dacă adunați cerința și nu lista scurtă, lista de verificare pentru analiza tehnică de due diligence este un început rezonabil, iar numerele nefuncționale merită discutate primele.

Întrebări frecvente

Ce înseamnă dezvoltare software enterprise? Enterprise se definește prin constrângeri, nu prin mărimea cumpărătorului. Un proiect se califică atunci când are o suprafață largă de integrare deținută de mai multe părți, o obligație contractuală de disponibilitate și de restabilire, expunere la reglementare, mai multe grupuri de părți interesate care pot bloca fiecare o lansare, volume de date care rup proiectările naive și cerința de a coexista cu sisteme vechi pe care nimeni nu le înțelege pe deplin. O companie mare poate comanda un proiect obișnuit, iar o firmă mică reglementată unul cu adevărat enterprise.

Cât costă un program software enterprise în Regatul Unit? Ca estimări interne din angajamente britanice, un serviciu unic cu două sau trei integrări și o țintă de disponibilitate de 99,5 la sută ajunge de la GBP 120.000 la GBP 250.000 în primul an. Un sistem departamental orientat spre client la 99,9 la sută ajunge de la GBP 300.000 la GBP 700.000. O platformă centrală care înlocuiește un sistem vechi ajunge de la GBP 900.000 la GBP 2,5 milioane. Adăugați între cincisprezece și douăzeci și cinci la sută din costul construcției pe an pentru funcționare și suport.

Are nevoie un furnizor enterprise de ISO 27001, Cyber Essentials sau SOC 2? Ele dovedesc lucruri diferite. Cyber Essentials este o linie de bază susținută de guvernul britanic, formată din cinci controale tehnice, cu un nivel Plus verificat prin audit tehnic independent și cerut de PPN 014 pentru multe contracte publice. ISO/IEC 27001:2022 certifică un sistem de management al securității informației, așa că declarația de domeniu de pe certificat contează mai mult decât certificatul. SOC 2 este un raport american de atestare emis de o firmă de audit financiar, iar doar un tip 2 testează dacă acele controale au funcționat de-a lungul unei perioade.

Ce sunt obiectivele de punct de restabilire și de timp de restabilire? Obiectivul punctului de restabilire este cât de multe date acceptați să pierdeți după un dezastru, așa că un RPO de o oră înseamnă că poate dispărea până la o oră de tranzacții. Obiectivul timpului de restabilire este cât timp acceptați să fiți indisponibili, așa că un RTO de patru ore înseamnă că serviciul trebuie să deservească din nou trafic în patru ore. Ambele împing arhitectura și costul mai mult decât orice funcționalitate, pentru că aleg între copie și restaurare, pilot light, warm standby și multi-sit activ/activ.

Ce trebuie să prevadă despre ieșire un contract software enterprise? Patru lucruri. Proprietatea sau accesul transferabil la depozitul de cod sursă, la lanțul de construcție și la definițiile de infrastructură. Documentație suficientă cât un terț competent să opereze sistemul, inclusiv proceduri de operare și inventarul acreditărilor. Depozit fiduciar al codului acolo unde furnizorul este mic față de valoarea contractului, cu depuneri verificate, nu neverificate. Și o clauză de predare cu preț stabilit, care numește zilele de transfer de cunoștințe și tariful, ca plecarea să fie o factură, nu un litigiu.