Pasgemaakte ingenieurswese
Sagteware gebou vir die proses wat jy werklik uitvoer — wolkgebore, gedokumenteer, getoets, en oorhandig sonder ’n skuld wat jy op dag een erf.
Wat pasgemaakte ingenieurswese is
Pasgemaakte ingenieurswese beteken dat sagteware spesifiek vir een organisasie se proses gebou word, eerder as om ’n produk wat vir ’n algemene mark gebou is, op te stel. Dit is die regte keuse wanneer die proses wat geoutomatiseer word ’n bron van mededingende voordeel is, wanneer geen produk pas sonder om te verander hoe die besigheid werk nie, of wanneer lisensie- en aanpassingskoste vir ’n kant-en-klaar stelsel die koste oorskry om presies te bou wat nodig is.
Pasgemaak teenoor kant-en-klaar
Ons begin die meeste gesprekke deur kliënte uit ’n pasgemaakte bou te probeer praat, want vir ’n groot deel van besigheidsprobleme bestaan ’n produk reeds en om dit op te stel is goedkoper as om te bou. Rekeningkunde, betaalstaat, CRM, hulptoonbank en e-posbemarking is opgeloste markte; ’n pasgemaakte weergawe is gewoonlik ’n duur manier om met minder kenmerke te eindig.
Pasgemaak word die beter ekonomie in vier situasies.
Die proses is die voordeel. As hoe jy iets doen die rede is waarom kliënte jou kies, beteken om dit in ’n generiese produk te enkodeer om iemand anders se weergawe daarvan aan te neem, en jou onderskeider word ’n stel omweë.
Niks pas sonder verwringing nie. Wanneer om ’n produk te "implementeer" beteken om die besigheid te verander om by sy aannames te pas, sluit die ware koste die produktiwiteitsverlies van daardie verandering in, wat selde in die vergelyking verskyn.
Lisensie-ekonomie verander. Pryse per sitplek op skaal, of ’n produk waarvan die waardevolle kenmerk agter ’n ondernemingsvlak sit wat jy andersins nie nodig het nie, kan ’n bou binne twee tot drie jaar goedkoper maak, insluitend onderhoud.
Integrasie is die produk. Soms is wat nodig is nie ’n toepassing nie, maar die laag tussen toepassings. Dit is integrasiewerk, en dit word op die integrasiepilaarbladsy gedek.
Ons plaas die vergelyking op skrif tydens omvangbepaling, insluitend die argument om nie te bou nie. ’n Kliënt wat ’n produk op ons advies koop, is ’n beter langtermynverhouding as een wat iets bou waaroor hulle spyt is.
Wolkgebore en modulêre argitektuur
Ons bou standaard wolkgebore: toepassings wat ontwerp is vir die omgewing waarin hulle loop, eerder as om bloot daarheen verskuif te word.
Mikrodienste waar hulle hul plek verdien. Dienste word verdeel langs besigheidsvermoëns wat teen verskillende tempo's verander en verskillend moet skaal, nie ter wille van hulself verdeel nie. ’n Verspreide stelsel het werklike operasionele koste, en ’n goed gestruktureerde modulêre monoliet klop swak geteekende mikrodienste elke keer. Ons sê watter een ons dink jy nodig het en waarom.
Bedienerloos vir die regte werklaste. Gebeurtenishanteerders, geskeduleerde take, lêerverwerking en stekelrige lae-basislyn-verkeer loop as bedienerlose funksies waar om net vir uitvoering te betaal klop om vir onbenutte kapasiteit te betaal. Bestendige, latensie-sensitiewe werklaste loop op houers. Die besluit word per werklas geneem, nie per organisasie nie.
Houers en infrastruktuur as kode. Toepassings word in Docker-houers gelewer; omgewings word in weergawebeheerde infrastruktuurkode gedefinieer sodat verhoog en produksie dieselfde omgewing is wat twee keer gebou word, en ’n nuwe omgewing ’n pyplynlopie eerder as ’n week se opstelling is.
Dataontwerp eerste. Die meeste toepassings is ’n databasis met ’n koppelvlak, en die meeste wat sleg verouder doen dit omdat die datamodel ’n nagedagte was. Ons modelleer die domein in PostgreSQL voordat ons ’n skerm bou, plaas beperkings in die databasis en hou migrasies in weergawebeheer. Geld word in heelgetal-kleinste-eenhede gestoor, want dryfpuntrekenkunde met valuta is ’n defek wat vir ’n oudit wag.
Modulêre vervanging van verouderde stelsels. Monoliete word vermoë vir vermoë agter ’n fasade vervang, met die ou stelsel steeds aktief totdat elke vervanging ’n volle besigheidsiklus deurloop het. Grootknal-herskrywings is die betroubaarste manier om ’n jaar te spandeer en niks te lewer nie.
Sekuriteits- en nakomingsingenieurswese
Sekuriteit is ’n ontwerpinset, nie ’n kontrolelys voor bekendstelling nie.
Verifikasie en toegangsbeheer. Rolgebaseerde toegangsbeheer word volgens die werklike organisasiekaart ontwerp en aan die bedienerkant by elke versoek afgedwing. Multifaktorverifikasie is standaard vir administratiewe toegang, en enkelaanmelding integreer met die identiteitsverskaffer wat jy reeds gebruik.
Databeskerming onder POPIA. Persoonlike inligting word tydens datamodellering geklassifiseer. Bewaringstydperke, skrappingspaaie, toegangslogboeke en die vermoë om alles wat oor ’n persoon gehou word, voor te lê, word ingebou, want om ’n datasubjekversoek in ’n toepassing in te pas wat nooit daarvoor beplan is nie, is duur en dikwels onmoontlik.
Toepassingsekuriteit. Geparameteriseerde navrae, uitsetenkodering, CSRF-beskerming, afhanklikheidskandering in die pyplyn, geheime in ’n bestuurde stoor eerder as konfigurasielêers, en diensrekeninge met die minste voorregte. Niks hiervan is eksoties nie; dit alles onderskei ’n toepassing wat ’n penetrasietoets oorleef van een wat dit nie oorleef nie.
Ouditeerbaarheid. Wie het wat verander, wanneer, en wat dit voorheen was. In gereguleerde omgewings is dit ’n vereiste; oral elders is dit wat ’n voorval verklaarbaar maak eerder as ’n raaisel.
Enkripsie en vervoer. TLS oral, enkripsie van persoonlike en finansiële data in rus, en sleutelbestuur wat nie van een persoon se skootrekenaar afhang nie.
Hoe ’n bou verloop
-
1
Ontdekking en omvangbepaling
Ons karteer die proses, die mense wat dit bedryf, die stelsels wat dit raak en die reëls wat dit moet gehoorsaam. Uitset is ’n omvang, ’n argitektuur, ’n kostereeks en ’n uitdruklike aanbeveling, insluitend ’n aanbeveling om nie te bou nie, waar dit die eerlike antwoord is.
-
2
Argitektuur en datamodel
Domeinmodel, diensgrense, integrasiepunte en die PostgreSQL-skema word ontwerp en hersien voordat kenmerkwerk begin. Dit is die goedkoopste punt om verkeerd te wees.
-
3
Iteratiewe lewering
Tweeweeklikse inkremente, elk wat eindig met iets wat in ’n toetsomgewing loop wat jy kan gebruik. Toetsdekking en dokumentasie is deel van die inkrement, nie ’n fase aan die einde wat gesny word wanneer tyd min raak nie.
-
4
Sekuriteitsoorsig en verharding
Toegangsbeheer, dataklassifikasie, afhanklikheidskandering en ouditlogboeke word aan die ontwerp getoets voor ingebruikneming, nie nadat ’n kliënt vra of dit veilig is nie.
-
5
Ingebruikneming en stabilisering
Ontplooiing deur dieselfde pyplyn wat deurgaans gebruik word, met monitering, waarskuwings en terugrol in plek. Stabilisering is beplande tyd, want die eerste twee weke van werklike gebruik bring altyd dinge aan die lig wat geen toetsomgewing sou doen nie.
-
6
Oorhandiging
Bronkode, infrastruktuurkode, bedryfsprosedures, argitektuurdokumentasie en ’n deurloop met die span wat daarvoor verantwoordelik sal wees. Of jy ons daarna behou, behoort ’n kommersiële besluit te wees, nie ’n tegniese noodsaaklikheid nie.
Verbintenismodelle
Vaste-omvang-bou. ’n Gedefinieerde uitkoms, ’n vaste prys en ’n vaste skedule. Pas werk waar die omvang werklik vooraf kenbaar is: ’n vervanging vir ’n stelsel wat reeds bestaan, of ’n toepassing met ’n goed verstane proses daaragter. Veranderings gaan deur ’n geskrewe veranderingsproses, wat is wat ’n vaste prys betekenisvol hou.
Toegewyde kapasiteit. ’n Ooreengekome ingenieurskapasiteit vir ’n tydperk, wat aan ’n geprioritiseerde agterstand werk wat jy beheer. Pas deurlopende produkontwikkeling waar die rigting duidelik is maar die volgende kwartaal se kenmerke nie.
Argitektuur en hersiening. Ons argitekte werk met jou bestaande span (ontwerp die stelsel, hersien die bou, ontsluit besluite) sonder dat ons die meerderheid van die kode skryf. Pas organisasies met ingenieursvermoë wat senior argitektuur eerder as meer hande nodig het.
Redding en herstel. ’n Projek wat gestol het, of ’n stelsel wie se oorspronklike span weg is. Ons assesseer eerlik, insluitend wanneer die bevinding is dat die kode vervang eerder as herstel moet word, en ons sê so voordat ons die werk aanvaar.
Die verbintenis tot geen oordrag van tegniese skuld nie
Tegniese skuld is nie ’n morele mislukking nie; dit is ’n finansieringsbesluit, en dit is aanvaarbaar wanneer dit doelbewus geneem en volgens skedule terugbetaal word. Wat nie aanvaarbaar is nie, is ’n verskaffer wat ’n sperdatum haal deur teen ’n stelsel te leen wat jy daarna moet onderhou.
Ons verbintenis is spesifiek en kontroleerbaar. Dokumentasie, toetsdekking en infrastruktuur-as-kode word binne elke inkrement gelewer, nie uitgestel na ’n fase wat gesny word nie. Enige kortpad wat geneem word om ’n datum te haal, word op skrif aangeteken, met die koste om dit terug te betaal, en die besluit om dit te dra is joune eerder as ons s'n. Afhanklikhede is aktueel by oorhandiging. En oorhandiging sluit alles in wat nodig is om die stelsel sonder ons te bedryf en te verander: bronkode, infrastruktuurdefinisies, bedryfsprosedures en ’n werkende plaaslike ontwikkelingsomgewing. As ons dit behoorlik gedoen het, is jy vry om te vertrek.
Vrae oor pasgemaakte ingenieurswese
Wanneer is pasgemaakte sagteware die regte keuse bo ’n kant-en-klaar produk?
Wanneer die proses ’n mededingende voordeel is en ’n generiese produk dit sou platmaak; wanneer om ’n produk te implementeer sou beteken om die besigheid te verander om by sy aannames te pas; wanneer lisensie-ekonomie per sitplek op jou skaal ’n bou binne twee tot drie jaar oorskry; of wanneer wat werklik nodig is die integrasielaag tussen bestaande stelsels is. Buite daardie gevalle is dit gewoonlik goedkoper om ’n bestaande produk op te stel, en ons sal jou so vertel tydens omvangbepaling.
Wat beteken die verbintenis tot geen oordrag van tegniese skuld nie in die praktyk?
Dokumentasie, toetse en infrastruktuur-as-kode word binne elke tweeweeklikse inkrement gelewer, eerder as tydens ’n finale fase. Enige kortpad wat geneem word om ’n datum te haal, word neergeskryf met die koste om dit reg te stel, en dit is jou besluit of jy dit aanvaar. Afhanklikhede is aktueel by oorhandiging, en oorhandiging sluit bronkode, infrastruktuurdefinisies, bedryfsprosedures en ’n werkende plaaslike omgewing in; genoeg om die stelsel sonder ons te bedryf en te verander.
Op watter tegnologiestapel bou julle?
Hoofsaaklik PHP en Laravel vir toepassingswerk, PostgreSQL vir relasionele data, Docker vir verpakking en AWS vir infrastruktuur, met bedienerlose funksies vir gebeurtenisgedrewe en geskeduleerde werklaste. Waar ’n bestaande stelsellandskap anders vereis, byvoorbeeld ’n interne .NET- of Java-platform of ’n spesifieke wolk, werk ons daarin eerder as om jou tot ’n herskrywing te probeer oorreed.
Wie besit die intellektuele eiendom in ’n pasgemaakte bou?
Jy. Intellektuele eiendom in opdragwerk dra oor na die kliënt, soos in die verbintenisooreenkoms gestel. Voorafbestaande komponente en oopbron-biblioteke bly onder hul eie lisensies, en ons lys wat daardie is voordat die bou begin eerder as by oorhandiging.
Kan julle ’n stelsel oorneem wat ’n ander verskaffer gebou het?
Ja, begin met ’n assessering van die kode, datamodel, infrastruktuur en ontplooiingsproses. Daardie assessering lewer ’n eerlike antwoord op, wat soms is dat ’n herskrywing van ’n komponent goedkoper is as om dit te herstel. Ons gee jou die assessering en die redenasie of jy nou met ons voortgaan of nie.
Hoe prys julle ’n bou?
Vaste-omvang-werk word geprys vanaf ’n omvangbepaalde argitektuur ná ontdekking, met ’n geskrewe veranderingsproses. Toegewyde kapasiteit word per tydperk geprys. Nie een word van ’n kenmerklys alleen aangehaal nie, want ’n prys wat gegee word voordat die datamodel verstaan word, is ’n raaiskoot waarvoor iemand uiteindelik betaal.
Bepaal die omvang van ’n bou
Bring die proses, nie die spesifikasie nie. Ons sal dit karteer, jou vertel of dit gebou of gekoop moet word, en die weergawe prys wat die moeite werd is om te doen.
Bespreek ’n omvangbepalingsessie