Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Ontwerpprincipes voor de cloud

 

Computable Expert

Henri Koppen
Directeur, THINGKS. Expert van Computable voor de topics Digital Transformation en Cloud Computing.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5187335). © Jaarbeurs IT Media.

8


Lees meer over


 

Reacties

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;-)

@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.

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?

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×