Szoftverfejlesztés

Abból indulunk ki, amit a csapata üzemeltetni tud, és amihez munkaerőt talál, amit a többi rendszere használ, és amit a szoftvernek tudnia kell. A legtöbb üzleti szoftvernél ez egy elterjedt nyelvet jelent, például TypeScript, Java, C# vagy Python, egy relációs adatbázist és az Ön által már használt felhőt. Minden döntést és annak indokait rögzítjük.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

Igen. A bérlői elkülönítést, a bérlőnkénti konfigurációt, a szerepköröket, a számlázási kapcsolódási pontokat és az auditnaplókat már az első kiadástól megtervezzük, mert utólag hozzáadni őket az adatmodell újraírását jelentené. Önnel együtt döntjük el, hogy a bérlők adatbázist, sémát vagy semmit nem osztanak meg, biztonsági és költségigényei alapján.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

A platformja önálló, saját API-val rendelkező üzleti képességekből épül fel, például az árazásból, az ügyfélbevezetésből vagy a számlázásból. Mindegyik módosítható, méretezhető vagy lecserélhető anélkül, hogy a többihez hozzányúlnánk, és az új termékek újrahasznosíthatják őket. Ez olyan platformokhoz illik, amelyek évekig nőni fognak; egy kis eszköznek nincs rá szüksége.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

Az új alkalmazások többségénél a Reactet használjuk Next.js-szel, mert támogatja a szerveroldali renderelést, és erős az eszköztámogatása. Angularral és Vue.js-szel is dolgozunk, és az Ön által már használt keretrendszerben folytatjuk, ha ez a célszerű választás.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

Asztali alkalmazást akkor válasszon, ha a munkához offline használat, közvetlen hozzáférés eszközökhöz vagy helyi fájlokhoz, nagy adat- vagy grafikai igény, vagy gyors, billentyűzettel vezérelt képernyők kellenek. A legtöbb más igénynél a webes alkalmazás könnyebben bevezethető és frissíthető. Esetről esetre adunk javaslatot, és néha egy webes alkalmazás egy kis asztali komponenssel a helyes válasz.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

A natív alkalmazások nyújtják a legjobb teljesítményt és a legjobban illeszkednek az adott operációs rendszerhez. A platformfüggetlen alkalmazások egy kódbázist osztanak meg Windows, macOS és Linux között, ami csökkenti az építés és a módosítás költségét. Natívot javaslunk, ha egy platform dominál vagy a munka igényes, platformfüggetlent pedig, ha több platform számít.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

Igen, azoknál a feladatoknál, amelyek ezt lehetővé teszik. Önnel együtt döntjük el, hogy az egyes felhasználóknak milyen adatokra van szükségük az eszközön, ezeket titkosítva tároljuk, és a hálózat helyreállásáig rögzítjük a változtatásaikat. Ha ugyanaz a rekord két helyen változik, egyeztetett szabályok döntik el, melyik változás érvényes, vagy egy személyt kérnek meg a döntésre.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

Igen. Integráljuk azokat az eszközöket, amelyeket munkatársai használnak, például vonalkódolvasókat, nyugta- és címkenyomtatókat, mérlegeket és fizetési terminálokat. Az egyes eszközök illesztőprogramjain, SDK-in vagy szabványos portjain keresztül kapcsolódunk, és az Ön által használt pontos modellekkel és firmware-rel tesztelünk, mert az azonos típusú eszközök gyakran eltérően viselkednek.

Tovább: Alkalmazás-, platform- és komponálható termékfejlesztésHivatkozás erre a kérdésre

A Swiftben és Kotlinban készült natív alkalmazások biztosítják a legteljesebb hozzáférést az eszköz funkcióihoz. A React Native-ben vagy Flutterben készült többplatformos alkalmazások kódjuk nagy részét megosztják az iOS és az Android között, ami csökkenti az elkészítésük és módosításuk költségét. Natív megoldást akkor javaslunk, ha az alkalmazás erősen függ az eszköztől, a legtöbb üzleti és fogyasztói alkalmazáshoz pedig többplatformosat.

