Det er ingen tvil om at implementering av en SaaS-tjeneste er vesentlig enklere enn et on-premise produkt.
Årsaken er lett å forklare: Det er ingen tekniske installasjonsoppgaver som involverer kunden, og tjenesten inneholder ofte et sett standardiserte og ferdig konfigurerte prosesser som kan danne et godt utgangspunkt for å komme i gang.
Men til tross for at hver enkelt SaaS-tjeneste isolert sett kan være enklere å ta i bruk må kunden planlegge sitt systemlandskap som utgjør summen av SaaS-tjenester og gjenværende on-premise systemer (arven). Derfor er det å sy sammen et systemtjenestelandskap ingen enkel oppgave, spesielt når tjenestene, i en stadig mer granulert form, leveres fra ulike skyer både i inn- og utland. Det er ikke til å unngå at det vokser frem en Multi-Cloud/Multi Platform arkitektur.
Derfor er det å sy sammen et systemtjenestelandskap ingen enkel oppgave, spesielt når tjenestene, i en stadig mer granulert form, leveres fra ulike skyer både i inn- og utlandBo Hjort Christensen
Gode integrasjonsmetoder gjør denne sammensyingen enklere enn tidligere (API-teknologien), men man skal ikke undervurdere oppgaven med å forvalte integrasjoner. Av gammel vane er vi svært opptatt av eierskap til, og forvaltning av tjenestekomponentene (systemene), men like viktig er faktisk forvaltning av integrasjonene (API-Management). Ikke glem det.
Et vesentlig spørsmål i denne sammenheng er hvor integrasjonen har sitt opphav. I prinsippet er det fire muligheter.
En av systemprodusentene på hver side av integrasjonen kan eie den. Da inngår den i produsentenes produktkatalog (tjenestekatalog) og har ofte en leiepris.
Den tredje type eier kan være en uavhengig ISV (Independent Software Vendor) som lever av å bygge integrasjoner i et standardisert format. Integrasjonen er å betrakte som deres tjeneste til markedet. I alle disse tre eirskapsmodellene ligger det et ansvar hos produsenten om løpende å vedlikeholde integrasjonen.
En siste type eierskap er når integrasjonen er bygget spesifikt for en kunde, gjerne av en implementeringspartner. Da hviler det et betydelig ansvar både på partneren og kunden. Dette som en innledning til det som er hovedtemaet i denne artikkelen.
Jeg ser tydelig en tendens til at kundene definerer tre prosessdomener, nemlig ansattdomenet, kundedomenet og produktdomenet (inkludert tjenester og prosjekter)Bo Hjort Christensen
Min erfaring er at planlegging av systemlandskapet er en prosess som skjer i flere steg, basert på en top-down tilnærming. Jeg ser tydelig en tendens til at kundene definerer tre prosessdomener, nemlig ansattdomenet, kundedomenet og produktdomenet (inkludert tjenester og prosjekter).
ERP 2021- et kompakt fagseminar ledet av Bo Hjort Christensen. Meld deg på her!
3 viktige masterdata
Alle prosesser og systemtjenester i disse domenene sentrerer rundt 3 særdeles viktige masterdata, henholdsvis ANSATT, KUNDE og PRODUKT. Store og komplekse selskaper tenderer mot å bygge og optimalisere et systemtjenestelandskap for hvert av domenene, og knytte dem sammen. Det betyr i praksis at virksomheten velger 3 plattformer, nemlig en ERP-plattform (Kjernesystemet), en HR-plattform og en Handelsplattform. Eksempelvis SAP som ERP-kjerne, Workday som HR-kjerne og Salesforce som Handelskjerne.
Hver av plattformene berikes av nisjeløsninger for ulike formål som integreres via ulike API-er. I tillegg er det ofte en tett integrasjon mellom de tre plattformene.
Dette er en strategi som har en del til felles med Best-of-Breed, der hovedvalgene er de tre nevnte plattformene. Men det er ganske så klart at for mange selskaper vil det fortsatt være formålstjenlig å «samle» systemstøtten for flere domener i én plattform.
I figuren viser jeg nettopp det. I prinsippet har vi å gjøre med 3 hovedarkitekturer. Den første har jeg beskrevet som en tydelig tre-deling av systemlandskapet. Den andre arkitekturen samler to av domenene i én plattform.
I eksempelet er det støtte for kundedomenet og produktdomenet som er samlet, f.eks. Oracle Netsuite. Men det kunne vært omvendt, nemlig at ansatt- og produktdomenet var de som ble samlet i én og samme plattform. Workday er et godt eksempel i så måte. Den tredje arkitekturen representerer en plattform som favner alle tre prosessdomenene, slik tilfellet er med f.eks. Oracle ERP Cloud. Hva som er riktig arkitektur avhenger av kundens forretningsmodell, forretningsplaner og ikke minst dynamikken i hvert av domenene. Å bryte opp arkitekturen i tre domener der den ansvarlige eier søker å optimalisere systemutnyttelsen innen sitt område, gir en større grad av fleksibilitet. Samtidig skapes den en noe større mulighet for å skifte ut en plattform, uten nødvendigvis å skifte de to andre.
Sagt litt enkelt. I et av de store ledende konsulentselskapene i Norge har man valgt en todelt arkitektur der ansatt og produkt (tjeneste) er samlet i Workday og Kundedomenet håndteres av Salesforce.
Begrunnelsen for dette ligger nettopp i selskapets forretningsmodell, der ansattdomenet og produktdomenet er usedvanlig tett sammenvevd fordi det er de ansatte som leverer produktene (tjenestene). Det er de ansatte som utgjør selve produksjonsmaskineriet. Mitt hovedpoeng er at arkitekturplanlegging handler om planlegging på flere nivåer.
Valg av hovedarkitektur (1, 2 eller 3 plattformer) er en av de viktigste arkitekturvalgene som gjøres. Dette er an typisk overordnet arkitekturbeslutning. Dernest er det et spørsmål om å balansere funksjonalitet mellom plattformene og supplerende nisjeløsninger.
Jeg håper dere ser tegningen.
ERP 2021- et kompakt fagseminar ledet av Bo Hjort Christensen. Meld deg på her!