In het boek Informatiemanagement beschrijven Laury Bollen en Mark Vluggen een indeling van informatiesystemen, waarbij onderscheid gemaakt wordt in vier soorten systemen:

[Laury Bollen en Mark Vluggen] onderscheiden vier groepen van informatiesystemen:

(1) Transactieverwerkende systemen

Transactieverwerkende systemen zijn systemen die transacties verzamelen en verwerken die betrekking hebben op operationele bezigheden. Bijv. ERP-systemen. Op het operationele niveau van de organisatie krijgen managers vooral te maken met gestructureerde problemen. Transactieverwerkende systemen bieden ondersteuning bij het nemen van gestructureerde beslissingen. Hoewel deze systemen zich vooral richten op ondersteuning van activiteiten op het operationele niveau van de organisatie, zijn ze wel degelijk van essentiel belang voor de informatievoorziening van de hogere hiërarchische niveaus in de organisatie. Deze systemen leggen namelijk de basis voor de totale informatievoorziening binnen de organisatie.

(2) Informatieverwerkende systemen

Systemen die gericht zijn o het genereren, vastleggen en toegankelijk maken van informatie. Kantoorapplicaties (spreadsheets, tekstverwerking) zijn een bekend voorbeeld.

(3) Managementsystemen

Systemen die overzicht en rapportages geven die gericht zijn op het besturen van organisaties. Deze systemen moeten ondersteuning bieden bij gestructureerde problemen, maar vooral bij semi-gestructureerde problemen. Dit zijn namelijk de problemen waar het middenmanagement het vaakst mee te maken krijgt.

(4) Strategische systemen

Systemen die gericht zijn op de ondersteuning van het topmanagement. Op dit niveau worden vooral ongestructureerde beslissingen genomen. Executive Information Systems kunnen worden ingezet om it type beslissingen te ondersteunen.

(...)

Gestructureerd probleem

Probleem waarbij de besluitvormer gebruik kan maken van vaste procedures. Het gaat hier om vaak terugkerende problemen, waarvoor een standaardoplossing bestaat.

Semi-gestructureerd probleem

Probleem waarbij de fasen uit het besluitvormingsproces (intelligence, design choice) deels gestructureerd en deels ongestructureerd zijn.

Ongestructureerd probleem

Probleem waarbij geen enkele van de fasen uit het besluitvormingsproces (intelligence, design choice) is gestructureerd. Er kan dus geen gebruik worden gemaakt van vaste procedures om het probleem op te lossen. In plaats daarvan wordt gebruik gemaakt van intuïtie en menselijke oordeelskracht.

Bron: Informatiemanagement, Laury Bollen & Mark Vluggen

In het boek Informatiearchitectuur - de infrastructurele benadering beschrijven Wim van der Sanden en Bart Sturm het begrip architectuur als volgt:

[Architectuur] is de wijze waarop een visie of idee herkenbaar is geconcretiseerd in de opbouw van een object. Op basis van deze omschrijving kunnen vijf definiërende kenmerken van architectuur worden onderscheiden:

1. Architectuur beschrijft de structuur van een object, dat wil zeggen: uit welke componenten het object is samengesteld; wat hun functie is, welke bijdrage ze elk leveren aan de algemene doelstellingen; hoe deze componenten samenhangen.

2. Architectuur is bij uitstek het instrument om de kwaliteit van het geheel te sturen. Hoe uitdagender de doelen, des te belangrijker is de samenhang. Een goede samenwerking tussen de componenten moet suboptimaal gedrag voorkomen en synergie bewerkstelligen.

3. Essentieel voor een architectuur is dat zij uitdrukking geeft aan een visie. Niet elke structuur noemen we een architectuur. (...) Ontbreekt een visie, dan kan het geheel nog wel een structuur hebben, alleen drukt die niets uit: het geheel is 'stijlloos', een structuur zonder ziel.

4. Architectuur is het resultaat van onderhandeling. Architectuur is belangrijker naarmate de eisen hoger zijn. Pas dan moet de architect de grenzen van het mogelijke onderzoeken. De architectuur verschaft evenwicht tussen wenselijkheid, maakbaarheid en andere tegengestelde eisen en belangen.

5. Architectuur vormt een scharnierfunctie tussen 'wensen' en 'doen'. De architectuur slaat een brug tussen enerzijds de doelstellingen - wat moet er worden bereikt - en anderzijds de uitvoering - wat daarvoor moet worden gedaan.

Bron: Informatiearchitectuur - de infrastructurele benadering, Wim van der Sanden en Bart Sturm

Volgens Jaap Schekkerman geeft voordat hij zelf de domeinmodellen beschrijft van de enterprisearchitectuur de belangrijkste valkuil van architecturen:

Architecten hebben sterk de neiging om een businessarchitectuur te ontwikkelen die vanuit hun perspectief compleet is, opgezet vanuit een methodische benadering en die semantisch correct is, gebruikmakend van een standaardmodelleringstaal. Daarbij worden soms allerlei logische elementen toegevoegd om maar consistent in de benadering te zijn. Juist deze drive naar compleetheid, juistheid is hun grootste valkuil, want vanuit het perspectief van een businessmanager of businesseigenaar zijn al die systematische correctheden helemaal niet nodig.

 

Schekkerman onderkent vijf domeinmodellen die tezamen invulling geven aan de enterprisearchitectuur:

1. Bedrijfsobjectenmodel.

2. Integrale bedrijfsfunctiemodel.

3. Systeemfunctiemodel.

4. Gemeenschappelijk informatiemodel.

5. Procesmodel.

 

Ad (1) Bedrijfsobjectenmodel

"Het bedrijfsobjectenmodel geeft eenduidige definities voor de verschillende bedrijfsobjecten en hun samenhang. Deze definities vormen het semantische kader van begrippen die in het bedrijfsfunctiemodel alsook in het systeemfunctiemodel en het gemeenschappelijke informatiemodel worden gehanteerd. (...) Het bedrijfsobjectenmodel geeft zaken weer waarover de organisatie gegevens wil vastleggen. Gegevens worden vastgelegd in en gebruikt door bedrijfsfuncties. Hierbij is het belangrijk te beseffen dat gegevens regelmatig worden gebruikt in andere bedrijfsfuncties dan waarin ze worden vastgelegd. Dat betekent dat gegevens op een 'open' wijze moeten worden vastgelegd: domeinonafhankelijk, het liefst gebaseerd op een gemeenschappelijk informatiemodel.

Het doel van het opstellen van een objectenmodel is meervoudig:

