Software as a Service of Commercial Off-The-Shelf
Software as a Service (SaaS-) of Commercial Off-The-Shelf (COTS-)producten voorkomen dat je zelf oplossingen realiseert die in de markt al bestaan en goed doordacht zijn. Vaak zijn deze oplossingen zeer geschikt voor standaard bedrijfsactiviteiten, zoals HR en/of financieel management. Ook als je hiervoor een standaard SaaS- of COTS-oplossing koopt, kun je de ontsluiting van de data en daarmee de interoperabiliteit van een ASC realiseren. Hieronder lees je hoe:
- Read-only Datastore (RDS-)interfaces: Mits beschikbaar is het mogelijk om de RDS via ETL uit de applicatiedatabase te verkrijgen. Anders kan je de ESB gebruiken om via de database, API of events de RDS te vullen.
- API: Een API-manager kun je gebruiken om een applicatie API of database te ontsluiten of anders de RDS. Je kunt ook een API creëren en aanbieden via services op een ESB die de applicatiedatabase of API ontsluit.
- Event-uit interface: Indien een applicatie een event interface heeft, kan de data eenvoudig doorgestuurd worden door een event manager. Deze kan eventueel ook database events afvangen. Dit laatste kan tevens met een ESB.
- Event-in interface: Een event manager kan je gebruiken om events te ontvangen en door te sturen naar een applicatie event interface.
Optionele componenten
Behalve de bovengenoemde standaard onderdelen kennen ASC’s ook een tweetal optionele elementen. Deze licht ik hieronder toe.
User interface/UX
Een ASC kan voor gebruikers ontsloten worden via één of meerdere User Interfaces (UI). Vaak zullen deze gebruikmaken van de ASC API’s die toegang bieden tot data en specifieke systeemtransacties. Echter zal in de praktijk een UI vaak onderdeel zijn van een portaalomgeving, waarin de UI-ontsluiting voor meerdere gerelateerde ASC’s tegelijk is ondergebracht. In dat geval behoort de UI niet specifiek tot de ASC zelf.
Referentiedatabase
Een ASC is vaak afhankelijk van de data van andere ASC’s. Ter illustratie: een ‘klantorder’-ASC gebruikt specifieke klantdata uit een ‘Klant’-ASC. Omdat SIDAF streeft naar autonome ASC’s is een directe verstrengeling met het ‘Klant’-ASC via een synchrone realtime API-verbinding niet wenselijk. Referentiedata kan hierbij een oplossing zijn. De ‘klantorder’-ASC kan bijvoorbeeld een kopie van de relevante klantgegevens opslaan uit de ‘Klant’-ASC, die events aanleveren aan de klantorder.
In deze blog las je over de samenstelling van ASC’s in SIDAF. Wil je meer weten over SIDAF of de ASC’s? Neem dan contact met ons op.
De volgende blog binnen de SIDAF serie zoomt in op hoe je een ASC in de praktijk het beste kunt realiseren.
Let op: Je bent hierbij zeer afhankelijk van de door de SaaS-/COTS-omgeving geboden interfaces.
Domeinoverstijgende systemen
Een ERP-systeem overstijgt qua data meestal meerdere domeinen. Ook in dit geval zijn er mogelijkheden om enkele ASC-principes te adapteren. SIDAF adviseert in dat geval om de betreffende applicatiefuncties en data te identificeren en elk toe te wijzen aan een specifiek domein. Vervolgens kun je voor elk betrokken domein een ‘virtuele’ ASC definiëren, waarna de data extern gemaakt kan worden in bijvoorbeeld een RDS per domein. Zo is de interface-implementatie van de ASC eenvoudiger. Een mooi bijkomend voordeel is dat een eventuele toekomstige migratie naar een nieuw systeem eenvoudiger wordt.
In deze blog hebben we gezien dat ASC’s eenvoudig te realiseren zijn als je ze zelf bouwt of vormt op basis van bestaande microservices. Maar ook commerciële software is tot op zekere hoogte als ASC in te richten. Wil je meer weten over SIDAF of de ASC’s? Neem dan contact met ons op.
De volgende blogs binnen de SIDAF serie gaan in op de data-uitwisseling tussen domeinen.