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.
Als een gesloten product niet aan jouw verwachtingen voldoet, en de oplossing geen prioriteit heeft bij de leverancier dan is het game-over.
Met open bron software heb je jouw lot in eigen hand. Kun je het zelf niet oplossen dan huur je iemand in die het voor jou doet. (dat noemen we ook wel vrijheid)
– de vlieger “gratis” –
is de misvatting die algemeen heerst.
De community die software maakt/test/verbetert/dokumenteert verdient aan de verspreiding.
Soms kan een gebruiker zelf installeren, dan is dat mooi meegenomen. Er is echter een heel eko-systeem van bedrijven en bedrijfjes die met de diensten bij FOSS geld verdienen.
Met FOSS koop je vrijheid en onafhankelijkheid, vraag maar eens na bij de stad München.
Soms krijg ik weleens het idee dat het bij Open Source meer om een geloof gaat dan een oplossing, beetje zoals sommigen cloud als antwoord op elke vraag zien. In de reacties wordt gelukkig al aangegeven dat Open Source niet altijd staat voor gratis, integendeel zelfs als ik kijk naar TCO hiervan in verhouding tot sommige closed source oplossingen. Maar goed vrijheid heeft een prijs hoewel ik niet de indruk heb dat veel gebruikers ook daadwerkelijk de source code aanpassen.
Kort gezegd zitten er zowel voor- als nadelen aan Open Source, dit artikel (en sommige reacties) laten in elk geval zien dat auteur vooral last heeft van een Calimero-complex want Open Source valt niet tussen wal en schip maar past soms wel en soms niet. Gaat niet zo zeer om de code maar de standaarden en ooit heb ik al eens een artikel hierover geschreven: ‘Open Source of Open Sores’
“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.”
“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.”
Pascals OSS businessmodel 😉
@Ewout
“Gaat niet zo zeer om de code maar de standaarden” dat klopt helemaal maar juist FOSS bedrijven hechten veel (meer) waarde aan het gebruik van standaarden.
MS probeert steeds zijn ideeen als standaard door te drukken inklusief het korrumperen van het gehele ISO-systeem. Daar kies ik liever voor ODF.
Er zal m.i. altijd een mix van FOSS en commercieel zijn omdat de beste oplossing niet altijd FOSS is. Zo kocht ik een commercieel produkt omdat de FOSS-versie me overtuigde van de kwaliteit.
@Jan van Leeuwen (de andere Jan blijft akelig stil)
Dat F(L)OSS bedrijven meer waarde hechten aan standaarden is niet helemaal correct, ze hebben vooral een commercieel belang bij een grote community welke het makkelijkste verkregen kan worden door aan te haken op een standaard. En een standaard is vaak niet meer dan iets dat veel gebruikt wordt waarbij marktaandeel vooral wordt verkregen door de marketing. Een mooi voorbeeld hiervan is misschien wel Google die ons een eindeloze stroom F(L)OSS tools geeft maar die de belangrijkste code hiervan niet openbaart.
F(L)OSS oplossingen lijken op andere keuzes maar missen op essentiële onderdelen vaak functionaliteiten waardoor horizontale en/of vertikale integratie bemoeilijkt wordt. Een probleem met F(L)OSS is namelijk de te grote keus, er is bijvoorbeeld al een wildgroei (fork) in de Open Source selectie framewerken (OSMM/BRR/QSOS) waardoor evaluatie vaak gedaan wordt op basis van ‘first fit’ in plaats van ‘best fit’ en iets soortgelijks zie ik ook bij cloud applicaties.
P.S.
ODF is leuk maar ik zie de ‘Excel hell’ nog niet gauw bevriezen want Microsoft heeft het jaren geleden slim gespeeld door met PC’s Works mee te leveren.
@Ewout, ik voel me een beetje aangesproken, maar meestal meng ik me niet in de discussie rond mijn eigen artikels 😉
De discussie over open standaarden is evenwel erg interessant. Ik denk dat developers van OSS een (natuurlijke) voorkeur hebben voor open standaarden. Daarnaast zijn gesloten standaarden buiten bereik, ze zijn immers gesloten. Wel kan gekozen worden voor het reverse “engineren” van gesloten standaarden, maar dat is blijkbaar erg moeilijk (zie OpenOffice / LibreOffice).
De ongelijkheid hierin lijkt me duidelijk, OSS developers kunnen niet (of moeilijk) meedoen met gesloten standaarden, maar commerciële developers / bedrijven wordt niets in de weg gelegd om open standaarden te omarmen. Mogelijk dat hier een commerciële “strijd” aan ten grondslag ligt, maar dat is vanaf mijn positie gissen.
De discussie over “gratis”, of beter gezegd, over TCO van OSS vind ik minder interessant. Hoewel de software gratis kan zijn betekent dat niet dat de TCO nul is. Dat weten we nu wel. Dat de TCO vaak lager is (uitzonderingen bevestigen de regel) zal ook wel duidelijk zijn.
Mijn artikel heb ik geschreven omdat naar mijn idee veel van de uitgangspunten en doelen van enterprise architecten prima met Linux en OSS bereikt kunnen worden. Toch gebeurt dat niet veel (althans niet dat ik zie). Dat vind ik jammer. Ik hoop de discussie daarover een beetje op gang te helpen – voor zover dat nodig mocht zijn.
@Jan van der Torn
Ik voel me vereerd maar als je het vuurtje brandend wilt houden zul je er zo nu en dan een blok hout op moeten gooien, niet reageren lijkt me dus niet handig.
In eerste reactie heb ik al gezegd dat OSS soms wel en soms niet past en in tweede reactie ga ik daar wat dieper op in omdat bij ‘first fit’ alleen naar de directe voordelen/kosten gekeken wordt terwijl een ‘best fit’ ook rekening houdt met de minder voor de hand liggende kosten/nadelen. Twee LDAP structuren onderhouden lijkt me bijvoorbeeld niet handig hoewel er misschien betere oplossingen zijn.
Betreffende bouwstenen bestaat core Linux inderdaad uit een kleine kernel maar is het weer afhankelijk van de distributiekanalen die per distributie nogal af kunnen wijken. Als we het over een standaard gaan hebben lijkt dit me iets om in ieder geval te noemen en als ik me niet vergis zit er ook een ‘subscription fee’ aan die kanalen waardoor je stelling over lagere TCO m.i. toch wat discutabel is. Het neigt dus veel naar de cloud waar allerlei ontwikkelingen zijn met Open Source voor database, middleware en nog wat andere componenten in de stack.
Als iemand die al jaren Linux applicatieservers en KA-omgevingen support, vind ik dit artikel wat magertjes. Een van de continue opduikende problemen zijn embedded systemen (printers,routers, telefooncentrales) wiens webinterface alleen werkt onder IE, om maar eens wat te noemen. Of de ontbrekende support voor Dymo labelprinters (zie maar iets anders te vinden). Of websites als PostNL die jaren alleen onder IE wilde werken. Of Flash-support (geen nieuwe ontwikkelingen meer, dus je kan alleen nog Chrome gebruiken met eigen Flash support)? Converteren van mailings van MS Office naar OpenOffice bleek ook geen sinecure. Een ander probleem is dat soms een software project abandoned wordt door ontwikkelaars en dan alleen door maintainers wordt beheerd. Maar op het moment dat die tegen een road-block aanlopen, dan laten ze het pakket vallen als een baksteen (bijv. apt-proxy in Ubuntu LongTermServer support!, van de ene op de andere dag werd besloten dit pakket te droppen en moesten wij na een update op stel en sprong over naar apt-cacher-ng). Ook bleek het LTS-support team regelmatig geen zin te hebben in back-ports van Samba. Of wat dacht je het upgraden van niet-LTS naar LTS (als je noodgedwongen even een tussenstap moest maken)?
Ook het full-system backups maken van nieuwere generatie filesystemen bleek geen synecure (om maar nog niet te beginnen over het ReiserFS debacle, ontwikkelaar Hans Reiser die voor moord achter de tralies ging…). Ik blijf voor open source, maar dan wel graag via een full-solutions provider of in grote bedrijven.. Een voordeel is er wel: het beheer van open source scheidt de mannen van de muizen, alleen echte beheerders kunnen dit aan.
@ Ewout,
Ja er zijn wel wat mensen die OSS zo ongeveer als heilig verklaren, ik ben er ook zo een dat was wel duidelijk lijkt me.
Exact hetzelfde kom je tegen vanuit het MicroSoft kamp.
Het grote verschil is dan OSS aanhangers iha een hoop meer knowhow van ICT hebben dan de moderne klikklakklaar specialisten.
Daar kunnen we over soebatten maar genoemd feit valt niet te ontkennen.
Vraag blijft dan natuurlijk of iemand werkelijk zit te wachten op mensen met vakinhoudelijk talent.
@Mauwerd,
Om eventuele vergissingen uit te sluiten, het bedoelde programma op mijn website was uiteraard ook een produkt van mijn eigen hand, en komt mij aldus wel degelijk toe.
Weet niet zeker of daar onduidelijkheid over is.
Verder vond ik je aansluitende opmerking wel vermakelijk.