- opsporen van homoniemen en synoniemen om zo eenduidigheid te creëren

- opstellen van een definitiemodel van begrippen die de basis vormen van communicatie en daarmee uiteindelijk de basis van gemeenschappelijk gegevensgebruik

- optimaliseren van eenduidigheid in communicatie

Het bedrijfsobjectenmodel is feitelijk een definitiemodel. In dit model worden begrippen gedefinieerd en (vanuit de definities) in onderlinge samenhang beschreven. Het model bestaat uit een visualisatie waarin objecten in hun onderlinge samenhang worden weergegeven en uit een tekstgedeelte waarin de objecten met hun eigenschappen worden beschreven."

 

Ad (2) Integraal bedrijfsfunctiemodel

"Een integraal bedrijfsfunctiemodel is een inrichtingsonafhankelijke beschrijving van de taakgebieden (ook wel bedrijfsfuncties) van een organisatie die toegevoegde waarden leveren aan de omgeving en intern aan de onderdelen van die organisatie zelf, alsmede de informatierelatie tussen die taakgebieden en de entiteiten die input leveren en output ontvangen als resultante van die taakgebieden.

In de omgeving van een organisatie worden klanten, gebruikers, burgers, bedrijven, instellingen en ander organisaties onderscheiden die informatie leveren aan die organisatie of waaraan de organisatie informatie levert. Deze betrokkenen worden dan vaak ook actoren genoemd.

Een bedrijfsfunctie is de combinatie van een taak of taakgebied en een doel dat daarmee bereikt moet worden. Een bedrijfsfunctie ondersteunt daarmee het houden van richting zoals aangegeven door uitspraken over missie, visie en strategie, en het behalen van de doelstellingen die daaraan verbonden zijn."

 

Ad (3) Systeemfunctiemodel

"Het systeemfunctiemodel weerspiegelt de functionaliteit van het gewenste geautomatiseerde informatiesysteem ter ondersteuning van de bedrijfsfuncties; hierbij worden de informatierelaties, het gedrag van het systeem en de gegevens weergegeven. Het systeemfunctiemodel bestaat uit een gedetailleerde functionele specificatie van alle functies uit te voeren door het computersysteem."

 

Ad (4) Gemeenschappelijk informatiemodel

"In een gemeenschappelijk informatiemodel wordt vastgelegd welke informatie voor een thema op welke wijze wordt genoteerd. (...) Het gemeenschappelijke informatiemodel bestaat uit een aantal samenhangende onderdelen die gezamenlijk de beschrijving van het model vormen: begrippen, classificatie, objectbeschrijvingen en interoperabiliteit."

 

Ad (5) Bedrijfsprocesmodel

"Bij het modelleren van processen worden bedrijfsprocessen schematisch in kaart gebracht. Het beschrijft dus hoe een organisatie haar processen/taken uitvoert en is daardoor dus inrichtingsafhankelijk. Doorgaans wordt onderscheid gemaakt in:

- Primaire processen: alle activiteiten waarvan de output direct bijdraagt aan het resultaat voor de klant. De primaire bedrijfsprocessen vormen het bestaansrecht van de organisatie.

- Sturende processen: alle activitieiten die benodigd zijn om de organisatie en de processen te kunnen besturen.

- Ondersteunende processen: alle activiteiten die nodig zijn om het primaire proces te faciliteren.

Het verdient de voorkeur om bij het opstellen van het procesmodel steeds uit te gaan van het klantperspectief. Dit kan een externe of een interne klant zijn. Dit helpt vast te stellen wat primair het belang is in het proces. Het houdt de focus gericht op de bedrijfsdoelstellingen. (..) Procesmodellen zijn de basis voor werkinstructies, functie-/rolbeschrijvingen en aansturing."

 

 

Bron: Businessarchitectuur vanuit de business, Jaap Schekkerman, in: State of the art architectuur 2012, Frank Baldinger en Daan Rijsenbrij

In het boek De functioneel beheerder en BiSL beschrijven Kees Ruigrok en Ernst Bosschers de kwaliteitseisen die op basis van ISO 25010 gesteld (kunnen) worden aan software:

De standaard ISO/IEC 9126 Software engineering - product quality is in 2011 vervangen door het ISO/IEC 25010 System and Software Quality Model, dat onderdeel is van de serie standaarden ISO/IEC 250000. Het doel van deze serie is het ondersteunen van de ontwikkeling en verwerving van softwareproducten door hulp te bieden bij de specificatie en evaluatie van kwaliteitseisen. De serie bestaat uit vijf hoofddelen: 25000 kwaliteitsmanagement, 25010 kwaliteitsmodel, 25020 kwaliteitsmeting, 25030 kwaliteitseisen en 25040 kwaliteitsevaluatie. Wij beperken ons tot de bespreking van het kwaliteitsmodel.

