Ohjelmistokehitys

Lähdemme siitä, mitä tiiminne pystyy ylläpitämään ja mihin se pystyy rekrytoimaan, mitä muut järjestelmänne käyttävät ja mitä ohjelmiston on tehtävä. Useimmille liiketoimintaohjelmistoille se tarkoittaa valtavirran kieltä, kuten TypeScriptiä, Javaa, C#:a tai Pythonia, relaatiotietokantaa ja jo käyttämäänne pilveä. Kirjaamme jokaisen valinnan ja sen perusteet.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Kyllä. Suunnittelemme asiakkaiden eristyksen, asiakaskohtaisen konfiguraation, roolit, laskutuksen liitynnät ja auditointijäljet ensimmäisestä julkaisusta lähtien, koska niiden lisääminen myöhemmin tarkoittaa tietomallin uudelleenkirjoittamista. Sovimme kanssanne, jakavatko asiakkaat tietokannan, skeeman vai eivät mitään, tietoturva- ja kustannustarpeidenne perusteella.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Alustanne rakennetaan itsenäisistä liiketoimintakyvykkyyksistä, joilla on omat APInsä, kuten hinnoittelu, käyttöönotto tai laskutus. Jokaista voi muuttaa, skaalata tai korvata koskematta muihin, ja uudet tuotteet voivat käyttää niitä uudelleen. Se sopii alustoille, jotka kasvavat vuosia; pieni työkalu ei sitä tarvitse.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Käytämme Reactia Next.js:llä useimmissa uusissa sovelluksissa, koska se tukee palvelinpuolen renderöintiä ja siinä on vahvat työkalut. Työskentelemme myös Angularin ja Vue.js:n kanssa ja jatkamme jo käyttämässänne kehyksessä, kun se on järkevä valinta.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Valitkaa työpöytäsovellus, kun työ vaatii offline-käyttöä, suoraa pääsyä laitteisiin tai paikallisiin tiedostoihin, raskasta dataa tai grafiikkaa tai nopeita näppäimistökäyttöisiä näyttöjä. Useimpiin muihin tarpeisiin verkkosovellus on helpompi ottaa käyttöön ja päivittää. Suosittelemme tapauskohtaisesti, ja joskus oikea vastaus on verkkosovellus pienellä työpöytäosalla.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Natiivit sovellukset antavat parhaan suorituskyvyn ja parhaimman istuvuuden kullekin käyttöjärjestelmälle. Alustariippumattomat sovellukset jakavat yhden koodikannan Windowsin, macOS:n ja Linuxin kesken, mikä pienentää niiden rakentamisen ja muuttamisen kustannusta. Suosittelemme natiivia, kun yksi alusta hallitsee tai työ on vaativaa, ja alustariippumatonta, kun usealla alustalla on merkitystä.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Kyllä, tehtävissä, joissa se on mahdollista. Sovimme kanssanne, mitä dataa kukin käyttäjä tarvitsee laitteella, pidämme sen salattuna ja tallennamme heidän muutoksensa, kunnes verkko palaa. Kun sama tietue muuttuu kahdessa paikassa, sovitut säännöt ratkaisevat, kumpi muutos voittaa, tai pyytävät ihmistä valitsemaan.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Kyllä. Integroimme laitteisiin, joita henkilöstönne käyttää, kuten viivakoodinlukijoihin, kuitti- ja tarrakirjoittimiin, vaakoihin ja maksupäätteisiin. Yhdistämme kunkin laitteen ajureiden, SDK:iden tai vakioporttien kautta ja testaamme täsmälleen niillä malleilla ja laiteohjelmistoilla, joita teillä on, koska samantyyppiset laitteet käyttäytyvät usein eri tavalla.

Lukekaa lisää: Sovellus-, alusta- ja komposoitava tuotekehitysLinkki tähän kysymykseen

Natiivit sovellukset Swiftillä ja Kotlinilla antavat täyden pääsyn laitteen ominaisuuksiin. Alustariippumattomat sovellukset React Nativella tai Flutterilla jakavat suurimman osan koodistaan iOS:n ja Androidin välillä, mikä laskee niiden rakentamisen ja muuttamisen kustannusta. Suosittelemme natiivia, kun sovellus riippuu vahvasti laitteesta, ja alustariippumatonta useimpiin liiketoiminta- ja kuluttajasovelluksiin.