Tovább: Mobil, térbeli számítástechnika és digitális ikrekHivatkozás erre a kérdésre

A digitális iker egy fizikai helyszín vagy folyamat valós idejű 3D-modellje, amelyet az érzékelőiből és rendszereiből származó adatok táplálnak. Akkor érdemes megépíteni, ha a helyszínnel kapcsolatos döntéseket költséges a valóságban kipróbálni. Ilyen például egy gyártósor átalakítása, egy kikötő tervezése, egy okosvárosi negyed üzemeltetése vagy a munkatársak felkészítése ritka eseményekre.

Tovább: Mobil, térbeli számítástechnika és digitális ikrekHivatkozás erre a kérdésre

Azokhoz, amelyek a valódi helyszínt írják le: ipari IoT- és érzékelőplatformokhoz, épület- és üzemi rendszerekhez, valamint ERP- és eszközkarbantartási rendszerekhez. Megállapodunk az adatforrásokról és a frissítésük gyakoriságáról, hogy az iker a helyszín valós állapotát mutassa.

Tovább: Mobil, térbeli számítástechnika és digitális ikrekHivatkozás erre a kérdésre

Igen, ahol a felhasználói utak ezt lehetővé teszik. A felhasználónak szükséges adatokat titkosítva tároljuk az eszközön, a módosításait pedig sorba állítjuk, amíg a kapcsolat helyre nem áll. A szinkronizálási szabályok határozzák meg, mi történik, ha ugyanaz a rekord két helyen változott, és ezeket a szabályokat Önnel együtt alakítjuk ki.

Tovább: Mobil, térbeli számítástechnika és digitális ikrekHivatkozás erre a kérdésre

Az első drótvázlattól a WCAG 2.2 AA szerint tervezünk: elegendő kontraszt, látható fókusz, logikus olvasási sorrend, kellően nagy célterületek és címke minden vezérlőelemhez. Automatizált ellenőrzések futnak minden változtatásnál. Minden kiadás előtt a kulcsfontosságú felhasználói utakat kézzel is teszteljük billentyűzettel és képernyőolvasókkal.

Tovább: UX és autonóm minőségmérnökségHivatkozás erre a kérdésre

Igen. A jobbról balra haladó tervezés több a képernyő tükrözésénél: a navigáció, a folyamatjelzők és az irányt jelző ikonok tükröződnek, a számok, a logók és a médiavezérlők általában nem. Az arab szöveghez saját betűtípus, betűméret és sormagasság kell, és mindkét irányt anyanyelvi olvasókkal ellenőrizzük.

Tovább: UX és autonóm minőségmérnökségHivatkozás erre a kérdésre

A felülettesztek általában elbuknak, amikor egy gomb máshová kerül vagy új nevet kap, pedig a funkció továbbra is működik. Az önjavító tesztek MI segítségével újra megtalálják az elemet, és frissített tesztet javasolnak, amelyet egy mérnök az elfogadás előtt átnéz. A tesztcsomag így megbízható marad, anélkül hogy valódi hibákat rejtene el.

Tovább: UX és autonóm minőségmérnökségHivatkozás erre a kérdésre

Gyorsan átolvas nagy mennyiségű régi kódot: elmagyarázza, mit csinál egy program, végigköveti, merre haladnak az adatok, refaktorálást javasol, és teszttervezeteket készít. A mérnökök döntik el, mi változzon, minden sort felülvizsgálnak, és karakterizációs tesztekkel igazolják a működést. Az MI felgyorsítja a megértést, de nem helyettesíti az ellenőrzést.

Tovább: Örökölt rendszerek MI-vel gyorsított korszerűsítéseHivatkozás erre a kérdésre