[Het kwaliteitsmodel (ISO 205010) bestaat uit een tweetal submodellen: Productkwaliteit en Kwaliteit tijdens gebruik. Deze submodellen zijn onderverdeeld in respectievelijk acht en vijf categorieën die op hun beurt weer 31 en 11 kwaliteitseigenschappen bevatten.

Op dit moment is er nog geen officiële vertaling door het Nederlands Normalisatie Instituut uitgegeven, maar omwille van de duidelijkheid hebben wij gekozen voor Nederlandstalige termen en definities. Daar waar in de officiële titel van de norm ISO 25010 sprake is van Systems and Software spreken wij over applicaties. Hieronder geven we korte definities van de categorieën en kwaliteitseigenschappen.

 

I. Productkwaliteit

 

(1) Geschiktheid

Mate waarin functies van een applicatie voldoen aan expliciete en impliciete kwaliteitsverwachtingen, bij gebruik onder gespecificeerde condities. N.B. dit betreft niet de mate waarin voldaan wordt aan de specificaties uit het functioneel ontwerp.

(1.1) Functionele compleetheid: mate waarin de set functies alle gespecificeerde taken en gebruikersdoelen ondersteunt.

(1.2) Functionele correctheid: mate waarin de applicatie de juiste resultaten met de gewenste nauwkeurigheid levert

(1.3) Functionele toepasselijkheid: mate waarin de functies de uitvoering van specifieke taken en het behalen van doelen faciliteren

 

(2) Prestatie-efficiëntie

Prestaties gerelateerd aan de gebruikte hoeveelheid resources onder gespecificeerde condities.

(2.1) Snelheid: mate waarin responsetijden, verwerkingstijden en doorvoersnelheid van een applicatie tijdens de uitvoering voldoen aan de wensen.

(2.2) Middelenbeslag: mate waarin de hoeveelheid en type resources die gebruikt worden door een applicatie tijdens uitvoering voldoet aan de wensen.

(2.3) Capaciteit: mate waarin de maximale waarden van een applicatieparameter voldoen aan de wensen (bijv. aantal items dat kan worden opgeslagen, het aantal gelijktijdige gebruikers en omvang van de gegevensopslag)

 

(3) Uitwisselbaarheid

Mate waarin een applicatie informatie uit kan wisselen met andere applicaties en/of de gewenste functies kan uitvoeren terwijl ze deel uitmaakt van dezelfde hard- of softwareomgeving.

(3.1) Beïnvloedbaarheid: mate waarin een applicatie haar gewenste functies efficiënt kan uitvoeren terwijl het een gemeenschappelijke omgeving en middelen deelt met andere applicaties, zonder schadelijke invloed op enige ander applicatie.

(3.2) Koppelbaarheid: mate waarin twee of meer applicaties informatie kunnen uitwisselen en de uitgewisselde informatie kunnen gebruiken.

 

(4) Bruikbaarheid

Mate waarin een applicatie gebruik kan worden door gespecificeerde gebruikers om effectief, efficiënt en naar tevredenheid gespecificeerde doelen te bereiken in een gespecificeerde gebruiksomgeving.

(4.1) Geschiktheidsherkenning: mate waarin gebruikers herkennen of een applicatie geschikt is voor hun behoeften c.q. functionele geschiktheid.

(4.2) Leerbaarheid: mate waarin een applicatie gebruikt kan worden door gespecificeerde gebruikers om gespecificeerde leerdoelen te bereiken met betrekking tot het effectief, efficiënt, zonder risico en met tevredenheid gebruik van de applicatie in een gespecificeerde gebruiksomgeving

(4.3) Bedienbaarheid: mate waarin een applicatie attributen heeft die het gemakkelijk maken om ermee te werken.

(4.4) Voorkomen van gebruikersfouten: mate waarin de applicatie gebruikers beschermt tegen het maken van fouten.

(4.5) Esthetica gebruikersinterface: mate waarin een gebruikersinterface het mogelijk maakt om een plezierige en voldoening gevende interactie aan de gebruiker te bieden

(4.6) Toegankelijkheid: mate waarin een applicatie gebruikt kan worden door mensen met de meest uiteenlopende kenmerken en mogelijkheden om een gespecificeerd doel te bereiken in een gespecificeerde gebruiksomgeving.

 

(5) Betrouwbaarheid

Mate waarin een applicatie gespecificeerde functies uitvoert onder gespecificeerde condities gedurende een gespecificeerde tijdsduur.

(5.1) Volwassenheid: mate waarin een applicatie voldoet aan betrouwbaarheidsbehoeften onder normale werkomstandigheden.

(5.2) Beschikbaarheid: mate waarin een applicatie operationeel en toegankelijk is op het moment dat men ze wil gebruiken.

(5.3) Foutbestendigheid: mate waarin een applicatie werkt zoals bedoeld ondanks de aanwezigheid van hard- of softwarefouten.

(5.4) Herstelbaarheid: mate waarin na een onderbreking van de dienstverlening de direct betrokken gegevens hersteld kunnen worden en/of de applicatie in de gewenste staat teruggebracht kan worden.

 

(6) Veiligheid

Mate waarin een applicatie informatie en gegevens beschermt zodat personen of andere applicaties de juiste mate van gegevenstoegang hebben overeenkomstig hun autorisatieniveau

(6.1) Vertrouwelijkheid: mate waarin een applicatie ervoor zorgt dat gegevens alleen toegankelijk zijn voor geautoriseerden.

(6.2) Integriteit: mate waarin een systeemapplicatie ongeautoriseerde wijziging van computerprogramma's of gegevens verhindert.

(6.3) Onloochenbaarheid: mate waarin kan worden bewezen dat aties of gebeurtenissen plaats hebben gevonden, zodat deze later niet ontkent kunnen worden.

(6.4) Verantwoording: mate waarin acties van een entiteit gekoppeld kunnen worden aan die specifieke entiteit.

(6.5) Authenticiteit:  mate waarin bewezen kan worden dat de identiteit van een onderwerp of bron overeenkomt met hetgeen wordt beweerd.

 

(7) Onderhoudbaarheid

Mate waarin een applicatie effectief en effciënt gewijzigd kan worden door de aangewezen resourcebeheerders.

(7.1) Modulariteit: mate waarin een applicatie dusdanig is samengesteld uit afzonderlijke componenten, waardoor een wijziging van een component met minimale impact heeft op andere componenten.

(7.2) Herbruikbaarheid: mate waarin een bestaande component hergebruikt kan worden.

(7.3) Analyseerbaarheid: mate waarin het mogelijk is om effectief en efficiënt de impact van een wijzigingsvoorstel voor een applicatie te beoordelen, om afwijkingen en/of foutoorzaken vast  te stellen of om onderdelen te identificeren die gewijzigd moeten worden.

(7.4) Wijzigbaarheid: mate waarin een applicatie effectief en efficiënt gewijzigd kan worden zonder fouten te realiseren of kwaliteitsvermindering te veroorzaken.

(7.5) Testbaarheid: de mate waarin effectief en efficiënt testcriteria vastgesteld kunnen worden voor een applicatie(deel) en waarin test uitgevoerd kunnen worden om vast te stellen of aan de criteria is voldaan.

 

(8) Overdraagbaarheid

Mate waarin een applicatie effectief en efficiënt overgezet kan worden naar een andere (hardware- en/of software- en/of operationele- en/of gebruiks-)omgeving

 

(8.1) Aanpasbaarheid: mate waarin een applicatie effectief en efficiënt aangepast kan worden aan andere hardware-, en/of software- en/of operationele- en/of gebruiksomgeving.

(8.2) Installeerbaarheid: mate waarin de applicatie effectief en efficiënt geïnstalleerd of verwijderd kan worden in een gespecificeerde omgeving.

(8.3) Vervangbaarheid: mate waarin een product een ander specifiek softwareproduct, met hetzelfde doel in dezelfde omgeving, kan vervangen.

 

II. Kwaliteit tijdens gebruik

(1) Effectiviteit: nauwkeurigheid en volledigheid waarmee gebruikers gespecificeerde doelen behalen.

(2) Efficiëntie: hoeveelheid resources die gebruikt zijn in verhouding tot de nauwkeurigheid en volledigheid waarmee gebruikers doelen behalen.

(3) Tevredenheid: mate waarin gebruikersbehoeften vervuld worden als de applicatie gebruikt wordt in een gespecificeerde gebruiksomgeving.

(3.1) Bruikbaarheid: mate waarin een gebruiker tevreden is met de voor de gebruiker waargenomen behaalde doelen, inclusief de resultaten en de gevolgen van het gebruik van de applicatie.

(3.2) Vertrouwen: mate waarin een gebruiker of andere belanghebbenden erop vertrouwt dat de applicatie zich zal gedragen zoals bedoeld.

(3.3) Genoegen: mate waarin een gebruiker tevreden is met het verwezenlijken van zijn persoonlijke wensen.

(3.4) Welzijn: mate waarin een gebruiker tevreden is met zijn fysieke welzijn.

(4) Risicobeperking: mate waarin een applicatie het risico beperkt voor economische status, mensenlevens, gezondheid of de omgeving.

(4.1) Matiging economisch risico: mate waarin een applicatie de risico's beperkt voor financiële status, efficiënte werking, commerciële eigendommen, reputatie of andere middelen in de beoogde gebruikscontexten.

(4.2) Matiging gezondheids- en veiligheidsrisico's: mate waarin een applicatie de risico's voor personen beperkt in de beoogde gebruiksomgevingen.

(4.3) Matiging omgevingsrisico's: mate waarin een applicatie de risico's voor eigendommen of voor de omgeving beperkt in de beoogde gebruiksomgevingen.

(5) Omgevingsdekking: mate waarin een applicatie effectief, efficiënt, zonder risico's en met voldoening gebruikt kan worden, zowel in de gespecificeerde gebruiksomgevingen als buiten deze initieel niet-expliciet gespeficeerde gebruiksomgevingen.

(5.1) Omgevingscompleetheid: mate waarin een applicatie effectief, efficiënt, zonder risico en met voldoening gebruikt kan worden in alle gespecificeerde gebruiksomgevingen.

(5.2) Flexibiliteit: mate waarin een applicatie effectief, efficiënt, zonder risico en met genoegen gebruikt kan worden buiten de initieel gespecificeerde gebruiksomgevingen.

 

Bron: De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

In het artikel Het drama dat “service” heet: 10 definities concludeert de redactie van de USM-portal eerst dat in vakliteratuur over Facility Management en ICT vaak een eenduidige, bruikbare definitie ontbreekt over wat een 'service' nu eigenlijk is. De redactie stelt zich hierbij de vraag hoe je een service überhaupt goed kunt managen als je eigenlijk niet weet wat het is. In het verdere vervolg van het artikel presenteren ze een definitie van zowel 'service' als 'dienstverlening'.

Hieronder een tweetal citaten en hierboven de visualisatie van de visie van USM op dienstverlening:

Hoe dat komt?

Dat is niet zo moeilijk te verklaren. Alle genoemde bronnen zijn sterk practice-gedreven. Dat betekent dat ze vooral werkwijzen beschrijven vanuit de beleving van een praktijk die ergens wordt aangetroffen. Die praktijken zijn dan weer ontstaan en niet ontworpen, al helemaal niet vanuit een eenduidige architectuur, waardoor ze incompleet en onvoldoende samenhangend zijn. dat beeld treffen we helaas overal in het werkveld van de IT en de rest van Facility Management aan.

(...)


We moeten dus op een andere manier naar het probleem kijken om het op te lossen, maar het moet wél over het object van dienstverlening gaan. Dat leidt tot het volgende.

• Als we de relaties tussen klanten en leveranciers als uitgangspunt nemen voor een service, dan komt die service altijd neer op het volgende: een leverancier stelt aan een klant een voorziening beschikbaar, waar die klant voor zijn eigen business gebruik van kan maken, en die bij dat gebruik door de leverancier wordt ondersteund.
• De voorziening bestaat uit een combinatie van goederen en gedrag.
• Daarmee is een service eenvoudig te definiëren als “een ondersteunde voorziening”. Een kortere definitie zul je nergens tegenkomen. Dienstverlening is dan net zo eenvoudig te definiëren als “het leveren van een ondersteunde voorziening” (of als je wil: “het leveren en ondersteunen van een voorziening”).
• Die service is dan te karakteriseren door z’n functionaliteit (wat de gebruiker er mee kan) en door z’n functioneren (hoe goed dat gaat), en dat geldt voor zowel de component ‘voorziening’ als voor de component ‘ondersteuning’.

Bron: Het drama dat “service” heet: 10 definities, 25 oktober 2018 op: USM-portal

In Architectuur Informatievoorziening voor Operationele Procesbesturing beschrijft Egon Willems hoe binnen UWV wordt omgegaan met zaakgericht werken:

Het werken met zaken is binnen de Nederlandse Overheid cruciaal voor het verbeteren van de dienstverlening en/of bedrijfsvoering. Het is een goede manier om:

• De klant juist te informeren over de voortgang van de desbetreffende klantvragen.
• De afhandeling te monitoren en te bewaken.
• Managementinformatie te verkrijgen over behaalde effecten.
• De behandeling van een klantvraag te reconstrueren.

Het concept van een zaak wordt in de GEMMA gedefinieerd als ‘een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden’. Alle zaakkenmerken en informatie die aan een zaak zijn gekoppeld vormen samen een virtueel ‘zaakdossier’.

[Vaak hanteert een organisatie] het zaakbegrip voor de werkzaamheden die voor externe klanten worden uitgevoerd. De GEMMA-definitie wordt daarvoor aangescherpt in:

Een zaak is een samenhangende hoeveelheid werk:
• ten behoeve van dienstverlening aan de externe klant, 
• met een gedefinieerde aanleiding en een gedefinieerd eindresultaat, 
• waarvan kwaliteit en doorlooptijd bewaakt moet worden.

Elke hoeveelheid werk die voor de externe klant wordt uitgevoerd, waarvan kwaliteit en doorlooptijd bewaakt moeten worden, wordt vastgelegd als zaak. Deze definitie van zaak moet niet worden verward met een juridische zaak of een zaak in de betekenis van ‘bedrijf’.

Onderscheid tussen zaak en proces
In de bovenstaande figuur zijn het verschil en de relatie weergegeven tussen het begrip ‘zaak’ en ‘proces’. Het begrip ‘zaak’ is gericht op de externe klant en het begrip ‘proces’ is gericht op de interne bedrijfsvoering. Een zaak bevat voor de klant herkenbare stappen. Een zaak is gekoppeld aan de afhandeling van een bedrijfsproces (van klantvraag, aanvraag of melding naar de levering van een dienst in de vorm van bijvoorbeeld een beschikking).

In de figuur wordt een relatief eenvoudig proces getoond met 17 stappen. Sommige stappen moeten parallel uitgevoerd kunnen worden. Andere stappen moeten meerdere keren doorlopen kunnen worden. De processtappen zijn in rood, blauw en wit weergegeven.

Een blauwe stap betekent een statuswijziging. De behandelaar dient dit in het zaaksysteem vast leggen. Een witte stap betekent dat er een relevant document aan het archief moet worden toegevoegd. Alleen de blauwe en de witte stappen vereisen dus een actie in het zaaksysteem, maar alle rode stappen hebben geen actie in het zaaksysteem tot gevolg. Deze kunnen door de behandelaar worden uitgevoerd zoals deze dat al jaren gewend is. Veelal met een materiesysteem, uit het hoofd, met een kladpapiertje of in een excelsheet. In plaats van 17 stappen, hoeft de behandelaar slechts vier statuswijzigingen in het zaaksysteem vast te leggen.

Een materiesysteem kan de operationele besturing van het proces ondersteunen, waarbinnen de statuswijzigingen op geautomatiseerde wijze kunnen worden doorgegeven aan het zaaksysteem. Dit voorkomt dubbele registratie door een behandelaar.

Naast het begrip ‘zaak’ zijn binnen de GEMMA ook de onderstaande begrippen gedefinieerd:
1. Zaaktype: generieke aanduiding van de aard van een zaak. Kenmerken van groepen vergelijkbare zaken worden vastgelegd met het ‘zaaktype’. Een zaak behoort altijd tot een zaaktype.
2. Zaaktypencatalogus: de registratie van alle zaaktypen met de bijbehorende kenmerken.

Binnen UWV wordt het begrip zaaktype één-op-één gekoppeld aan een dienst uit de dienstenportfolio die een finale overdracht is naar de externe klant. De naamgeving van een zaaktype is echter niet gelijk aan de naam van de bijbehorende dienst. De uitvoering van een zaak van een bepaald zaaktype bij UWV vindt plaats door middel van de uitvoering van een bedrijfsproces.

Zaakstatus: bij UWV worden de vier standaard statustypen gebruikt met een iets gewijzigde naamgeving:
• <Naam binnengekomen klantvraag> ontvangen.
• <Naam binnengekomen klantvraag> geaccepteerd.
• <Naam binnengekomen klantvraag> in behandeling genomen.
• ...
• <Naam binnengekomen klantvraag> afgehandeld.

De aanvullende statustypen bij ‘...’ zijn deels af te leiden vanuit de klantcontactmomenten. Ieder klantcontactmoment wijzigt de status van de zaak. Daarnaast zijn ook tussentijdse statuswijzigingen mogelijk vanuit de werkprocessen, voor zover dat relevant is vanuit het perspectief van de externe klant.

Voorbeeld Wajong:
• Aanvraag Wajong ontvangen.
• Aanvraag Wajong geaccepteerd.
• Aanvraag Wajong in behandeling genomen.
• Afspraak voor medische beoordeling gemaakt.
• Medische beoordeling plaatsgevonden.
• Medische rapportage verstuurd.
• Afspraak voor arbeidskundige beoordeling gemaakt.
• Arbeidskundige beoordeling plaatsgevonden.
• Arbeidskundige rapportage verstuurd.
• Afspraak voor participatieplan gemaakt.
• Gesprek over participatieplan plaatsgevonden.
• Voorlopig participatieplan verstuurd.
• Commentaar op voorlopig participatieplan ontvangen.
• Participatieplan verstuurd.
• Aanvraag Wajong afgehandeld.

Maximale doorlooptijd: de wettelijke termijn voor de maximaal toegestane doorlooptijd van een zaak is bij UWV opgenomen in de dienstenportfolio. Per dienst is een dienstspecificatie beschikbaar waarin de wettelijke tijdigheid van de levering van de dienst is beschreven.

Het zaaksysteem biedt continue inzicht in de werkelijke doorlooptijd en de deadlines van een zaak zodat het bewaken daarop plaats kan vinden, in dit voorbeeld tellend vanaf de ‘datum ontvangst complete aanvraag’ en de vastgestelde ‘deadline voor de datum verzending beslissing’ (datum ontvangst + 14 weken)

Gewenste maximale doorlooptijd: denk bijvoorbeeld aan ‘beslissing op een aanvraag op grond van de Wet Wajong moet binnen 8 weken na ontvangst van de complete aanvraag zijn verzonden’.

UWV kent verschillende soorten bedrijfsprocessen. Dit zijn minimaal:
• Beoordelen van een aanvraag: dit loopt van aanvraag tot en met beslissing (over recht, hoogte en duur) en eerste betaling van de uitkering.
• Continueren van een uitkering: dit bestaat uit het verzorgen van alle na de aanvraag liggende betalingen van de uitkering.
• Muteren van een uitkering: dit bestaat uit het verwerken van mutaties die mogelijk gevolgen hebben voor de duur en hoogte van een uitkering. In de huidige situatie is er per soort mutatie een apart bedrijfsproces uitgewerkt voor de afhandeling hiervan. Deze bedrijfsprocessen zijn specifiek uitgewerkt per wet (TW, Wajong, WAO, WAZ, WIA, WW en ZW) die UWV uitvoert.

Zoals eerder gesteld kunnen zaken worden opgevat als instanties van bedrijfsprocessen en bestaat er een sterke verwevenheid tussen de begrippen zaaktype, dienst en bedrijfsproces. De hiervoor genoemde bedrijfsprocessen zijn aan elkaar gerelateerd: de continuering is het vervolg van een beoordeling van een aanvraag en mutaties hebben een gevolg voor de continuering. Dit zijn dan gerelateerde zaken.

Het beoordelen van een aanvraag die door een klant is ingediend, is altijd gekoppeld aan de levering van een dienst uit de dienstenportfolio. Voorbeelden hiervan zijn:
• Beslissing toeslag WW, ZW, WAO, WAZ, Wajong en WIA.
• Beslissing arbeids- en of inkomensondersteuning Wet Wajong.
• Beslissing al dan niet toekennen WAZ.
• Nieuw recht en herleving WIA.
• Beslissing nieuw/herleven ontslagwerkloosheid.

Ieder type aanvraag wordt afgehandeld als nieuwe zaak van het zaaktype ‘Behandelen <aanvraagtype>’. Dit wordt als zaak gezien, omdat er sprake is van een hoeveelheid werk die voor de externe klant wordt uitgevoerd, waarvan kwaliteit en doorlooptijd bewaakt moet worden. Elke aanvraag kan leiden tot een recht op een uitkering.

Ook het continueren van een uitkering is altijd gekoppeld aan de levering van een dienst uit de dienstenportfolio. Voorbeelden hiervan zijn:
• Betaling inkomensondersteuning Wet Wajong.
• Betaling uitkering WAO, WAZ, WIA.
• Beslissing continuering ontslagwerkloosheid.
• Beslissing continuering BIA.

Doelstelling van deze diensten is het betalen van de uitkering en een eventuele toeslag op grond van de toeslagenwet, zodat de uitkeringsgerechtigde zo tijdig mogelijk de beschikking heeft over de hem toekomende uitkering. Elke betaling die wordt gedaan wordt in de dienstenportfolio gezien als teleenheid en wordt dus meegeteld in de verantwoordingsrapportages richting de opdrachtgever

Betalingen worden gedaan per wet en, indien van toepassing, voor meerdere rechten tegelijkertijd. De afhandeling van elke betaling vindt plaats als nieuwe zaak van het zaaktype ‘Betalen uitkering <wettype>’. Deze zaak heeft een relatie met één of meer voorgaande aanvraagzaken. Dit wordt als zaak gezien, omdat er sprake is van een hoeveelheid werk die voor de externe klant wordt uitgevoerd, waarvan kwaliteit en doorlooptijd bewaakt moet worden. Voor zaken van dit type geldt dat een beperkt aantal zaakstatussen voor de klant van belang is. Een klant wil graag inzicht in wanneer een uitkering is of nog wordt overgemaakt (de meestgestelde vraag aan het Klantcontactcentrum van UWV).

Voor het muteren van een uitkering geldt dat dit ook altijd gekoppeld is aan de levering van een dienst uit de dienstenportfolio. Voorbeelden hiervan zijn:
• Bestandsbeheer Wajong.
• Bestandsbeheer WAO, WAZ, WIA.
Deze diensten zijn eigenlijk geen echte diensten (finale externe overdrachten), maar representeren een verzameling van diensten die niet expliciet zijn benoemd in de dienstenportfolio. De werkzaamheden die tot bestandsbeheer behoren betreffen onder andere:
• Het verwerken van mutaties m.b.t. adresgegevens, fiscale gegevens en betaalgegevens. 
• Het verwerken van informatie die van betekenis is voor recht, hoogte en duur en het beoordelen of deze informatie leidt tot het in gang zetten van andere beoordelingsprocessen, zoals herzieningen en dergelijke.
• Het verwerken in de betaling van beslagleggingen, eigen bijdrage AWBZ of verzoeken om uitbetaling aan een verpleeginrichting of de gemeente.
• Aanpassen uitkeringshoogte bij de algemene wijziging van de uitkering.

De uitkeringsgerechtigde wordt geïnformeerd over het verwerkt hebben van mutaties. Ieder type mutatie wordt afgehandeld als nieuwe zaak van het zaaktype ‘Behandelen <mutatietype>’. Deze zaak heeft een relatie met één of meer continueringszaken. Dit wordt als zaak gezien, omdat er sprake is van een hoeveelheid werk die voor de externe klant wordt uitgevoerd, waarvan kwaliteit en doorlooptijd bewaakt moet worden.

Bron: Architectuur Informatievoorziening voor Operationele Procesbesturing - Gericht op de sturing van de uitvoering van de bedrijfsprocessen, Egon Willems

In het boek The Service Catalog - a practioner guide beschrijft Mark O'Loughlin hoe binnen ITIL IT-diensten waarde kunnen creëren voor klanten.

Bij ITIL gaat het bij het leveren van IT-diensten om het leveren van waarde voor de klant: de klant staat dus centraal. Volgens ITIL wordt de bedrijfswaarde (business value) van een IT-dienst gecreëerd door een combinatie van de bruikbaarheid van de dienst (service utility, wat de dienst doet) en de zekerheid van de dienst (service warranty; hoe goed de dienst dit doet).

De bruikbaarheid van een dienst wordt ervaren door de klant aan de hand van de kenmerken van de betreffende dienst die een positief effect hebben op de prestaties van taken die verband houden met de gewenste uitkomst. Het wegnemen of verminderen van beperkingen op de prestaties wordt ook opgevat als een positief effect.

De zekerheid van een dienst wordt afgeleid van het positieve effect dat de dienst beschikbaar is als het nodig is, waarbij in voldoende mate beschikbaar is (capaciteit, omvang) en continuïteit en beveiliging is geborgd.

In andere woorden: utility is wat de klant krijgt (fit for purpose) en warranty is hoe het wordt geleverd (fit for use).

Een dienst helpt een klant een bepaald eindresultaat te bereiken. Het realiseren van resultaten kan zijn door het uitvoeren van taken en wordt begrensd door verschillende beperkingen. Een dienst ondersteunt de uitvoering van taken en vermindert de druk van beperkingen.  ITIL stelt dat de waarde die ervaren wordt door de klant afhankelijk is van het ondersteunen van de prestaties van de dienst of het wegnemen van beperkingen die de prestaties van de dienst beïnvloeden en door de verzekering dat de dienst beschikbaar is zoals verwacht, om kan gaan met veranderende eisen (demand requirements) en adequate beveiligingsvoorzieningen heeft.

Pink illustreert het leveren van waarde door het verlenen van IT-diensten binnen ITIL als volgt:

Zie ook: IT-servicemanagement volgens ISM

Bron: The Service Catalog - a practioner guide, Mark O'Loughlin

 

Organisaties zijn doel-realiserende samenwerkingsverbanden. Een organisatie is dus een creatie van mensen voor mensen, die ontstaat als resultante van doelbewust menselijk handelen. Doelbewuste handelingen worden uitgevoerd door de medewerkers van een organisatie. De activiteiten gericht op een specifiek doel heten organisatie- of bedrijfsprocessen.

(...)

De volgende bouwstenen in een organisatie kunnen worden onderscheiden:

1. Organisatiestructuur.

2. Processen.

3. Informatiesystemen.

4. Technische infrastructuur.

 

Bedrijfsprocessen

... In het algemeen geldt dat door middel van processen input wordt omgezet in output, waarbij het de bedoeling is een bepaalde waarde toe te voegen aan een product of dienst ten behoeve van de klant.

(...)

Een bedrijfsproces betreft een gestructureerde en weloverwogen groep van activiteiten zodanig ontworpen om een specifieke prestatie te leveren voor een specifieke klant.

(...)

Een functie is de gewenste bijdrage van een (organisatie)deel aan een groter geheel waar het (organisatie)deel uit van maakt. Een taak betreft datgene wat gebeuren moet of gedaan moet worden, opdat de gewenste bijdrage tot stand komt, zodat de functie wordt vervuld.

(...)

De functie die een organisatie vervult, wordt de primaire functie van een onderneming genoemd. De primaire functie van een organisatie wordt vormgegeven door middel van het strategieformuleringsproces. Door middel van het strategieformuleringsproces wordt het primaire doel van de organisatie immers vastgesteld en verwoord in de missie van een organisatie. De primaire functie van een organisatie kan niet los worden gezien van de omgeving van de organisatie.

(...)

[M]edewerkers van een organisatie zullen belast worden of zijn met de uitvoering van diverse taken met als doel de primaire functie van een organisatie te vervullen. ... Binnen organisaties kunnen vele vormen en type organisatieprocessen worden onderscheiden. Om deze veelheid enigszins te structureren en overzichtelijk te houden is het handig om organisatieprocessen binnen organisaties te groeperen. ... Een zeer veelvoorkomende indeling is die in:

 

1. Primaire processen: processen die gericht zijn op het leveren van een directe bijdrage aan de realisatie van een product of een dienst. Omdat in het bijzonder deze processen zorgen voor de toegevoegde waarde zijn dit feitelijk de belangrijkste processen in de organisatie.

2. Ondersteunende processen: processen die gericht zijn p het 'in stand houden' van de productiefactoren. In feite gaat het om de mensen, de middelen (machines, apparatuur) en de informatievoorziening.

3. Bestuurlijke processen: processen die richting geven aan zowel de primaire als de ondersteunende processen.

 

Informatiesystemen

... Om te waarborgen dat [binnen een proces] de bedoelde activiteiten op het juiste tijdstip, op de juiste plaats, op de juiste wijze en in de juiste samenstelling (samenhang) plaatsvinden, is informatie benodigd. Het is daarom noodzakelijk dat voor elke activiteit inzichtelelijk wordt welke informatie benodigd is om een activiteit (= taak) aan te vangen, welke informatie benodigd is om een activiteit uit te voeren, welke informatie geregistreerd dient te worden, welke informatie verstrekt dient te worden voor de opvolgende activiteiten en welk informatie verstrekt dient te worden voor de interne en externe verantwoording die over de uitvoering van de activiteit dient te worden afgelegd ten behoeve van de oordeelsvorming van het management, met de onderliggende vraag of het beoogde doel (de functie) is gehaald.

Organisaties zullen informatiesystemen gebruiken om de beheersing van de informatiestromen ter ondersteuning van de activiteiten te waarborgen.

 

 

 

In het boek Softwarearchitectuur Overzicht en compendium geven Gert Florijn e.a. een uitleg van de kwaliteitseisen (niet-functionele eisen) die gesteld kunnen worden aan software:

Kwaliteit kan onderverdeel worden in productkwaliteit (de kwaliteit van de software) en proceskwaliteit (de kwaliteit van het ontwikkelproces). In het kader van architecturen verwijzen kwaliteitseisen meestal naar de productkwaliteit.

Conform [ISO9126] wordt softwarekwaliteit gedefinieerd als: een verzameling attributen van een softwareproduct die het mogelijk maken de kwaliteit te beschrijven en te evalueren. Een softwareattribuut kan verfijnd worden tot meerdere niveaus van sub-attributen.

Bij het opstellen van de eisen aan software gaat de aandacht vaak vooral uit naar de functionele eisen: wat moet het systeem doen. Daarnaast wordt er ook wel aandacht besteed aan proceseisen: kan de software snel en goedkoop worden ontwikkeld. Een derde categorie aan eisen betreffen de kwaliteitseisen: zij geven randvoorwaarden aan het (technisch) functioneren van een softwareproduct, bijvoorbeeld rond prestaties en beschikbaarheid.

In 1991 is het ISO9126-model gestandaardiseerd waarin zes kwaliteitseigenschappen werden beschreven:

 

1. Functionaliteit (functionality): een verzameling attributen die van invloed is op de aanwezighed van een set van functies en gespecificeerde eigenschappen.

2. Betrouwbaarheid (reliability): een verzameling attributen die van invloed is op de mate waarin software in staat is te functioneren onder vastgestelde voorwaarden tijdens een vastgestelde periode.

3. Bruikbaarheid (usability): een verzameling attributen die van invloed is op de inspanning benodigd voor het gebruik, en op de individuele beoordeling van dat gebruik, door een vastgestelde of impliciete verzameling gebruikers.

4. Efficiëntie (efficiency): een verzameling attributen die van invloed is op de relatie tussen het performancenvieau van de software en de hoeveelheid gebruikte resources, onder gespecificeerde omstandigheden.

5. Onderhoudbaarheid (maintainability): een verzameling attributen die van invloed is op de inspanning benodigd voor het maken van gespecificeerde wijzigingen.

6. Overdraagbaarheid (portability): een verzameling attributen die van invloed is op de mogelijkheid om de software van de ene omgeving naar een andere omgeving over te dragen.

Onder deze eigenschappen werden 21 subeigenschappen beschreven (als voorbeeld, niet als onderdeel van de standaard) die verder inhoud geven aan bovenstaande begrippen. Tussen 1991 en 1995 is, in het Quint1- en Quint2-project, een uitbreiding (het Quint/Extended ISO9126-model) opgesteld, waarin 32 subeigenschappen worden beschreven (waaronder de 21 van het ISO-model).

De bedoeling is dat er, met behulp van dit model, tijdens de requirementsfase een aantal kwaliteitseisen worden vastgesteld voor het softwareproduct. Dit kan met behulp van interviews, in workshops, door prototypes te evalueren, door vergelijkbare producten te analyseren, enzovoort.

Hieronder volgt een (niet dor ISO geautoriseerde) vertaling van de Engelse termen en definities uit het Quint-model. De onderstreepte begrippen zijn de toevoegingen uit het Quintmodel

Ad (1) Functionaliteit

• Geschiktheid (Suitability)
• Accurraatheid (Accuracy)
• Koppelbaarheid (Interoperability)
• Compliance
• Beveiliging (Security)
• Traceerbaarheid (Traceability)

Ad (2) Betrouwbaarheid

• Volwassenheid (Maturity)
• Fouttolerantie (Fault tolerance)
• Herstelbaarheid (Recoverability)
• Beschikbaarheid (Availability)
• Degradeerbaarheid (Degradability)

Ad (3) Bruikbaarheid

• Begrijpelijkheid (Understandability)
• Leerbaarheid (Learnability)
• Gebruiksgemak (Operability)
• Explicietheid (Explicitness)
• Aanpasbaarheid (Customisability)
• Aantrekkelijkheid (Attractivity)
• Duidelijkheid (Clarity)
• Behulpzaamheid (Helpfulness)
• Gebruiksvriendelijkheid (User-friendliness)

Ad (4) Efficiëntie

• Tijdgedrag (Time behavior)
• Resourcegedrag (Resource behavior)

Ad (5) Onderhoudbaarheid

• Analyseerbaarheid (Analysability)
• Veranderbaarheid (Changeability)
• Stabiliteit (Stability)
• Testbaarheid (Testability)
• Beheerbaarheid (Manageability)
• Herbruikbaarheid (Reusability)

Ad (6) Overdraagbaarheid

• Aanpasbaarheid (Adaptability)
• Installeerbaarheid (Installability)
• Conformance
• Vervangbaarheid (Replaceability)

Bron: Softwarearchitectuur Overzicht en compendium, onder redactie van Gert Florijn

 

In het boek Werken onder architectuur gaan Rob van de Wetering en Gerard van der Zaal in op het begrip informatiearchitectuur en betogen dat de hieronder vallende informatievoorziening té belangrijk is om aan de IT-afdeling over te laten:

Het gebruik van het woord 'architectuur' in bedrijven, dus buiten de context van gebouwen en steden, vindt zijn oorsprong in de IT-wereld. In het begin architectuur gebruikt voor de samenhang tussen de hardwarecomponenten, voor de opbouw van operating systems en in een iets later stadium voor de structuur van computernetwerken. Later pas zijn bedrijven ook de producten, processen en de organisatie vanuit een architectuurperspectief gaan bekijken.

De informatiearchitectuur wordt in de praktijk vaak als de overkoepelende IT-architectuur gezien. Daarmee wordt deze architectuur meteen een specifieke positie toebedeeld: de informatiearchitectuur zou met name voor en door IT-specialisten worden ontwikkeld. In onze visie is dat echter een misvatting om te veronderstellen dat de business hierbij geen directe betrokkenheid zou moeten hebben. [Wij] geven informatiearchitectuur daarom een bredere betekenis. In de informatiearchitectuur wordt de verbinding gelegd tussen de 'zachte' businessaspecten van de informatievoorziening en de 'harde' IT-aspecten daarbinnen. De business moet bij de invulling van de informatiearchitectuur de regie nemen en in de uitwerking moeten de business- en IT-zijde gezamenlijk optrekken.

(...)

De technische infrastructuur wordt vaak als afzonderlijke (IT-)architectuur naast de informatiearchitectuur geplaatst. Voor de business is de technische architectuur zoiets als het leidingwerk en de bedrading voor gas, water en licht in een huishouden: de gebruiker gaat er van uit dat het correct is aangelegd en bemoeit zich niet of nauwelijks met de inrichtingskeuzes die aan de installatie voorafgaan.

(...)

De informatiearchitectuur heeft ... betrekking op de informatievoorziening, de samenstelling van de gegevensarchitectuur en de applicatiearchitectuur, en de relaties daartussen. ... Vanuit de business geredeneerd gaat het in de informatiearchitectuur in de eerste plaats om de opbouw en de functie van de informatievoorziening binnen het bedrijf. De informatievoorziening vervult een ondersteunende rol bij de uitvoering van de processen. In die zin is de informatievoorziening een hulpmiddel, ondergeschikt aan producten, processen en organisatie. In de hedendaagse samenleving krijgt een belangrijk deel van de informatievoorziening vorm via geavanceerde informatietechnologie. Sommige vormen van proces- en organisatie-inrichting zijn zonder specifieke invulling van de informatietechnologie (IT) zelfs niet goed denkbaar. Een adequate inrichting van de informatievoorziening kan randvoorwaardelijk zijn. Tegelijkertijd biedt juist de IT ook nieuwe kansen. Dat geldt voor de proces- en organisatie-inirichting, maar zeker ook voor (de ontwikkeling van) bepaalde categorieën producten. Daardoor is de invloed van de IT en daarmee de invloed van de informatievoorziening op bedrijven erg groot geworden.

Het is begrijpelijk dat informatietechnologie en informatievoorziening in het dagelijkse spraakgebruik als synoniemen door elkaar worden gebruikt. De informatiearchitectuur is het aandachtsgebied van de IT-er geworden. De business wil zich via informatiemanagement nog wel met de planning en prioritering van innovatieve IT-ontwikkeling en de aanschaf van nieuwe systemen bezighouden. Meer inhoudelijke keuzes ten aanzien van de informatiearchitectuur zijn in menig bedrijf aan de IT-afdeling voorbehouden. Dat laatste is geen wenselijke ontwikkeling. In de eerste plaats zijn in bedrijven onderdelen en/of facetten van de informatievoorziening nog geheel of gedeeltelijk zonder IT ingericht. In de tweede plaats is het een misvatting om te denken dat de inrichting van IT alleen de verantwoordelijkheid van de IT-afdeling kan zijn.

De logica van de informatievoorziening en de IT daarbinnen is namelijk medebepalend geworden voor de inrichting van de businessarchitectuur. De business kan het zich daarom niet langer permitteren om zich ten aanzien van de informatievoorziening en de informatiearchitectuur reactief op te stellen. De business moet richting IT 'in the lead' blijven. Zowel via planning als budgettering, als via de inhoudelijke betrokkenheid en strategische besluitvorming. De componenten van de informatiearchitectuur vallen binnen het bereik van de businessarchitectuur. Het is aan de business om wensen en eisen ten aanzien van functionaliteit en performance van de IT kenbaar te maken, en het is aan de IT-ers om de mogelijkheden en onmogelijkheden van IT kenbaar te maken, en het is aan business en IT gezamenlijk om tot een wenselijk en realiseerbaar compromis te komen.

Bron: Werken onder architectuur, Rob van de Wetering en Gerard van der Zaal