Enamik ärisüsteeme on väärt täpselt nii palju, kui hästi nad räägivad kõige muuga, mida ettevõte kasutab. Liidestame maksed, raamatupidamise, laoprogrammid ja avalikud registrid nii, et vead on nähtavad ja käsitsi parandatavad.
Keskmine ettevõte ei ehitanud enamikku oma tarkvarast — ta ostis selle. CRM ühest kohast, ERP teisest, palgaarvestus kolmandast, e-pood neljandast. Iga ost oli omaette mõistlik ja iga süsteem teeb oma tööd hästi. Ainult et nende vahel liigub info inimese peas ja copy-paste’iga.
See on eraldi distsipliin oma API ehitamisest. Siin ei otsusta teie, mida teine pool pakub, kuidas ta autentib, millal ta oma välja ümber nimetab ja mis juhtub, kui ta kolmeks tunniks maha läheb. Töö seisneb selles, et ehitada kiht, mis neid erinevusi talub — ja mis annab märku enne, kui klient helistab.
Kuus valdkonda. Enamik projekte algab ühest neist ja avastab teise poole peal, et vaja on ka teist — seepärast tasub kaardistada tervik enne, kui esimest liidestust ehitama hakata.
Salesforce, SAP, Microsoft Dynamics, ServiceNow, HubSpot ja teised suured platvormid teie ülejäänud majaga. Igaühel on oma andmemudel ja oma arusaam sellest, mis on klient — töö algab sellest, et need omavahel kokku leppida.
Väiksemad pilveteenused — projektihaldus, tugi, turundus, raamatupidamine — ühendatud põhisüsteemiga nii, et andmed liiguvad ise. Koos autentimise, veakäsitluse ja monitooringuga, mida valmis konnektorid tavaliselt ei anna.
ERP, CRM, personalisüsteem, makselahendus ja analüütika üheks tervikuks, kus igal väljal on üks kokkulepitud tõeallikas. Ilma selleta on igal osakonnal oma versioon samast numbrist.
Kaks süsteemi lähevad alati lahku — küsimus on ainult selles, kas te saate sellest teada. Ehitame reeglid dublikaatide, vormingute ja konfliktide jaoks ning lepitusraporti, mis näitab lahknevused enne kui aruanne.
Kui osa süsteemidest on pilves ja osa teie serveriruumis, on liidestus ka võrgu- ja turvaküsimus, mitte ainult andmeküsimus. Katame mõlemad pooled: AWS, Azure, Google Cloud ja see, mis teil majas on.
Kaardistame, mis on täna millega ühendatud, kus info käsitsi liigub ja mis maksab kõige rohkem. Tulem on prioriteetide järjekord — enamik võitu tuleb tavaliselt kahest-kolmest liidestusest, mitte kõigist korraga.
Liidese stiili ei vali meie, vaid teine pool. Pärandsüsteemidega tähendab see sageli SOAP-i või failivahetust, ja korralikult tehtuna on see täiesti töökindel.
Lahutatud süsteemide arve ei tule kunagi ühe reana. Ta tuleb tundidena, vigadena ja otsustena, mis tehti vale numbri pealt. Need neli on mõõdetavad enne ja pärast.
Kõige kallim liidestus on see, mida teeb praegu inimene — iga päev, sama moodi.
Kui kaks süsteemi annavad sama küsimuse peale eri vastuse, ei saa kummagi peale otsust teha.
Liidestus, mille katkemisest saate teada kliendilt, on halvem kui liidestus, mida ei ole.
Kui iga uus tööriist nõuab kõigi olemasolevate ümbertegemist, siis te ei osta enam uusi tööriistu.
Neli etappi. Esiteks avastus ja arhitektuuri ülevaatus: mis süsteemid mängus on, kellele kuulub milline väli ja mis juhtub praegu siis, kui keegi midagi käsitsi muudab. Teiseks lahenduse disain — andmete vastavustabel, veakäsitlus, autentimine ja see, kas voog on sünkroonne või mitte. Kolmandaks arendus ja testimine simuleeritud partneri vastu. Ja neljandaks juurutamine koos monitooringu ja häiretega.
Ajakulu sõltub peaaegu täielikult teisest poolest. Hästi dokumenteeritud API ja kitsas maht on kahe kuni nelja nädala töö. Kui partneri dokumentatsioon on vale või testkeskkonda ei ole, kulub suurem osa ajast partneri käitumise väljaselgitamisele, mitte koodile — ja me ütleme seda ette, mitte kolmandas nädalas.
Partnerit valides küsige, mis juhtub siis, kui teine pool on maas, kuidas välditakse sama tellimuse kahekordset töötlemist, ja kust te näete, et liidestus töötab. Kui vastus viimasele on „klient annab teada”, siis monitooringut ei ole.
Eeldame, et teine pool on maas, aeglane või vastab valesti. Järjekorrad, korduskatsed ja idempotentsed kirjutamised on lähtepunkt, mitte hilisem parandus.
Simuleerime partneri liidese, nii et teie meeskond saab testida ka siis, kui partneri testkeskkond on kinni või seda ei ole olemas.
Lepitusraport võrdleb süsteeme regulaarselt ja näitab erinevused enne, kui need jõuavad aruandesse või kliendini.
Kui korralikku API-t ei ole ja jääb failivahetus või brauseriautomaatika, teeme selle ära — aga ütleme ette, mis see hooldusena maksab.
API võtmed, repositooriumid ja pilvekontod on teie omad. Liidestus ei tohi olla põhjus, miks te tarnijat vahetada ei saa.
Asume Tallinnas, samas ajavööndis ja samas lepinguraamistikus. Andmed jäävad soovi korral täielikult EL-i.
Makselahendused ja pangaliidesed, ERP- ja raamatupidamissüsteemid, CRM-id, laohaldus, logistika ja avalikud registrid, sealhulgas Eesti äriregister. Uue süsteemi puhul hindame liidese kvaliteedi ära enne, kui mahtu lubame.
Kokkuleppel. Kui partner muudab oma API-t, tuleb keegi seda jälgida — meie tugilepingu raames või teie meeskond, kellele anname üle monitooringu ja häirete seadistuse.
Andmeid liigutatakse krüpteeritult, logides ei säilitata isikuandmeid ja ligipääs on rollipõhine. Iga liidestuse kohta dokumenteerime, millised andmed liiguvad, kuhu ja millise õigusliku aluse alusel.
Valmis konnektor katab standardjuhtumi: kaks levinud süsteemi, vaikimisi väljad, üks suund. Kui teie andmemudel on standardne, on see õige valik ja me soovitame seda — odavam ja kiirem.
Vahe tuleb välja ääreolukordades. Mis juhtub, kui teine pool on kolm tundi maas? Kas sõnum läheb järjekorda või kaob? Kuidas lahendatakse konflikt, kui sama kirjet muudeti mõlemas süsteemis? Valmis konnektorid vastavad neile tavaliselt „ei tea”, ja just need juhtumid tekitavad hiljem kõige rohkem tööd. Kohandatud liidestus on see, kus need vastused on kokku lepitud ja kirjas.
Eeldusega, et see on halb — sest tavaliselt on. Kaks süsteemi, mis on aastaid eraldi elanud, sisaldavad dublikaate, eri vorminguid, tühje välju ja kirjeid, mis viitavad millelegi, mida enam ei ole.
Seepärast algab töö kaardistamisest: milline süsteem on iga välja jaoks tõeallikas, millised reeglid kehtivad vormingutele ja mis juhtub konflikti korral. Need reeglid pannakse kirja enne koodi. Töösse läheb ka lepitusraport, mis võrdleb süsteeme regulaarselt ja näitab lahknevused enne, kui need jõuavad aruandesse või kliendini — sest lahku minnakse alati, küsimus on ainult selles, kas te saate sellest teada.
Kitsa mahu ja hästi dokumenteeritud API puhul kaks kuni neli nädalat koos testide ja monitooringuga. Mitme süsteemi vaheline andmevoog, kus tuleb kokku leppida tõeallikad ja lepitusreeglid, on pigem kaks kuni neli kuud.
Aeg sõltub peaaegu täielikult teisest poolest, mitte meist. Kui partneri dokumentatsioon on vale või testkeskkonda ei ole, kulub suurem osa ajast partneri tegeliku käitumise väljaselgitamisele. Me ütleme seda ette, mitte kolmandas nädalas — ja kui olukord seda nõuab, alustame lühikese avastusetapiga, et anda number, mis peab.
Kirjeldage oma olukorda paari lausega. Vastame ühe tööpäeva jooksul.