Domain model Reporting, Sir!

 
04 februari 2010

In deze post beschrijf ik een praktijk case van het ontwerp van rapportage functionaliteit op een model gedreven applicatie. De applicatie is in een zonnebloemmodel opgebouwd rond een object-georiënteerd domeinmodel, wat tot nu toe een voornamelijk actief model is wat gedreven en niet de alomtegenwoordige CRUD functionaliteit biedt. De bedoeling is dat dat ook zo blijft. Over enige tijd hoop ik deze post op te kunnen volgen met resultaten uit de praktijk.

Requirements aan de rapportage in een notedop
Belangrijkste eisen aan de toe te voegen rapportage functionaliteit:
1. We verwachten veel verschillende rapportages, voor uiteenlopende zaken. Soms ad-hoc.
2. De gegevens waarover gerapporteerd moet worden bevinden zich voor een deel in een applicatie die niet extra belast mag worden gedurende een groot gedeelte van de dag.
3. Er zullen extra gegevens bij komen vanuit externe bronnen die we niet in onze applicatie in willen lezen, maar die we wel kunnen gebruiken binnen onze rapportages.
4. Verwachting is dat er nog wel meer externe bronnen van gegevens aangekoppeld zullen moeten worden.
5. Tevens is de verwachting dat er nog wel meer toepassingen voor de verzamelde gegevens zullen komen.
6. Tenslotte moet het geheel in enkele maanden up en running te krijgen zijn.

Keep it simple, stupid
Vanwege deze eisen hebben we al snel besloten om de rapportage uit de applicatie te houden. Al snel denk je dan aan een ‘standaard’ opbouw van de reporting infrastructuur, om gebruik te kunnen maken van tools die er al zijn. Inmiddels heb ik gelukkig enige (ook concrete) ervaring in het domein, want als je hierop gaat zoeken en er pas net in duikt, duizelt het nogal. Als je denkt dat software-ontwikkeling aan elkaar hangt van de acronymen, ga dan ook eens richting reporting kijken. BI, OLAP, ETL, OLTP, DWH, MOLAP, ROLAP, etc. En dan heb je ook nog het fenomeen dat een flink aantal bedrijven zijn geld erin verdient en elk weer zo zijn eigen visie hierop heeft.

Om het geheel beheersbaar en binnen redelijke termijn implementeerbaar te houden, beperken we ons tot het verzamelen, samenvoegen, transformeren en rapporteren van de data. Geen duur en groot pakket wat op dit moment te ingewikkeld is en dus niet gebruikt gaat worden, maar een eenvoudige structuur om in de behoefte te voorzien en binnen de organisatie ervaring op te doen met haken en ogen die samenhangen met rapportage.

Een simpele flow voor de rapportage-omgeving
De door ons opgestelde ‘standaard’ rapportage flow geeft aan welke elementen we in ieder geval terug verwachten in de op te leveren oplossing: zowel onze applicatie als externe gegevensbronnen (1), een afzonderlijk lopend proces dat de gegevensbronnen uit kan lezen, de juiste gegevens bij elkaar zoekt / valideert / aanvult / koppelt met stamtabellen en vervolgens laadt (2) in de rapportage-database (3) waarop we verwachten eenvoudig rapportages in te kunnen regelen en deze via een flexibele frontend aan te bieden aan de gebruikers (4).

Een standaard Rapportage-flow
Een standaard Rapportage-flow

Nu dan het aansluiten op de modelgedreven applicatie die het grootste deel van de gegevens op gaat hoesten. Het is een applicatie volgens het binnen Sogyo veel gebruikte zonnebloem model, zie de volgende figuur. Even voor degenen die het niet kennen: in het zonnebloem model is het domeinmodel nergens van afhankelijk, maar zijn de services eromheen juist afhankelijk van het domeinmodel. En dan ook alleen daarvan. Typerend is ook dat persistentie ook afhankelijk is van het domeinmodel en niet andersom. Voordeel is dat de alle applicatiebrede afhankelijkheden allemaal in het domeinmodel verwerkt zitten en dus ook als modelelementen daarin terugkomen en dat het aantal afhankelijkheden lineair toeneemt met het aantal externe koppelingen i.p.v. de kwadratische toename die men nog wel eens ziet.

Bronapplicatie voor de data, opgezet volgens het zonnebloemmodel

Bronapplicatie voor de data, opgezet volgens het zonnebloemmodel

Wat in het standaard Extract, Transform, Load (ETL) & Online Analytical Processing (OLAP) verhaal mijns inziens mist, is een duidelijke scheiding tussen de gegevensbronnen en het ETL-proces, waardoor het heel waarschijnlijk wordt dat het data-formaat wat verwacht wordt, impliciet wordt vastgelegd in datzelfde ETL-proces. Dat maakt het lastig om daar andere bronnen en applicaties later aan te koppelen. Daarom heb ik gekozen voor de volgende oplossing.

