SaaS-applicaties: URL, gebruikersnaam en wachtwoord: Klaar?

Deel 4: Operationele rapportage en managementinformatie

In het eerste blogartikel uit deze serie heb ik aandachtspunten beschreven voor de architectuur van een hybride applicatielandschap met meerdere SaaS-applicaties van verschillende leveranciers, applicaties in het eigen rekencentrum (‘on premise’) en applicaties in de ‘eigen’ cloud van de organisatie.  

Dit artikel beschrijft het vraagstuk van rapportage en managementinformatie in een applicatielandschap met verschillende ‘on premise’ en SaaS-applicaties.

Rapportage en managementinformatie

Veel SaaS-applicaties beschikken over eigen – geïntegreerde – voorzieningen voor rapportages en dashboards. Rapporten en dashboards zijn door de leverancier gedefinieerd en de applicaties beschikken over hulpmiddelen waarmee gebruikers deze rapporten en dashboards kunnen aanpassen en eigen rapportages en dashboards kunnen maken. De voorzieningen omvatten veelal ook het toevoegen van gegevens uit andere applicaties, bijvoorbeeld ‘financiële’ gegevens aan de managementinformatie van de personeels- en salarisadministratie voor budgettering en het doorrekenen van scenario’s.

Het gebruik van deze voorzieningen biedt veel voordelen: de standaard rapporten en dashboards zijn een goede start voor ‘eigen rapporten’ en de functionaliteit wordt met nieuwe releases uitgebreid. De voorzieningen zijn een goede oplossing zolang de informatie uit de betreffende SaaS-applicatie voldoende is om in de informatiebehoefte van de gebruikers te voorzien.

Wat is het vraagstuk?

Informatie uit één applicatie is vaak onvoldoende rijk voor managementinformatie. Managementinformatie vraagt veelal om een combinatie van gegevens uit meerdere applicaties (bronnen). Voorbeelden: Gegevens over organisatiestructuur, medewerkers en financiële gegevens, of gegevens uit sales en marketingsystemen gecombineerd met gegevens over productie, voorraden en inkoop.

Informatie uit verschillende bronnen/ applicaties moet bij elkaar gebracht worden. De eerste reactie van veel gebruikers en leveranciers is veelal om de gewenste gegevens uit het bronsysteem over te brengen naar de SaaS-applicatie van de gebruiker. Dit leidt al snel tot het ‘rondpompen’ van gegevens, met als resultaat dat dezelfde of vergelijkbare gegevens in meerdere SaaS-applicaties worden opgeslagen, zie figuur 1.
De gevolgen zijn onder andere vraagstukken over beveiliging en privacy, eenduidige gegevensdefinities en tijd- en tijdigheidsaspecten van de gegevens.

Er zijn meerdere varianten om dit scenario te voorkomen. De volgende paragrafen bevatten een toelichting van deze varianten.

Het datawarehouse

De ‘klassieke’ variant is een datawarehouse waarin gegevens uit de verschillende applicaties via ‘Extract, Transform, Load’ (ETL) processen naar het datawarehouse gekopieerd, bewerkt en gecombineerd worden zodat de data geschikt is voor rapportages en dashboards. Zie figuur 2.

Een datawarehouse met SaaS-applicaties wordt (nog) complexer dan een datawarehouse met ‘on premise’ applicaties:

• Niet alle SaaS-applicaties hebben voorzieningen voor het periodiek (dagelijks?) aanleveren van grote hoeveelheden data aan een extern datawarehouse.
• Het integreren van de data uit SaaS-applicaties in een datawarehouse vereist (gedetailleerde) kennis van de datastructuren van de SaaS-applicaties. Dat is kennis waarover veelal alleen de leverancier beschikt.
  De organisatie wordt ‘integrator’ van de verschillende SaaS-applicaties en dat is tegenstrijdig met de drijfveren voor het gebruik van SaaS-applicaties.
• SaaS-applicaties hebben een hogere wijzigingsfrequentie (patches en nieuwe releases) dan ‘on premise’ applicaties.
  Dit leidt tot extra inspanning voor onderhoud van de koppeling(en) en potentieel meer verstoringen bij het aanleveren van data en/of problemen met datakwaliteit.
