Sharing IT Best Practices with youSharing IT Best Practices with you
SaaS en SOA
Niet voor iedereen is het verschil tussen Service Oriented Architecture (SOA) en Software as a Service (SaaS) even duidelijk. Het verschil tussen SaaS en SOA is dat het eerste een softwareleveringsmodel is, terwijl de ander een softwarebouwmodel is.
SaaS en SOA zijn beide populaire modelen omdat beide besparingen op de IT-operatie opleveren. Dat doen ze door ieder op een eigen flexibele manier de bedrijfsbehoeften en IT-producten op elkaar af te stemmen. De manier waarop we die besparingen echter realiseren, is het belangrijkste verschil. En in veel opzichten is het vaak het beste om zowel SOA als SaaS in ons IT-platform op te nemen om zo de meeste kostenbesparingen en integratie voordelen te realiseren.
Zoals gezegd is SaaS slechts een methode voor het leveren van software. Een softwareleverancier verkoopt eenvoudig niet langer een DVD die we moeten installeren. In plaats daarvan host hij de applicatie op zijn eigen servers en geeft de gebruikers hierbij via internet toegang. Verrekening van de kosten verloopt via een abonnement. Het is externalisering van applicaties (bijvoorbeeld E-mail, human resources-toepassing, boekhouding, belastingen enzovoort).
Als we over SaaS spreken, praten we over volledig functionele stand-alone applicaties die een zakelijke dienstverlening bieden.
SOA is iets dergelijks als SaaS maar dan op een lager niveau. Een SOA oplossing biedt geen zakelijke dienstverlening, maar biedt in plaats daarvan kleine geïsoleerde processen als een service aan.
SOA is een architectuurstijl voor het bouwen van software. Het idee is dat we een applicatie bouwen door een reeks herbruikbare, ontkoppelde netwerkservices (bijv. Webdiensten ) te koppelen (of ermee samen te werken ). Het concept bestaat uit een set losse bouwstenen die we telkens in andere applicaties kunnen toepassen.
De term ‘service’ in beider naam wekt de verwarrend. SaaS en SOA bieden allebei “services”. Maar het doel verschilt: SaaS biedt services aan gebruikers terwijl SOA services aan andere applicaties biedt.
We kunnen SOA gebruiken om een SaaS-applicatie te bouwen. Het is niet verplicht, maar het is wel aan te raden. Met SaaS kunnen we onze services aan meer klanten leveren. Als de applicatie op een SOA-architectuur is gebaseerd, is hij eenvoudiger te schalen dan een meer monolithische “ik doe alles” -toepassing.
Voor de continuïteit is het zinvol is om sommige applicaties zowel in-source als out-source te kunnen gebruiken. SOA biedt een methode om snel opnieuw te kunnen configureren als bedrijfsomstandigheden de applicaties, databases en andere infrastructuur die wordt gehost in de datacenters wijzigen. Software updates van bedrijfsapplicaties leveren grote softwareleveranciers nog vaak geleverd volgens een SOA-opzet. ERP-functies zoals orderbeheer, grootboek en productieplanning levert men tegenwoordig voornamelijk op deze manier.
SaaS is een gemakkelijke toegankelijke manier om de applicaties en databases (in sommige gevallen ook de functies) van een bedrijf te sourcen. Enkele belangrijke oplossingen zijn bijvoorbeeld verkoopautomatisering, onkostenrapportage en werving.
Een van de belangrijkste uitdagingen bij SaaS is hoe we deze uitbestede applicaties effectief kunnen integreren met de intern gehoste applicaties.
Dit integratieprobleem biedt vele uitdagingen die verder gaan dan het verplaatsen van data tussen een bron en een bestemming. SaaS-applicaties bevinden zich altijd buiten de firewall. Veiligheid en betrouwbaarheid zijn daarom belangrijke overwegingen bij het koppelen van data en het identificeren van medewerkers, leveranciers en klanten. Dit geld ook voor hun privacy gevoelige data zoals bankrekeningen, BSN-nummers, enzovoort. Het gaat vaak om financiële transacties die we moeten controleren en bevestigen voor we ze accepteren.
SaaS-applicaties komen ten slotte meestal via een afdelingsinitiatief een organisatie binnen. Dit bemoeilijkt de integratie met andere IT oplossingen. In plaats daar van zou de aankoop via een centraal inkoopproces van de IT afdeling moeten lopen. Vaak wordt er een datafeed gebouwd voor de SaaS-applicatie. Die wordt via internet geleverd met de bedrijfsapplicaties achter de firewall. De technologie om de data te verplaatsen is vaak het gemakkelijke gedeelte.
Koppelingen van alle IT oplossingen binnen een organisatie moeten we echter effectief kunnen beheren. Alleen zo kunnen we SaaS-implementaties optimaal benutten en creëren we tegelijkertijd geen spagetti van eenmalige integraties tussen grote bedrijfssystemen.
Om de nieuwe SaaS-applicatie snel beschikbaar te stellen en de integriteit van het bedrijfssysteem te behouden, is het hergebruik van een bestaande interface belangrijk. Zo blijft het beheer van de koppelingen overzichtelijk. Een gemeenschappelijke databus biedt de interface om datatypes effectief te delen met meerdere SaaS-applicaties.
Zonder een databus is iedere SaaS-implementatie een nieuw IT-integratieproject dat we moeten financieren, bemannen, ontwerpen, coderen, testen en implementeren. Telkens als we rechtstreeks een nieuwe interface maken is dat een toevoeging aan het IT-budget. Dit maakt de beschikbare capaciteit voor werkelijk nuttige projecten telkens iets lager.
Met een standaard databus is de helft van het integratieprobleem al opgelost. Een SOAP-webservice op de bedrijfsapplicatie is meestal de herbruikbare interface tussen de bedrijfsapplicaties en SaaS-implementaties. Deze gedeelde interface geeft snelheid aan de SaaS-implementatie en biedt IT een gemeenschappelijke, zichtbare databus. De transacties monitoren, beheren en beveiligen we via dit kanaal. Zo voldoen we tevens aan de governance-eisen van de organisatie. Tegelijkertijd behalen we grote kostenbesparingen die we niet kunnen behalen met een directe interface.
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.