De volgende artikelen van de hand van Erik Philippus zijn de afgelopen jaren verschenen als column of artikel in vaktijdschriften, en worden vaak gebruikt als referentie of als hand-out bij workshops van ImprovemenT:

• Het belang van een informeel netwerk
• De zin en onzin van het lagen model
• Een juiste diagnose
• Het huwelijk tussen Agile en Architectuur
• De Agile Parachute
• Agile & Architecture: Friends or Foes
• Agile in tijden van recessie
• Waar is de architect gebleven?
• Modernization of Legacy Systems
• Software Quality is Free
• Op de rand van de chaos
• Rijkswaterstaatarchitectuur
• De planologie van softwaresystemen
• Haat-liefde verhouding met complexiteit
• ICT'ers krijgen de methodiek die ze verdienen
• Software maken blijft mensenwerk
• Een brug te ver
• De menselijke maat
• De spiegel van de software architect
• Winchester Mystery House
  

Het belang van een informeel netwerk

Voor architecten is het hebben en onderhouden van een breed, informeel netwerk van groot belang. Goed de weg weten in een multidisciplinaire omgeving is geen overbodige luxe als je te maken krijgt met perikelen rond integratie en test. Bovendien is het vrijwel onmogelijk om als architect van alle markten thuis te zijn, dus eens kunnen brainstormen met een vakgenoot uit een ander domein komt de kwaliteit van de architectuur alleen maar ten goede. Zeker in een wereld waar disciplines steeds dichter bij elkaar komen, is deel uit maken van een gemêleerd, informeel netwerk eigenlijk een voorwaarde om als architect bevredigend te kunnen opereren. Ter illustratie een anecdote, opgetekend in dit artikel.

De zin en onzin van het lagen model

Door middel van abstractie verbergt een architectuur details van het systeem, zodat we belangrijke, gewenste eigenschappen van een systeem kunnen identificeren, specificeren en borgen. Abstraheren is daarnaast een noodzakelijk proces om vanuit individuele gevallen tot algemeen geldende principes te komen. Een van oudsher veel toegepast principe is de gelaagde architectuur of multi-tier architecture,  waarbij systeem gedrag wordt verdeeld over verschillende niveaus van abstractie.

Deze opdeling in verschillende lagen is een veralgemenisering van het streven naar  loose coupling en high cohesion, bedoeld om software modules op een hoger niveau van inzetbaarheid en uitbreidbaarheid te brengen. De heuristiek die hierbij wordt toegepast, is de z.g. Law of Demeter,

In de praktijk is het helaas niet al goud wat er blinkt. Een fundamentele tekortkoming van het lagen model is dat het op gespannen voet staat met de z.g. cross-cutting concerns: functies die orthogonaal staan op de verantwoordelijkheden van de afzonderlijke lagen, Lees in dit artikel meer over de zin en onzin van het lagen model.

Een juiste diagnose

Probleem is dat diagnostiek, net als foutafhandeling, nog vaak wordt gezien als add-on in plaats van als integraal onderdeel van de systeemarchitectuur. Daardoor kent de diagnose-functionaliteit die we bijvoorbeeld in een moderne auto vinden nog diverse tekortkomingen. Een doelgerichte foutafhandeling en diagnostiek worden pas echt succesvol als de (systeem)architectuur ze expliciet ondersteunt. In dit artikel wordt deze mooie en
belangrijke taak voor de architect nader uit de doeken gedaan.

Het huwelijk tussen Agile en Architectuur

De relatie tussen agile en architectuur blijft een heikel punt. De grote boze wolf van veel agile adepten is het ‘BDUF’ (Big Design Up Front), een ontwikkelingsmethode waarbij het algemene ontwerp gemaakt wordt voordat met implementatie wordt gestart. Fanatieke agilisten betogen zelfs dat architecten ‘dinosaurussen’ zijn die zich vastbijten in een verouderde methodiek. Helemaal ongelijk hebben ze niet, want er zijn verstokte architecten die moeite hebben om achter de kristallen bol vandaan te komen. Gelukkig hebben de
meeste architecten de ivoren toren nu wel achter zich gelaten, Natuurlijk zal het tevoren uitdenken van bepaalde zaken ons later veel ellende besparen. Zeker als het gaat om de realisatie van complexe en omvangrijke software-intensieve systemen, blijft architectuur onmisbaar. Wie architectuur als vertegenwoordiger van het watervalmodel van tafel veegt, gooit het kind met het badwater weg. Zoals in dit artikel te lezen, is echter niet verkeerd om eens met een agile bril op naar architectuur te kijken.

De Agile Parachute

Verum's CEO Rob Howe heeft (stunt)vliegen als hobby. In een artikel in Bits & Chips trekt Rob een vergelijking tussen een piloot en projectmanager, en vraagt hij zich af hoe de vliegerij zou werken met een Agile-aanpak. Ik heb daar eens mijn gedachten over laten gaan, en als reaktie dit artikel geschreven.

Agile & Architecture: Friends or Foes?

The recent emergence of agile methods has shaken the foundation of the ivory tower architecture. A new breed of architects called Agile Architects is stepping up.