• De leveranciers van de SaaS-applicaties bepalen de frequentie, het moment én de inhoud van updates en nieuwe releases.
  De release-kalenders van de verschillende leveranciers zijn veelal niet synchroon, met als gevolg dat koppelingen met het datawarehouse continue ‘in beweging’ zijn.

Eén SaaS-applicatie voor managementinformatie

Eén van de SaaS-applicaties van de organisatie wordt gebruikt voor managementinformatie. De gegevens uit andere bronsystemen worden verzameld in de SaaS-applicatie. Zie figuur 3.

Deze variant is geschikt als er een beperkte hoeveelheid data is die ten behoeve van managementinformatie gedeeld wordt. Overwegingen voor de keuze van de SaaS-applicatie die voor managementinformatie gebruikt wordt, zijn:

• Gebruik die SaaS-applicatie zodat zo min mogelijk data tussen de applicaties gedeeld hoeft te worden.  
• Gebruik die SaaS-applicatie zodat alleen (relatief) statische data gedeeld hoeft te worden.
• Gebruik de SaaS-applicatie die het meeste – door de gebruikers uit de doelgroep – gebruikt wordt.
• Gebruik de SaaS-applicatie met de beste voorzieningen voor managementinformatie.

De nadelen van deze variant zijn vergelijkbaar met de nadelen van een datawarehouse.

Datavirtualisatie

Datavirtualisatie is een technologie waarmee gegevens uit verschillende bronnen via een logische data laag gecombineerd beschikbaar gemaakt worden. Gegevens uit ‘on premise’ applicaties, SaaS-applicaties en andere databronnen (zoals een datawarehouse) kunnen met datavirtualisatie als één databron worden ontsloten. Data blijft, in tegenstelling tot een datawarehouse, in de bronsystemen en wordt niet gekopieerd en data is ‘realtime’ beschikbaar. Zie figuur 4.

De logische datalaag bevat de beschrijving van de data: de betekenis, hoe data uit verschillende bronnen ‘gekoppeld’ worden, hoe data aan de gebruikers beschikbaar gemaakt worden en technische gegevens voor de koppeling met de bronsystemen. Toegang en beheer (‘governance’) van de data zijn gecentraliseerd in de logische datalaag. De voordelen van data virtualisatie ten opzichte van een datawarehouse oplossing zijn:

• Data van SaaS-applicaties kan via standaard koppelingen uit de SaaS-applicaties ontsloten worden. Dit vereist (in het algemeen) minder kennis van de datastructuren van de SaaS-applicaties
• Data is real-time: Gegevens in een datawarehouse worden in het algemeen periodiek ververst waardoor de gegevens niet actueel zijn.
• Data wordt niet gekopieerd.

Nadelen van dat virtualisatie zijn:

• Data virtualisatie is voor veel organisaties (relatief) nieuw.
• Data virtualisatie is afhankelijk van de bronsystemen:
  • De prestaties (‘performance’) zijn afhankelijk van de prestaties van de bronsystemen. Veel operationele applicaties zijn niet geoptimaliseerd voor rapportage doeleinden.
  • Er zijn geen voorzieningen voor het signaleren en oplossen van problemen met datakwaliteit. Een datawarehouse beschikt vaak wel over deze voorzieningen.

Conclusie

De voorzieningen van SaaS-applicaties voor rapportage en managementinformatie zijn een goede oplossing zolang de informatie uit één SaaS-applicatie voldoende is. Zodra gegevens uit meerdere bronnen benodigd zijn ontstaat het risico dat gegevens heen en weer gekopieerd gaan worden, met als gevolg vraagstukken ten aanzien van gegevenskwaliteit, privacy en beveiliging.

Er zijn meerdere varianten voor het oplossen van dit vraagstuk, met verschillende overwegingen en voor- en nadelen. Architectuur kan een belangrijke rol spelen in de keuze van de variant die het beste tegemoet komt aan de eisen en wensen van de organisatie.

Het onderwerp van het volgende deel in deze serie is het gebruik van e-mail voor SaaS-applicaties.