Vorige week ben ik bij het LAC (Landelijk Architectuur Congres) geweest in Nieuwegein. Ik ben nu een paar jaar Software Architect bij RBK en had dit ooit ergens ingevuld. Heel “toevallig” (toeval bestaat niet :-) ) kreeg ik een uitnodiging voor het LAC 2011. Aangezien ik nog genoeg te leren heb op dit gebied leek het me niet verkeerd om dit 2-daagse congres bij te wonen.
Het was een leuk, interresant en nuttig congres, waarbij ik veel geleerd heb. Het was wel even wennen: het was namelijk geen technisch congres (ik heb maar een keer Java en Oracle voorbij horen komen) wat ook te zien was aan de vele iPads en MacBooks (echte programmeurs hebben niet zo’n ding ;-) ). Veel algemene informatie gehoord, echter helaas weinig inhoudelijk over goede/slechte architecturen, tips, etc.
Over het algemeen staat niet vast wat een “architect” nu precies is, de meningen zijn nogal verdeeld. Per bedrijf en situatie is dit anders. Sowieso kunnen verschillende niveaus en typen aangegeven worden: Enterprise, Application, Infrastructuur/Netwerk, Informatie Architect etc.
Wel is duidelijk dat de architect van vroeger niet meer kan: gekscherend de “stugge dictator”. De technische ontwikkelingen gaan snel, veel veranderingen, en als bedrijf moet je snel kunnen veranderen. Dit betekent een flexibele architectuur die meehelpt in plaats van tegenwerkt.
De eerste keynote was van de CIO van ministerie van VWS. Zijn onderwerp: “doe maar klein en gewoon”. Architecten kunnen hele mooie diagrammen en techische documenten maken, en die kunnen echt “heel waar” zijn, maar niet-technische mensen begrijpen die totaal niet. Dus daar moet je bij het management niet mee aankomen. Beter is om een simpele tekening te maken en Jip & Janneke taal te gebruiken. Ook belangrijk is te weten wat bij bestuurders leeft: het aantal gigabytes of de betrouwbaarheid van de opslag, de snelheid of de veiligheid van geheime documenten in cloud?
De volgende keynote was van de Application Architect van de UBS Bank (Engeland). Hij beveelde aan om de “principles” goed te communiceren: plat gezegd het “waarom”. Als bijvoorbeeld op management niveau bepaalde beslissingen genomen worden, moet dit vertaald worden naar een globale technische structuur op het Enterprise niveau. Vervolgens wordt dit omgezet in gedetailleerdere structuur op Application niveau. Als laatste moeten de Developers dit uitvoeren.
Als alleen de kale eisen van hogerhand opgelegd worden, zullen de onderliggende lagen dit proberen te omzeilen. Daarom moet je het “waarom” steeds communiceren, zodat men het doel weet, dat het niet maar zo verzonnen is, etc. De mensen gaan dan meedenken en keuzes maken omdat men begrijpt waarvoor het is. Een belangrijk aspect is dat je feedback krijgt: bepaalde wensen kunnen tegen praktische problemen lopen. Normaal krijg je dit niet te horen, maar door de feedback krijgen de “hogere”lagen de bewustwording dat iets niet uitgevoerd kan worden.
Tussen de sessies door konden bedrijven in een Speakers Corner hun verhaal kwijt. Zo zal volgens Citrix het “Bring Your Own Device” concept steeds belangrijk worden. Werknemers hebben gemiddeld 3 devices (PC, Laptop, Smartphone, tablet, etc). Door deze via Citrix te verbinden kan de gebruiker overal zijn werk doen: sessies en data worden automatisch gesychroniseerd. De gebruiker kan vervolgens zelf zijn eigen device uitkiezen, meenemen of zelfs kopen...
De laatste sessies van de 1e dag die ik gevolgd hebben gingen over Agile en Architectuur. Deze zijn allebei nodig: de Waterfall methode is niet meer te doen in deze tijd, alleen in uitzonderlijke situaties zijn ze nog bruikbaar. Agile is de oplossing om debacles te voorkomen, maar waarbij de architectuur zeker belangrijk is! Ook bij de overheid wordt steeds meer Agile gewerkt, en met succes.
Interresant was te horen hoe Rabobank op deze manier werkt. Eerst hadden ze enkele langzame trage projecten van bijvoorbeeld 2 jaar. Nu hebben ze meerdere verschillende kleine teams met elk een eigen project. Bijna elke week verandert er wel iets (kleins) op www.rabobank.nl. Maar ook interne software wordt op de agile manier gedaan: bijvoorbeeld in een nieuwe versie konden ze een nieuw soort hypotheek/verzekering eerst alleen maar aanmaken, in de volgende week of nog later pas deze muteren. Dit lijkt raar, maar in de praktijk was het erg succesvol: in de 1e week waren er al 300.000 van het nieuwe product waren verkocht! Dus de 1e versie, hoe beperkt, was gelijk succesvol.
Dit agile werken houdt wel in dat de architect anders moet werken: teams werken veel sneller, maar hebben een beperkte scope. De architect heeft wel het overzicht en moet de structuur in de gaten houden. Hij moet “bij” alle teams zijn, maar kan niet “in” elk team zitten. Oftewel ook flexibel kunnen werken en wisselen en goed priotoriseren: zorgen dat niemand op jou wacht.
Om echt te profiteren van de snelle en flexibele software afdeling, moet het bedrijf in zijn geheel agile gaan werken. Want je hebt niets aan een 2 wekelijkse update als de implementatie afdeling maar per half jaar updates uitrolt. Meestal kan de QA/Test afdeling goed agile werken, en vinden de testers dit erg prettig: snelle feedback en betere samenwerking. De business en implementatie afdelingen (bovenste c.q. laagste laag) leveren meestal problemen op. Deze moeten erg wennen aan de nauwere betrokkenheid, meer en gerichte vragen, meer updates, etc.
Niet alleen software kun je agile maken, maar ook als bedrijf in het algemeen. Je kunt dan een bepaald business onderdeel of dienst agile maken, zodat je snel op marktveranderingen kunt reageren. Hierbij is het nodig dat je weet wat de barrières in je bedrijf zijn, wat de hotspots zijn (risico, belangrijk, impact, etc), welke je eventueel kunt uitbesteden, etc.
“Lean” kun je ook gebruiken: dit is echter een niveau hoger dan agile: eerst heb je bijvoorbeeld XP (coding standards, test driven development, contineous intergration, design patterns, etc), daarbovenop komt agile (als proces: korte sprints, alleen documenteren wat nodig is, etc). Lean is weer algemener en kun je gebruiken om binnen je bedrijf te kijken welke bedrijfsprocessen je kunt optimaliseren: bijvoorbeeld onderzoeken hoe lang het duurt totdat een bugmelding opgelost is, en waar de meeste tijd/vertraging in zit.
Als laatste werd een reallife casus besproken waarbij SOA (Service Oriëntend Architechture) gebruikt werd. Deze sessie was wel praktischer, hoewel ook een beetje simpel. Gedemonstreerd werd dat je door alleen RPCs (remote procedure call) en (web)services te gebruiken je niet direct flexibeler hoeft te zijn. Belangrijk is dat de business logica op 1 plek ligt (in de service) en niet bij alle clients: als een business rule verandert dan moeten alle clients geupdate worden. Eenvoudig en logisch maar misschien juist daarom snel over het hoofd gezien?
(dit was dag 1, hopelijk de volgende keer dag 2)
Het was een leuk, interresant en nuttig congres, waarbij ik veel geleerd heb. Het was wel even wennen: het was namelijk geen technisch congres (ik heb maar een keer Java en Oracle voorbij horen komen) wat ook te zien was aan de vele iPads en MacBooks (echte programmeurs hebben niet zo’n ding ;-) ). Veel algemene informatie gehoord, echter helaas weinig inhoudelijk over goede/slechte architecturen, tips, etc.
Over het algemeen staat niet vast wat een “architect” nu precies is, de meningen zijn nogal verdeeld. Per bedrijf en situatie is dit anders. Sowieso kunnen verschillende niveaus en typen aangegeven worden: Enterprise, Application, Infrastructuur/Netwerk, Informatie Architect etc.
Wel is duidelijk dat de architect van vroeger niet meer kan: gekscherend de “stugge dictator”. De technische ontwikkelingen gaan snel, veel veranderingen, en als bedrijf moet je snel kunnen veranderen. Dit betekent een flexibele architectuur die meehelpt in plaats van tegenwerkt.
De eerste keynote was van de CIO van ministerie van VWS. Zijn onderwerp: “doe maar klein en gewoon”. Architecten kunnen hele mooie diagrammen en techische documenten maken, en die kunnen echt “heel waar” zijn, maar niet-technische mensen begrijpen die totaal niet. Dus daar moet je bij het management niet mee aankomen. Beter is om een simpele tekening te maken en Jip & Janneke taal te gebruiken. Ook belangrijk is te weten wat bij bestuurders leeft: het aantal gigabytes of de betrouwbaarheid van de opslag, de snelheid of de veiligheid van geheime documenten in cloud?
De volgende keynote was van de Application Architect van de UBS Bank (Engeland). Hij beveelde aan om de “principles” goed te communiceren: plat gezegd het “waarom”. Als bijvoorbeeld op management niveau bepaalde beslissingen genomen worden, moet dit vertaald worden naar een globale technische structuur op het Enterprise niveau. Vervolgens wordt dit omgezet in gedetailleerdere structuur op Application niveau. Als laatste moeten de Developers dit uitvoeren.
Als alleen de kale eisen van hogerhand opgelegd worden, zullen de onderliggende lagen dit proberen te omzeilen. Daarom moet je het “waarom” steeds communiceren, zodat men het doel weet, dat het niet maar zo verzonnen is, etc. De mensen gaan dan meedenken en keuzes maken omdat men begrijpt waarvoor het is. Een belangrijk aspect is dat je feedback krijgt: bepaalde wensen kunnen tegen praktische problemen lopen. Normaal krijg je dit niet te horen, maar door de feedback krijgen de “hogere”lagen de bewustwording dat iets niet uitgevoerd kan worden.
Tussen de sessies door konden bedrijven in een Speakers Corner hun verhaal kwijt. Zo zal volgens Citrix het “Bring Your Own Device” concept steeds belangrijk worden. Werknemers hebben gemiddeld 3 devices (PC, Laptop, Smartphone, tablet, etc). Door deze via Citrix te verbinden kan de gebruiker overal zijn werk doen: sessies en data worden automatisch gesychroniseerd. De gebruiker kan vervolgens zelf zijn eigen device uitkiezen, meenemen of zelfs kopen...
De laatste sessies van de 1e dag die ik gevolgd hebben gingen over Agile en Architectuur. Deze zijn allebei nodig: de Waterfall methode is niet meer te doen in deze tijd, alleen in uitzonderlijke situaties zijn ze nog bruikbaar. Agile is de oplossing om debacles te voorkomen, maar waarbij de architectuur zeker belangrijk is! Ook bij de overheid wordt steeds meer Agile gewerkt, en met succes.
Interresant was te horen hoe Rabobank op deze manier werkt. Eerst hadden ze enkele langzame trage projecten van bijvoorbeeld 2 jaar. Nu hebben ze meerdere verschillende kleine teams met elk een eigen project. Bijna elke week verandert er wel iets (kleins) op www.rabobank.nl. Maar ook interne software wordt op de agile manier gedaan: bijvoorbeeld in een nieuwe versie konden ze een nieuw soort hypotheek/verzekering eerst alleen maar aanmaken, in de volgende week of nog later pas deze muteren. Dit lijkt raar, maar in de praktijk was het erg succesvol: in de 1e week waren er al 300.000 van het nieuwe product waren verkocht! Dus de 1e versie, hoe beperkt, was gelijk succesvol.
Dit agile werken houdt wel in dat de architect anders moet werken: teams werken veel sneller, maar hebben een beperkte scope. De architect heeft wel het overzicht en moet de structuur in de gaten houden. Hij moet “bij” alle teams zijn, maar kan niet “in” elk team zitten. Oftewel ook flexibel kunnen werken en wisselen en goed priotoriseren: zorgen dat niemand op jou wacht.
Om echt te profiteren van de snelle en flexibele software afdeling, moet het bedrijf in zijn geheel agile gaan werken. Want je hebt niets aan een 2 wekelijkse update als de implementatie afdeling maar per half jaar updates uitrolt. Meestal kan de QA/Test afdeling goed agile werken, en vinden de testers dit erg prettig: snelle feedback en betere samenwerking. De business en implementatie afdelingen (bovenste c.q. laagste laag) leveren meestal problemen op. Deze moeten erg wennen aan de nauwere betrokkenheid, meer en gerichte vragen, meer updates, etc.
Niet alleen software kun je agile maken, maar ook als bedrijf in het algemeen. Je kunt dan een bepaald business onderdeel of dienst agile maken, zodat je snel op marktveranderingen kunt reageren. Hierbij is het nodig dat je weet wat de barrières in je bedrijf zijn, wat de hotspots zijn (risico, belangrijk, impact, etc), welke je eventueel kunt uitbesteden, etc.
“Lean” kun je ook gebruiken: dit is echter een niveau hoger dan agile: eerst heb je bijvoorbeeld XP (coding standards, test driven development, contineous intergration, design patterns, etc), daarbovenop komt agile (als proces: korte sprints, alleen documenteren wat nodig is, etc). Lean is weer algemener en kun je gebruiken om binnen je bedrijf te kijken welke bedrijfsprocessen je kunt optimaliseren: bijvoorbeeld onderzoeken hoe lang het duurt totdat een bugmelding opgelost is, en waar de meeste tijd/vertraging in zit.
Als laatste werd een reallife casus besproken waarbij SOA (Service Oriëntend Architechture) gebruikt werd. Deze sessie was wel praktischer, hoewel ook een beetje simpel. Gedemonstreerd werd dat je door alleen RPCs (remote procedure call) en (web)services te gebruiken je niet direct flexibeler hoeft te zijn. Belangrijk is dat de business logica op 1 plek ligt (in de service) en niet bij alle clients: als een business rule verandert dan moeten alle clients geupdate worden. Eenvoudig en logisch maar misschien juist daarom snel over het hoofd gezien?
(dit was dag 1, hopelijk de volgende keer dag 2)
1 opmerking:
c444h1mthgz675 custom sex doll,wholesale sex toys,sex chair,black dildos,fantasy toys,bullets and eggs,Clitoral Vibrators,realistic dildo,cheap sex toys z830n3anpor696
Een reactie posten