Architecturale context
Context
Samenvatting hoe we de architectuur opdracht hebben begrepen.
Visie
Steden hebben het moeilijk om het gedrag van de burgers te veranderen zonder incentivering. Uit vorige projecten blijkt dat 'vouchers' en 'lokale (digitale) munten' (sociaal krediet zoals duimpjes up) daarvoor goed werken. Maar die worden ook te snel verzilverd in euro's en blijven niet binnen het systeem. Daarnaast leiden verschillende incentiveringen ook tot eigen vouchers of (digitale) munten hetgeen resulteert in een versnipperd landschap van systemen. De keuze om al de lokale economie te steunen dan wel expliciet te kiezen voor een digitale munt die regionaal besteed kan worden (= aantrekkelijker voor de burger) moet bij de initiatiefnemer (lees: lokaal bestuur) liggen: waar steun aan lokale economie belangrijkste finaliteit is, moet er gekozen kunnen worden voor een lokale munt. Wanneer een incentivering op een bepaalde maatschappelijk wenselijk gedrag ligt, is een regionale campagne die toeleidt tot een regionale munt vaak interessanter. (Bron: REF01)
Doelstellingen
- De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. (Bron: REF01)
- Een platform dat 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform'. (Bron: REF01)
- Een 'schaalbare' architectuur dat snel en efficiënt uitrolbaar is in andere regio die dat zouden wensen. (Bron: REF01)
Stakeholders
Deze paragraaf beschrijft de belangrijkste stakeholders. Stakeholders zijn mensen die actief betrokken zijn bij de architectuur opdracht en/of het project, of wiens belangen positief of negatief kunnen worden beïnvloed door de uitvoering of voltooiing van de integratie opdracht en/of het project.
Stakeholders behoeften
| Rol | Vertegenwoordigd door | Verantwoordelijkheid | Bezorgdheden | Actie (*) |
| Stad Geel | ||||
| OSLO | ||||
| IOK | Stijn Claes - Koen Van den Eynde | Ondersteuning van Kempense lokale besturen (en in eerste instantie stad Geel) met het uitrollen van een schaalbaar platform dat incentivering mogelijk maakt aan de hand van digitale munten. | ||
| VLOCA | Mieke Van Cauwenberghe | Verantwoordelijkheid is tweeledig. Enerzijds wil VLOCA in co-creatie met kenniscentra, bedrijven, lokale besturen en burger(organisaties) een gedragen referentiekader, dat bestaat uit principes, concepten en architectuurcomponenten, tot stand brengen. Dit moet gaandeweg leiden tot een beheersbare open city architectuur voor slimme steden en gemeenten. Anderzijds is het de bedoeling om bovenstaande (eerste) resultaten door te vertalen naar een draaiboek voor aanbestedende (lokale) overheden. Dit draaiboek moet hen ondersteunen om slimme oplossingen uit te rollen, conform de Vlaamse Open City Architectuur. | Hebben we de vereiste capabilities om de lokale besturen te ondersteunen zodat we hun keuzes veilig kunnen stellen naar de software leveranciers dat toekomstbestendig, consistent en in overeenstemming is met de VLOCA architectuur richtlijnen? | |
(*) KS: Keep satisfied (High Power en Low Interest). MC: Manage Closely (High Power en High Interest) KI: Keep Informed (Low Power en High Interest). M: Monitor (Low Power en Low Interest)
Use cases
In deze paragraaf worden de use cases (goals) beschreven t.o.v. dat de doelstellingen (drivers) die gerealiseerd dienen te worden door de transitiearchitectuur. (Bron: REF01)
| N° | Doelstelling (Driver) |
N° | Use Cases |
| CoT.2021.003.1 | Een platform die 'goed gedrag' beloont met een 'lokale munt' die enkel in de regio kan ingeruild/gespendeerd worden = 'regio breed incentiveringsplatform' | UC3 | Participatie Mechanisme: Een gebruiksvriendelijke platform om zowel als 'donor' als 'collector' als 'spender' zichzelf te kunnen registreren en 'regels'/'parameters' voor ontvangen en gebruiken te kunnen vastleggen. Voor de definities van Donor, Collector en Spender. |
| UC4 | Marketing: Aanradingsprogramma om de lokale economie aan te trekken om mee te doen zowel als 'donor' (= participerende organisatie die zelf een stimulansaanbod aanbiedt) of 'sponsor'/'advertiser' (= organisatie die een stimulansaanbod wil financieren) alsook als 'collector' (= winkels die deze munt aanvaarden als betaling) Inclusief communicatieplatform om berichten, nieuwsletter, alerts, bevestigingen enz te kunnen beheren. | ||
| UC10 | Helpdesk, klachten & reviews: Helpdesk bij vragen, FAQ, klachten en reviews door alle betrokken partijen. | ||
| UC6 | Inzichten & Dashboarding: Het verkrijgen van inzichten in het gebruik en de positieve impact op 'goed gedrag' en 'lokale economie' die het beleid kan gebruiken. (Analyse van 'verval' of 'demurage' = waardeverlies, waar gaat dat geld naartoe bvb goed doel,...) | ||
| CoT.2021.003.2 | Een 'schaalbaar' architectuur dat snel en efficient uitrolbaar is in andere regio die dat zouden wensen. | UC2 | Integratie: Integratie met bestaande (en nieuwe) applicaties die als 'vertical' (organiseren van een stimulansaanbod) fungeren maar ook stadsapplicaties, websites, cadeaubonnen applicaties en zelfs MijnBurgerProfiel (app) |
| UC7 | Principes: Schaalbaarheid (voor extra steden en regio's), interoperabiliteit (voor extra toepassingen) en cross verticale principes van het platform is cruciaal. | ||
| Schaalbaar = | |||
| * uitbreidbaar naar andere gemeenten / regio's | |||
| * andere (nieuwe of bestaande) verticals moeten kunnen koppelen met het platform | |||
| * ook aan bestedingszijde moet het platform flexibiliteit bieden (besteding bij handelaar, B2B (mits wetgevend kader), donatie aan lokale organisatie/doel/project, andere (crowd funding) systemen... | |||
| UC8 | Draaiboeken: Een bibliotheek leveren van draaiboeken die de steden en gemeenten een 'how to' uitleggen ifv hun behoeften en context. | ||
| CoT.2021.003.3 | De lokale/digitale munt moet kunnen dienen als 'betaalmiddel' tussen C2C en B2B (mits wetgevend kader) om die munt zo lang mogelijk binnen de regio te houden. | UC1 | Digitale wallet: Digitale wallet van meerdere soorten munten (lokaal, regionaal, enz. en evt andere systemen, zoals Uitpas) waar zowel stortingen, uitgaven/overschrijven en consulteren van saldo's door de eigenaar en participanten kunnen gebeuren. |
| UC9 | Compensatie mogelijkheden: Bij het kiezen voor een (additionele) lokale economie, willen we een evenwichtig systeem hebben tussen regionale en lokale muntsystemen opdat eventueel geld zou kunnen terugvloeien tussen gemeenten/steden. Onevenwichtig is bvb indien een gemeente A sponsort met de hoop op het spenderen bij lokale handelaars in gemeente A terwijl er factueel buiten proporties uitgegeven wordt door de burgers in gemeente B. | ||
| UC11 | Betalingen: Vanuit het platform één betalingsmodule die over alle 'verticals' heen kan gebruikt worden om te vermijden dat de handelaar verschillende systemen moet hebben per verticaal om geld te kunnen 'krijgen' van de 'shopper' | ||
| UC5 | Omzetting Mechanisme: Een facturatie- en betalingssysteem dat de eerste en allerlaatste conversie regelt zodat de lokale munt in praktijk omgezet kan worden in euros. |
KPI behoeften
| N° | KPI | Prestatie maatstaf | Streefwaarde |
| CoT.2021.003.X-UCnn | KPI-001 | Verkoop KPI ter illustratie: Als handelaar kan je kijken naar je het aantal verkoop per uur, dag, week, maand, kwartaal of jaar. | Als streefwaarde kan je een percentage, een getal (in een bereik), … opgeven. Eventueel opgedeeld in tijd. |
| KPI-002 | Marketing KPI ter illustratie: Als handelaar kan je kijken naar het App verkeer, zoals het totaal aantal bezoeken voor jouw account. Meer verkeer betekent meer potentiële klanten. | ||
| KPI-003 | Customer Service KPI ter illustratie: De Net Promotor Score (NPS) meet de klanttevredenheid en klantenloyaliteit. Deze score wordt afgemeten aan de mate waarin klanten jou als handelaar aan iemand zouden aanbevelen. | ||
| KPI-004 | Productie KPI ter illustratie: De productiecyclus KPI vertelt je hoe lang het duurt om één advertentie te maken van start tot finish. Als je deze KPI goed in de gaten houdt krijg je belangrijke inzichten in de efficientie van jouw productie proces. | ||
| KPI-005 | Financiële KPI ter illustratie: De Return on Investement (ROI) KPI vertelt je wat je terug hebt verdiend t.o.v. jouw inspanningen. Hoe hoger het getal, hoe beter. De ROI heeft betrekking op alle uitgaven en inkomsten. | ||
| DY-UCnn | KPI-006 | ||
| KPI-007 | |||
| DZ-UCnn | KPI-008, … | ||
Enterprise generieke architectuur
De L1-capabilities als startpunt voor de enterprise architectuur.
VLOCA Capability map
De VLOCA capabilities die in staat zijn om de doelstellingen en use cases te realiseren. De omkaderde capabilities zijn diegenen die werden gedetecteerd voor dit traject.
Er zijn verschillende L1-value streams (= VLOCA-cirkel) aanwezig in het VLOCA Capability map:
- Visie en strategie ontwikkeling: Het vaststellen van een richting en visie voor een organisatie. Dit omvat het definiëren van de bedrijfsstrategie en het beheren van strategische initiatieven. Het creëren van een visie, een missie en strategische doelstellingen en dus om ervoor te zorgen dat de organisatie in de gewenste richting beweegt.
- Ontwikkelen en beheren van Smart City producten en diensten: Beschrijven van het aanbod met betrekking tot het concept van het ontwikkelen en beheren van 'Smart City' producten en diensten.
- Promotie van de Smart City producten en diensten: Het begrijpen van markten, klanten en mogelijkheden. Het ontwikkelen van marketingstrategieën. Het ontwikkelen, beheren en uitvoeren van marketingplannen. Het ontwikkelen van verkoopstrategieën. Het beheren van verkooppartners en allianties.
- Leveren van Smart City producten en diensten: Gaat over het plannen, beheren en uitvoeren van supply chain-activiteiten. Het aanschaffen van producten en diensten van leveranciers en het beheren van logistiek. Alsook het aanbieden van producten en diensten aan klanten en het identificeren van uitvoeringsplannen voor de levering van de verkochte producten en diensten.
- Opvolgen van klanten: Het opvolgen van klanten na de levering van producten en diensten. Dit omvat het ontwikkelen en plannen van klantenservice praktijken met het oog op het sturen van processen met betrekking tot vragen na verkoop, feedback, garanties en terugroepacties.
Alsook zijn er verschillende (soorten van) L1-capabilities (= VLOCA-pillaren):
- Strategisch: Maken deel uit van de algehele strategie, ze ondersteunen (deels) de ambitie van de Vlaamse Overheid, Agentschap Binnenlands Bestuur & VLOCA.
- Strategic Control: Het definiëren en sturen van de VLOCA-visie, missie en strategie op steden en gemeenten
- Market Watch: Het definiëren en uitvoeren van onderzoek voor het begrijpen van de markten. Afhandelen van de externe marktanalyses (bv. PEST) als strategische input voor marketing afdelingen.
- Enabling: Creëren van mogelijkheden. Ze dragen bij aan het succes van operationele capabilities.
- Information Management: Informatie beheer is het bedrijfsproces van het verzamelen, opslaan, beheren en onderhouden van informatie in al zijn vormen gedurende de informatielevenscyclus.
- Operationeel: Wat een organisatie moet doen om zijn bedrijfsstrategie te kunnen uitvoeren. Zij worden gedefinieerd en opgebouwd doorheen de tijd, kunnen niet gemakkelijk worden geïmiteerd en vormen daarom een concurrentievoordeel voor de organisatie.
- Product Management: Ervoor zorgen dat de kwaliteit van alle producten (goederen en diensten) voldoet aan de verwachtingen in het aanbod. Deze capability omvat o.a. de markt- en consumentenbehoeften, productstrategie en portfolioveranderingen. Ook de ontwikkeling van productverbeteringen of nieuwe innovatie-ideeën komen aan bod.
- Supplier Management: Het beheren van de relatie die de lokale besturen onderhouden met haar leveranciers. Het omvat het stellen van doelen voor de samenwerking met leveranciers, het plannen van de activiteiten om met leveranciers in contact te komen, het classificeren van leveranciers op strategisch belang en het evalueren en controleren van leveranciers.
- Marketing Management: Beheert enerzijds de tactiek en anderzijds de marketing planning voor het komende jaar. Deze capability ontvangt zijn primaire informatie van andere capabilities zoals Market Watch, Product-, Sales & Distribution en Customer Management.
- Supply Chain Management: Coördineren van vraag en aanbod van/naar producten en diensten met klanten, medewerkers, partners en leveranciers.
- Sales & Distribution Management: Het beheren van de acceptatie van verkooporders via touchpoints, het coördineren van resterende activiteiten die nodig zijn om de bestelde producten en diensten aan de klanten en partners te leveren volgens een gespecificeerd leveringscontract.
- Customer Management: Het organiseren en beheersen van de continuïteit en ontwikkeling van kennis over de individuele B2B / B2C en klant en onze relatie met hem/haar. Het maken en beheren van overeenkomsten met klanten. Deze overeenkomsten kunnen formele (levering) contracten zijn, maar ook marketing toestemmingen en algemene voorwaarden, aanvaard door de klanten.
- Contact Center Management: Het registreren van de context en inhoud van het service request contact via tickets. Bevat service catalogi, waarin alle mogelijke vragen staan vermeld die we verwachten te behandelen met behulp van een kennisbank om de afhandeling van service requesten efficiënter en coherenter te maken. De kennisbank zorgt voor transparantie over beschikbare oplossingen & antwoorden op bekende problemen.
- Supporting: Waarde toevoegen aan andere capabilities. Geen specifieke concurrentievoordeel, kunnen worden geïmiteerd en uitbesteed.
- Finance: Beheer van alle business- en IT functies die nodig zijn voor het beheer van de financiële middelen van Smart City producten en diensten, inclusief boekhouding, treasury en interne en externe financiële rapportage.
- Human Resources: Beheer van alle activiteiten die nodig zijn om de best mogelijke match te creëren tussen de Smart City behoeften en de behoeften van de medewerkers die op de markt beschikbaar zijn om arbeid te verrichten. Het omvat het hele scala aan activiteiten, van instroom tot uitstroom van medewerkers, gedurende de gehele levenscyclus van medewerkers binnen een (lokale) organisatie.
Enterprise architectuur (EA) principes
EA principes (L1) definiëren de onderliggende algemene regels en richtlijnen voor het gebruik en de inzet van de L1-capabilities in de VLOCA trajecten. Ze weerspiegelen een mate van consensus tussen de verschillende architectuur onderdelen van het traject en vormen de basis voor het nemen van toekomstige beslissingen. Niet te verwarren met L2 & L3 vereisten (requirements).
Enterprise architectuur principe beschrijvingen
Bij het ontwerp van de transitiearchitectuur binnen trajecten & projecten dient er rekening te worden gehouden met de EA-principes. Voor elk principe wordt de volgende informatie verstrekt:
- Principe: een korte definitie van het principe, meestal in één woord
- Statement: een korte beschrijving wat we willen bereiken
- Rationale: de reden waarom het principe belangrijk is
- Implicaties: implicatie van het principe voor de uitvoerende organisatie
| EA Principe | Statement | Rationale | Implicaties |
| Functionaliteit in de juiste business area | We zorgen er voor dat de ICT toepassingen zich binnen de juiste operationele omgevingen bevinden, binnen de steeds veranderde wensen en noden van de organisatie. | Nieuwe en bestaande systemen en applicaties zullen de huidige grenzen van de operationele werking overschrijden. | Creëren, bijwerken en onderhouden van business-, applicatie- en technologie architecturen via veranderingsgerichte ontwerpen. |
| Omni channel | We gaan voor een omni channel aanpak zodat de eindgebruiker tijdens een interactie, zoals aandacht (terug) aantrekken, kan schakelen tussen verschillende digitale kanalen. | De eindgebruiker gebruikt de diverse digitale kanalen door elkaar terwijl de ervaring, prijzen, informatie, ... hetzelfde zijn. | Alle digitale kanalen komen volledig samen, waardoor een volledig transparant proces ontstaat. Elk eindgebruiker gerichte applicatie dient te worden gebouwd met het oog op responsiviteit, zodat het geschikt is voor tablets, mobiele apparaten, pc/laptop, sociale media, chatbots, ... Op widget (of micro client)-niveau is co-development met derde partijen mogelijk, waarbij we niet alleen ICT services (IaaS & PaaS) delen, maar ook business services (SaaS). |
| Cross Channel | We gaan voor een cross channel aanpak zodat we de interacties tussen de eindgebruikers geïntegreerd kunnen afstemmen op de operationele activiteiten van de medewerkers van de Vlaamse Overheid. | Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. | Op het eindgebruiker niveau worden business en ICT-services gebouwd met het oog op geïntegreerd gebruik van diverse operationele kanalen. Implicaties: Door online en offline kanalen te mixen, dient de eindgebruiker op één uniforme manier bediend te worden zodat er zowel externe afspraken met de eindgebruiker, als interne afspraken tussen front- en back-office personeel dienen gemaakt te worden. In commerciële bedrijven zijn verkoopkanalen meestal gemixt, waarbij de klant er kan voor kiezen om artikelen online te bestellen en af ??te halen in een fysieke winkel. De klantenservice moet hiervan ook op de hoogte zijn. Hetzelfde principe kan toegepast worden door de burger centraal te stellen, want burgers, die in een ander context klanten zijn, verwachten hier ook een vlotte dienstverlening die tegemoetkomen aan hun noden. |
| KISS | Keep it simple, stupid. We willen eenvoud en duidelijkheid brengen in een steeds complexere ICT landschap. | Systemen en applicaties als geheel volgen de solution architecturen, gemaakt in de PLAN fase, als input voor solution development in de BUILD fase. | Afstemming nodig tussen VLOCA -, solution- en software architecturen via een architectuur & technologie governance. |
| Ontkoppeling | We willen dat de systemen en applicaties ontkoppeld worden, zodat ze onafhankelijker van elkaar werken. | Om overal veranderingen te voorkomen met nieuwe systeem- en applicatie functies, worden lagen ontkoppeld door gebruik te maken van duidelijke en gedocumenteerde gestandaardiseerde interfaces. | Presentatiegericht naar front-end en service gerichte interfaces naar back-end. Als technisch resultaat moeten de interfacing en aangepaste code naar de systemen en applicaties nauw aansluiten bij de technologie van de leverancier of de technologie van het ontwikkelingsteam. |
| Robuustheid | We willen betrouwbare systemen en applicaties die voldoen aan de noden en wensen van de eindgebruikers. | Systemen en applicaties worden gebouwd, gekocht, samengevoegd en geconfigureerd volgens robuustheid criteria. | Dit betekent dat een systeem of applicatie na een onderbreking zo snel mogelijk een aanvaardbare werkende staat moet hebben, waarbij de graad van robuustheid zal afhangen van de maturiteit en de positie van de ICT oplossing in de organisatie, zoals enerzijds de prototypes, MVPs, aangekochte (kern) en legacy systemen en anderzijds de front- en back-office applicaties. |
| Onderhoudbaarheid | We zorgen voor een degelijk onderhoud van de (nieuwe) ICT oplossingen binnen de gewenste prestatie vereisten. | De algehele (business & ICT) operationele efficiëntie mag niet worden beperkt door nieuwe ICT oplossingen, noch zullen we enige functionele en technische achteruitgang van de huidige ICT oplossingen toestaan ??tijdens een projectfase. | Operationele, business en ICT presatie (service) contracten dienen opgesteld te worden tussen dienstverleners en dienstafnemers, om zo de bedrijfscontinuïteit te waarborgen. |
| Standaard software | We gaan er zoveel mogelijk vanuit om eerst te herbruiken, dan aan te kopen en uiteindelijk te beslissen om systemen en applicaties zelf te bouwen. | De systemen en applicaties volgen zoveel als mogelijk de "reuse, before buy & before build" richtlijnen. | Dit betekent dat er (integratie) architectuur en technologie richtlijnen nodig zijn, zodat voorstellen van ICT-leveranciers / integratoren en deliverables van het ontwikkelteam kunnen worden bepaald zodat we op het juiste moment, de goede dingen doen teneinde ICT oplossingen uit te voeren aan de juiste prijs. |
| Scheiding van verantwoordelijkheden | We willen systemen en applicaties goed van elkaar scheiden zodat er meer mogelijkheden zijn voor uitbreidingen via (micro) componenten, hergebruik en onafhankelijke ontwikkeling (separation of concerns). | De componenten en modules van de systemen en applicaties moeten worden gescheiden op basis van het soort werk dat wordt uitgevoerd. | De realisatie van de ICT services dienen te worden geclassificeerd via functionele decompositie, zodat we de algehele complexiteit kunnen opsplitsen en de ontbonden elementen (componenten en modules) in kaart kunnen brengen op de business realisatie. |
| Flexibiliteit | We willen meer flexibiliteit inbouwen in de ICT ontwikkelingsomgevingen om de winstgevendheid en productiviteit van de ICT oplossingen te verhogen. | De systemen en applicaties moeten worden ontworpen en aangestuurd om de kosten van toekomstige veranderingen te minimaliseren met respect voor de verschillende ICT evolutie behoeften binnen de organisatie. | Dit impliceert dat ICT evoluties zoveel mogelijk onafhankelijk gebeuren binnen drie ontwikkelingslagen want presentatie-georiënteerde ontwikkelingen evolueren veel sneller in de front-ends dan ontwikkelingen in de back-ends. Dit weerspiegelt voor front-end ontwikkelingen in Agile methodieken en DevOps-tooling, in container- en workflow gebaseerde applicaties in de tussenlaag en in back-ends ontwikkelingen waar men de legacy / buy investeringen wenst te waarborgen. Deze verschillende ICT evoluties, leiden tot verschillende oplevering cycli (release cycles). Content, web en mobiele ICT evoluties veranderen veel sneller (wekelijks) dan producten die door de back-ends worden aangeboden (trimestrieel). Ontwikkeling en installatie processen en hun bijbehorende tooling, die verschillende technologieën, ontwikkelaar profielen en verwachtingen scheppen, moeten deze diversiteit van behoeften kunnen ondersteunen. |
| Eindgebruikerservaring | We gaan voor een passende eindgebruikerservaring die herbruikbaar is binnen verschillende web sites en mobiele toestellen. | De passende gebruikerservaringen worden zoveel mogelijk bepaald op basis van de volledige cross-channel ervaring van de eindgebruiker ook wel customer journey genoemd. | Dit betekent dat binnen een algemeen aanvaarde huisstijl (en een huisstijl per lokale entiteit), stijl gidsen (style guides) moeten worden gedefinieerd en geïmplementeerd, die bepalend zijn voor de keuze van UI-applicatie patronen. Zoals adaptieve schermen gebaseerd op de rol(len) van de eindgebruiker. |
| Technologie standaardisatie | We willen een éénmalige integratie met de achterliggende systemen en applicaties door meer in te zetten op service georiënteerde oplossingen. | Reduceren van de technologiekosten door gebruik te maken van service georiënteerde oplossingen die worden aangedreven door interoperabiliteit, teneinde de herbruikbaarheid van de achterliggende systemen en applicaties te verhogen. | Om interoperailiteit te organiseren, moeten applicaties worden ingedeeld in drie soorten applicaties: * consumer services in de front-ends of end-user experience, die informatie (inhoud) aan de eindgebruiker leveren * broker services in de service-communication laag, die de verzoeken van eindgebruikers van een willekeurig aantal consumer services naar provider services beheren. * provider services, in de back-ends of core systems laag, die informatie (inhoud) verschaffen, al dan niet via broker services, door toegang te krijgen tot gegevens die worden beheerd door een bepaald kern systeem (CRM, ERP, ...). De gegevensstromen die tussen de bovenstaande applicaties worden gebruikt, omvatten standaard gegevensformaten en protocollen, die worden beschreven in integratie architectuur documenten. |
| Levenscyclusbeheer | We willen een duidelijk zicht krijgen hoelang systemen en applicaties in de organisatie worden gebruikt. | Men weet welke systemen & applicaties in de organisatie worden gebruikt om de organisatie te veranderen door middel van innovaties, en/of transformaties en/of verbeteringen. Maar ook welke systemen & applicaties er gebruikt worden om de organisatie draaiende te houden. | Als gevolg hiervan moeten we ons ervan bewust zijn dat niet alle (huidige) ICT oplossingen worden geleverd met de bedoeling om eeuwig mee te gaan. Sommige ICT oplossingen voor nieuwe ideeën zijn erop gericht om snel te worden vervangen, zoals prototypes. Andere ICT oplossingen zijn er als 'enabler' voor gemeenschappelijke ideeën en worden daarom geleverd met de bedoeling om lang mee te gaan. Daarom is een technologie selectie proces nodig ondersteund door architectuur, zodat we de juiste investeringsbeslissingen kunnen nemen over de verderzetting van ICT oplossingen. Een heat-map dus met de betrokken applicaties en systemen. |
| Schaalbaarheid | We willen schaalbare systemen en applicaties om de toenemende communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties, aan te kunnen. | De systemen en applicaties verwerken de toenemende werkdruk, volgens de eisen van de (eind)gebruikers, op een verwachte manier zonder daarbij in de fout te gaan. Dit door extra 'resources' toe te voegen aan het ICT landschap, extra vermogen voor deze 'resources' en een efficiënt beheer van het werkgeheugen en data. | Systemen en applicaties zouden bij voorkeur steeds meer in de cloud of in tweede orde op schaalbare on-prem infrastructuur moeten worden aangekocht en/of geïmplementeerd. De applicaties moeten ook worden gekocht en/of gebouwd met het oog op 'service stateless', wat inhoudt dat (status) gegevens in een 'in-memory state' zoveel mogelijk dienen te worden gepersisteerd naar (tijdelijke) schaalbare databronnen. |
| Bedrijfsbeveiliging | We zorgen er voor dat de communicatie, data en gebruik onderling tussen eindgebruikers, systemen en applicaties op een veilige manier gebeuren. | Alle ICT-oplossingen die binnen de organisatie worden gebruikt, moeten voldoen aan alle beveiligings- en privacybeleidsregels om de kans op inbreuken te verkleinen of liefst onmogelijk te maken. Gegevens zijn daardoor beschermd tegen ongeautoriseerd gebruik en openbaarmaking. | Beveiliging moet in de eerste plaats vanuit een business perspectief worden bekeken, omdat beveiligingsbeleid nauw verband houdt met business veranderingen. De (lokale) organisatie(s) dient/dienen hiervoor een eigen beveiligingsbeheer (bv. group policies op departement, dienst, team, ...) te hebben waar eindgebruikers (users), rollen, toegankelijkheid, ... lokaal en centraal beheerd kunnen worden via duidelijke procedures, richtlijnen en standaarden. Als gevolg hiervan zullen we alleen toegang tot gegevens verlenen aan die personen die toegang zouden moeten hebben. |
| Databeveiliging | We willen vermijden dat de manier waarop data wordt behandeld en beheerd, grote beperkingen opleveren in de uitvoering van de activiteiten binnen de organisatie, waarbij we data zien als een enabler en niet als knelpunt. | We zien data als een troef (data as a product) waaruit we verschillende voordelen kunnen creëren zoals de behoeften en ervaringen van de (eind)gebruikers beter leren kennen om een betere relatie te ontwikkelen, sneller kunnen reageren op veranderingen, verhogen van de operationele efficiëntie door transparante communicatie, beter kunnen beslissen via huidige en toekomstige inzichten, snellere verwerking van (gewijzigde) wet- en regelgevingen via notificaties uit betrouwbare bronnen, verlagen van allerlei risico's door hogere data kwaliteit, ... met data als onderdeel van de organisatie cultuur. | Een data-gedreven organisatie omvat het correct classificeren via een betere segmentatie en gerichte communicatie in de organisatie. De organisatie en haar entiteiten hebben hiervoor een afgestemde data management en governance zodat (lokaal) georganiseerde data door de juiste stakeholders kan worden vertrouwd, georganiseerd en geconsumeerd. Een goed draaiende 'information management' haalt steeds meer gegevens uit interne systemen en applicaties en maak beter en nuttig gebruik van externe data, waarbij data kwaliteit van groot belang is voor het bepalen van efficiënte inzichten en nakomingen van o.a. GDPR regelgevingen. Om de datastromen die vertrekken van de operationele omgevingen naar de comsumptie omgeving in goede banen te leiden, is een overkoepelende Data Flow Manager (DFM) nodig om de data binnen en buiten de organisatie op te nemen, te transformeren en te distribueren. De hoofdtaak van de DFM is om data te verplaatsen en te laten evolueren over drie verschillende DFM-lagen, nl.: #Onboarding Data Layer, waarbij de data van de operationele omgevingen eerst tijdelijk worden opgeslagen in Landing Zones om ze nadien te consolideren waarop regels kunnen worden toegepast. De data met conflicten worden in een aparte quarantaine geplaatst, zodat de bronnen in de operationele omgevingen die kunnen verbeteren en opnieuw kunnen introduceren. #Integration Layer, waarbij de aanvaarde data wordt geïntegreerd volgens het business data model van de organisatie #Consumption Layer, zodat de (eind)gebruikers de benodigde gegevens in de meest geschikte formaten en technologieën, kunnen consumeren |
Enterprise specifieke architectuur
Duidelijke indicatie van de business-, informatie- en applicatie architectuur op de gedetecteerde capabilities Strategic Control, Supplier Management, Marketing Management, Suppply Chain Management, Sales & Distribution Management, Customer Management, Contact Center Management & Information Mangement.
Enterprise Business architectuur
Capability realisatie vanuit een business perspectief, start vanuit business functies. Een business functie is een concept dat wordt gebruikt in het domein Business Architecture en vertegenwoordigt wat er wordt gedaan. Dit betekent dat we kijken naar het gedrag, de acties, oftewel wat er GEBEURT.
Incentivering business architectuur tekening
Incentivering business architectuur beschrijvingen
Hierbij een lijst van de business functies die een extra woordje uitleg nodig hebben.
| Business functie | Omschrijving |
| Beheer tarificatie | Tarificatie bevat de business logica om de prestaties van de Consumenten, alsook de handelstransacties van de Aanbieders te verwerken volgens de nomenclatuur. Tevens communiceert ze de verschillende tarificatie stappen met de financiële dienst. |
| Beheer facturatie | Facturatie verwerkt de binnenkomende vorderingen van de Aanbieders, stelt facturen op naar de Donors, berekent de verdeling van de uitbetalingen naar de Aanbieders en communiceert de verschillende facturatie stappen met de financiële dienst. |
| Financieel & klanten beheer | Boeken van (correcties op) vorderingen, voorschotten, provisies, saldi, ... |
| Zakelijke woordenlijst | Het hoofddoel van de zakelijke woordenlijst is om ons begrip van algehele terminologie te verbeteren, zodat we effectiever kunnen communiceren in de hele organisatie, in plaats van mensen woorden anders te laten gebruiken of hun eigen interne vocabulaire te laten ontwikkelen, wat leidt tot zinloze discussies. |
| Data governance | Het organiseren van een efficiënte informatiestroom binnen de organisatie, ervoor zorgen dat deze gemakkelijk vindbaar en moeiteloos toegankelijk is, rekening houdend met de geldende privacy wetgeving. |
| Data beheer | Beheer van (master)databronnen, waardoor data effectief en efficiënt kunnen worden ontsloten, verwerkt en gebruikt. |
| Intelligentie beheer | Het organiseren van het verzamelen, vormgeven en delen van (inzichtelijke) informatie-elementen over één enkel of een groep van onderwerpen en/of dingen . Inzicht in deze onderwerpen en dingen en hun gedrag door het profiel van een onderwerp of ding te beschrijven, ze in segmenten te groeperen, voorkeuren te voorspellen en de evolutie van het gedrag van deze onderwerpen en dingen in de loop van de tijd te volgen. |
Enterprise Information architectuur
De business objecten, binnen de informatie architectuur, worden gebruikt om de bedrijfsconcepten en terminologie te communiceren en te beheren, samen met de bijbehorende definities en relaties tussen die termen. Bij business objecten kijken we naar de statische werkelijkheid, wat HEBBEN we.
We onderscheiden 3 niveau’s :
- Het hoogste niveau zijn de informatie onderwerp gebieden of subject area’s, zodat men sneller kan navigeren naar deze gebieden die het meest interessant zijn en reeds eerste definities en relaties kunnen worden opgesteld en bepaald.
- Het tweede niveau zijn de L2-business objecten en deze maken deel uit van minstens één informatie onderwerp gebied. L2-business objecten zijn voor het merendeel een abstractie van de OSLO kern data entiteiten, dus zonder gerelateerde data entiteiten.
- Het derde niveau zijn de L3-business objecten en hun gerelateerde data entiteiten. Zij worden gekoppeld aan L3-business processen met vermelding van hun CRUD-actie (Create, Read, Update & Delete). Deze viewpoints worden beschreven in het Solutions Continuüm en maken dus geen deel uit van deze architectuur studie.
Incentivering Supply Chain information architectuur tekening
Incentivering Supply Chain informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben.
| Subject Area of Business object | OSLO-type | Omschrijving |
| Sponsor | JA | AGENT (generieke OSLO-classe). |
| Consument | JA | AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. |
| Aanbieder | JA | AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod |
| CriteriumVereiste | JA | Criterium dat toelaat te bepalen of een gebruiker recht heeft op een stimulansaanbod. |
| Stimulansaanbod | JA | |
| Bewijs | JA | De beschrijving van wat men moet voorleggen om te kunnen voldoen aan de CriteriumVereiste(n) van een specifiek Stimulansaanbod. |
| Beloning | JA | Beschrijving van de beloning die bij een stimulansaanbod hoort. Dit is wat zal ontvangen worden bij de consumptie van dit stimulansaanbod. Dit is niet de effectief ontvangen beloning, maar de beschrijving van wat je zal ontvangen. |
| Stimulans consumptie | JA | Consumptie van een stimulansaanbod |
| Beloningsontvangst | JA | De effectieve beloning die ontvangen is bij de consumptie van een stimulansaanbod |
| Bewijslevering | JA | Het bewijs dat effectief geleverd wordt bij de consumptie van het stimulansaanbod door een Agent. |
Incentivering Marketing informatie architectuur tekening
Incentivering Marketing informatie beschrijvingen
Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben.
| Subject Area of Business object | OSLO-type | Omschrijving |
| Product aanbiedingen | NEE | Vrijwillige maar voorwaardelijke toezegging die ter acceptatie aan de consument via een advertentie werd voorgelegd en die commercieel afdwingbaar wordt als deze door de consument wordt geaccepteerd. |
| Campagnes | NEE | Een campagne is een gegroepeerde actie om gedurende een bepaalde periode een product aanbieding te promoten om consumenten te boeien |
| Marketing betrokkenen | NEE | Een partij (individu of organisatie) die een interactie heeft met een handelaar, om een product en/of dienst te leveren. |
| Marketingkanalen | NEE | Een marketingkanaal is waarop een burger of consument wordt blootgesteld aan het merk, product, dienst, ... van een bepaalde handelaar (via een marketing agentschap). Dus elke interactie die de perceptie van de consument kan veranderen. |
| Promoties | NEE | Is een marketingactie die bestaat uit het bezorgen van een specifieke boodschap aan een specifieke subgroep van geselecteerde betrokkenen voor een bepaalde marketingcampagne. |
| Sponsor | JA | AGENT (generieke OSLO-classe). |
| Consument | JA | AGENT (generieke OSLO-classe). Iemand die of iets dat kan handelen of een effect kan teweeg brengen. |
| Aanbieder | JA | AGENT (generieke OSLO-classe). Aanbieder van het stimulansaanbod |
| DirectMarketing | JA | Directe communicatie met de consument, dit kan via kanalen zoals e-mail, sociaal media, (push) notificaties, websites, webchat, ... |
| Consent | NEE | Vrijwillige indicatie van de wens van de burger of consument waarmee hij/zij akkoord gaat met de verwerking van de betreffende persoonsgegevens voor een bepaalde vorm van verwerking. Een toestemming kan 3 statussen hebben gegeven, niet gegeven of ingetrokken. |
| Distributie | JA | |
| PublicRelations | JA | Campagne met als doel om het imago te verbeteren |
| VerkoopPromotie | JA | Reclame, advertenties, korting, |
| PublicatieEvent | JA | Een PublicatieEvent zal altijd deel uitmaken van een bredere Campagne. Dit maakt het mogelijk om een Campagne op te starten die meerdere PublicatieEvents kan omvatten. Bevat o.a. de attribuut 'PublicatieKanaaltype' en dat kanaal wordt gebruikt om publicatie te verspreiden en staat dus dichter bij het publiceren ipv het maken van de inhoud. |
| Campagne | JA | Een Campagne is het geheel van acties om te informeren en het stimuleren van gewenst gedrag bij het doelpubliek. |
| InformatieObject | JA | InformatieObject kan de vorm aannemen van tekst, beeld, audio |
| PublicatieExpressie | JA | Bevat o.a. de attribuut 'PublicatieTooltype' en die tool wordt gebruikt om publicatie te maken en staat dus dichter bij het maken van inhoud ipv het publiceren. |
| Stimulansaanbod | JA | |
Incentivering Contact Center informatie architectuur tekening
Incentivering Contact Center informatie beschrijvingen Hierbij een lijst van de informatie elementen die een extra woordje uitleg nodig hebben.
| Subject Area of Business object | OSLO-type | Omschrijving |
| InformeerActie | JA | OSLO-Notificatie:InformeerActie |
| Kennisgeving van informatie aan zij die het aanbelangt. Deze informatie kan via meerdere kanalen naar een individu of naar een doelgroep genotificeerd worden. | ||
| NotificatieBericht | JA | OSLO-Notificatie:Notificatiebericht |
| Een bericht van een afzender naar een bestemmeling met als doel het informeren van de bestemmeling. | ||
| Melding | JA | OSLOthema-melding:Melding |
| Beschrijft de melding van een probleem of een vaststelling die mogelijks aanleiding geeft tot een actie van de overheid. De Melding kan gebruikt worden voor het capteren van feedback met betrekking tot concrete informatievelden. | ||
| Terugmelding | JA | OSLOthema-melding:Terugmelding |
| Beschrijft de terugmelding van fouten of onvolledigheden in digitale gegevensbronnen naar de verantwoordelijke bronbeheerder. Een terugmelding kan gebruikt worden om bijvoorbeeld een foutief adres te melden op een website of een fout in de digitale weergave van een diploma. | ||
| Meldingsobject | JA | OSLOthema-melding:Meldingsobject |
| Het Meldingsobject identificeert een resource,een specifiek deel van een resource,een bepaalde representatie van een resource of een combinatie hiervan welke gebruikt wordt binnen de (Terug)Melding. In de praktijk kan het Meldingsobject beschreven worden aan de hand van instanties van de klasse Eigenschap. Het Meldingsobject heeft een Dataset als bron en een TijdToestand, om de datum en het tijdstip vast te leggen, waarop het Meldingsobject dient ge nterpreteerd te worden. De klasse Eigenschap beschrijft de data velden waaruit een Dataset bestaat met Concept waarden bestaande uit een exhaustieve lijst aan mogelijk waarden (bv. een codelijst). | ||
| Behandelaar | JA | OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) |
| Agent die werd aangewezen om de melding en/of het meldingsobject op te volgen en af te handelen. | ||
| Indiener | JA | OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) |
| Agent die de Melding heeft aangemaakt en/of ingediend. | ||
| Betrokkene | JA | OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) |
| Agent die als derde belang heeft bij de Melding of ge mpacteerd is door de behandeling ervan. Bijvoorbeeld indien de melding werd aangemaakt door een derde, bijvoorbeeld een ambtenaar van de gemeente op vraag van een burger. | ||
| Melder | JA | OSLO-Generiek:Agent (Applicatie, Organisatie of Persoon) |
| De Agent die het probleem waarover gemeld wordt opmerkte. De melder zal niet telkens gekend zijn. Bijvoorbeeld in het geval van een anonieme melding via een website. |
Enterprise Applicatie architectuur
De Applicatie Architectuur ondersteunt de Business Architectuur. De L2-Application Components realiseren de L1-capabilities, waarbij de L3-applicatie elementen, die behoren tot het Solutions Continuüm en niet in-scope voor deze studie, een "implementatie" is van de L3-business processen.
Incentivering applicatie architectuur tekening
Hierbij een lijst van de applicatie componenten die een extra woordje uitleg nodig hebben.
| Applicatie Component | Omschrijving |
| Strategic Management Tool | Strategic management tools omvatten instrumenten als een SWOT-analyse en een PEST-analyse. Men gebruikt deze tools voor strategische managementplanning om precies te bepalen waar men de komende jaren en daarna naartoe gaat en hoe ze daar moeten komen. |
| Data Explorer | Technologie dat op een eenvoudige wijze de evolutieve ‘Onboarding’ gegevens kan opnemen waarop men binnen enkele seconden, complexe ad-hoc queries op deze gegevens kan uitvoeren. De source connectoren zijn verantwoordelijk om een technische verbinding te maken met de externe bron en leest de brongegevens uit in de meeste geschikte formaat volgens de data-verantwoordelijke van de brongegevens, na voorlegging van gesupporteerde connectoren van de gekozen ‘Data Explorer’ technologie. Indien de gewenste connector niet standaard aanwezig is, moet het mogelijk zijn om een custom connector te maken. |
| ETL | Technologie dat bij het beheren van databanken verwijst naar extraheren (Extract), transformeren (Transform) en laden (Load) naar drie afzonderlijke functies die worden gecombineerd in één technologisch platform. |
| API Management | API-management technologie wordt ingezet om een zo goed mogelijk beheer te hebben van gegevensuitwisseling, dit zowel voor de data-consument (consumer) als voor data-producent (producer). APIs stellen gegevens ter beschikking voor consumptie via drie specifieke 'Loads' meestal binnen een near/real-time streaming context waarbij de consumer applicatie zich aanpast aan de aangeboden data definities van de APIs: * initial loads, eerste keer, met geplande downtimes en meestal grote hoeveelheid aan data * incremental loads, volgende keren, met eventuele downtimes en meestal minder grote hoeveelheid aan data aangezien deze worden uitgevoerd na initial loads. * recurring loads, voor gewijzigde gegevens via zero-downtime deployment d.m.v. on-the-fly schema migraties (delta files) en meestal voor kleine hoeveelheid aan data aangezien deze gebeuren na de incremental loads. Men dient voor deze ‘Load’ type wel de keuze te maken om dit ofwel verder aan te bieden via het data of applicatie integratie platform. |
| Business Intelligence (BI) | Technologie ten dienste voor de: * data-analist: ze analyseren de verstrekte gegevens om bv. de omzet van de organisatie te verbeteren. Ze hebben mogelijk een data-mart nodig, inclusief enkele aggregaties, toegepaste bedrijfsregels en filtering, en het gebruik van een datamodel als dimensionale modellering die analytische query's mogelijk maakt. * BI-ontwikkelaar: ze hebben toegang tot de ‘Organized Data’ om data marts, BI-rapporten en dashboards te maken voor de data-analisten en/of BI-eindgebruikers. * BI-eindgebruiker: ze hebben gegevens nodig uit de ‘Organized Data’ en/of de beschikbare data marts van de BI-ontwikkelaars, alsook self-service BI tooling dat hen in staat stelt om de gegevens te verkennen en te exploiteren. |
| Artificial Intelligence (AI) | Technologie dat de data scientist in staat stelt om data: * te verkennen: gegevens worden verkend om te selecteren welke gegevens nuttig zijn voor hun model * te exporteren: nadat de gegevens zijn geselecteerd tijdens de verkenning, exporteren de data scientists de vereiste gegevens naar hun eigen data science workbench om feature-engineering en model training op te starten. * te industrialiseren: wanneer het analytische model klaar is om in productie te worden gebruikt, zal een geautomatiseerd proces de gegevens van de ‘Organized Data’ exporteren naar de data science industrialization omgeving. * te trainen: data scientists moeten hun analytisch model ook vaak trainen en kalibreren op basis van productie gegevens. * Data scientists gebruiken o.a. tools en talen als python, R, databricks, ...om de data te analyseren en analyse modellen te creëren. |
| Datawarehousing | Is de technologie waar de gegevens centraal worden gehistoriseerd waaruit men verder deze gegevens geaggregeerd, getransformeerd en verrijkt kunnen ophalen om geinformeerde keuzes te kunnen maken d.m.v. rapportages of/en-analyses. |
| Master Data Management | Is de technologie om de belangrijkste bedrijfsgegevens te beheren ter ondersteuning van de transactionele of operationele gegevens. Master data beschrijft op een unieke wijze de klanten, medewerkers, materialen, leveranciers, enz. die bij data uitwisseling betrokken zijn. Ze worden typisch onderverdeeld in ofwel Plaatsen (locaties, geografie, sites, ...), Partijen (personen, klanten, leveranciers, werknemers, ...) en Dingen (producten, materiaal, voertuigen, ...). |
| Document Management | |
| ERP | Via een ERP-oplossing kan elke afdeling of elk bedrijfsdomein onafhankelijk en centraal beheerd worden. Voordelen zijn onder meer interoperabiliteit van gegevens, verbeterde communicatie en verhoogde gegevensbetrouwbaarheid door het gebruik van een enkele database. ERP verbetert ook de kwaliteit van bedrijfs-brede besluitvorming. Een op maat gemaakte bestelling kan bijvoorbeeld van de verkoopafdeling naar voorraadbeheer gaan en vervolgens naar facturering naar financiën en productie. Door een ERP te gebruiken, is dit type proces een efficiënte en continue reeks gebeurtenissen die het gemakkelijk maken om individuele bestellingen te volgen. |
| CRM | Customer Relationship Management (CRM) is een technologie voor het centraal beheer van alle relaties en interacties van een organisatie met zijn (externe) contactpersonen. Een CRM-systeem biedt een 360-graden beeld van hun contact, waardoor ze betere relaties kunnen opbouwen door persoonlijker en relevanter te communiceren. |
| Derdebetalersysteem | Het derdebetalerssysteem verwijst naar de mogelijkheid om het volledige bedrag van handelstransacties niet direct te moeten betalen in digitale munt. Het is een soort alternatief voor de klassieke terugbetaling, een meer directe en toegankelijke oplossing. Bij dit systeem wordt de ontvanger rechtstreeks door de donor vergoed. Dit betekent dat er geen directe betaling moet gebeuren tussen de burger en ontvanger en dat de ontvanger na de prestatie wordt terugbetaald. Als men een derdebetalerssysteem toepast, betaalt men alleen het persoonlijk aandeel, indien van toepassing, d.w.z. het bedrag dat na tussenkomst van de donor nog voor eigen rekening van de burger blijft. |