Archive for the ‘Blog’ Category

Wendbaarheid voor alles

De laatste jaren ligt de focus bij organisaties steeds meer op wendbaarheid. Snel kunnen anticiperen op ontwikkelingen in de markt, de politiek en de techniek. Dat vinden veel bestuurders tegenwoordig belangrijker dan sturen op kosten. Opvallend is dat bestuurders steeds vaker een korte termijn visie lijken te hebben. Twee tot vier jaar vooruit kijken is wel het maximum. Wat daarna komt ‘zien wij dan wel weer’.

Enerzijds is dat te verklaren vanuit de gedachte dat veel bestuurders niet veel langer dan drie à vier jaar op dezelfde plek zitten. Het is van belang om succesvol te zijn bij het halen van korte termijn doelstellingen. Als architect denk je vaak verder vooruit en heb je dikwijls moeite met bestuurders die geen lange termijn visie lijken te hebben.

Anderzijds is een korte termijn visie zo gek nog niet. In de huidige maatschappij is het wel verstandig om je te richten op successen die op korte termijn behaald kunnen worden. Maatschappelijke en economische ontwikkelingen blijken immers steeds minder goed voorspelbaar te zijn.

Wendbaarheid is essentieel om als onderneming te kunnen overleven. Ook van overheidsinstanties en non-profit-organisaties wordt verwacht dat ze snel kunnen anticiperen op veranderende behoeftes als gevolg van maatschappelijke ontwikkelingen. Het is logisch dat daarom steeds meer agile ontwikkelmethoden worden ingezet voor systeemontwikkeling. Het doel is het leveren van businesswaarde in een korte time to market. voor IT-voorzieningen. Lange ontwikkeltrajecten worden vermeden, waarmee tegengegaan wordt dat het systeem dat uiteindelijk wordt opgeleverd meteen al achterhaald is en dus geen waarde oplevert. Echter, alleen met agile ontwikkelen van nieuwe functionaliteit ben je er niet. De architectuur moet de wendbaarheid ook ondersteunen.

De laatste decennia hebben architectuurafdelingen sterk ingezet op standaardisatie en generieke functionaliteit. Generieke componenten of bouwblokken kunnen door verschillende business lines worden gebruikt en gecombineerd tot specifieke oplossingen. Business lines zijn bijvoorbeeld verzekeringslabels bij een verzekeringsconcern of op doelgroepen gerichte organisatieonderdelen bij overheidsinstellingen. De business driver was dikwijls kostenreductie en de IT-driver was rationalisatie. Dit laatste was vooral gericht op het vervangen van meerdere systemen met vergelijkbare functionaliteit door één generiek systeem.

De wendbaarheid wordt door die ontwikkeling echter maar zelden verbeterd. Business lines zijn vaak gericht op een bepaalde doelgroepen. Om die maximaal te kunnen bedienen wordt specifieke, onderscheidende functionaliteit gevraagd. Generieke componenten combineren en configureren tot specifieke functionaliteit blijkt nogal tegen te vallen in de praktijk. Vaak zie je dat generieke componenten uitgebouwd worden tot zeer complexe applicaties als gevolg van wensen vanuit verschillende business lines. Specifieke wensen worden niet gehonoreerd, omdat het verplichte gebruik van een generieke oplossing dat in de weg staat.

Dit frustreert de wendbaarheid van de business lines. Aanpassen van generieke componenten raakt alle gebruikers. Dit vergt veel afstemming, veel afhankelijkheden in releaseplanningen en veel testen. Business lines hebben last van wijzigingen als gevolg van wensen uit andere business lines. Dit terwijl ze andere prioriteiten hebben en hun budget en capaciteit liever aanwenden om eigen veranderingen door te voeren.

Willen wij maximale wendbaarheid, dan moeten wij durven afstappen van sturen op standaardisatie en generieke oplossingen. Dat betekent overigens niet dat je deze uitgangspunten volledig moet loslaten. Ze mogen echter de wendbaarheid niet frustreren.

Standaarden en generieke componenten zijn prima te gebruiken voor functionaliteit die niet of nauwelijks aan verandering onderhevig is en ook werkelijk generiek is. De opzet van een grootboek verandert bijvoorbeeld niet vaak. Anders wordt het als het op specifieke doelgroepen gerichte functionaliteit gaat. Als je dit met alleen generieke componenten kunt invullen, dan kun je je afvragen waarom je verschillende doelgroepen hebt onderkend. Optimale klantbediening vraagt om optimaal daarop afgestemde applicaties. Als je snel wilt inspelen op nieuwe wensen of technologische mogelijkheden, dan wil je wijzigingen kunnen doorvoeren zonder met andere business lines te hoeven afstemmen en concessies te doen. Ook wil je niet wachten op de voor alle business lines geschikte generieke oplossing.

