HKBA Inrichtingskeuzes

Uit ASTRA
Versie door ASTRAbot (overleg | bijdragen) op 18 jul 2024 om 10:52 (Nieuwe pagina aangemaakt met '{{Publicatie |Redactiestatus=Actueel |Paginastatus=publiceren }} Categorie:HKBA_Elementen '''Resultaat:''' bepaal binnen de ontwerpruimte de keuzes voor vorm en inrichting van de dienst '''Waarom:''' met dit element bepaal je binnen de ontwerpruimte de keuzes voor vorm en inrichting van de dienst. Als het goed is heb je in de andere elementen een inrichtingsonafhankelijk procesmodel opgesteld. Om dat te kunnen implementeren moeten keuzes worden gemaakt...')
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springen Naar zoeken springen


Resultaat: bepaal binnen de ontwerpruimte de keuzes voor vorm en inrichting van de dienst

Waarom: met dit element bepaal je binnen de ontwerpruimte de keuzes voor vorm en inrichting van de dienst. Als het goed is heb je in de andere elementen een inrichtingsonafhankelijk procesmodel opgesteld. Om dat te kunnen implementeren moeten keuzes worden gemaakt over inrichtingsaspecten die horen bij de dienst waar je op dit moment mee bezig bent, zoals “volgorde van acties”, “vorming van functionaristypen”, “toedeling aan personen of organisatie”. Deze aspecten kunnen worden ingedeeld in verschillende organisatie dimensies, zoals zoals security, organisatie, personeel, administratie. Dit zijn keuzes die vallen onder Organisatie Implementatie Variabiliteit:

Stappenplan

Als structuur hiervoor kun je SCOPAFIJTH aanhouden. Dit is een acroniem voor de meest voorkomende (ondersteunende) processen van een organisatie. Vul daarbij die aspecten in die bij de implementatie van de rol een dienst spelen.

Denk aan

  • het kwalificeren van mensen & middelen (benodigde / haalbare expertise), kwantificeren van mensen & middelen (#fte's van welke kwaliteit in de operatie, toepassen systeem X, …), beide zowel voor operatie als transformatie
    • Voorbeeld: voor de competentie “EHBO-diploma van niveau X” kiest DJI voor plaatsen extra bijrijders (met logistieke consequenties voor personele en rittenplanning!) of bijscholen van bestaande (bij)rijders
  • procesmodel cf. werk@wijzer


Voorbeeld

Onderdeel Voorbeeld
Security dienst heeft risicoprofiel

dienst past toe risicomaatregel (b.v. 2FA, uitsluitend gebruik van Justitienet, …)

dienst past toe autorisatieregels (b.v. RBAC, ABAC, PBAC)

privacytoets* voor informatiedienst is uitgevoerd

Communicatie
Organisatie informatiedienst wordt verzorgd door informatiedienstleverancier

informatiedienst wordt uitgevoerd door informatiedienstuitvoerder

IT-systeem produceert informatieproducttype

Personeel functionaristype beheerst competentie*

actor [mandateert/delegeert] actor

Administratieve organisatie
Financiën
Informatievoorziening dienststap wordt uitgevoerd in modus {expliciet; impliciet}

informatieproducttype kent informatieproducttyperepresentatietype(n)

informatieproducttype vervult informatiebehoefte (uit 5E, 8.5E)

informatieproducttype valt onder classificatie*

informatieproducttype wordt verstrekt via informatieactiepatroon {vraagpatroon, attenderingspatroon}

informatieproducttype is resultaat van informatiedienst

Juridisch
Technologie koppelvlak is van type kanaal {H2H, M2M, H2M}

koppelvlak hanteert koppelvlakstandaard {eBMS | WUS | REST-API; (Grote Berichten)}

informatiedienst-interactie wordt geïmplementeerd via berichttype(n)

actor <uitvoerder> is (voor deze dienststap) benaderbaar via koppelvlak

actor <geadresseerde> is (voor deze dienststap) benaderbaar via koppelvlak

productrepresentatietype wordt aangevraagd / geleverd via koppelvlak

Huisvesting
  • Voorbeeld autorisatietabel cf. dienstoriëntatie/DEMO
Mag reageren op diensttoestand

Functionaristype

D01 / verzocht D01 / beloofd D01 / herroepen
F1 A A A
F2 D
F3 M

A = attributie M = mandaat D= delegatie


Toelichting

  • Dit wordt gestuurd door beleidskeuzes, b.v. wanneer uitvoeringsmodus expliciet/impliciet etc.  
  • Denk bij middel-keuzes aan agent, systeem, applicatie, kanaal, functionaris, ...
  • Beleidskeuzes kunnen ook gaan over optimalisaties (zoals door wel/niet uitbesteden, overdragen, parallelliseren / volgorde, anders routeren, …) die in de “keten” bereikt kunnen worden – d.w.z. kijk verder dan het koppelvlak waar informatie wordt uitgewisseld. Dit gebeurt veelal tijdens procesontwerp.
  • Dit vult de relatie met invalshoek "Maakbaarheid" geheel in. De haalbaarheid betreft zowel de toekomstige operatie als de voorgenomen transformatie; dat laatste heeft dan raakvlak met portfoliomanagement
  • voorbeelden
  • splitsen: (TARGET-) operatie versus transformatie
  • splitsen: welke keuzes passen op niveau keten <--> ketenpartner (achter koppelvlak; bijvoorbeeld intern proces, intern IT-systeem)?
  • Welk deel is eventueel nog INPUT voor “vaststellen ontwerpruimte”? ⇒ M. Maakbaarheid
  • Ad privacytoets. De inhoud van een informatieproducttype moet zich verhouden tot de privacywetgeving:
    • Transparantie: helder voor alle betrokkenen
    • Doelbeperking: de persoonsgegevens worden voor een welbepaald gewettigd doel verzameld en mogen niet voor andere zaken gebruikt worden
    • Gegevensbeperking: enkel de noodzakelijke gegevens die voor het beoogde doel noodzakelijk zijn, mogen worden verzameld
    • Juistheid: de persoonsgegevens moeten correct zijn en blijven
    • Bewaarbeperking: de persoonsgegevens mogen niet langer bewaard worden dan nodig voor het beoogde doel
    • Integriteit en vertrouwelijkheid: de persoonsgegevens moeten beschermd worden tegen toegang door onbevoegden, verlies of vernietiging
    • Verantwoording: de verantwoordelijke moet kunnen aantonen aan deze regels te voldoen
    • Proportionaliteit: …
  • Toets de keten op privacy- en security-sterkte door het systematisch formuleren van "abuse cases”. Zie Ioana Marginas, DEMO and Security. IBM, 2009.