Artikel

Leidt standaardisatie tot meer hergebruik? - deel 2

Wat is het voordeel van standaarden en hoe moet je er mee omgaan als organisatie? Als je inzoomt op standaarden dan kun je verschil maken in soorten standaarden. Ook dien je als organisatie de standaarden te selecteren die passen bij de grootte van de organisatie. Deze onderwerpen komen terug in deel 2 van dit artikel.

Problemen binnen de onderneming met verticale standaardisatie

Helaas kunnen we niet veel mooie voorbeelden van standaardisatie en hergebruik geven voor software en hardware binnen de ICT. Als je van twee verschillende softwareleveranciers een stuk software aanschaft dat in dezelfde programmeertaal is geschreven en met dezelfde technologie communiceert, is er absoluut geen garantie dat de twee stukken software met elkaar kunnen communiceren. Voor software is er wel horizontale standaardisatie, maar bijna geen verticale standaardisatie. Op het niveau van netwerken en applicatie-communicatietechnologiën zijn er wel standaarden zoals het TCP-IP protocol en XML-standaard, maar de inhoudelijke specificatiestandaarden voor berichtenverkeer die gebruik maken van XML zijn er nog niet of zijn nog volop in ontwikkeling.

StUF, een mooi voorbeeld

StUF (Standaard Uitwisselings Formaat) is de XML-ketenstandaard voor het elektronisch uitwisselen van gegevens binnen gemeenten en in de ketens waarin gemeenten participeren. StUF definieert uit welke attributen de objecten bestaan die samen de basisgegevens vormen zoals adressen en gebouwen. Ook wordt de mogelijkheid geboden om niet-standaard informatie binnen StUF met elkaar uit te wisselen. StUF is aangewezen als standaard voor overheidsinstellingen, maar is echter nog volop in ontwikkeling. Jaarlijks verschijnt er nog een nieuwe versie. Je moet er overigens niet aan denken dat elektronica fabrikanten elk jaar met nieuwe netsnoeren op de markt komen en dat je in huis wel tien verschillende soorten stopcontacten hebt. Momenteel schakelen we over van StUF 2.04 naar 3.01. Applicaties die met de ene versie van StUF kunnen werken, kunnen lang niet altijd met de ander versie van StUF werken. Het voordeel van StUF staat echter buiten kijf: applicaties kunnen in de nabije toekomst beter en meer binnen en over organisaties worden hergebruikt. ‘Door het gebruik van de vernieuwde StUF standaard kunnen kosten worden bespaard door toenemende technische en semantische interoperabiliteit’ (bron: www.egem-iteams.nl).

StUF is een voorbeeld van standaardisatie die mogelijk uiteindelijk zal leiden tot meer hergebruik van applicaties en services in organisaties. De berichten-specificatiestandaard maakt het mogelijk om standaard StUF-behandel- en verwerkingdiensten (services) met een applicatie (dienstverlener) te gaan aanbieden. Randvoorwaarde is wel dat de StUF enigszins stabiel gaat worden.

Eén leveranciersgedachte, een utopie

Verschillende instellingen en organisaties werken met het principe ‘door alle ICT-oplossingen van één leverancier af te nemen, werken alle ICT-oplossingen optimaal met elkaar samen. Hoe anders is de praktijk: geen enkele ICT-leverancier ter wereld kan alle oplossingen leveren. Als je als afnemer relatief klein bent op de markt, heb je ook nog eens weinig te eisen van de leveranciers. Dit mondt allemaal vaak uit in dat alles van een zelfde leverancier zeer goed samenwerkt als één geheel. Bijvoorbeeld één integrale database. Alles wat aan moet sluiten op een familie van oplossingen van een leverancier werkt doorgaans  zeer slecht met elkaar samen. Dit komt vaak doordat de integratie van de deeloplossingen niet is gedaan op basis van open standaarden, maar op basis van een interne (propietary) leveranciers standaard. Op dit punt zijn architecten van zeer grootte waarde voor een eindgbruikersorganisatie. Zorg ervoor dat de organisatie in haar architectuur geen producten of technologieën, maar open standaarden heeft als stijl-elementen. Dat maakt onafhankelijkheid richting leveranciers zo optimaal mogelijk. Voor kleine organisaties is dit van levensbelang om de regie over de eigen ICT-omgeving te blijven houden.

