Ervaringen met het bestuderen van TOGAF
22 April 10 - 00:00
Aandachtsgebied: default -
Link naar dit artikel
Gedurende het grootste deel van 2009 heb ik samen met een aantal collega's van Logica The Open Group Architecture Framework (TOGAF) bestudeerd. De belangrijkste reden hiervoor was om meer kennis van TOGAF krijgen, maar ook wilden velen klaar te zijn voor TOGAF certificering. Samen met twee collega's was ik de manager van het proces.
Het bestuderen van het TOGAF boek was niet gemakkelijk. Het boek bevat 778 pagina's met een hoge informatiedichtheid en het is niet makkelijk leesbaar. We hadden gepland om het TOGAF boek hoofdstuk voor hoofdstuk te bestuderen: van kaft tot kaft. In 10 avondsessies zouden we onduidelijkheden in- en vragen over het TOGAF materiaal bespreken. In deze avondsessies en gedurende het lezen hebben we een paar zaken geleerd die ik u niet wilde onthouden:
- Het is niet praktisch om het boek van kaft tot kaft te lezen. In de eerste hoofdstukken wordt terminologie gebruikt die pas veel later in het boek wordt uitgelegd.
- U kunt het beste starten met het lezen van deel III (ADM Guidelines and Techniques) en deel IV (Architecture Framework Content) en daarna pas de feitelijke ADM fases (deel II) lezen.
- Het boek (of de online versie van TOGAF als u dat liever hebt) is niet perfect. Het bevat een aantal fouten en gebruikt soms verwarrende termiologie. Bijvoorbeeld: wat is precies een "building block" volgens TOGAF? Het kostte ons een uur discussie om consensus te bereiken over de definitie (die ik trouwens gecontroleerd met een van de auteurs van TOGAF bij een bezoek aan de Open Group): een building block is alles. Dezelfde onduidelijkheid hadden we met de term "Enterprise Continuum" (lees hoofdstuk 39 in het boek). Hetzelfde geldt voor het verschil tussen artefacten en deliverables.
- Niet alle delen van TOGAF zijn van gelijke volwassenheid. De ADM is vrij uitgebreid (hoewel het technische architectuur deel de meeste details bevat), maar bijvoorbeeld de hoofdstukken over security architecture, SOA en architecture maturity modellen zijn zeer dun.
Naast de bovengenoemde punten (en ik ben vast nog meer punten vergeten) is TOGAF is nog altijd een zeer rijke bron van informatie over Enterprise Architecture, met veel inzicht, checklists en modellen die in de praktijk direct gebruikt kunnen worden.
TOGAF moet alleen een beetje meer volwassen worden.
Guru 4 Pro
15 April 10 - 00:00
Aandachtsgebied: default -
Link naar dit artikel
Op woensdag 30 juni 2010 presenteer ik in Amstelveen voor Logica een Guru4Pro sessie met als titel De Cloud: wat is het en wat zijn de valkuilen?
De sessie is gratis en voor iedereen toegankelijk. Er zijn zelfs broodjes beschikbaar, wat wilt u nog meer?
Via deze link kunt u zich aanmelden en vindt u meer informatie over de tijd en het adres.
Hier is de tekst op de uitnodiging:
"Iedereen heeft het erover, maar weinigen weten precies wat het is: de cloud. Het is iets met het draaien van applicaties in de internetwolk, maar hoe gaat dat precies? Bij cloudcomputing gaat altijd om het draaien van applicaties op een datacenter van een derde partij, waarbij de applicaties worden ontsloten via het Internet. Wat zijn hierbij de mogelijkheden en de valkuilen, wat is de stand der techniek en waar moet ik rekening mee houden? Logica vertelt op deze avond haar visie op de cloud; met beide benen op de grond in plaats van met het hoofd in de wolken."
Ik hoop veel van u te zien!
De beveiliging van uw data in de cloud
11 April 10 - 00:00
Aandachtsgebied: default -
Link naar dit artikel
Het gebruik van cloudservices wordt langzaamaan gemeengoed. Vooral voor niet-bedrijfskritische applicaties kan het gebruik van cloudservices interessant zijn. Voor email bijvoorbeeld. Maar hoe zit het met de beveiliging van uw data in deze email cloudservices?
Vrijwel alle email infrastructuren in bedrijven zijn vergelijkbaar. Email is niet onderscheidend en wordt daarom vaak als een commodity beschouwd. Maar een email infrastructuur is niet zo simpel als het lijkt. Eindgebruikers willen hun email graag op allerlei manieren en plaatsen kunnen lezen en bewerken. Het verwerken van email gebeurt vaak niet alleen op de werkvloer, maar ook vanaf thuis, bij klanten of via een mobiele telefoon. Email moet daarom bereikbaar zijn via verschillende kanalen, ook buiten kantooruren. Bedrijven moeten hiervoor hun email infrastructuur geschikt maken. Een ander fenomeen bij email is spam. Meer dan 90% van alle email in de wereld is spam. Beheerders moeten voor email infrastructuren adequate maatregelen treffen om spam tegen te gaan. Ook het scannen van email op virussen is een taak die bij de inrichting van een email infrastructuur hoort. Al met al veel werk voor een email service die als commodity kan worden gezien.
Een alternatief kan zijn om een email service af te nemen vanuit de cloud. De kosten zijn over het algemeen veel lager dan het bijhouden van een email infrastructuur in het eigen bedrijf. De betrouwbaarheid is hoog en het beheer wordt uit handen genomen. Vooral voor kleine bedrijven en start-ups is het gebruik van applicaties uit de cloud erg aantrekkelijk.
Er zijn verschillende aanbieders van email services in de cloud. De meest bekende is Gmail van Google, maar ook Microsoft (Hotmail) en een groot aantal kleinere aanbieders zijn actief in deze markt. Google biedt behalve de Gmail service voor eindgebruikers ook email service voor bedrijven. Inmiddels zijn er reeds 400.000 bedrijven die gebruik maken van Gmail.
Het is voor bedrijven belangrijk te controleren hoe het is gesteld met de beveiliging van de data die in de cloud wordt opgeslagen (zoals de bedrijfskritische informatie in emails). Voordat er met een cloud aanbieder in zee wordt gegaan dienen daarom de contractuele voorwaarden te worden gecontroleerd. Enkele punten zijn:
- Hoe wordt door de cloud aanbieder gegarandeerd dat data veilig wordt opgeslagen en dat andere personen of partijen niet bij de data kunnen komen (denk ook aan de fysieke beveiliging van onder andere de datacenters; wordt dit ook extern geaudit?)
- Hoe wordt gegarandeerd dat data niet kwijtraakt, vernietigd wordt, etc Is het mogelijk dat u een - al dan niet externe - audit uitvoert bij de cloud aanbieder?
- Wat gebeurt er met uw data als de cloud aanbieder failliet gaat, overgenomen wordt of als de service niet langer wordt aangeboden?
- Waar wordt uw data fysiek bewaard? Op Amerikaanse servers? Valt de data ook onder Amerikaans recht (zoals de Patriot act en SoX)?
- Wat is de exit strategie als u besluit data uit de cloud naar een andere aanbieder te verhuizen of om het zelf weer te gaan beheren? Wordt dit toegestaan? In welk formaat krijgt u uw informatie? Wordt de informatie bij de cloud aanbieder dan ook daadwerkelijk vernietigd? Is dit te controleren?
Allemaal valide punten lijkt me. Maar de grote vraag is natuurlijk: Wie controleert dit daadwerkelijk? Ik verwacht dat de meeste bedrijven die cloud services gaan gebruiken (vaak uit financiële overwegingen) bovenstaande punten niet allemaal adresseren. Of heb ik het mis?
Meer artikelen: Zie de linkerbalk.