Architecture has always been controversial in the agile community. Should design be done up front, how much, and when does architecture turn into BDUF, the big bad wolf of agile programming? The agilists are right to some extend: most traditional architecture processes are heavy weight, long-winded and time-consuming. In circles of architects, however, agile methods are perceived as architecturally weak, disconnected from the realities of delivering large, multidisciplinary software-intensive systems in complex environments. As outlined in this article, Agile Architecting is an attempt to combine the best of both worlds.

Agile in tijden van recessie

In het in 2001 verschenen artikel “Moving Upward in a Downturn”, doet Darrell Rigby uit de doeken hoe bedrijven een economische neergang kunnen benutten in plaats van eraan ten onder te gaan. Het artikel heeft destijds weinig aandacht gekregen, want na 2001 volgden zeven vette jaren, en wie maakt zich dan druk om een recessie? Nu de angst voor een wereldwijde economische neergang snel om zich heen grijpt, lijkt de tijd rijp om Rigby’s artikel nog eens onder de loupe te nemen.

De aanbevelingen in het artikel van Rigby lijken onverkort van toepassing te zijn op organisaties met software ontwikkeling als core business. Uiteraard worden er al veel langer pogingen ondernomen om tot een meer efficiente aanpak van softwareproductie te komen, iets dat met name speelt in de ontwikkeling van complexe, software-intensieve apparaten in een multidisciplinaire omgeving. Toch is het opvallend dat alle, door Rigby genoemde punten terugkomen in de Agile aanpak, met name in de Scrum methode voor project management. De voorliggende vraag is of het aanbeveling verdient om - juist in tijden van recessie – anticyclisch te investeren in de Agile Scrum manier van werken. Dit artikel geeft het antwoord op die vraag.

Waar is de architect gebleven?

Geïllustreerd door een voorval bij het bouwen van een huis onder architectuur, wordt in dit artikel beschreven dat ook in het software domein ontwikkelaars en gebruikers zich vaak noodgedwongen moeten aanpassen aan de architectuur van een systeem, in plaats van andersom. Zou de mate van betrokkenheid van de architect bij het bouwen en in gebruik stellen van producten op basis van zijn of haar architectuur daar iets mee te maken hebben?

Modernization of Legacy Systems

Most organizations facing severe legacy problems are trapped in a downward spiral of spending an increasing amount of resources on maintaining the obsolete software system, including continuous bug-fixing, preparation of hot fixes for urgent problems in the field, updating the old system with new features in a non-economical way, etc. Sooner or later the organization will find itself in sheer survival mode, spending nearly all the available development budget on corrective maintenance instead of innovation. This article describes a pragmatic, step-wise approach for the modernization of legacy systems.

Software Quality is Free

The traditional view on software development projects is that there is always a tension between time, money and quality. “You can’t have all three”, is the widespread software engineering truism, also known as the famous ‘devil’s triangle’. The common conviction is  that a need to cut costs will inevitably result in a lower quality, or that strict ensurance of quality will probably jeopardize the project planning. It rarely happens that quality is deployed explicitly as a means to bring a project back on track. Existing methods of project scheduling focus on time/cost tradeoffs, but do not model quality explicitly.
In this article, Erik Philippus makes a stand against this subsidiary role of software product quality. Based on his own experience as an architect and consultant in a large variety of software development projects, he will argue that it is the lack of the quality that is expensive, not the quality itself.

Op de rand van de chaos

Menig architect heeft te maken met uit de pan rijzende complexiteit van multidisciplinaire, software-intensieve systemen. De integratieproblematiek tijdens het realisatieproces van het product, de diverse systeemconfiguraties in de hand en het stabiel krijgen en houden van complexe machines zijn vaak uitdagingen van formaat. We moeten als architect het onderscheid maken tussen het deel van het systeem dat we onder controle kunnen (en ook moeten) brengen met behulp van ‘traditionele’ ontwikkelmethoden, en een deel van het systeem waarvoor we dat nu juist niet moeten doen. Voor dit laatste, vaak kleiner maar vitaal onderdeel van het systeem moeten we maximale adaptiviteit zien te bereiken. Dit artikel moedigt de ‘Agile Architect’ aan om het juiste onderscheid tussen beide delen te maken.

Rijkswaterstaatarchitectuur

Nogal wat bedrijven worstelen met legacyproblematiek. De moeilijkheid is niet zozeer het ontwerpen van een verbeterde architectuur, maar eerder de combinatie van de lopende projecten met de renovatiewerkzaamheden, vaak omschreven als: ‘verbouwen met de winkel open’. Hoe doe je dat op een effectieve manier? Dit artikel gebruikt de metafoor van de aanleg van de Eindhovense randweg om aan te geven waar je mee te maken krijgt als je eens goed de bezem door het softwarebouwwerk wilt halen en tegelijkertijd de hete adem in je nek voelt van de eerstvolgende release.

De planologie van software systemen