Het nadeel en gevaar van jonge standaarden

In de ICT is er een opmerkelijk fenomeen: jonge innovatieve aanpakken en methoden adopteren als zijnde dé standaard. Eindgebruikersorganisaties verwachten van een standaard namelijk een bepaalde volwassenheid, prestaties en kwaliteit. Maar hoe goed de bedoelingen meestal ook zijn, een beloftevolle innovatieve aanpak is meestal nog lang geen rotsvaste standaard. Al was het alleen maar om de vele nieuwe versies die in de eerste jaren opnieuw worden uitgebracht van de standaard.

Ook zien we vaak dat ICT-producten of ICT-diensten open standaarden bevatten die dan een klein beetje worden uitgebreid naar een dialect. De gebruiker van de dienst of het product denkt dat er van een standaard gebruikt wordt gemaakt, maar in feite maakt de gebruiker gebruik van een dialect en wordt er toch een onnodige en ongewenste afhankelijkheid naar een leverancier toe gecreëerd (customer lock-in heet dit in vaktermen). Een voorbeeld hiervan is SQL, de standaard vraagtaal voor databases. Ansi 2 SQL is een open standaard die door Sybase, IBM, Oracle en Microsoft is uitgebreid naar SQL-dialecten voor hun databases. Dit maakt al snel dat applicaties onnodig vastzitten aan één van deze leveranciers.

Wat kan de architect bijdragen aan meer hergebruik door standaardisatie?

De architect doet er goed aan om een overzicht te maken van de producten, oplossingen, technologieën, concepten, aanpakken en methoden die in een organisatie gebruikt worden.
Door met een overzicht in beeld te brengen hoe jong of oud bepaalde oplossingen zijn, in welke mate iets een open standaard is, hoe wijdverbreid het  gebruik is en hoe iets juist gekoppeld is aan één enkele standaard, krijgt de directie inzicht waar weerstand bij innovatie zal zitten of probleemgebieden bij integratie en samenwerking. Ook krijgt men dan zicht op waar men bewust verantwoord innovatief risico neemt en waar men een behoudende koers vaart.

De architect kan met visualisaties verschillende scenario’s uitwerken door principes te laten gaan gelden (op papier) voor de organisatie. Een voorbeeld van een dergelijk principe dat kan worden gebruikt in een scenario is : “door open standaarden te eisen van leveranciers in ICT-oplossingen, minimaliseren we de afhankelijkheid naar leveranciers toe en halveren we het benodigde IT-budget.“ Een enterprise principe voor een ander scenario is “door inkoop van diensten vanuit een regiemodel, optimaliseren we de wendbaarheid van de organisatie”. Een derde (hypothetisch) principe dat veel architecten eens zouden moeten uitwerken is: “door het ontdubbelen van generieke functies in applicaties en generieke gegevens in databases, decimeert het aantal benodigde applicaties en databases.”

Om de voordelen van standaarden te benutten dienen ze op een bepaald volwassenheidsniveau in de organisatie te worden gebruikt. Elke oplossing, aanpak of methode staat of valt bij de gratie van goed gebruik door gebruikers. De architect heeft hier als taak om te laten zien dat er eigenlijk geen pure ICT-projecten of business-projecten bestaan. Elk verandering in een organisatie heeft altijd human resources-, tijds-, financiële-, informatie- en technologie componenten in zich.

In visualisaties kan de architect goed naar voren laten komen hoe dubbele oplossingen voor dezelfde vraagstukken onnodig transformatietijd en -geld kosten. Aan de andere kant moet de architect ook wel duidelijk maken hoe het handhaven van spelregels bij het inkoopproces en toezicht van belang zijn om ICT-oplossingen herbruikbaar te houden. Want als niets erop aansluit, wat heb je dan aan je standaard?

Categorie:   
Auteur(s)
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.