Dit vraag om een architectuur waarbij zorgvuldig is afgewogen welke componenten generiek of specifiek zijn en welke bovendien gedeeld gebruikt worden. Soms is al veel flexibiliteit te creëren door de mogelijkheid te scheppen verschillende versies van generieke componenten naast elkaar in productie te kunnen nemen. Dat voorkomt moeizame releaseplanningen. Versiebeheer wordt wat complexer, maar hogere wendbaarheid maakt veel goed.

Continuous Architecture: organisatiestructuur volgt architectuur

In mijn vorige blog: de 10 best practices van continuous architecture, heb ik als één van de onderdelen genoemd dat de teamsamenstelling binnen een organisatie een afspiegeling dient te zijn van de architectuur. In deze blog zal ik dit verder toelichten en mijn zienswijze hierop geven.

Wat moet je doen als je als organisatie een op SOA principes gebaseerde architectuur hebt omarmt, maar jou ICT organisatie nog traditioneel is ingericht. Functionele afdelingen van ontwikkelaars, testers, infraspecialisten, soms nog per gebruikte technologie waarvan mensen als naar gelang behoefte worden ingezet in projecten. Projecten die allemaal bouwen aan hetzelfde op SOA gerichte IT-landschap, en daardoor ook meer en meer afhankelijkheden krijgen van elkaar. Lees Verder

4 leidende uitgangspunten voor samenwerking en ketenintegratie(architectuur)

In navolging van mijn laatste blogpost waarin ik vaststel dat er maar weinig ketenintegratiearchitecturen zijn opgesteld zal ik in deze blogpost nader ingaan op vier (4) leidende uitgangspunten. Als architect mag ik ook wel de term ‘leidende principes’ hanteren. In de rest van dit artikel zal ik echter de term uitgangspunten blijven hanteren.
Een aantal van deze leidende uitgangspunten hebben ook in de voorgaande blog de revue kort gepasseerd. Deze onderstaande uitgangspunten zijn wat mij betreft de basis voor de realisatie van een succesvolle samenwerking en ketenintegratiearchitectuur.

Voorwaardelijk aan ondergaande uitgangspunten is dat alle partijen in de keten werken aan een gemeenschappelijk doel. Dit gezamenlijke doel kan wettelijk bepaald zijn of het behalen van een bepaald belang: bijvoorbeeld winst, verbeteren klantrelatie en dienstverlening etc.

Uitgangspunt 1: Vertrouwen

Er dient een wederzijds vertrouwen te bestaan tussen de ketenpartijen. Indien het vertrouwen ontbreekt zal de keten nooit succesvol kunnen worden. De uitdrukking ‘de keten is zo sterk als de zwakste schakel’ is hierin echt van toepassing. Lees Verder

Ontwikkelen en Inrichten onder Architectuur (Deel4)

Ontwikkelen & Inrichten onder Architectuur (DEEL 4/4)

Richten, Inrichten en Verrichten

Managers en Enterprise Architecten die onder architectuur een organisatie ‘Ontwikkelen en Inrichten’ doen dat in een continu proces van ‘Richten, Inrichten en Verrichten’. Zij betrekken daarbij de interne en externe ontwikkelingen die zich nu en wellicht in de nabije toekomst voltrekken. Met behoudt van de nodige realiteitszin, confronteren zij de actuele stand van de huidige inrichting met hun bevindingen. Bij de realisatie van een nieuwe inrichting, ligt de focus vooral op Lees Verder

10 best practices van Continuous Architecture

In mijn vorige blog heb ik gesproken over de noodzaak voor Continuous Architecture. Het vakgebied Architectuur dient zich aan te passen aan de agile omgeving waarin het zich bevindt. Architectuur moet het doel hebben om continu en just-in-time voorzien van architectuur aan teams, programma’s en de organisaties als geheel.

In deze blog bespreek ik 10 best practices om Continuous Architecture in de praktijk vorm te geven:

1. Architectenrol in teams (2-4 teams per architect)
Elk agile ontwikkelteam dient de rol van architect te kennen en deze ook in te vullen. Een architect (met kennis van business, informatie en infrastructuur) is voor deel van zijn tijd toegewezen aan team. De architect zal ook bij het team zijn enige werkplek hebben. Meestal is het geen fulltime functie en kan één architect meerdere teams bedienen (2-4). De architect is beschikbaar voor directe architectuur vragen vanuit de teams tijdens de dagelijkse standups, welke zo veel mogelijk worden bijgewoond door de architect. Lees Verder

Samenhang tussen meerdere organisaties en/of allianties door projectie

De relaties tussen verschillende organisaties en hun contractuele allianties kunnen ook worden uitgedrukt door middel van projectie. In onderstaande figuur hebben we als voorbeeld de bekende alliantie Senseo afgebeeld, een contractuele alliantie tussen Philips en Sara Lee / DE.

Dit voorbeeld is ontleend aan het werk op het gebied van de alliantiebesturing van De Man (2006). De Man onderscheidt met betrekking tot de besturing van contractuele allianties 13 bouwstenen, alle geplaatst op een dichotomie formeel / informeel. Als het karakter van de alliantie een sterkere ‘control’ benadering vergt worden de elementen uitgedrukt op het corresponderende deel van de dichotomie, zoals de juridische vorm, financiële afspraken, scope en exclusiviteit, conflictoplossing procedures en gezagsverhouding / hiërarchie, meer dominant in de besturing van de alliantie. Lees Verder

Continuous Architecture, the next wave…

Meer en meer organisaties organiseren hun IT voortbrengingsproces op een Agile manier. De slechte ervaringen met de oude manier van werken, de vele IT projecten die zijn mislukt of gigantisch zijn uitgelopen, maar ook de belofte om continu waarde te leveren haalt vele organisaties over de streep. De eerste resultaten hierbij zijn ook goed. Er wordt veel sneller werkende software gerealiseerd en organisaties merken dat om deze snel in hun landschap te laten landen er ook veel meer aandacht moet zijn voor automatisch testen en continuous deployment. Continu werken aan werkende software op basis van de prioriteiten gesteld door de product owner zorgt er daarnaast voor dat projectmatig werken ook steeds meer op de achtergrond verdwijnt. Lees Verder

Zelfrijdende overheid

Onlangs hadden we het op de NAF Insight van 26 maart jl. over Decision Oriented Architecture. Beslissingstechnologie en andere Artificiële Intelligentie technologie zijn aan een flinke revival bezig. In dat kader vroeg ik mij af of het niet tijd wordt voor een zelfrijdende overheid.

Google's self driving car

Google’s self driving car

Lees Verder

Agile Enterprise Architectuur met GEA en SAFe

Begin januari ben ik een certified Scaled Agilist geworden door het examen te halen zoals dat wordt aangeboden na een training van SAFe (scaled agile framework). Ik heb die gevolgd omdat ik heilig geloof in de agile principes bij systeemontwikkeling, en ook benieuwd was op welke manier architectuur aan bod zou komen zodra de methode boven individuele teams uitstijgt. Bij technieken als Scrum is architectuur al vaak ondergesneeuwd, of wordt er gesproken over emerging design, waarmee min of meer gezegd wordt dat de architectuur vanzelf zal ontstaan. Architectuur wordt daar echter sterk verward met Ontwerp en software architectuur. Bij architectuur gaat het volgens mij om Inzicht in en sturen op Samenhang.  Samenhang tussen afdelingen, tussen applicatie componenten, tussen doelstellingen ,tussen business  en IT. Lees Verder

Ervaring met werken onder architectuur

Werken onder Architectuur is bij veel organisaties ingericht, maar niet altijd op de goede manier. In deze blog wil ik mijn ervaringen hierover met je delen.

Het werken onder architectuur is geen doel op zich, het is een manier om grip te krijgen op de informatievoorziening en bedrijfsvoering. Architectuur moet de bedrijfsstrategie en doelen van de organisatie ondersteunen. Verder zullen veranderingen die in de markt en binnen de organisatie gebeuren in samenhang onder architectuur uitgevoerd moeten worden. Om te zorgen dat “werken onder architectuur” gaat functioneren, is het allereerst van belang dat de visie over architectuur bekend is. Dit is nodig zodat we dan de architectuur producten, organisatie en processen die daarbij horen goed kunnen inrichten. Lees Verder

Contact

Wattbaan 51-1, 3439 ML Nieuwegein, Nederland
Telefoon: 030–602 82 80
Website: http://iteye.wpengine.com
Email: info@it-eye.nl