Het is voor bedrijven noodzakelijk om de snelle veranderingen in onze maatschappij te volgen. Consequentie hiervan is dat zij hun ict-voorzieningen snel aan moeten kunnen passen zonder daarmee concessies te doen aan de beschikbaarheid en veiligheid van systemen en gegevens. Om dit te bereiken worden er afspraken gemaakt over waaraan dergelijke veranderingen moeten voldoen of onder welke condities deze uitgevoerd mogen worden.
Deze afspraken, of wel principes, worden architectuur genoemd. Het architectuurdenken is heel gebruikelijk bij grote bedrijven en organisaties omdat niemand alleen in staat is deze complexiteit te overzien. De interne it-organisatie, externe leveranciers en dienstverleners hebben zich allen te conformeren aan deze (enterprise) architectuur, het zogenaamde: werken onder architectuur.
Architectuur als middel
Voor wat betreft de (infrastructurele) architectuur kunnen dit afspraken zijn over, gegevens, informatie beveiliging, applicaties, interfaces en de infrastructuur zelf. Zo kunnen bijvoorbeeld het aantal operating systemen of databases beperkt worden. Met dergelijke beperkingen wordt de infrastructuur beter te overzien en de organisatie is daardoor beter in staat het beheer uit te voeren. Ook consequenties van wijzigingen zijn zo beter te overzien. Architectuur is daarmee geen doel op zich, maar heeft tot doel een consistente en veilige ict te realiseren waarop efficiënt wijzigingen doorgevoerd kunnen worden. De architectuur ontwikkelt zich ook in de tijd en zal kan niet statisch zijn. Enterprise architecten zijn verantwoordelijk voor het naleven van de bestaande architectuur en het ontwikkelen daarvan.
Enterprise architecten
Veel enterprise architecten zijn echter onbekend met open source software en de (detail) mogelijkheden die dit biedt voor de architectuur. Als Linux al een platform binnen de architectuur is (en dat komt steeds vaker voor) dan is het een uitzondering op verschillende vlakken. De meeste organisaties hebben centraal gebruiker beheer ingericht op basis van Microsoft Active Directory. Linux-servers worden veelal niet gekoppeld (maar kunnen dat overigens wel). Linux gebruikers worden of lokaal aangelegd, of er wordt een LDAP-gebaseerde structuur naast Microsoft Active Directory gebouwd. Deze Linux-systemen worden dan meestal gebruikt voor web sites of content management systemen zodat er geen noodzaak is voor eindgebruikers daarop in te loggen. Het wordt als platform toegestaan, maar het is wel een uitzondering. Je zou kunnen stellen dat het geïsoleerd ingezet wordt.
Gemiste kansen
Naar mijn idee past open source software juist heel goed binnen het architectuur denken. Er zijn talloze tools die het naleven van afspraken juist veel makkelijker maken. Er zijn tools waarmee het management van Linux-systemen gestandaardiseerd en geautomatiseerd kunnen worden zoals bijvoorbeeld, Red Hat Satelite voor deployment en Puppet voor management. Standaard biedt Linux talloze bouwblokken om systemen te hardenen zoals bijvoorbeeld Secure Shell (SSH) dat encrypted toegang tot systemen kan geven, of Secure Copy waarmee bestanden encryped tussen Linux-systemen gekopieerd kunnen worden. SSH en SCP kunnen eenvoudig verder beveiligd worden door root acces te weigeren en gebruikers alleen met een RSA of DSA key te laten inloggen. Beiden maken standaard deel uit van ieder Linux-installatie.
Verder kunnen middels het Sudo-mechanisme (sudoers file) root rechten aan users gegeven worden op specifieke commando’s. Wanneer men echt hecht aan sucurity (en dat doen enterprise architecten) dan mogen zeker Security Enhanced Linux (SELinux) en AppArmour niet vergeten worden. Op basis hiervan kunnen de rechten van processen op systemen verder beperkt worden. Als laatste zou ik de CIS Benchmark voor Red Hat-systemen willen noemen. Dit is een uitgebreide beschrijving van (mogelijk) te nemen maatregelen die een Red Hat Linux-systeem veiliger maken. Van iedere maatregel is beschreven hoe deze geïmplementeerd moet worden, waarom het systeem veiliger wordt en bovenal hoe het gecontroleerd (audit) kan worden.
Veiligere infrastructuur
De beschreven mogelijkheden zijn maar een greep uit de mogelijkheden die open source software biedt om een it-omgeving veilig en beheersbaar te houden. Bedrijven die al bekend zijn met Linux en open source software kennen deze mogelijkheden ongetwijfeld. Ik zou daarom graag een pleidooi willen houden voor Linux en open source software bij enterprise architecten. Verdiep je in de mogelijkheden en probeer ze toe te (laten) passen. Maak ze in al haar mogelijkheden onderdeel van de (enterprise) architectuur. De organisatie waarvoor je werkt zal je dankbaar zijn.
We hebben een paar jaar geleden veel geëxperimenteerd met het integreren een (embedded) Linux platform, maar kwamen toch wel wat problemen tegen m.b.t. half- en full domaintrusts i.c. de selecteerbeschikbaarheid van security- en distribution-groups. Inmiddels heb je weer te maken met claims-based authentication e.d. waardoor oude problemen onbelangrijk kunnen worden en tegelijk nieuwe kunnen ontstaan. Je moet dus wel uitgebreid testen als je eraan begint, want anders kun je voor rare verrassingen komen te staan.
Verder moet er natuurlijk wel een aanleiding voor zijn of op zijn minst een doel aan ten grondslag liggen. Vaak is Linux juist sterk als het om ip-gerelateerde diensten gaat (VoIP, BGP e.d.) en dan is koppelen van directory services meestal niet nodig of zelfs ongewenst.
In Estland is de overheid met succes gewoon met open source bezig hoor. En inmiddels behoren zijn tot de beste online dienstverleners.
http://www.computerweekly.com/news/2240158387/Interview-GDS-head-Mike-Bracken-on-Estonias-digital-services
En nu zijn het VK en de BDR ook al aan het kijken naar dit soort oplossingen. Oftewel zal de Nederlandse overheid nou eindelijk het stigma van zich af kunnen werpen door open source te gaan?
Bij architectuur is het niet anders als op andere terreinen dat keuzes altijd worden gemaakt ‘met de kennis van nu’. Je vaststelling dat architecten vaak weinig kennis hebben van open source software en de mogelijkheden daarvan is terecht. Maar niet exclusief voor open source. ‘Architectuur’ houdt mijns inziens veel te vaak op bij papieren modellen of prncipes die best kunnen deugen, maar te weinig opleveren als je ze niet (mee) vertaalt richting techniek en implementatie. Ondanks regelmatig geuite goede voornemens zie ik nog steeds veel ivoren torens waarin architecten het verdacht vinden wanneer collega-architecten zich bezig houden met technische zaken als (bijvoorbeeld) inzet van Linux. Je advies onderschrijf ik, maar dan dus breder dan alleen m.b.t. Linux.
Overigens denk ik dat het overgaan op meer extern gehoste toepassingen de afwegingen tussen op Windows- of Linux-gebaseerde oplossingen minder relevant zullen maken (maar dat is een andere discussie).
De reactie van Ad Gerrits bevestigt mijn eerste gedachte na het lezen van het artikel: waarom zou een architect zich bezig houden met het kiezen van open of closed source?
De keuze voor open of closed source is in mijn ogen geen architectuurkeuze maar een implementatie. De architect bijv. bedenkt een concept/architectuur waarin een database nodig is. Daarbij komen eventueel nog eigenschappen van deze database.
Bij implementatie ga je vervolgens kijken welke databases voldoen aan de eisen en wensen. Nu kun je de eigenschappen natuurlijk zo beschrijven dat alleen open source voldoet, maar je kunt je afvragen of je als architect dan goed bezig bent.
Dat open source / linux veel mogelijkheden biedt ben ik het helemaal mee eens. Maar een stukje “onbekend maakt onbemind”, compatibiliteitsproblemen, onduidelijkheid over ondersteuning (vooral bij integraties tussen diverse open source producten) maakt mensen toch huiverig om hiervoor te kiezen.
(hierbij doel ik met name op wat specifiekere toepassingen, niet op de wijdverbreide implementaties als bijv. Apache op linux. Recentelijk tegen een probleem aangelopen bij de integratie van 2 producten, waarvan één open source. Issue bleek al meer dan een jaar bekend bij de community maar had geen prioriteit. Waar kan ik als “klant” nu terecht is een vraag die dan al snel naar boven komt?)
@Pa Va Ke
Een architect moet met van alles en nog wat rekening houden hoor. Eveneens als een architect voor gebouwen dat ook moet doen. Brandveiligheid, sterkte berekeningen, zorgen voor genoeg zonlicht etc.
Een Enterprise architect zal ook rekening moeten houden met lange termijn zaken en dus uitbreidbaarheid e.d. En laat op dat vlak nou open source redelijk sterk zijn omdat daar geen commerciële belangen in meespelen om de eigen software stack te promoten maar juist de gebruiker laten kiezen in het combineren van onderdelen omdat het gebruik van open standaarden simpelweg de norm is.
@Johan
Een architect moet rekening houden met brandveiligheid, klopt. Maar als hij vluchtwegen plant en brandwerende muren/deuren is het kader gezet.
De implementatie (welk merk deur, welke kleur) hoeft niet meer bij de architect te liggen, maar kan in onderliggende laag komen (uitvoer/tool/materiaal selectie)
Quote “Waar kan ik als “klant” nu terecht is een vraag die dan al snel naar boven komt?”
PaVaKa ik ben stomverbaast over jouw opmerking daar ik jou zoals je wellicht weet altijd erg hoog inschat.
De essentie van OpenSourceSoftware is niet dat je de community jouw probleem laat oplossen maar dat je zelf een poging daartoe doet en jouw oplossing aan de community bijdraagt zodat eenieder daar voordeel aan heeft !
Ben je zelf daartoe technisch niet in staat, dan zoek je een partij die dat wel kan.
(Om er vervolgens idd achter te komen dat het overgrote deel van de ‘specialisten’ dan door de mand vallen)
Veel OSS is idd kostenvrij in te zetten maar daar staat enig eigen initiatief tegenover.
@pascal, ik neem aan dat pavake de vraag stelde vanuit het klantperspectief. Die stelt die vraag.
Het antwoord, OSS is niet business case gedreven want er is geen business, zorgt voor de wal en schip positie.
@Pascal
Jouw reactie beschrijft heel mooi mijn “probleem” met open source.
Ik ben een eindgebruiker van producten, niet een programmeur die bijdragen kan leveren aan de community.
Als klant wil ik graag ontzorgd worden, en ergens aan kunnen kloppen voor ondersteuning. We willen ons bezig houden met onze core competenties, niet met het ontwikkelen van integraties tussen tools en bijdragen leveren aan de community.
Dat mag best wat geld kosten. Als ik hiervoor vervolgens een derde partij in moet gaan schakelen, dan gaat de vlieger “gratis” misschien nog wel op, maar vliegt zij een stuk minder hoog.
Je insteek (die ik overigens wel kan plaatsen) roept meteen ook een andere vraag op: als bedrijven/overheden kiezen voor OSS oplossingen te gaan, plannen zij dan ook meteen een hoeveelheid werk in om bij te kunnen dragen aan de open source community daar waar nodig?
PaVaKe,
Je slaat de spijker op zijn kop !
First of all, het is niet de OSS community die OSS als zijnde gratisch aanbied zij heeft daar geen enkel belang bij, en gratisch is zoals je zelf aangeeft maar relatief.
Het zijn de commerciele partijen die dat wel doen, en sterker nog zelf wel geld durven te vragen iets te verkopen wat ze niet toekomt.
Voor OSS geld wel degelijk een buisness model, maar dat is een heel ander model dan het ‘schuiven van dozen’ aka ‘installeren van CDtjes’.
De centjes vallen juist te verdienen doordat je iets kan wat mijn buurjochie van 10 (daar issie weer) niet veel beter en goedkoper kan.
Van heel veel OSS produkten gruwel ik zelf ook, omdat deze vooral bedoeld zijn om lui zonder enige kennis van zaken allerlij kunstjes te laten uithalen waarvan zij in het geheel geen idee hebben wat ze nu eigenlijk doen.
Denk b.v. eens aan produkten als DirectAdmin, Plesk, CPanel, maar ook diverse webframeworks of hoe dat spul allemaal heet, wat in essentie gewoon bedoeld is om de leek een nog grotere puinhoop te laten maken van wat het internet al is. brrrrr…
Ik heb nooit beweerd dat OSS gratisch is, heel wat lui denken ‘dat doet Pascal wel even want dat vind hij leuk’ Wrong, ik speel piano en gitaar, dat vind ik leuk. met mooi weer tuf ik rond in mijn jeep of maak ik een wandeling, dat vind ik leuk. voor IT-geneuzel wens ik gewoon net als iedere andere IT-neus betaald te worden.
Op je laatste vraag, kan ik met enige terughoudendheid bekennen dat het antwoord JA is.
Er zijn b.v. bedrijven die in opdracht modules schrijven voor Drupal (liever zij dan ik) welke later gewoon tot de OpenSource versie behoren.
Mijn terughoudendheid bestaat eruit dat ik nooit serieus grote overheidsprojecten heb gedaan. Een zeer sucsesvol project in deze (en niet eens OSS) heb ik uiteindelijk wegens gebrek aan respons maar op de plank gelegd.
Ooit heb ik eens een keer een programaatje verkocht dat ik gewoon van mijn eigen website had geplukt… tja als je niet bereid bent zelf even te zoeken en de eventuele aanpassingen te maken dan moet je er maar voor betalen. Niets mis mee, de schilder werkt ook niet voor niets.
Mijn voorkeur voor OSS komt eigenlijk vooral doordat ik me vrijwel altijd stoor aan de kwaliteit, of het ontbreken van relevante functionaliteit bij gesloten software.
Neem b.v. MS-Windows… even los van de kwaliteit, en de gebruikersonvriendelijkheid ervan,
het OS neemt enorm veel diskruimte in en vraagt force CPU capaciteit, maar heel basale functionaliteit die zo’n beetje elk ander OS kent zit er standaard niet in. hou maar.
Ik ben me er overigens wel van bewust dat ik op Computable een vreemde eend in de bijt ben.