Ieder bedrijf is tegenwoordig in meer of mindere mate een it-bedrijf. Neem het it-component weg van een bedrijf en praktisch niet één organisatie functioneert meer. Maar we worden ook steeds meer een leverancier van een it-product of -dienst: Contact zoeken via de website, digitaal kunnen factureren of bestellingen doen op basis van zelfbediening.
Maar denk ook aan het delen van bestanden en samenwerken, of het openstellen van interne gebruikte software middels webservices, zodat derde-partijen bijvoorbeeld zonder tussenkomst van een medewerker een order kunnen plaatsen.
Dit soort initiatieven beginnen klein, maar groeien langzaam uit, waardoor het een belangrijk onderdeel wordt van het onderscheidende vermogen van de organisatie. Omdat er vaak aan het begin van zo’n traject niet nagedacht is over de langere termijn zijn hier een aantal ontwerpprincipes die de levensduur van je diensten kunnen vergroten en het opbouwen van een technische schuld kunnen vermijden.
Wereldwijd
Globaal als uitgangspunt is een opwarmertje. Steeds vaker staan de (virtuele) servers niet in het land waar de organisatie zijn diensten aanbied. Of draait de website ergens anders dan waar de gebruiker de dienst gebruikt. Dit heeft gevolgen als er bijvoorbeeld vastgelegd wordt wanneer welke gebruiker wat doet. Hou altijd rekening met gebruikers en tijdzones. Neem meertaligheid altijd mee in het ontwerp, aangezien later toevoegen vaak lastig is. Dit geldt al bij de website van de organisatie. Naast Nederlands wil je dan ook Engels aan kunnen bieden en een taal achteraf toevoegen leidt tot allemaal uitdagingen.
Multitenant
In het verlengde van meertaligheid: Cloud computing is fundamenteel gericht op het bedienen van meerdere klanten, zonder dat deze bij elkaars data kunnen. Zorg ook dat meerdere klanten naast elkaar kunnen leven in een dienst. Maak iedere versie al vanaf dag één klaar voor multitenancy. Zo maken ontwikkelaars vaak de keuze of iedere klant een eigen database krijgt, of dat er meerdere klanten in één database kunnen bestaan. Zorg juist dat beide scenario’s mogelijk zijn.
Zelfbediening is de basis
De kracht van zelfbediening kan moeilijk overschat worden. Verregaande zelfbediening zorgt voor schaalbaarheid: Meer klanten kunnen bedienen met minder eigen arbeid op tijdstippen die de klant het beste uit komt. Zelfbediening betekent ook dat de organisatie de automatisering onder controle heeft en een mate van volwassenheid bereikt heeft. Zelfbediening is vaak complexer dan het lijkt. Meerdere disciplines van software defined tot en met ‘user experience’ en interactief ontwerp komen eraan te pas en ook de infrastructuur moet het aankunnen.
Alle communicatie over webservices
Webservices zijn interfaces tussen apparaten/applicaties over het netwerk en worden ook wel eens aangeduid als application programming interface (api). Webservices praten in de regel over http- of https-verbindingen en dat heeft als voordeel dat ze niet gebonden zijn aan specifieke besturingssystemen, programmeertalen of protocollen. Het voordeel is dat een webservice in zichzelf kan bestaan en functioneren, maar ook met alles en iedereen kan communiceren. Ik ben er groot voorstander van dat alle applicaties alleen maar communiceren door middel van webservices, zelfs in een client/server scenario. Met andere woorden: Een applicatie heeft geen directe verbinding meer met de database, maar haalt zijn data en business-logica uit de webservice laag. De voordelen zijn immens, maar er zijn ook nadelen. Als extra tussenlaag kost dit performance en latency en het is makkelijk om een spaghetti aan koppelingen te maken, waardoor een oerwoud ontstaat.
Identity and access management
Gelukkig is hiervoor het ontwerpprincipe ‘Eén identity and access management (iam)’. Alle toegang tot data wordt geauthenticeerd over één kanaal. De autorisatie zelf vindt binnen de applicatie of service zelf plaats. Voordelen is centraal beheer, maar ook toegang en inzicht in datastromen, wat leidt tot meer veiligheid, betere controle en eenvoudiger regie voeren. Iam is zelf in feite ook een webservice.
Iedere gebruiker die toegang wil tot iets moet dus geïdentificeerd worden door de iam en je kunt ook instellen tot wat een gebruiker toegang heeft. Uiteraard geldt wel: Als je software maakt voor anderen moet het aansluiten op zo veel mogelijk iam-systemen. Saml lijkt overigens in een rap tempo de winnende verbindende taal te worden die iam-systemen spreken.
Iam zit echt in de lift, steeds meer cloud aanbieders maken dit onderdeel van hun dienstverlening en de complexiteit om het toe te passen neemt snel af. Vooral grotere organisaties hebben veel baat bij IAM om te kunnen voldoen aan compliance en als onderdeel van governance.
Separation of concerns
Kun je het ene onderdeel los gebruiken van het andere onderdeel? Door verantwoordelijkheid en logica goed te scheiden worden de life-cycles van oplossingen langer. Afhankelijkheden zorgen voor allerlei problemen. Als data corrupt raakt in een bepaald deel en deze heeft ook afhankelijkheden in de keten, dan kan er niet zonder na te denken een backup teruggezet worden. Nu is het functioneel gescheiden van ‘concerns’ niet altijd makkelijk. Als er bijvoorbeeld een service is die scans in leest, dan wil je dit gescheiden houden van het workflow systeem wat iets met die scans doet. Het scannen kan dan ook voor meerdere doeleinden gebruikt worden.
De praktijk
Ik kom bij veel verschillende soorten bedrijven waaronder software-ontwikkelaars. Ik ben nog geen oplossing tegengekomen die al deze principes hanteert en ik heb wel vaak software gezien die aan geen enkel genoemd ontwerpprincipe voldeed. Wat ik mooi vind aan deze principes is dat ze heel goed te toetsen zijn. Er kan een checklist van gemaakt worden. Het zijn een soort standaard terugkerende requirements.
Deze principes leiden naar schaalbare oplossingen met een lange levensduur. Hiermee wordt een platform gerealiseerd waaraan ook andere partijen waarde kunnen toevoegen en dit zorgt weer voor een ander bij-effect: Kijk bijvoorbeeld eens naar de dominante positie van Apple en Android. Zij hebben een platform gebouwd en daarop is een heel ecosysteem ontstaan. Dit is de reden waarom Microsoft het moeilijk heeft een groot marktaandeel te veroveren. Je kunt de principes van een systeem kopiëren, maar niet het gehele ecosysteem, al sla je daar miljarden op stuk.
Uiteraard is dit slechts een algemene greep uit de ontwerpprincipes die ik hanteer. Welke principes hanteer jij? In de reacties kunnen we zo een opbouwende discussie voeren.
Dag Jack,
“Ben het met je eens dat ICT en architectuur onderbelicht zijn in de visie van Henri.”
Bedoel je mijn visie, of de visie in deze opinie?
Ik zal dit artikel toelichten, hopelijk kan ik daarmee je mening wellicht een stukje bijsturen.
Allereerst vind ik het belangrijk om een leesbaar artikel te schrijven wat te consumeren is voor een groot deel uit de IT doelgroep. Van programmeur tot CIO, en uiteraard kun je dan niet de diepte in. Om de grootste alinea in je reactie als voorbeeld te nemen: Ik denk dat minimaal 95% van de Computable lezers -en dan ben ik voorzichtig- niet begrijpt wat jij probeert duidelijk te maken. Nu is het mijn absolute overtuiging dat als je ingewikkelde filosofische principes niet aan een grote groep kunt uitleggen je opbrengst zeer gering is. Maar goed, nu naar mijn artikel inhoud.
Wat is de opbrengst van goede ict architectuur? Mits goed gecommunicieerd (the ability to execute) dan bereik je duurzaamheid, veiligheid, veerkrachtigheid, besparingen door lagere technische schuld, en hopelijk ook een stukje wendbaarheid, maar dat is een subset van duurzaamheid.
Als je dan deze ontwerpprincipes nog eens bekijkt; ontwerp voor cloud, bedienen van meerdere klanten in een omgeving, zelfbediening, service georiënteerd, centrale identiteit en toegangscontrole, dan raakt dit ineens wel de kern van goede ict architectuur.
De ontwerpprincipes zijn zoals dat heet “loosely coupled” met de it architectuur. Je kunt je aan de principes houden zonder overkoepelende architectuur, waarbij je *waarschijnlijk* de voordelen behaald die ik eerder aanhaalde in deze reactie op de vraag wat goede architectuur opbrengt.
Om heel eerlijk te zijn: Ontwerpprincipes zijn veel beter te consumeren dan architectuur, omdat architectuur zich vooral richt op structuur en ontwerpprincipes op gedrag. Als je ze kunt combineren is dat geweldig en ik zal het zeker aanraden. Maar als de architectuur ontbreekt dan heb je in ieder geval je principes nog 🙂
Dat ICT onderbelicht is in mijn visie of artikel kan ik niet plaatsen. Misschien bedoel je dat het “te hoog over” is en te weinig technische details. Die kan ik wel geven, maar dan kom ik weer terug op mijn eerste deel van de reactie: Daarmee wordt de doelgroep te nauw. En aangezien de brug tussen IT en de business nu juist mijn stokpaardje is, wijk ik daar hier op deze site niet snel vanaf.
Enne BRM/BPM/SOA et cetera gaat sec genomen ook niet over ICT. ICT is dan slechts de implementatie.
Kun je wat met mijn reactie?
Henri,
Dank voor de zorgvuldige toelichting op je standpunt!
Een discussie tussen ons is lastig omdat je nogal vaak begrippen gebruikt die ik liever vermijd; dit
vanwege jouw wetenschappelijke instelling versus mijn filosofische instelling.
Waar jij nog rustig spreekt over:
data, logica, processen, systemen, structuur en gedrag,
daar spreek ik veel liever over:
objecten, functionaliteit, diensten, applicaties, architectuur en (menselijk) handelen.
Als je stelt:
“..als de architectuur ontbreekt dan heb je in ieder geval je principes nog”.
dan zeg ik:
“..als de architectuur ontbreekt dan ben je er niet; laat staan dat je dan nog principes hebt”.
Jij plukt je principes, rijp en groen, zo uit de lucht 🙂
Architectuurprincipes zijn noodzakelijk, want zonder deze ben ik er niet; van mijn eigen principes (bijvoorbeeld: thuis geen vlees eten) kan ik afwijken.
Neemt niet weg dat je in voorgaande reactie zeer rake en interessante opmerkingen maakt. Met name je koppeling ontwerpprincipes en gedrag – menselijk handelen dus – is boeiend. In hoeverre kan een mens zijn levensstijl ontwikkelen/ontwerpen op basis van zijn principes? Hoe krijgen we verbinding tussen globaal (=wereldwijd) denken en lokaal handelen?