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.
@ewout: alleen al in de 2 reacties hierboven tel ik Henri, Elias, ZZP’ers, Cloud, NIST, VVD en Schippers die het moeten ontgelden. Prima natuurlijk om, ook scherp, te reageren als je het ergens niet mee eens bent. Maar het schiet niet op als je van iedereen die een afwijkende mening heeft zegt dat ie het niet snapt of zelfs dat ie niet deugt.
@Ad
Ik probeer zoveel mogelijk de naam van Henri te voorkomen, zo gebruik ik ook omschrijvende termen als: Luke Skywalker van de cloud, Zonnekoning Zonder Princpes, Droogstoppel, dr Jykell en mr Hyde enzovoort.
Niet veel anders dan wat de auteur doet want als het kwaakt als een eend, het waggelt als een eend en het ziet er uit als een eend dan kun je de term eend proberen te vermijden maar dat is gewoon net als die andere van (Sp)eijk waar opinie met minder of meer dezelfde strekking komt, mijn cloud principes zijn goed en die van alle anderen fout.
Zou het toeval zijn dat deze – controleerbaar via datum/tijd – na mijn reactie kwam want ik citeer vooral uit het werk van gevraagde klokkenluiders, de hele sterrenslag op dit platform bewijst dat meeste liever met vingers in de oren roepen dat het allemaal niet waar is.
Sorry Ad, maar een ad hominem kan ik ook maken want je profiel lezend heb ik wel enige vragen omdat de meeste ZZP-ers als de notarissen in DigiNotar case zijn, terwijl systeem aantoonbaar lek was procederen om het te continueren.
Wie de bal kaatst kan deze terug verwachten:
Hoe ga je een kruiwagen vol met kikkers – SOA volgens ZZP-ers – onder controle houden als je vooruit wilt?
De ‘separation of concern’ in principes van de auteur om even een sprongetje naar mijn obscure vergelijking met de VVD in het algemeen en Schippers in het bijzonder te maken gaat om verbind de puntjes, kleur het plaatje en maak het verhaaltje af;-)
Dag Henri,
Mooie opzet, jammer dat je niet een architectuur opzet kiest voor principes.
Dus de naam van het principe, het statement, de rationale en de complicaties. Dan krijg je een minder wollig verhaal.
In het engels zou het ook krachtiger klinken:
– Multi-language
– Multi-tenant
– Selfservice
– Service oriented
De volgende logische zaken zouden toegevoegd kunnen worden en zijn generiek:
– Secure by design
– Elastic
– On-demand
– Pay per use
– Building block based
Volgens mij zijn er wel 10 basisprincipes te bedenken.
Het artikel lijkt wel heel erg te zijn geschreven vanuit de technische “eisen” voor de inzet van XaaS-achtige bij grotere, internationaal opererende organisaties. Waarbij de vestigingen in de verschillende landen (min-of-meer) zelfstandig opererende entiteiten zijn. Bijvoorbeeld als onderdeel van een franchising formule.
Maar zelfs als het inderdaad geschreven is vanuit startende, commerciële bedrijven, dan waag ik het te betwijfelen of rekening houden met de genoemde aspecten nou echt gaat helpen. Zelfs al zouden die bedrijven de potentie hebben door te groeien naar een internationaal opererend bedrijf, dan nog duurt het de nodige jaren voor je daar bent. In de tussentijd is de organisatie in zijn bedrijfsvoering al meerdere keren over de kop gegaan.
Immers, al groeiende naar een internationaal opererende organisatie krijg je eerst heel andere vraagstukken voor je kiezen.
Denk bijvoorbeeld eens aan de processen rondom marketing, verkoop en levering. Ga je wereldwijd overal precies hetzelfde doen? En hoe dwing je dat dan af? Blijf je dit ook doen op langere termijn?
Een van de alternatieven is dat er per regio of land een iets ander smaakje van gemaakt wordt al naar gelang lokale gebruiken en culturen?
De bemensing van een dergelijke groei is ook zoiets. Ga je op zoek naar lokale partijen om mee samen te werken? Doe je een aantal overnames? Of ga je e.e.a. van de grond af aan opbouwen door zelf mensen aan te nemen?
Kortom, IT diensten en producten vanaf dag 1 zodanig ontwerpen dat die varianten allemaal gefaciliteerd kunnen worden? Ik geloof er niet in. De aanloopkosten zouden enorm zijn terwijl het nog maar zeer de vraag is of die voorinvestering uiteindelijk ook rendeert.
Dag Willem,
Architectuur staan in mijn ogen los van principes. Je voorgestelde opzet is wel krachtiger, en wollig taalgebruik moet ik wat meer leren te vermijden, daarbij houdt ik wel van een verhaal en wordt een opsomming wat saai. Beide hebben hun eigen publiek en doel. Maar thanks voor de suggestie!
Secure by design stond ook hoog op mijn lijstje in dit artikel: Ieder element de keten moet in principe zelfstandig een vorm van veiligheid bezitten. Berichten in transit en rust minimaal versteuteld, wachtwoorden met zout, tokens sessie specifiek en eindig in tijd, et cetera. Maar ik heb ervoor gekozen om slecht een paar principes in een eerste artikel te plaatsen. Maar je aanvulling staat zeker op mijn netvlies!
Will: Deze principes hebben inderdaad een technische inslag, maar zijn absoluut geen eisen; meer slimme suggesties. Overigens denk je veel te groot en -mijn inziens- te moeilijk! Stel je voor dat je instructies moet geven aan chaffeurs voor een poort. Dan praat je over één locatie, maar de bestuurders kunnen wel uit 20 verschillende landen komen! Als verder een dienst hebt (as a service) die je start in Nederland, maar ook elders relevant kan zijn, dan zit je al met twee talen (Nederlands en Engels). Dus meertaligheid is zeker geen overbodige “aanloopkosten”.
Ook met je ” processen rondom marketing, verkoop en levering. Ga je wereldwijd overal precies hetzelfde doen?” maak je het te groot.
De door mij genoemde principes -en nogmaals-; dit is geen uitputtende lijst, verre van, zijn juist heel erg simpel te implementeren. En als je deze achteraf moet toevoegen, dan heb je een probleem en dat is *wel* architectuur waar Willem op wijst.
Eén van de eerste zaken die ik -zonder uitzondering- doe als ik ergens mee aan de slag ga is het beschrijven van het domein. Ik noem dat DDD en is ook één van mijn principes van de categorie architectuur. Zo’n domein beschrijving is een *niet* technische beschrijving van het domein van de klant of branche. Als je een school als voorbeeld pakt heb je dus; leraren, personeel, studenten & ouders (welke alle personen zijn). Locaties, klassen, agenda’s en roosters. Vakken, competenties, semesters, et cetera. Je beschrijft de relaties, acties, input, output. Als zo’n domein vorm begint te krijgen kun je ontwerpbeslissingen nemen. Alles wat je bouwt en aansluit op dat domein, klopt en heeft een lange levensduur. Samen met de lijst aan hanteerbare principes + architectuur zit dan gewoon goed in elkaar. Als je hier handig in bent is dit zeer waardevol gereedschap waar je moeilijk mee de mist in kan gaan. Maar goed, nu ga ik weer helemaal los! Als je het over passie hebt, kun je dit er denk ik wel onder scharen.
Nu ga ik omkleden, ik moet naar een feestje 🙂
@Henri
Bedankt voor de uitgebreide toelichting. Het lijkt erop dat de intro van het artikel in combinatie met “Wereldwijd” en “Multitenant” me op het verkeerde been hebben gezet.
Eigenlijk is er natuurlijk maar 1 ontwerp principe. Het systeem moet doen wat de klant wil tegen een prijs die de klant bepaalt. Misschien wil die bijvoorbeeld gewoon een docje downloadbaar maken voor anonieme gebruikers. Multitenancy met IAM en andere opwarmertjes lijken me dan bijv wat overdreven 🙂
Maar cloud is jouw feestje en ik kan me voorstellen dat je als consultant maling hebt aan pavakes stelling dat ‘de’ niet bestaat in ict.
De cloud met jouw ontwerpprincipes is dan altijd het antwoord op de vraag van de klant.
Felix, één van de eerste terugvragen die ik stel als een klant het heeft over klant focus is; “Wie is je klant?”. Je zult je verbazen over hoeveel discussie er dan ontstaat. Een leuke vervolgvraag is dan hoeveel klanten een klant heeft….
Uiteraard moet je nadenken over welke principes wel en niet nodig zijn.
En wat DE betreft; ook wel “The” in het engels. Dan vraag ik me af of ik nu contact heb met DE kat die Felix heet 😉
Ach, als cloud niet het antwoord is, dan noem ik het snel private cloud…
@Henri
Dat Felix zich in eigen reactie al tegenspreekt, het zijn namelijk 2 principes waarover hij het heeft bij de functionaliteit en prijs, moet je niet gaan ‘downplayen’ door te beginnen over de klant van de klant.
@Felix,
Verwar je hier niet requirements met architectuurprincipes?
Blijft natuurlijk de interessante vraag hoe deze zich tot elkaar verhouden.
Als we de vraag naar het verschil tussen architectuurprincipes en requirements opvatten als de vraag naar de verhouding tussen ICT en de business, dan hebben we een stevig probleem als we deze los van elkaar zien. Daarom zou ik stellen: architectuurprincipes vormen de architecturale randvoorwaarden waarbinnen requirements kunnen worden getoetst en gerealiseerd. ICT maakt dus de business mogelijk die op haar beurt de dienstverlening aan de klant mogelijk maakt. Vanuit de business worden ict-diensten steeds meer als enabler van klantproducten verwacht. Zodoende kunnen de architectuurprincipes ook mogelijkheidsvoorwaarden worden genoemd.
Ben het met je eens dat ICT en architectuur onderbelicht zijn in de visie van Henri.