Lukekaa lisää: Mobiili, tilalaskenta ja digitaaliset kaksosetLinkki tähän kysymykseen

Digitaalinen kaksonen on elävä 3D-malli fyysisestä paikasta tai prosessista, syötettynä sen antureiden ja järjestelmien datalla. Se kannattaa rakentaa, kun paikkaan liittyviä päätöksiä on kallista testata todellisuudessa. Esimerkkejä ovat tuotantolinjan muuttaminen, sataman suunnittelu, älykkään kaupunginosan ylläpito tai henkilöstön kouluttaminen harvinaisia tapahtumia varten.

Lukekaa lisää: Mobiili, tilalaskenta ja digitaaliset kaksosetLinkki tähän kysymykseen

Niihin, jotka kuvaavat todellista kohdetta: teollisiin IoT- ja anturialustoihin, rakennus- ja laitossysteemeihin sekä ERP- ja kunnossapitojärjestelmiin. Sovimme datalähteet ja sen, kuinka usein kukin päivittyy, jotta kaksonen näyttää kohteen sellaisena kuin se on.

Lukekaa lisää: Mobiili, tilalaskenta ja digitaaliset kaksosetLinkki tähän kysymykseen

Kyllä, kun polut sen sallivat. Tallennamme käyttäjän tarvitseman datan laitteelle salattuna ja jonotamme hänen muutoksensa, kunnes yhteys palaa. Synkronointisäännöt päättävät, mitä tapahtuu, kun sama tietue on muuttunut kahdessa paikassa, ja suunnittelemme ne säännöt kanssanne.

Lukekaa lisää: Mobiili, tilalaskenta ja digitaaliset kaksosetLinkki tähän kysymykseen

Suunnittelemme WCAG 2.2 AA:n mukaan ensimmäisestä luonnoksesta lähtien: riittävä kontrasti, näkyvä kohdistus, looginen lukujärjestys, riittävän suuret kosketuskohdat ja tunniste jokaiselle säätimelle. Automaattiset tarkistukset ajetaan jokaisessa muutoksessa. Ennen jokaista julkaisua testaamme keskeiset polut käsin näppäimistöllä ja ruudunlukijoilla.

Lukekaa lisää: UX ja autonominen laadunvarmistusLinkki tähän kysymykseen

Kyllä. Oikealta vasemmalle -suunnittelu on enemmän kuin näytön peilaamista: navigaatio, edistymisilmaisimet ja suunnalliset kuvakkeet peilautuvat, kun taas numerot, logot ja median säätimet yleensä eivät. Arabiankielinen teksti tarvitsee oman kirjasimensa, kokonsa ja rivikorkeutensa, ja katselmoimme molemmat suunnat äidinkielisten lukijoiden kanssa.

Lukekaa lisää: UX ja autonominen laadunvarmistusLinkki tähän kysymykseen

Käyttöliittymätestit hajoavat yleensä, kun painike siirtyy tai nimetään uudelleen, vaikka ominaisuus toimisi yhä. Itsestään korjaavat testit käyttävät tekoälyä elementin löytämiseen uudelleen ja ehdottavat päivitettyä testiä, jonka insinööri katselmoi ennen hyväksyntää. Sarja pysyy luotettavana paljastamatta todellisia virheitä.

Lukekaa lisää: UX ja autonominen laadunvarmistusLinkki tähän kysymykseen

Se lukee suuria määriä vanhaa koodia nopeasti: selittää, mitä ohjelma tekee, jäljittää, minne data menee, ehdottaa refaktorointeja ja luonnostelee testejä. Insinöörit päättävät muutoksista, katselmoivat jokaisen rivin ja todistavat sen karakterisointitesteillä. Tekoäly nopeuttaa ymmärtämistä; se ei korvaa varmennusta.

Lukekaa lisää: Tekoälyllä kiihdytetty legacy-järjestelmien modernisointiLinkki tähän kysymykseen