Igen. A COBOL-programokat felhőnatív szolgáltatásokká alakítjuk vagy építjük újra, a DB2-adatokat pedig minden lépésnél egyeztetve migráljuk. A kötegelt feladatok és a fájlalapú interfészek korszerű megfelelőt kapnak. A stabil, de költségesen áthelyezhető elemek egy API-réteg mögött maradhatnak, amíg sorra nem kerülnek.

Tovább: Örökölt rendszerek MI-vel gyorsított korszerűsítéseHivatkozás erre a kérdésre

Amikor a régi mag stabil és helyesen működik, de nehezen érhető el. Az elé helyezett korszerű API-k révén új csatornák, partnerek és termékek használhatják a funkcióit anélkül, hogy a belső felépítéséhez hozzányúlnának. Akkor javasoljuk a cserét, ha a rendszer akadályozza a változtatásokat, nem tehető biztonságossá, vagy már nem található hozzá szakember.

Tovább: Örökölt rendszerek MI-vel gyorsított korszerűsítéseHivatkozás erre a kérdésre

A szuverén felhő az adatokat, a működést és a jogi irányítást egy joghatóságon belül tartja. Lehet regionális szolgáltató, kormányzati felhő, egy hiperskálázó megfelelő ellenőrzésekkel rendelkező régiója vagy a saját adatközpontja. Akkor van rá szüksége, ha a jogszabály vagy a szabályozója előírja, hogy bizonyos nyilvántartások az országban maradjanak. Mielőtt javasolnánk, hol fussanak, feltérképezzük, mely munkaterheléseire vonatkoznak ilyen szabályok.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

Általában azt, amelyiket már használja, hacsak nincs egyértelmű ok a váltásra. A döntő tényezők az adattárolási hely, a meglévő szerződései és szaktudása, a szükséges menedzselt szolgáltatások, valamint az, hogyan kapcsolódnak a többi rendszere. Az AWS-szel, a Microsoft Azure-ral, a Google Clouddal, az Alibaba Clouddal és regionális kormányzati felhőkkel dolgozunk, és a szolgáltatóspecifikus kódot azokra a helyekre korlátozzuk, ahol megéri.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

Az infrastruktúrát nyílt forráskódú eszközökkel, például Terraformmal, OpenTofuval vagy Pulumival definiáljuk, a munkaterhelések pedig Kubernetesen vagy más hordozható platformon futnak. Ahol egy szolgáltató saját szolgáltatása a jobb választás, tudatosan használjuk, és leírjuk a kivezetés útját. A végén írásos becslést kap arról, mekkora munkát jelentene az egyes munkaterhelések átköltöztetése.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

Ez rendszerenként változik: hol tárolhatók az adatai, milyen teljesítmény- és kapcsolatigénye van, milyen licencei vannak, és mit tud a csapata működtetni. Sok vállalat hibrid rendszerkörnyezetet működtet, ami akkor működik jól, ha egységes egészként tervezték. Összehasonlítjuk a lehetőségeket költség, kockázat és ráfordítás szerint, és azt javasoljuk, amelyiket mi választanánk.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

Akkor érdemes megfontolni, ha az adatok nem hagyhatják el az Ön határait, vagy ha a használat elég egyenletes ahhoz, hogy a saját kapacitás kevesebbe kerüljön, mint a hívásonkénti fizetés. Összehasonlítjuk a munkaterheléséhez egy privát fürtöt, egy szuverén felhőt és egy nyilvános modellszolgáltatást, majd méretezzük a fürtöt és a kiszolgált modelleket.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

Igen. Abból indulunk ki, ami van, és csak azt cseréljük, ami már nem támogatott, vagy útban van a tervnek. Ahol hardvert vagy licenceket kell vásárolni, meghatározzuk, mire van szükség és miért, a beszállítót pedig Ön választja.

Tovább: Felhőmérnökség, SovereignTech és hibrid migrációHivatkozás erre a kérdésre

