I disse dager er de fleste bedriftsarkitekturer verken fisk eller fugl. De består av hundrevis av store og tusenvis av mindre systemer, alle sydd sammen til et sprøtt lappeteppe av design. Selv om dette til en viss grad alltid har vært tilfelle innen IT, er det som er annerledes i dag med bedriftsarkitekturer at kritiske applikasjoner – store og mindre – finnes på begge sider av brannmuren. I tillegg til kaoset er mange av disse applikasjonene ikke eid eller kontrollert av organisasjonene avhengig av dem. Uten tvil har pendelen svingt fra rekkefølgen til drivhusdatasentre til kaoset av innovasjon i skyen. Pendelen begynner imidlertid å svinge tilbake mot orden ettersom nye måter å sy sammen systemer på utvikles. Etter hvert som nye integreringsmetoder går videre, står bedriftsarkitekter overfor den enestående utfordringen med å balansere skybasert med lokale applikasjoner.
Cloud Systems
Mange IT-avdelinger er fristet til å ignorere systemer i skyen. Tross alt, de valgte dem ikke, de betaler ikke for dem, og de kan ikke opprettholde dem. De føler sterkest på denne måten om SaaS-applikasjoner der de arkitektoniske avgjørelsene ble tatt med et firmakredittkort. Likevel ville det være en alvorlig feil å ikke anerkjenne deres betydning for moderne organisasjoner. Virksomheten har grepet muligheten til å redusere overhead, utvide rekkevidden og forbedre driften, og de er ikke i ferd med å gi slipp på det. Ettersom pendelen svinger tilbake mot organisasjoner som tar kontroll over dataene deres, kommer IT til å spille en større og større rolle utover brannmuren. Mange styringsproblemer kommer med skyen. Det viktigste blant disse er den stadig økende betydningen av datasikkerhet. Sikkerhet er imidlertid ikke det eneste problemet. Dataintegritet, applikasjonspålitelighet og leverandørens levedyktighet er også økende problemer. IT er den eneste avdelingen som er i stand til å administrere dette vanvittige lappeteppet av applikasjoner. Derfor, når det gjelder å optimalisere en bedriftsarkitektur, har du ikke råd til å se bort fra data som ligger i skyen med vilje. Det ville hjelpe hvis du hadde verktøyene som var designet for å koble til skyapplikasjoner.
Lokale systemer
Mange deler av virksomheten foretrekker å flytte alt til skyen og bare være ferdig med det. De vil gjerne skrive en sjekk hver måned, logge på hver morgen med Facebook-kontoen sin, og ha en hals å kvele. Dette synet er kortsiktig. Etter noen anslag er det fortsatt 220 milliarder linjer med COBOL-kode i produksjon i dag, som representerer 80 % av all bedriftsprogramvare.[i] Utfordringen med å flytte all data de har produsert gjennom årene til skyen er upraktisk. I overskuelig fremtid vil de fleste lokale systemer forbli nettopp det – on-premise. De er for dyre til å gjøre det til en smart forretningsbeslutning å flytte dem. Når det gjelder å samkjøre bedriftsarkitekturer, har du ikke råd til å unnlate å huske dataene som ligger på stedet. Det ville hjelpe om du hadde verktøyene som var designet for å koble til lokale applikasjoner.
konklusjonen
Bedriftsarkitekturen til de fleste virksomheter er verken fisk eller fugl, og det kommer ikke til å endre seg. Du har ikke råd til å ignorere dataene i skyen. Du har ikke råd til å glemme dataene på stedet. Enterprise Architects må finne en balanse mellom sikkerhet, tilgjengelighet og rimelighet. Å finne denne balansen kan være spesielt utfordrende i et produksjonsmiljø hvor mange av systemene er tilpasset og skreddersydd til den spesifikke prosessen i anlegget. Mange produsenter har konkludert med at den eneste praktiske måten å få dette til på er å bruke plattformer og API-er som Jitterbit for å koble til applikasjoner både i skyen og på stedet. Jitterbit er den eneste tråden som er sterk nok til å sy sammen den vanvittige quilten til gjeldende bedriftsarkitekturer. Vår eBok Kraften til APIer for tilkoblet produksjon beskriver noen av deres opplevelser. Vurder å laste den ned.
[I] "COBOL er overalt. Hvem skal vedlikeholde den?" Den nye stabelen. 08. mai 2017. Åpnet 22. mars 2019. https://thenewstack.io/cobol-everywhere-will-maintain/.
