I det siste har jeg fått spørsmålet om man bør velge å satse på Service Orientert Arkitektur (SOA) eller Software as a Service (SaaS) når det er behov for nye applikasjoner. Jeg tolker spørsmålet som om at usikkerheten er basert på om SOA og SaaS er to konkurrerende arkitekturer. Så hva er egentlig forskjellen?
SOA er en applikasjonsarkitektur, mens SaaS (også kalt skybaserte tjenester) er en internettbasert leveransemodell for applikasjoner. I denne artikkelen kommer jeg til kort til å forklare hva SOA og SaaS innebærer, og hvordan de med fordel kan kombineres.
Applikasjonsarkitektur
SOA er applikasjonsarkitektur som har kommet over hype-stadiet og er i dag en naturlig del av kravspesifikasjonen til store selskaper. Kort forklart betyr SOA at man bryter opp applikasjoner i selvstendige moduler (services) som løser de funksjonelle behovene i applikasjonen gjennom å kommunisere med hverandre på en standardisert måte. Den mest vanlige måten er at de kommuniserer seg imellom ved hjelp av webservices.
Service Orienterte prinsipper kan brukes internt i en applikasjon, men et mer vanlig bruksområde er å bruke SOA for å integrere ulike applikasjoner. Fordelene som oppnås med riktig bruk av SOA er enklere integrasjon mellom applikasjoner, gjenbruk av forretningslogikk på tvers av ulike forretningsprosesser og økt endringsevne gjennomenklere vedlikehold og videreutvikling av applikasjonene.
Programvare som en tjeneste
SOA er altså en applikasjonsarkitektur, mens SaaS er en leveransemodell for applikasjoner.
SaaS baserer seg på at applikasjonen finnes tilgjengelig på internett og at kundene ikke behøver å investere i maskinvare og lisenser for å bruke den funksjonaliteten som applikasjonen tilbyr.
SaaS applikasjonen kan være bygget på en Service Orientert Arkitektur, men behøver ikke være det. SaaS har flere fordeler, blant annet vil kundene slippe å tenke på hvor mye maskinvare de må investere i for å takle varierende last, de betaler kun etter forbruk og det er raskt å komme i gang med en ny applikasjon.
Hva er gevinsten med å kombinere SOA og SaaS?
Stikkordet her er applikasjonsintegrasjon. De fleste kunder har i dag behov for å integrere flere applikasjoner for å oppfylle funksjonelle behov. En SaaS-leverandør vil sjelden tilby alle de applikasjonene kunden ønsker seg og behovet for å integrere interne og skybaserte applikasjoner oppstår.
Fordelen med å bruke SOA her er at hvis de skybaserte applikasjonene og de interne kan tilby standardiserte SOA grensesnitt så det mye enklere å integrere applikasjonene.
SOA er ikke svaret på alle spørsmål
Det er viktig å merke seg at SOA i seg selv ikke løser alle utfordringer med å integrere interne og eksterne applikasjoner, blant annet så er datasikkerhet en utfordring som må løses. En annen utfordring er hvordan man sikrer forutsigbar responstid og oppetid når noen applikasjoner ligger utenfor bedriftens kontrollerbare infrastruktur. Dette gir føringer på hvilke applikasjoner som i dag enkelt kan tilbys gjennom en skybasert leveransemodell, men det finnes løsninger også på disse utfordringene.
For å lykkes med en satsning på SOA og SaaS er det en fordel å ha med seg mennesker med SOA- og integrasjonskompetanse, sikkerhetsarkitekturkompetanse, samt god kunnskap til IT og SOA–governance.
Fin artikkel.
Her kommer noen punkter til med utfordringer ihht SOA-arkitektur:
- I et stort selskap, må man ha et system for å ha god oversikt over alle SOA-tjenester og ha god dokumentasjon på disse. Om man tar SOA “to the extreme”, kan man få veldig mange tjenester som gjør drift av dette veldig tungt.
- Versjonshåndtering kan være tyngre i et SOA-miljø fordi man til enhver tid må ha oversikt over hvilke andre tjenester som “abonnerer” på en tjeneste, slik at hvis man er nødt til å kjøre en oppdatering og endre et interface. Alle som “abonnerer” på tjenesten vite om endringer. Det kan da være tungt å planlegge deployment av X antall applikasjoner fordi man må gjøre endringer i en tjeneste.
- Tjenestene kan ha en tendens til å bli “gamle”, slik at man må vedlikeholde kode med forskjellig arkitektur/rammeverk. Man må også sørge for at man har personale som har kompetanse på hver enkelt applikasjon. Det er også viktig å løpende holde tjenester vedlike og oppdatere dem, slik at de ikke blir så gamle at de blir tunge å vedlikeholde.
- Performance-trollet kan komme og spise deg om man lager for mange tjenester og tankeløs bruk av tjenestene.