A DevOps az a gyakorlat, amelyben a fejlesztők és az üzemeltetők közösen felelnek a szoftver működtetéséért. A platformmérnökség termékké alakítja ezt a gyakorlatot: belső fejlesztői platformot ad, amely minden csapatnak ugyanazt a tesztelt módszert kínálja a szolgáltatások buildelésére, telepítésére és futtatására. Csapatai így a funkciókra fordíthatják idejüket, nem a folyamatokra.

Tovább: DevOps, platformmérnökség és MI-kódolási keretrendszerekHivatkozás erre a kérdésre

Általában azokat, amelyek már megvannak Önnél. Az infrastruktúrához Terraformmal, OpenTofuval és Pulumival, a konténerekhez Kubernetesszel, valamint az elterjedt CI/CD-szolgáltatásokkal dolgozunk, köztük a GitLab CI/CD-vel, a GitHub Actionsszel és az Argo CD-vel. Csak akkor javaslunk váltást, ha egy eszköz akadályozza azt, amire szüksége van.

Tovább: DevOps, platformmérnökség és MI-kódolási keretrendszerekHivatkozás erre a kérdésre

Nem, ha használati esetenként állítjuk be őket. Egy feladat csak akkor kerül kisebb modellhez, ha ugyanazokon az értékeléseken megfelel, mint az élvonalbeli modell, gyorsítótárazott választ pedig csak ott használunk, ahol a tárolt válasz helyes marad. Ami bizonytalan, továbbra is a nagyobb modellhez kerül.

Tovább: SRE, megfigyelhetőség, valamint felhő- és MI-token FinOpsHivatkozás erre a kérdésre

A GreenOps a FinOps megközelítését alkalmazza az energiára és a szén-dioxid-kibocsátásra. A munkaterheléseket a tényleges felhasználásukhoz méretezzük, és ha várhatnak, ott és akkor futtatjuk őket, ahol és amikor tisztább az áram, a jelentéseket pedig az ESG-beszámolói által igényelt formában készítjük el.

Tovább: SRE, megfigyelhetőség, valamint felhő- és MI-token FinOpsHivatkozás erre a kérdésre

A támogatás modellenként és firmware-verziónként változik. A CBOM-audit során minden HSM-et ellenőrzünk, és csak ott tervezünk frissítést vagy cserét, ahol szükséges.

Tovább: Posztkvantum-kriptográfia és kvantumbiztos titkosításHivatkozás erre a kérdésre

Ritkán. A posztkvantum-kriptográfia a már meglévő hálózatokon és hardveren fut, a QKD-hez viszont dedikált optikai kapcsolatok kellenek. A QKD-t csak néhány nagy értékű kapcsolatnál vizsgáljuk meg, ahol egy szabályozó hatóság vagy egy partner elvárja.

Tovább: Posztkvantum-kriptográfia és kvantumbiztos titkosításHivatkozás erre a kérdésre

AWS, Microsoft Azure, Google Cloud, Alibaba Cloud és regionális kormányzati felhők, valamint az Ön saját adatközpontjai és privát GPU-fürtjei. Az infrastruktúrát Terraformban, OpenTofuban vagy Pulumiban definiáljuk, a munkaterhelések Kubernetesen futnak, így a szolgáltató megválasztása nyitott marad.

Tovább: Felhő és infrastruktúraHivatkozás erre a kérdésre

Igen. Felmérjük, mely szolgáltatások kötik Önt a szolgáltatóhoz, megtervezzük a célkörnyezetet egy szuverén felhőben, egy másik szolgáltatónál vagy a saját adatközpontjában, és szakaszosan költöztetjük a munkaterheléseket, mindegyikhez visszaállítási lehetőséggel. Ön dönti el, meddig megy el: egyes ügyfelek mindent átköltöztetnek, mások csak azokat a munkaterheléseket, amelyekre a szabályozó hatóságuk figyel.

Tovább: Felhő és infrastruktúraHivatkozás erre a kérdésre