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.
Lekker kort en krachtig geformuleerd wat jouw belangrijkste principes zijn (waarbij ik me van harte aansluit). Op je vraag welke principes vooral belangrijk zijn pik ik uit jouw lijstje de “Separation of concerns” die ik dan veralgemeniseer tot “service-oriëntatie”. Wat mij betreft iets waarvan enkele principes die je noemt (deels) zijn afgeleid (services, api’s, zelfbediening, iam). Om nog een nieuwe aan te vullen wil ik het uitgangsgpunt “Geschiktheid” toevoegen: bepaal altijd zorgvuldig binnen de eigen context wat geschikt is (ipv wat ‘het beste’ is). Uiteraard door goed te luisteren naar wat je organisatie wil bereiken, maar ook door bijv. rekening te houden met het volwassenheidsniveau op verschillende gebieden.
Opmerking: ik snap wat je bedoelt, maar dat je met httP(s) niet meer gebonden zou zijn aan een specifiek Protocol zie ik als slip-of-the-pen 😉
Hey Ad, haha, dat http en protocol, hmm, uhm, ja, dat was een slip-of-the-pen.
Het zijn een aantal principes, en er zijn er nog veel meer in vele dimensies. Geschiktheid is een goede met een lastiger te omschrijven context. Past het bij je techniek? Past het bij je organisatie? Past het bij je doelgroep? Past het bij het eco-systeem? Het onderwerp alleen al is een time-sink in zichzelf 🙂
Alvast bedankt voor je snelle aanvulling!
Henri,
Ik wil even terug komen op wat punten:
Wereldwijd:
Servers bestaan uit data. Zonder data zijn servers nutteloos en vice versa. Het is ook goed om te weten waar je data landt. En of dit conform en aansluit op de regelgeving waar je aan moet voldoen.
Beschikbaarheid:
Ik lees niet veel over beschikbaarheid. Dit lijkt mij toch een essentieel onderdeel van de ontwerpprincipes. Je wilt er toch zeker van zijn dat de dienst die je aanbiedt beschikbaar is, en dat SLA’s geborgt zijn. Hier moet je tijdens het ontwerp ( lees kiezen van aanbieder ) toch echt wel rekening mee houden. Je moet er natuurlijk niet aandenken dat je bestellingen of factuurs kwijt raak.
Ik zal het niet hebben over RPO’s/RTO’s, bandbreedte en IOPS want die discussie hebben we al te vaak gevoerd. Maar de technologie van het aangeboden cloudplatform moet natuurlijk wel genoeg snelheid bieden en geen beperkingen opleveren. Want gaat dan ten koste van het succes van je dienst.
Je haalt best leuke punten aan, maar je vergeet in mijn optiek toch wel enkele essentiele zaken. Ik heb zo een idee dat dit wel weer een leuke discussie gaat opleveren.
Hey Ruud,
In deze opinie pak een zeer kleine greep aan ontwerpprincipes. Ik heb er namelijk meer dan honderd! Uiteraard moet je ontwerpen op beschikbaarheid (redundantie en fail-over), en ik geef ook niet aan welke de belangrijkste is en welke nice-to-have. Daarnaast -en dat levert veel discussie op- zijn er allemaal deelgebieden te benoemen. Gaat het over de software ontwikkeling principes? Infrastructuur principes? Transactionele principes, compliance principes, wetgeving? Beveiliging? et cetera. Het spectrum is *immens* en jouw suggesties horen daar uiteraard bij!
Waar je data landt is niet per se een ontwerpprincipe -het staat los van het ontwerp-. Een ontwerpprincipe zou kunnen zijn dat je bouwt volgens de wetgeving van een bepaald land of branch.
De ontwerpprincipes uit dit stuk; global, multitenant, selfservice, service oriented, for IAM, zijn opwarmertjes en goede generieke vertrekpunten.
Jij voegt er nu dus twee aan toe: Ontwerp voor beschikbaarheid, en ontwerp voor wetgeving/compliance. Thanks!
Henri,
Dank voor je heldere uitleg. Dit zal mogelijke onduidelijkheid in de rest van de discussie voorkomen.
Waar voor dank!
Henri,
[…] steeds meer cloud aanbieders maken dit onderdeel van hun dienstverlening en de complexiteit om het toe te passen neemt snel af (je had het over IAM) […]
Kijk uit voor addertje onder het gras! Dit punt heb ik in mijn artikel “I AM in de Cloud” besproken.
Reza, heel terecht. IAM is iets wat je zelf onder controle wilt hebben, en uitbesteden is een behoorlijk ingrijpende stap, vandaar dat ik hem ook tot ontwerpprincipe verhef. Maar als jouw dienst dus een onderdeel word in een keten die organisatie overstijgend is, dan is het dus raadzaam om te zorgen dat je oplossing goed te koppelen is aan diverse IAM’s. Dit zal de acceptatie vergroten en voor veel andere partijen een bezwaar wegnemen. Het is dus een verkoopargument waarmee je compliant bent naar ja afnemer toe. Je zorgt er in feite voor dat jouw dienstverlening niet debet is aan het mogelijke oerwoud van de klant.
De Luke Skywalker van ’the force of selfservice is with you’ heeft duidelijk geen ontwerpprincipes maar prutst gewoon wat aan. Al 20 jaar lang en daardoor heeft de sector ook zo’n slechte naam gekregen want ontwerpen vanuit de mogelijkheden van techniek in plaats van de capaciteit van een organisatie is precies waar het telkens misgaat. In aanvullende reactie zeggen dat je wel 100 principes hebt doet denken aan Ton Elias, even opportuun. Ik heb veel minder basisprincipes, eigenlijk maar 3 waar je echter telkens maar 2 van kunt kiezen:
1. Betrouwbaar
2. Snel
3. Goedkoop
Zo kun je kiezen voor snel en betrouwbaar maar dan is het niet goedkoop en vice versa geldt dat als je het goedkoop en snel wilt dan is het niet betrouwbaar. Dat je bij uitwerking van die simpele
principes honderden tot duizenden keuzen hebt is weer een ander verhaal. Betreffende aanvulling ‘geschiktheid’ van de andere ZZP-er wil ik graag even wijzen op een algemeen geaccepteerde definitie van SOA:
“A service-oriented architecture can be defined as a way of designing and implementing enterprise applications that deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services).”
Webservices zijn niet per definitie een invulling van SOA, net als dat de keus voor zo’n architectuur niet altijd geschikt is. Wie enige ervaring heeft met de governance van SOA architecturen weet dat hier ook geen combinatie van betrouwbaar, snel en goedkoop mogelijk is. Dat plaatst opmerking dat je geen ecosysteem kunt kopiëeren al sla je er miljarden op stuk in deze verder waardeloze opinie mogelijk in de juiste context. Tenslotte draait nog een groot aantal kritische IT services op ouderwetse mainframes welke misschien niet goedkoop zijn maar ook weer geen miljarden kosten want je hoeft het Internet tenslotte niet na te bouwen binnen je eigen datacenter.
Helaas vergeten meeste SOA verkoper dit nog weleens, roepen dat je Enterprise applicaties ontwerpt maar niet verder komt dan het toefje op de taart, een Apple of Android device dus. Dat is dus Nederland ICT op zijn best want zoals ik in inleiding al noemde is de organisatorische capaciteit hier in grote mate bepalend, grensoverschrijdende bedrijvigheid (Enterprise) gaat niet alleen om taal want veel lastiger zijn alle verschillende wetten:
“Cloud services brings jurisdiction and regulation considerations, which can directly influence the way in which DATA is managed and governed, in addition to raising issues concerning liability, enforcement, and compensation”
Maar ja, auteur die mijn opinie over data obscuur vindt terwijl dat de kroonjuwelen zijn van menige organisatie zal niets van mijn basisprincipes begrijpen. Die heeft tijdens Cloud Architecten Aliance alleen de voeding genoten en de ‘op’ gemist. Voordat alle ZZP-ers met onthechtingsproblemen van oude kunstjes me weer één gele ster opplakken lees nu eens goed wat er allemaal al geschreven is over aspect data, want lifecycle van een mens ligt ergens rond de 90 jaar, reken nu eens uit wat dat betekent voor de kosten van privacy:
“Privacy governance around the world has evolved around two competing models. Europe made some rights of individuals inalienable and assigned responsibilities to Data Controller organizations, whereas in the United States companies inserted waivers of rights into Terms and Conditions contracts allowing exploitation of data in exhaustive ways known as the ‘Notice and Choice’ principle.”
Deze informatie komt uit beleidsstuk, niet een marketingfolder en geeft het gevaar aan van ‘selfservice’ als het om de cloudoplossingen van auteur (en overheid) gaat. In de voorgaande opinie noemde ik dat cryptisch het verschil tussen metrieke en imperiale stelsel want het is niet mijn taak om Elias wijzer te maken. Dat laat ik graag aan schreeuwlelijk van Gockham groep over die vrij juist was in constatering dat MRS systeem – zoals veel oplossingen bij de overheid – niet strookt met basisprincipe betrouwbaar als het om persoonsgegevens gaat. Maar ja, ZZP-ers die al 20 jaar hetzelfde kunstje doen houden dan ook geen rekening met wijzigingen in wetgeving, laat staan internationaal.
Voor een aantal multinationals, grensoverschrijdende bedrijven dus die met name door SOA principes nog niet echt als een Enterprise functioneren heb ik uitdaging geschetst in één plaatje. Deze laat vooral het verschil zien tussen het jaren 90 denken in IT oplossingen (Raines’ Rules van uitbesteding) en de huidige business uitkomsten als je processen niet op orde zijn. Product denken door SOA principes standaard in te vullen met webservices zorgt ervoor dat je uiteindelijk eindigt met een kruiwagen vol kikkers, zolang je niet beweegt blijven ze zitten maar als je vooruit wilt springen ze alle kanten op. En je hebt veel minder bewegingsruimte geven als de leverancier de richting bepaald want beschuldigende vingertje van de overheid naar de markt is volgens mij gewoon de opmaat naar volgende migratie probleem omdat Windows 2003 volgend jaar ten grave gedragen wordt.
@Reza
Aangezien je link naar oude opinie geeft, mij een antwoord beloofde maar met een andere opinie kwam dan succesverhaal bij overheid concludeer ik dat hier ook sprake was een ‘voortschrijdend’ inzicht. Zoiets als rijkspassen vervangen omdat – zoals ik al in reactie stelde – proces zelf nog niet op orde is.
Ewout, het tegenovergestelde van liefde is onverschilligheid. Naar mij toe ben je niet onverschillig, dus het moet wel liefde zijn 😉 Bedankt voor je uitgebreide reactie.
Je 1) Betrouwbaar 2) Snel 3) Goedkoop principes gaan overigens over projecten. Er zijn best diensten die aan drie principes voldoen.
De SOA definitie onderschrijf ik helemaal.
Over meer dan 100 ontwerpprincipes: Ik denk dat er in de bouw nog veel meer zijn, IT is een heel breed spectrum, de ontwerpprincipes zijn een hele goede basis die goed toe te passen zijn, je hoeft niet altijd alle principes toe te passen (keuzes), maar de beslissing om ze al dan niet toe te passen zou ik in mijn ogen wel bewust nemen.
Het realiseren van multitenancy kost natuurlijk geld, ieder stukje functionaliteit kost geld en moet ook nog eens onderhouden en getest worden. Multitenancy achteraf toevoegen is een complexe en dure zaak, vraag dat maar aan Alfresco (document management systeem). En zeker in het cloud tijdperk is het bijna een voorwaarde.
Schrijvende over cloud en wijzend op jouw reactie betreffende DATA: Mijn artikel heeft sec niets te maken met cloud (computing). Dit is eigenlijk een “easter egg”, dus als je kijkt naar deze ontwerpprincipes, zou je cloud helemaal achterwege kunnen laten en ik kan je stukje dan ook niet plaatsen over beleid, wetgeving en vertrouwelijkheid.
Nu noem je SOA een kruiwagen vol kikkers. Maar stel dat je geen SOA hanteert. Hoe beweeg je dan je enterprise? Hoe is dat dan anders?
@Henri
Je moet bij de VVD gaan want die verkopen lastenverzwaringen als bezuinigingen. Ontwerpprincipes als: wereldwijd, multitenancy en self(web)services klinkt heel erg als cloud en in overtreffende trap van leugens daarover heb je nu dus lobbyisten, politici en Henri Koppen:
“The US negotiators in the Department of Commerce (NIST) worked closely with US trade lobbies, on a series of “FAQs” for US companies to interpret the Agreement to marginalize EU privacy rights, building in loopholes on such questions as what counted as identifiable data, refusing rights of access, and avoiding any duty of finality or right of deletion. Safe Harbour proved so Byzantine that no EU citizen navigated the bureaucracy to lodge a complaint for many years.”
Als je mijn teksten al te moeilijk vindt dan denk ik dat je helemaal verdwaalt in Byzantijnse labyrinth van voorwaarden en garanties zoals ik al in mijn eerste reactie stelde. Dat we nu met Big DATA principes op zoek naar alle ‘easter eggs’ gaan die jij allemaal verstopt hebt is de reden dat Buma aan het mijmeren is over de dienstplicht. Lees ook nog eens mijn opinie: ‘ICT is een nationaal belang’ want het leger aan ZZP-ers bij de overheid blijkt gewoon niet doeltreffend omdat ze de vaardigheden van Von Clausewitz missen. Nogmaals, snel en goedkoop past prima bij de cloud maar als je het betrouwbaar wil is het door alle aanvullende beveiligingsmaatregelen niet goedkoop meer. En die draaitol van de VVD (Schippers) weet dat donders goed en heeft daarom net zo’n Byzantijns labyrinth opgericht.
Voor jou wordt het de billen van bejaarden wassen want als Zonnekoning Zonder Principes ben je net als van (Sp)Eijk met je constante: “Dan maar liever de lucht in!” en dus ongeschikt voor dienst op een kanonneerboot;-)