Vaak wordt beweerd dat software-ontwikkeling een unieke tak van sport is, en dat we vooral op onszelf zijn aangewezen om ons vakgebied tot volwassenheid te brengen. In dit artikel wordt uitgebreid stilgestaan bij de overeenkomsten van software-ontwikkeling en planologische besliskunde. Met name de 'Mixed Scanning Methode' die al decennia lang wordt gebruikt bij het nemen van belangrijke stedebouwkundige beslissingen, kan in ons vak tot voorbeeld dienen om de Agile aanpak te laten landen in projecten voor de ontwikkeling van complexe, multidisciplinaire software-intensieve systemen. In het artikel wordt een voorstel voor 'Mixed Scanning' voor de Agile Scrum methode uitgewerkt.

De haat-liefde verhouding met complexiteit

Complexiteit is een hot issue als het gaat om de ontwikkeling van ingewikkelde, software-intensieve systemen. Gebaseerd op het reductionistische wereldbeeld, trachten vrijwel alle ontwikkelmethodieken complexiteit krampachtig onder de duim te krijgen. Complexiteit wordt gezien als onvermijdelijk gevolg van software evolutie, en op allerlei manieren moet worden voorkomen dat ongewenste complexiteit roet in het eten gooit. Dit is een vorm van doorgeschoten controle-denken, gebaseerd op het idee van de 'maakbare wereld'. De realiteit is echter dat turbulentie en onzekerheid een normaal en dagelijks onderdeel vormen van software projecten. Sterker nog: complexiteit is eerder een voorwaarde voor, dan een gevolg van evolutie!
In dit Engelstalig artikel wordt het gedrag van complexe systemen toegelicht aan de hand van de 'complex systems theory'. Het is een uitnodiging voor systeem architecten om eens een andere invalshoek te kiezen voor het bouwen van complexe software systemen, mede geinspireerd door de chaos theorie.

ICT'ers krijgen de methodiek die ze verdienen

De vermeende communicatieve handicap van ICT’ers blijft een dankbaar onderwerp van discussie. ICT’ers vormen zelfs een veiligheidsrisico van binnenuit vanwege hun introverheid, zo lezen we op de voorpagina van Computable. Door hun cognitieve benadering van problemen verloopt de besluitvorming minder adequaat. Dit artikel plaatst vraagtekens bij deze nogal eenzijdige benadering. Gedragspatronen van de ICT’er zijn niet los te zien van het hardnekkige paradigma dat de software industrie al tientallen jaren in z’n greep heeft. Er is een paradigmaverschuiving nodig om het gedrag van ICT’ers blijvend te veranderen. Gelukkig wint het Agile gedachtengoed snel aan populariteit, een hoopvol teken dat deze paradigmaverschuiving al in gang is gezet. Lees hier meer over de evolutie van de ICT, geinspireerd door het gedachtengoed van Claire Graves en zijn model van 'value systems'.

Software maken blijft mensenwerk

Het maken van software gaat zelden van een leien dakje. Veel producenten van software-intensieve apparaten willen de kwaliteit van de afgeleverde producten structureel verhogen. De daarvoor benodigde investering in menskracht kan vaak niet worden gedaan, omdat een aanzienlijk deel van de engineers druk bezig is om de zaak bij de klant draaiend te houden. In de meeste ontwikkeltrajecten is nauwelijks tijd voor bezinning. Er wordt zo druk gezaagd, dat er geen tijd is om de zaag te slijpen. In dit artikel, eerder verschenen in het tijdschrift Bits & Chips, wordt aangegeven hoe een structurele verhoging van de productiviteit van het ontwikkelteam de ruimte verschaft om uit die spiraal te komen.

Een brug te ver?

Te pas en te onpas worden projecten in de civiele bouwwereld als analogie opgevoerd om software ontwikkel trajecten te verduidelijken. Het blijkt dat bij het al te gretig overnemen van concepten uit de fysieke bouwwereld, er nog wel wat addertjes onder het gras kunnen zitten. Lees in dit artikel meer over het (al dan niet terecht) toepassen in de IT van een metafoor uit de bouwwereld: de 'software bouwmanager'.

De Menselijke Maat

Wat heeft de menselijke maat met software, en in het bijzonder met architectuur te maken? Het nader beschouwen van de betekenis van de menselijke maat levert inzichten op, die zowel persoonlijk als zakelijk van belang zijn. Lees er hier meer over.

De spiegel van de software architect

Een succesvolle IT architect zal oog moeten hebben voor (on-)gewenste gedragspatronen ‘op de ontwikkelvloer’, maar dat laat onverlet dat een architect ook in staat moet zijn hand in eigen boezem te steken. Het kunnen reflecteren op de invloed van het eigen handelen, is kenmerkend voor het volwassen worden van de software architect. Ter kennismaking en aanmoediging van dit proces worden in dit artikel een aantal gedragspatronen van IT architecten, 'ter leering ende vermaek’.

Winchester Mystery House

Hoe het een bouwproject kan vergaan zonder duidelijike doelstelling, wordt op wonderlijke wijze geillustreerd door het Winchester Mystery House. Elk systeem heeft een architectuur, maar in dit geval kost het enige moeite om de logica te ontdekken... Lees hier meer over dit wonderlijke project.