Kyllä. Käännämme tai rakennamme COBOL-ohjelmat uudelleen pilvinatiiveiksi palveluiksi ja muutamme DB2-datan täsmäytyksin jokaisessa vaiheessa. Eräajot ja tiedostorajapinnat saavat nykyaikaiset vastineet. Vakaat ja siirtämisen osalta kalliit osat voivat jäädä rajapintakerroksen taakse vuoroaan odottamaan.

Lukekaa lisää: Tekoälyllä kiihdytetty legacy-järjestelmien modernisointiLinkki tähän kysymykseen

Silloin, kun vanha ydin on vakaa ja oikein mutta vaikeasti saavutettava. Nykyaikaiset rajapinnat sen edessä antavat uusien kanavien, kumppaneiden ja tuotteiden käyttää sen toimintoja koskematta sen sisäisiin rakenteisiin. Suosittelemme korvaamista, kun järjestelmä estää muutoksen, sitä ei voi suojata tai sitä ei enää voida miehittää.

Lukekaa lisää: Tekoälyllä kiihdytetty legacy-järjestelmien modernisointiLinkki tähän kysymykseen

Suvereeni pilvi pitää datan, operaatiot ja oikeudellisen hallinnan yhden lainkäyttöalueen sisällä. Se voi olla alueellinen tarjoaja, valtion pilvi, hyperskaalapalvelun alue oikein valvontakeinoin tai oma konesalinne. Tarvitsette sellaisen, kun laki tai valvojanne edellyttää tiettyjen tietojen pysyvän maassa. Kartoitamme, mitkä työkuormistanne kuuluvat tällaisten sääntöjen piiriin, ennen kuin suosittelemme niiden sijaintia.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

Yleensä sitä, jota käytätte jo, ellette ole selkeää syytä vaihtaa. Ratkaisevat tekijät ovat datan sijainti, nykyiset sopimuksenne ja osaamisenne, tarvitsemanne hallinnoidut palvelut ja se, miten muut järjestelmänne yhdistyvät. Työskentelemme AWS:n, Microsoft Azuren, Google Cloudin, Alibaba Cloudin ja alueellisten valtion pilvien kanssa ja pidämme toimittajakohtaisen koodin siellä, missä se on kannattavaa.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

Infrastruktuuri määritellään avoimen lähdekoodin työkaluilla, kuten Terraformilla, OpenTofulla tai Pulumilla, ja työkuormat ajetaan Kubernetesissä tai muilla siirrettävillä alustoilla. Kun tarjoajan oma palvelu on parempi valinta, käytämme sitä tarkoituksella ja kirjaamme irtautumisreitin. Saatte kirjallisen arvion siitä, mitä kunkin työkuorman siirtäminen vaatisi.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

Se riippuu järjestelmäkohtaisesti: missä sen dataa saa säilyttää, sen suorituskyky- ja yhteystarpeet, sen lisenssit ja se, mitä tiiminne pystyy ylläpitämään. Moni yritys pyörittää hybridiympäristöä, joka toimii hyvin, kun se on suunniteltu yhtenä kokonaisuutena. Vertaamme vaihtoehtoja kustannusten, riskin ja työn määrän suhteen ja suosittelemme sitä, jonka itse valitsisimme.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

Harkitkaa sitä, kun data ei saa lähteä rajanne ulkopuolelle tai kun käyttö on niin tasaista, että omistettu kapasiteetti maksaa vähemmän kuin kutsukohtainen maksu. Vertaamme yksityistä klusteria, suvereenia pilveä ja julkista mallipalvelua työkuormallenne ja mitoitamme sitten klusterin ja sen palvelemat mallit.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

Kyllä. Lähdemme siitä, mitä teillä on, ja korvaamme vain sen, mikä on tuen ulkopuolella tai suunnittelun tiellä. Kun laitteistoa tai lisenssejä on ostettava, määrittelemme, mitä tarvitaan ja miksi, ja te valitsette toimittajan.

Lukekaa lisää: Pilvi-insinöörityö, SovereignTech ja hybridimigraatioLinkki tähän kysymykseen