Bron-applicatie met Rapportage-omgeving en standaard dataformaat

Bron-applicatie met Rapportage-omgeving en standaard dataformaat

Hoe zit het dan met uitbreidbaarheid?
In de bovenstaande architectuur is aan de bronapplicatie een rapportage-service toegevoegd, die de gegevens exporteert naar een standaard dataformaat. Het idee is om dit formaat vast te leggen met bijvoorbeeld xsd’s. De rapportage-service doet eigenlijk deel 1 van het ETL proces, de E en een deel T. De rapportage-omgeving dient het standaard dataformaat as-is in te lezen, te transformeren naar het schema in de rapportage database en daar vervolgens in te laden (TL). Het voordeel van het toevoegen van het standaard dataformaat wordt duidelijk als we later extra bronnen en extra toepassingen voor de data toe gaan voegen.

Toekomstige uitbreiding van de rapportage-omgeving

Toekomstige uitbreiding van de rapportage-omgeving

Externe bronnen kunnen met een mapping naar het standaard dataformaat uitgelezen worden en de rapportage-omgeving kan deze data uitlezen. Eventueel moet het dataformaat nog uitgebreid worden wanneer extra bron-informatie beschikbaar komt. Andere toepassingen kunnen gebruik maken van dezelfde data, aangezien deze in een expliciet vastgelegd formaat beschikbaar is.

Met welk dataformaat, rapportage datamodel en welke regelmaat?
Met de bovenstaande architectuur moet het mogelijk zijn om de eerste fase van het opzetten van een rapportage-omgeving goed door te komen en heeft het de potentie om ook in de toekomst onderhoudbaar en uitbreidbaar te blijven. Aan alle in paragraaf 2 genoemde eisen wordt voldaan. Het standaard dataformaat kost natuurlijk wel enige ontwikkeltijd en deze zal mogelijk enkele malen aangepast moeten worden, maar door automatische validatie van de data die uit de bronnen komt en door de rapportage-omgeving ingelezen wordt door deze tegen de opgestelde schema’s te houden, zorgen we ervoor dat beide in synch blijven lopen.

Omdat de wensen en eisen wat betreft rapportage op dit moment nog te vaag zijn en de hoeveelheid data op dit nog beperkt is, kiezen we in eerste instantie voor een volledige verversing van de data in de rapportage-database met enige regelmaat en een rapportage datamodel dat dicht bij het standaard dataformaat ligt, om de hoeveelheid werk op dit moment te beperken.

Ondersteunende argumenten voor het kiezen van een regelmatige en volledige verversing van de rapportage-database  zijn, dat 1) de bronapplicatie met een volledige verversing soms sterk belast wordt, maar niet bij elke transactie. Door de juiste timing te kiezen zal deze rapportage workload geen invloed hebben op de standaard processen. 2) Tevens is de integriteit van de de data bij een volledige verversing eenvoudiger te realiseren, zeker daar de eerste externe bron van data ook slechts met een bepaalde regelmaat data aan gaat leveren en niet continue.

Conclusie
Ook na het bespreken van deze opzet met een aantal experts kwam ik tot dezelfde conclusies, dus dit wordt de architectuur waar we mee gaan werken voor het eerstkomende jaar. De belangrijkste eisen worden vervuld en er zijn voldoende mogelijkheden om delen van het landschap aan applicaties dat hieromheen gaat ontstaan onafhankelijk van elkaar te upgraden.

De verwachting is dat de frequentie van updaten van de rapportage-data bij voldoende gebruik omhoog zal gaan.  Tevens zal de hoeveelheid data in de toekomst nog toe gaan nemen en is een volledige verversing van de rapportage data niet meer mogelijk / wenselijk. Mooi om te zien is dan dat de rapportage service in de bronapplicatie daarmee steeds dichter bij de karakteristieken van de ORM zal komen te liggen. De overstap zal dan namelijk gemaakt moeten gaan worden van een volledige export naar een export van gegevens bij het optreden van wijzigingen.

De overstap naar een Event Driven Architecture is dan niet zo groot meer: laat de persistency en rapportage reageren op dezelfde domain events en je hebt dat deel eigenlijk al klaar. Aangezien ik me al enige tijd in deze architectuur en daaraan verwante stijlen zoals CQRS/DDDD aan het verdiepen ben, is dit zeker een interessant perspectief.

Feedback en Follow-up
Over enige tijd zal de implementatie gebeurd zijn en ik zal dan ook de resultaten publiceren. Mogelijk is het ook iets wat zich beter voor een presentatie leent, maar dat gaan we tegen die tijd zien.

Als je feedback hebt op het bovenstaande ontwerp, laat het dan zeker weten. Ik ben erg benieuwd naar alle vormen van feedback hierop en je kunt erop rekenen dat ik zal reageren, al is het alleen al om je te bedanken.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur

Tags: , , , , , ,