DevOps on käytäntö, jossa kehittäjät ja operaatiot jakavat vastuun ohjelmiston ajamisesta. Alustainsinöörityö muuttaa tämän käytännön tuotteeksi: sisäiseksi kehittäjäalustaksi, joka antaa jokaiselle tiimille saman testatun tavan rakentaa, ottaa käyttöön ja ajaa palveluja. Tiiminne käyttävät aikansa ominaisuuksiin, eivät putkiin.

Lukekaa lisää: DevOps, alustainsinöörityö ja tekoälyn koodausympäristötLinkki tähän kysymykseen

Yleensä niitä, jotka teillä jo on. Työskentelemme Terraformin, OpenTofun ja Pultumin kanssa infrastruktuurissa, Kubernetesin kanssa kontteja varten ja yleisten CI/CD-palvelujen kanssa, mukaan lukien GitLab CI/CD, GitHub Actions ja Argo CD. Suosittelemme muutosta vain, kun jokin työkalu estää sen, mitä tarvitsette.

Lukekaa lisää: DevOps, alustainsinöörityö ja tekoälyn koodausympäristötLinkki tähän kysymykseen

Eivät, kun ne asetetaan käyttötapauskohtaisesti. Tehtävä siirtyy pienemmälle mallille vasta, kun se läpäisee samat arvioinnit kuin huippumalli, ja välimuistissa olevia vastauksia käytetään vain siellä, missä tallennettu vastaus pysyy oikeana. Kaikki epävarma ohjataan yhä suuremmalle mallille.

Lukekaa lisää: SRE, havaittavuus sekä pilven ja tekoälyn token-FinOpsLinkki tähän kysymykseen

GreenOps soveltaa FinOps-lähestymistapaa energiaan ja hiileen. Työkuormat mitoitetaan sen mukaan, mitä ne käyttävät, ajetaan siellä ja silloin, kun sähkö on puhtaampaa, jos ne voivat odottaa, ja raportoidaan ehdoilla, joita ESG-raportointinne tarvitsee.

Lukekaa lisää: SRE, havaittavuus sekä pilven ja tekoälyn token-FinOpsLinkki tähän kysymykseen

Tuki vaihtelee mallin ja laiteohjelmistoversion mukaan. Tarkistamme jokaisen HSM:n CBOM-auditoinnissa ja suunnittelemme päivitykset tai vaihdot vain sinne, missä niitä tarvitaan.

Lukekaa lisää: Postkvanttisalaus ja kvanttiturvallinen salausLinkki tähän kysymykseen

Harvoin. Postkvanttikryptografia toimii verkoissa ja laitteistossa, jotka teillä jo on, kun taas QKD vaatii erilliset optiset linkit. Tarkastelemme QKD:tä vain muutamalle arvokkaalle linkille, joilla valvontaviranomainen tai kumppani sitä odottaa.

Lukekaa lisää: Postkvanttisalaus ja kvanttiturvallinen salausLinkki tähän kysymykseen

AWS:n, Microsoft Azuren, Google Cloudin, Alibaba Cloudin ja alueellisten hallituksen pilvien sekä omien datakeskustenne ja yksityisten GPU-klustereiden kanssa. Infrastruktuuri määritellään Terraformilla, OpenTofulla tai Pulumilla ja työkuormat ajetaan Kubernetesilla, joten palveluntarjoajan valinta pysyy avoimena.

Lukekaa lisää: Pilvi ja infrastruktuuriLinkki tähän kysymykseen

Kyllä. Arvioimme, mitkä palvelut sitovat teidät palveluntarjoajaan, suunnittelemme tavoitteen suvereeniin pilveen, toiseen palveluntarjoajaan tai omaan datakeskukseenne ja siirrämme työkuormat vaiheittain, kullekin peruutuspolku. Te päätätte, kuinka pitkälle menette: jotkut asiakkaat siirtävät kaiken, toiset vain ne työkuormat, joista valvontaviranomaisenne välittävät.

Lukekaa lisää: Pilvi ja infrastruktuuriLinkki tähän kysymykseen