A book on pragmatic software architecture, patterns and frameworks?

One of the major items on my wish list – that is on the professional half of it – is to write a book that displays my ideas on software architecture, patterns and frameworks. Yes I know, there are many books on software architecture, and there are many books that explain patterns, and yes there also are a lot of books that show you how to work with framework A, B or C.

So you would say, why on earth would you want to write a book on these subjects? Well there’s three major reasons. First, there’s not a lot of books out there that combine all these subjects into one single coherent story that will actually help you to write your applications better. Second, maybe I’m a bit arrogant on this, but I feel like I have something to all the stuff that’s out there. And last but not least, I finally need to get this stuff out of my head! Maybe ambitious, but let´s see!

Order from the menu

To be honest, you might like or not like all of the ideas in this book, or even may totally disagree with some of them. Actually, you probably will. But on the whole, I hope this book will be able to inspire you and illuminate you in how to build software. It´s often a matter of taste. So consider this book as a menu. Just order from it what you like. You don´t need to copy the C# and .NET code examples from the book, but rather I hope that use can use them to shape your own ideas on software architecture, frameworks and patterns. Take from it what you like, and forget about the few things you don’t like. 

A first step

What’s the first step towards writing this book? I’ve been teaching about software architecture, patterns and frameworks for .NET for quite a number of years, and the material from these courses will be a good start, similar to the way I shaped my book on UML – from iterating over the material I had for my UML courses.


Along with the course material comes the work I’ve done in projects, and as a result the work we (the core team) do on our ever-evolving and improving ADF.NET framework.

Architecture and frameworks

So here’s the overview of the material in the software architecture and patterns course:

  • Introduction. All the usual bla bla and thanks you stuff.
  • How to set up your software architecture? A mild and brief introduction. Thinking about layers, elements in layers,  collaborations (yes CRC). And of cause you can not start without summing up some of the good practices, such as
  • (Software architecture != List<Framework>). How people mix up architecture and frameworks.
  • How frameworks can kill your project. It’s all about dependencies guys. This chapter will be a write out of my talk with the same name.
  • Some patterns to help avoid getting killed. Explaining the different variations of layer super types, my fine descriptor pattern, and the use of dependency injection and the manager-provider pattern.
  • Glue 1.0. My first framework. Short introduction into setting up a minimal framework, using your architecture and the above patterns, minimizing dependencies between your application code and the frameworks you use. It should provide you with the glue to keep your “regular” developers in the loop.
  • Extension methods and fluent interfaces. Have got a bit (not all by far!) to say on how to use them to enable your application developers to code easier and more natural using your first framework.
  • Lasagna and ingredients. What layers would you need in your application? Suggesting presentation, process, domain and data/services. And suggesting a lot of elements in the different layers.


In the next chapters I will slowly go through the individual layers. First, let’s investigate the presentation layer:

  • Panels and lists. The basic patterns of presentation layer elements. And a straightforward implementation of a user interface independent panel. Just for the fun of it.
  • The master of detail. Introducing some typical user interface patterns, such as manage, select, search, master-detail, list-detail and the effect of those patterns on your architectural and Glue 1.0 framework requirements.
  • MVWTF. Looking at the different variations in model-view patterns, and discussing the relevance. But briefly, there’s enough said on this stuff.
  • Binding and persisting. Coupling and de-coupling your models, view-models, domain objects, whatever to and from the user interface.
  • The view-model. Sense and non-sense of view-models.
  • Validations. Things to validate and things not to validate in the user interface.


Next the process layer gets a rub:

  • Why do I need a process layer? Explaining the least well-understood layer in application architectures.
  • An brief introduction to smart use cases. Still an excellent unit of work, implementation and testing for projects. This chapter will follow the lines of my presentation on this particular topic.
  • Implementing smart use cases. Introducing the task pattern, and re-iterating the manager-provider pattern. Great stuff I think! Also re-visiting the MVWTF patterns again. 
  • Unit and regression testing smart use cases. How you can write your own extensions to regular unit test framework to allow regression tests over your smart use cases.


The layer it all revolves about:

  • About being domain driven. Design, code and test, do it domain driven. Now I’m not going to repeat Eric Evans’ book here, but I do repeat (briefly) the basic concepts that derive from his work. Think of entities, repositories, factories, value objects and services.
  • Augmenting your domain. However, we are using some additional patterns in our projects that are useful patterns. Here I’ll discuss the smart reference pattern, revisit value objects, and talk about cached domain objects. I might even introduce you to search objects.
  • Business rules and validations. How do you write and where do you place your business rules, and what validations do you execute in the domain layer?
  • Independent state. Domain objects, or entities, have identity and state. This state can come from a lot of place – not all being SQL Server. So the big question here is: can I keep my domain objects independent of how we get and set its state. Well yes you can, hence the internal state patterns jumps in.

Data, services and the outside world

All the way down to the bottom, in the cellar of your application, lies the data / services layer:

  • Does the data layer really exist? Hey weren’t we using NHibernate or Entity Framework? So why do we need a data layer, and if so, what is in it?
  • Map and wrap. When querying data sources it is very likely that you will need to provide some sort of mapping from your world to the outside world. I’ll show you some simple patterns of to achieve this mapping, allowing you to wrap your domain objects around the outside world’s objects.
  • Creating queries. Again, do you really need to implement a query patterns. We do have LINQ do we? Well yes, but LINQ does not cover all your possible sources of data – a lot, but not all. So a brief introduction of the query pattern – and some implementation aspects might not be a bad idea.
  • On the way out. Somehow you will need to reach out to the outside world of your application. Virtually the outside world can be just about anything. A (set of) databases of course, but what about OData, JSON, plain or not so plain XML, restful or restless web services, Twitter, Entity Framework, NHibernate, Facebook, you name it. The gateway pattern should help you here.


    Mildly put, this little blog post could well be the introduction for this new book – except for the thank you notes. Do you miss anything, or already agree or disagree? Want to help annotating or reviewing the manuscript in progress? Don´t hesitate to become a part of the writing process. Please comment here!

Een introductie in agile business intelligence [in Dutch]

Om kosten te besparen, een veelgenoemde aanleiding voor Business Intelligence (BI) projecten, wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Hierbij speelde een interessant fenomeen. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert daarentegen direct geld op. En dus ging men op zoek naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk frauders vinden.

[Dit artikel is gepubliceerd in Database Magazine]

De hiergenoemde doelstelling is archetyisch voor BI-projecten. Hoewel dergelijke doelstellingen vaak nog redelijk zijn te definieren, is de realisatie hiervan vaak schimmig. Welke rapportages moeten worden ontwikkeld en wat staat daar op? Welke bronsystemen moeten hiervoor worden geraardpleegd? En wanneer het project eenmaal loopt, doen zich doorlopend nieuwe inzichten voor. Bijvoorbeeld over het ontbreken van benodigde informatie in bronsystemen. En anders doet de opdrachtgever wel inspiratie voor nieuwe wensen en eisen op uit feedback over opgeleverde rapportages en analyses. BI-projecten kenmerken zich derhalve door onvolledige requirements en doorlopend voortschrijdend inzicht.

Op het gebied van systeemontwikkelmethodieken hebben zich de laatste jaren enorme veranderingen voorgedaan. Meer en meer organisaties en projecten stappen over een nieuwe generatie methodieken, die voortschrijdend inzicht niet langer schuwen, maar juist omarmen en zich kenmerken door cooperatieve samenwerking en het frequent, in korte iteraties opleveren van software. Deze methodieken worden wel de ook de agile methodieken genoemd. De vraag is hoe deze methodieken, afkomstig uit reguliere softwaredevelopment, ook een positieve bijdrage kunnen leveren aan het uitvoeren van BI-projecten.

Wat kenmerkt een BI-project?

De doelstellingen van BI-projecten zijn altijd direct business gerelateerd, zoals het minimaliseren van verzekeringsfraude of het behouden van klanten. Tijdens een project worden analyses en rapportages gedefinieerd die ondersteunen bij het beheersen en optimaliseren van de bedrijfsprocessen van de opdrachtgever. Deze rapportages en analyses worden – meestal dagelijks – gevoed uit het ontwikkelen datawarehouse. Kenmerkend voor dit type projecten is dat lastig is vast te stellen welke concrete bijdrage deze analyses en rapportages uiteindelijk leveren. Neem voorbeeld de eerdergenoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld men kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken en het aantal gevonden fraudeurs. Uiteindelij k bleek na afloop van het project dat de resultaten nog beter waren dan van te voren was geschat.

Alhoewel vroegtijdig in projecten nog is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks te formuleren. Wat wil de opdrachtgever nu echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecom operator. Pas toen de opdrachtgever het rapport onder ogen kreeg, bleken er diverse soorten inkomende berichten te zijn, die ook weer gekoppeld zijn aan diverse soorten uitgaande berichten. Een typisch voorbeeld van voortschrijdend inzicht.

Een interessant fenomeen is ook het extractie-, transformatie- en laadproces (ETL). Hierbij worden in een aantal stappen de gegevens uit bronsystemen verzameld, geïntegreerd en geaggregeerd tot een formaat dat voor de rapportages en analyse benodigd is. In de meeste BI-projecten beslaat dit type werk zo’n 80% van de ontwikkeltijd.




Toch blijft dit werk meestal onzichtbaar voor de opdrachtgever. Deze concentreert zich – terecht – vooral op de op te leveren rapportages en analyses. Maar doordat de bluk van het werk in een BI-project op ETL is gefocust, worden meestal ook de fasen van zo’n project rond ETL ingericht. Dat wil zeggen, dat eerst alle extracties worden ontwikkeld, aansluitend de transformaties, om vervolgens alle gegevens te laden. Pas nadat dit is gelukt worden de rapportages en analyses gedefinieerd, zoals weergegeven in onderstaand afbeelding.




Met als gevolg dat pas in deze laatste fase van het project iets wordt opgeleverd waarmee de opdrachtgever aan de slag kan. Dit heeft een belangrijk nadeel. Pas in een laat stadium geeft de klant feedback. Mogelijke aanpassingen aan rapportages en analyses als gevolg hiervan zijn nu lastig te realiseren omdat alle ETL al is opgeleverd. Bovendien is het niet uitgesloten dat als gevolg van deze feedback sommige stappen uit de ETL overbodig blijken. In dit laatste geval is er zelfs werk voor niet uitgevoerd. Dan wordt het BI-project een dure onderneming.

Tenslotte kan het nog voorkomen dat voor de gewenste rapportages en analyses gegevens nodig zijn die niet direct uit de bronsystemen zijn af te leiden. Aanvullende gegevens worden dan vaak handmatig toegevoegd tijdens de ETL. Vaak worden hiervoor gaandeweg het project kleine administratieve applicaties ontwikkeld. Nog los van het feit dat deze applicatietjes door de verkeerde ontwikkelaars worden ontwikkeld – business intelligence specialisten en geen reguliere ontwikkelaars – worden deze hiaten in gegevens meestal pas lopenede het project ontdekt. Met alle gevolgen vandien.

Wat kenmerkt agile software development?

In de reguliere software development is afgelopen jaren een hele nieuwe generatie aan methodieken ontstaan, die de best practices van vorige generaties koppelen aan een sterk iteratieve en cooperatief karakter. Deze methodieken, zoals DSDM, extreme programming, Scrum, Smart en feature driven development (FDD) kenmerken zich alle als volgt:

  • Korte iteraties. Werkende software wordt opgeleverd in korte iteraties, variërend van twee weken tot een maand. Tijdens ieder van deze iteraties wordt een klein deel van de software geanalyserd, ontworpen, gebouwd, getest en vaak zelds opgeleverd. Pas bij de start van een iteratie wordt vastgesteld welke functionaliteit tijdens de komende iteratie wordt ontwikkeld. Hiermee verkorten projecten de feedbacklus met de opdrachtegever rigoreus. Zo verbetert de kwaliteit van de ontwikkelde software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waarin de software vaak in een big bang wordt opgeleverd aan het eind van het project.
  • Compacte eenheid van werk. Bovenstaande kan alleen worden bereikt als er een eenduidige en kleine eenheid van werk wordt gehanteerd in projecten. Hierbij geldt dat individuele work items directe waarde vertegenwoordigen voor de opdrachtgever en bovendien zo klein zijn dat er meerdere zijn te realiseren tijdens een individuele iteratie.
  • Snel en frequent opleveren van software. Tijdens agile projecten wordt al tijdens de eerste iteraties software opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat problemen, bijvoorbeeld rond de architectuur, al vrij snel na de start van het project boven water komen.
  • Incorporeren voortschrijdend inzicht. Anders dan in traditionele projecten, waar voortschrijdend inzicht zoveel mogelijk wordt uitgebannen, is het in agile projecten mogelijk en zelfs gebruikelijk nieuwe requirements nog tijdens het lopende project mee te nemen. Hiertoe wordt pas bij de start van een iteratie vastgesteld welke work items tijdens deze iteratie worden opgepakt. Nieuw work items kunnen hierbij worden meegenomen, ten faveure over al eerder benoemde werk items.
  • Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen klant en opdrachtnemer, waarbij bij voorkeur op dagelijkse basis overleg plaatsvindt, bijvoorbeeld om de nieuwe gerealiseerde work items te bekijken.
  • Geïntegreerd testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is het testen van de software van cruciaal belang vanaf dag één in een project.


Een bekende agile methodiek is Smart, die veel is toegepast in reguliere systeemontwikkelprojecten. Deze methodiek is ooit ontwikkeld als implementatie van DSDM, maar is inmiddels uitgegroeid tot een kernachtige agile methodiek, waarin best practices zijn ondergebracht uit bijvoorbeeld Rational Unified Process, Scrum en extreme programming. Naast typische agile karakteristieken die hierboven zijn beschreven kent Smart een aantal additionele technieken, voortgekomen vanuit de praktijk. Deze technieken geven projecten een eenduidige eenheid van werk, maar helpen ook om de voortgang te bewaken:

  • Smart use cases. De eenheid van schatten, plannen, requirementsanalyse, ontwerp en ontwikkeling is een gestandaardiseerde vorm van use cases, die wel smart use cases worden genoemd. Smart use cases worden gebruikt om de functionele requirements van een project uit te drukken. Interessant aan deze smart use cases is dat ze gelijkmatig van grootte en complexiteit zijn, waardoor ze gemakkelijk zijn in te schatten, en zo klein zijn dat er diverse binnen het tijdbestek van een enkele iteratie worden gerealiseerd.
  • Smart estimation. Aanvullend hierop is een schattingstechniek die de totale complexiteit en omvang van een project uitgedrukt in smart use case punten. De smart use cases worden hiertoe uitgedrukt op een eenvoudige schaal, die van 1 tot 5 gaat, maar voor uitzonderingssituaties 8 en 10 heeft gereserveerd. Er zijn voor diverse typen projecten standaardtypen use cases geïdentificeerd, die al zijn uitgezet op deze schaal. Dit geldt voor het ontwikkelen van bedrijfsapplicaties, service-oriëntatie, content management en reporting, bijvoorbeeld met behulp van Sharepoint. Inmiddels zijn er ook standaardtypen voor ETL opgesteld.
  • Monitoring. De voortgang in Smart-projecten wordt voortdurend gemonitord via een tweetal pragmatisch gereedschappen. Zo wordt een agile dashboard gebruikt waarin de status van de smart use cases uit het project is uitgedrukt. Bovendien hanteren projecten een burn down chart, waarin steeds de verwachte einddatum is te extrapoleren.

Fasen van Smart

Smart kent een beperkt aantal eenvoudige fasen, zoals is weergegeven in onderstaande afbeelding. Een project is verdeeld over twee voorbereidende fasen genaamd Propose en Scope, een kortcyclische hoofdfase Realize, een afrondende fase Finalize en eventueel een fase voor het beheren van de applicatie die Manage wordt genoemd. Deze latste fase start zodra het project de software heeft opgeleverd.



In iets meer detail:

  • Propose. Tijdens deze fase wordt de scope, de omvang en de complexiteit van het project vastgesteld, uitgedrukt in smart use cases. Propose mondt uit in een projectvoorstel en een eerste schatting.
  • Scope. Tijdens Scope wordt het projectvoorstel verder uitgewerkt, waarbij onder meer herbruikbare componenten en niet-functionele requirements op het menu staan. Deze fase leidt tot het plan van aanpak voor de uitvoering van de rest van het project.
  • Realize. De fase Realize is gericht op het interactief realiseren van de software. Deze fase is opgedeeld in korte iteraties, liefst van twee weken. Tijdens iedere van deze iteraties worden een aantal smart use cases gerealiseerd. Welke use cases dit zijn, wordt vastgesteld bij de start van een iteratie (in de deelfase Plan). Daarna worden ze gerealiseerd tijdens een dagelijkse sub-iteratie in Realize. De iteratie wordt uiteindelijk afgerond en geëvalueerd (in deelfase Evaluate).
  • Finalize. Tijdens de iteraties van de fase Finalize wordt de software afgerond. Er wordt geen nieuwe functionaliteit meer ontwikkeld. Vervolgend wordt het project afgerond en geëvalueerd.
  • Manage. Deze fase beschrijft het onderhoud van de opgeleverde software. Ook hierbij gelden de smart use cases als uitgangspunt, en wordt meestal gewerkt in maandelijkse of tweemaandelijkse iteraties.

Hoewel de meeste agile methodieken zijn voortgekomen uit de reguliere systeemontwikkeling, zijn de karakteristieken, technieken en fasering goed toepasbaar in business intelligence projecten – wat in principe natuurlijk ook software development is. Laten we eens kijken.

Snel en frequent opleveren

Het snel en frequent opleveren van voor de klant relevante software is een aspect van agile methodieken dat in business intelligence bijzonder goed van pas komt. In plaats van de verticale fasering in traditionelere BI-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. Niet langer worden alle extracties eerst opgeleverd, aansluiten de transformaties en het laden van de gegevens om pas daarna de rapportages te ontwikkelen. Liever wordt er per rapportage ontwikkeld. Hierbij kiest de opdrachtgever welke rapportages de hoogste prioriteit hebben, en start het team met het uitsluitende realiseren van de daartoe benodigde extracties en transformaties, en het opstellen van de rapportage. Deze kanteling van werkzaamheden vergroot de mogelijkheden op feedback van de opdrachtgever, en de toepasbaarheid van het opgeleverde. Belangrijk bijkomend voordeel is dat de rapportages zodra ze beschikbaar zijn, soms al enkele weken na aanvang van het project, direct kunnen worden aangewend om de bedrijfsprocessen te verbeteren. Zo toont het project al op heel korte termijn benefits.

Korte iteraties

Agile software development promoot het werken in heel korte iteraties, bijvoorbeeld van twee weken of dertig dagen. Bij de start van iedere iteratie wordt beschouwd welke work items de hoogste prioriteit hebben. Dit zijn rapportages, maar individuele smart use cases die van pas komen bij de realisatie van een rapport. Zo wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals in traditionele werkwijzen, maar kunnen nieuwe inzichten direct worden geïncorporeerd. Hoewel het principe geldt dat tijdens de lopende iteratie de scope niet mag wijzigen, kunnen nieuwe requirements al tijdens een eerstvolgende op de rol worden gezet. Zodra de opdrachtgever de eerste versie van een rapportage of analyse onder ogen krijgt, kan hij of zij direct feedback formuleren, die ook weer direct wordt geïmplementeerd; zonder daarbij afbreuk te doen aan de structuur en voortgang van het project. We hebben in projecten gemerkt dat zo het in de praktijk benutten van analyses en rapportages (zeg maar de acceptatie) sneller tot stand komt. Tenslotte is het mogeljk nieuwe inzichten rond eventueel benodigde data entry direct op te pakken, zodra deze gaande het project worden onderkend.

Compacte eenheid van werk

Kort door de bocht gezegd is een BI-project uit te drukken in drie typen ontwikkelwerk: datamodellering en ETL, het definieren van analyses en rapporten en het ontwikkelen van data entry applicaties. In Smart geldt de smart use case als eenheid van werk, zowel voor het beschrijven van de requirements, het maken van schattingen als het realiseren van voor de gebruiker relevante functionaliteit – en zelfs als eenheid voor het testen van deze functionalitiet. Voor het modelleren van smart use cases gelden strikte richtlijnen, die ertoe bijdragen dat smart use cases een vergelijkbare lage granulariteit hebben, en al vroeg in een project zijn toe te passen – al tijdens de fase Propose. Er is een groot aantal standaardtypen smart use cases beschreven, die use case stereotypes worden genoemd. Voorbeelden hiervan zijn manage (onderhoud van een object), search (zoeken naar objecten), graph (rapportage) of file import.

Opvallend genoeg is gebleken dat smart use cases ook prima in agile BI-projecten kunnen worden aangewend. Wat betreft het definiëren van rapportages en het ontwikkelen van aanvullende data entry ligt dit voor de hand, omdat dergelijk werk niet wezenlijk verschilt van reguliere software development. Maar ook voor het vaststellen van analyses en zelfs voor het uitvoeren van ETL zijn inmiddels use cases stereotypes vastgesteld, zoals collect, integrate en aggregate.

Smart use cases worden vroeg al vroeg in een agile BI-project geïdentificeerd, tijdens de Propose en Scope fasen. Daarbij wordt alleen de overview van use cases vastgelegd; details worden pas uitgewerkt tijdens realisatie. Aan de hand van deze overview is de omvang en doorlooptijd van het project in te schatten. Aansluitend worden de iteraties uit de fase Realize ingepland. Tijdens deze iteratie ligt de focus op het realiseren van individuele rapportages, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en de definitie van de gewenste rapportage.



Deze wordt zo snel mogelijk gerealiseerd en met de opdachtgever afgestemd. Bijkomend voordelel is dat de onderliggende dataflows, die nu zijn uitgedrukt in smart use cases, beter individueel te testen zijn, en zelfs is door het modelleren van de use cases hergebruik van dataflows snel geïdentificeerd.

In BI-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Immers, ieder nieuwe rapportage kan direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben BI-projecten baat bij het met voortschrijdend inzicht dat onstaat dankzij de korte iteraties in agile projecten. Beter dan dit uit te bannen, zoals traditioneel wordt gepoogd, is het om juist effectief gebruik te maken van deze inzichten en feedback. Daarbij is de keuze om in projecten te focussen op de realisatie van individuele rapportages en analyses, in plaats van laag voor laag de benodigde ETL te ontwikkelen.

Agile dashboards

Daarbij biedt Smart een tweetal pragmatische gereedschappen om de voortgang van het project te bewaken; een agile dashboard en een burn down chart. Tijdens de uitvoering van een project verkeren de individuele smart use cases in verschillende, opvolgende statussen, zoals New, In Iteration, Working, Testing, Rework en Accepted. Het agile dashboard biedt een overzicht over de smart use cases in het project, die in kolommen zijn verdeeld, afhankelijk van de status waarin ze zich bevinden. In een oogopslag is zo, ook voor de opdrachtgever, te zien hoever het project is.


Omdat de smart use cases worden uitgedrukt in smart use case punten, is bij ieder statuswijziging direct na te gaan hoeveel punten (en uren) nog benodigd zijn om het project te voltooien. Een burn down chart toont de dagelijkse momentopname van deze uren, uitgezet in de tijd. Een eenvoudige extrapolatie kan nu de verwachte einddatum van het project calculeren.


In agile BI-projecten is het overigens niet alleen zeer zinvol een burn down chart te gebruiken voor het gehele project, maar ook om een dergelijke chart per rapportage te projecteren. Juist omdat de rapportages zo snel mogelijk moeten worden opgeleverd, levert dit laatste de opdrachtgever directe informatie over de voortgang, en wanneer het nieuwe rapport is in te zetten in het besturen van zijn bedrijfsprocessen.


De agile karakteristieken, fasen en technieken zoals hier gepresenteerd spelen bijzonder goed in op de snel wijzigende en uitbreidende wensen en eisen aan BI-projecten. Het toepassen van smart use cases biedt projecten daarnaast een gestructureerde, maar vooral pragmatische manier om in het hele project met eenzelfde eenheid van schatten en werken te opereren. De gereedschappen die in Smart-projecten worden gebruikt om de voortgang te meten, zoals het agile dashboard en de burn down charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses, met snel resultaat tot gevolg, en met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?

Sander Hoogendoorn
Principal Technology Officer Capgemini

Sandra Wennemers
Managing Consultant Capgemini

Zie ook www.smartusecase.com voor meer informatie over Smart, smart use cases (inclusief stereotypes) en smart estimation.

De uiterste houdbaarheidsdatum van requirements

Vorige week gaf ik – voor de zoveelste keer – training in het identificeren en modelleren van smart use cases. Dit keer bevond ik me in de hippe ruimtes van Meeting Plaza Utrecht, boven het altijd sfeervolle Hoog Catharijne. Tijdens de goed verzorgde lunch werd het onderwerp al snel bepaald door de uiterste houdbaarheidsdatum. Van levensmiddelen, maar meer nog, van requirements.


In de horeca is het al jaren een goed gebruik, het stickeren van levensmiddelen, zo weet ik van televisieprogramma’s als Keuringsdienst Van Waren.. Een eenvoudige sticker vertelt wanneer het product is opengemaakt, en tot wanneer het houdbaar is. Is deze uiterste houdbaarheidsdatum verstreken, dan wordt het product weggegooid, onbruikbaar voor consumptie.


Maar dan. De uiterste houdbaarheidsdatum van requirements? Het onderwerp kwam ter tafel toen een van de cursisten vertelde op dit moment te werken aan de realisatie van een verzameling requirements uit een RFC die inmiddels twee jaar oud is. Twee jaar oude requirements? De kans is groot dat deze requirements inmiddels al behoorlijk beschimmeld zijn; wet- en regelgeving is gewijzigd, en de wensen van de gebruikers zijn ontegenzeggelijk veranderd. Als tijdens een gemiddeld project de requirements al 20-25% wijzigen, hoe vergaat het dan requirements die ergens op een plank liggen te verstoffen?

Requirements en kaas

Welbeschouwd zijn requirements te vergelijken met kaas. Je hebt jonge requirements, net rijp genoeg om te consumeren, jong belegen requirements die eigenlijk al hadden moeten worden gerealiseerd, en dan oude requirements, die opzichtig beginnen te brokkelen. Tenslotte zijn alle ongebruikte requirements overjarig. Wellicht smaakvol, maar ze vallen al uit elkaar op het moment dat ze worden gehanteerd.


En net als kaas die op een plank ligt te rijpen verdienen requirements dezelfde zorgzame aandacht willen ze na een of twee jaar nog consumeerbaar zijn. Ze moeten worden omgedraaid, geevalueerd en verzorgd. Gebeurt dit niet dan verschimmelen ze en moeten ze eenvoudigweg uit de handel worden genomen, ongeschikt voor comsumptie.

Ik denk dan ook dat het een goed idee is ook requirements te stickeren, net als alle andere bederfelijke waar. Wanneer zijn ze aangemaakt, en belangrijker nog, wanneer dienen de requirements gerealiseerd te zijn.

Maar wanneer zijn onze requirements eigenlijk bedorven? Een kritisch agile luisteraar zal wellicht zeggen dat requirements beginnen met rotten zodra ze zijn opgeschreven. Immers, voortschrijdend inzicht begint direct te werken. Wellicht is het goed een standaardtermijn voor bederf te hanteren, zeg een half jaar. En wellicht zijn requirements waarin de user interface speelt sneller bedorven. Die krijgen dan een sticker van drie of vier maanden. En wanneer requirements over hun uiterste houdbaarheidsdatum heen zijn? Gewoon weggooien!


Het is overigens goed mogelijk de uiterste houdbaarheidsdatum te rekken. Hier komt het bekende YAGNI-principe goed van pas. You aren’t gonna need it. Ofwel voorkom in projecten al het werk dat op dit moment nog niet nodig is. Doorvertaald naar requirements komt dit er op neer dat alhoewel het verstandig is aan het begin van een project vast te stellen welke requirements er moeten worden gerealiseerd, alle details  van deze requirements pas echt nodig zijn zodra de realisatie ervan aanvang neemt. En dat is pas veel later.

Dit verklaart ook deels het succes van agile, kort-iteratieve projecten. De details (analyse en ontwerp) van een requirement worden pas bepaald zodra deze tijdens een van de iteraties daadwerkelijk wordt gebouwd. Zo wordt voorkomen dat er vroeg in een project veel werk in requirements wordt gestoken die nooit worden gerealiseerd, zoals in watervalprojecten nog wel eens het geval is. En bovendien, wanneer de details bijvoorbeeld pas na een half jaar worden onderzocht, is het voortschrijdend inzicht van dat half jaar automatisch geborgd. Om in de metafoor te blijven, zo zijn requirements altijd vers.

Benieuwd overigens wat de uiterste houdbaarheidsdatum van deze post zal blijken te zijn.

Avatar, reuse and model driven software development

Last week my daughter Sam (13), her friend Joey and I went to see the movie Avatar in 3D at the IMAX theatre in Rotterdam. Following up on the hype and reading reviews I just got curious. Especially after reading an interview with director James Cameron, who previously directed Aliens and Titanic.

Being more than interested in model driven software development, this interview cracked me up. James Cameron states that there’s a model for every rock, every straw, every tree on the planet Pandora, and for every piece of skin and body of the inhabitants. That’s something for you.  On the one hand you might say: hey, this Avatar project took over 7 years to build, and it costs around 400 million dollar. No way should we do software development projects like that.

James Cameron: “Use the models for sequels”

But it gets more interesting. In the interview James Cameron also says that the argument that sold Avatar to studio 20 Century Fox is that these expensive and extensive models could be used for any number of sequels. To sum up why the studio put up with the length and price of the project in one simple word: it’s reuse.

Seeing is believing

I have to admit, seeing is believeing. This movie has the most incredible visual appearance I ever witnessed. And it’s all generated from the model. And that’s where I got jealous, or even a bit depressed.

There we are: enthusiastic software engineers building business software from our BPMN or UML models or our textual or visual DSL’s. Whatever abbreviation you follow, be it MDA, MDD, FMDD, or MDSD, we think we’re doing great jobs raising the level of abstraction just a little bit from hand-written code. But even this very little step  forward seems to be highly complex. The technology is hard, the meta-level thinking is harder, and convincing management and customers (the studios) that this is the way to go with software development is even more challenging.

Kindergarten stuff

But in comparison to the complexity and size of producing Avatar our whole MDx venue is kindergarten stuff. We’re not creating a highly detailed blasting 3D movie experience. We are only implementing a simple business process to change your address at your local bank. Pfff. Is that all?

Jake Sully: “Ha ha, changing your address at your local bank is difficult?“

Don’t get me wrong. We will simply have to move from hand-writing applications to modeling and generating applications. Raising the level of abstraction is the only way to deal with the rapidly increasing level of complexity of technology vendors present us with, and the ever increasing demand for new software, presented on new devices. There’s just no way we can keep with this demand just by hand-writing all the code, not with all the developers in the world, not with the best-of-class frameworks at hand, not with the best agile processes and techniques in place (let alone waterfall).

Even though model driven techniques are no silver bullet either it will play an increasingly important role in software development . Our work will be around simplifying customer demand, standardizing techniques and raising our levels of abstraction, writing less code and generating more code. And for those of you not yet convinced: go see Avatar or preferably one of its likely many sequels.

Serviceorientatie vormgeven met smart use cases [In Dutch]

This post was originally written to be published as a chapter in an upcoming book on IT architecture. The book will be presented at the Landelijk Architectuur Congres 2009 in Nieuwegein, The Netherlands. This post will likely also be published in two parts in Software Release Magazine.

Ondanks dat ik inmiddels al zo’n twintig jaar in dit vakgebied rondloop, blijven software development projecten uitdaginen opleveren. Zo werkte ik eerder dit jaar coach aan een agile project waarmee een grote logistieke onderneming nieuwe producten voor hun klanten ontsloot.

Alhoewel ik vooral als coach was ingezet op het begeleiden van het proces, was het project technologisch een hele kluif. Een Java portal als front end, orchestratie van processen in SAP middleware, back office systemen in PeopleSoft, SAP en .NET die moesten worden “verserviced”, en niet te vergeten een aantal interfaces naar externe systemen, waar we niet of nauwelijks invloed op konden uitoefenen. Al met al een typisch voorbeeld van een service georienteerd project. Dit type projecten kenmerkt zich door hun hoge complexiteit, en zijn daarom slecht in te schatten en te plannen. Alhoewel niet de oplossing voor alle uitdagingen, bestaat er een techniek die smart use cases wordt genoemd, die concreet en pragmatisch bijdraagt aan het beter inschatten, plannen, maar ook realiseren en testen van servicegeorienteerde projecten.

Service georienteerde projecten zijn complex

Iedereen die in dergelijke projecten heeft gewerkt, weet het inmiddels wel: service georienteerde architecturen maken het uitvoeren van dit soort projecten er niet makkelijker op. Dit soort projecten kenmerken zich een groot aantal organisatorisch, functioneel en technisch complicerende factoren:

  • Diverse stakeholders. Servicegeorienteerde projecten automatiseren in het algemeen bedrijfsprocessen, die meestal meerdere organisatorische eenheden en verschillende systemen doorsnijden. Dientengevolge zijn er vaak diverse stakeholders betrokken bij het project.


Een servicegeorienteerd project kent vele stakeholders

  • Flexibele front end technologien. Voor het realiseren of uitbreiden van de front end(s) wordt vaak gebruik gemaakt van state-of-the-art, of zelfs bleeding edge technologie, waarover niet altijd evenveel kennis beschikbaar is in de organisatie.
  • Heterogene back end technologien. De diverse systemen die ontsloten dienen worden – verserviced – zijn gerealiseerd in allerhande technologien, al dan niet verouderd.
  • Externe interfaces. Niet zelden wordt ook gebruik gemaakt van systemen die extern zijn aan de organisatie. Op deze systemen kan het project meestal weinig invloed uitoefenen, hooguit zijn de interfaces bekend. Helaas zijn dit soort interfaces zelden stabiel, en aan wijzigingen onderhevig.
  • Diverse rollen. Opvallend aan service georienteerde projecten is dat er een breed scala aan rollen betrokken is. Zo zorgt de diversiteit aan technologie al voor een breed palet aan developers – zo is een SAP CRM consultant geen SAP XI developer, en een .NET developer niet per se ook een software architect. Maar ook andere traditionele en minder traditionele rollen al informatie-analisten, ontwerpes, user inferface designers, enterprise architecten, business consultants en last but not least project managers, vinden hun weg in dit type projecten.

Service georienteerde projecten zijn lastig te plannen

Een recent voorbeeld is een project voor een verzekeraar voor het realiseren van een nieuw hypotheekoffertesysteem. Belangrijkste streven bij dit project was het realiseren van straight-through processing (het zonder humane tussenkomst doorvoeren van hypotheekoffertes naar de back office) en het flexibel kunnen toevoegen van nieuwe hypotheekproducten.

Naast de haast traditionele handicaps als schuivende requirements, bleek gedurende het project dat de interfaces van externe systemen niet aansloten op de gegevens die nodig waren om de benodigde processen uit te voeren. Daarnaast bleek ook de gebruikersvriendelijkheid van de (gegenereerde) webpagina’s tot hoofdbrekens te leiden. Het project levert nu hopelijk ruim een jaar na dato op, en heeft ruim vier keer zoveel gekost als oorspronkelijk begroot.

Maar waarschijnlijk vertel ik u als lezer hiermee nog niets nieuws. Lastig is wel dat deze complexiteit voor uw project een aantal ondermijnende gevolgen kan hebben. Om u een indruk te geven laat ik er hier toch maar een paar de revue passeren:

  • Externe afhankelijkheden. Service georienteerde projecten zijn vrijwel zonder uitzondering afhankelijk van derden, ofwel partijen binnen de eigen organisatie die andere planningen er op nahouden, ofwel partijen buiten de eigen organisatie, die lastig beinvloedbaar zijn.
  • Moeilijk in te schatten. Wie al eens in een offertetraject voor een dergelijk project heeft geparticipeerd; het maken van een goede schatting is cruciaal maar extreem lastig.
  • Moeilijk te plannen. Lastige schattingen, diverse stakeholders, externe afhankelijkheden, en talrijke projectrollen maken het er niet makkelijker op voor de beoogd project manager om een goed planning voor het project af te leveren.
    Een ding is zeker: een traditionele lineaire aanpak, waarin flexibiliteit tot een minimum wordt beperkt, is uit den boze. Een service georienteerd project kent vele wendingen – steeds meer overigens naarmate het project langer duurt.

Het zal u niet verbazen dat met deze consequenties service georienteede projecten te vaak niet op tijd en op budget worden opgeleverd, of dat gaandeweg het project wordt besloten slechts een deel van de vereiste functionaliteit op te leveren. Tenslotte worden de beoogde uitgangspunten voor het project vaak niet gehaald. Denk daarbij aan het in service ontsluiten van legacy back end systemen, het realiseren  van hergebruik ten einde toekomstige projecten sneller te kunnen uitvoeren, het opbouwen van een repository van services or het snel en flexibel kunnen toevoegen van nieuwe producten en features.

Hoe complex is het project eigenlijk?

Zoals gezegd zijn service georienteerde projecten meestal lastig te schatten en derhalve nog lastiger te plannen. Een belangrijk vraag die bij aanvang van dit soort projecten dan ook dient te worden gesteld om een goede kosten-baten-analyse te kunnen maken is: hoe groot en complex is ons project nu eigenlijk?

Een belangrijk struikelblok bij het beantwoorden van deze op het oog eenvoudige vraag is dat er allerlei verschillende typen deliverables zijn te onderkennen in een service georienteerd project. Denk hierbij bijvoorbeeld maar aan webpagina’s, schermen, services, orchestratie, domeinobjecten, transacties. Dit maakt het “tellen” van de totale complexiteit van een project lastig. En zelfs wanneer al deze verschillend typen deliverables zouden kunnen worden geteld, dan nog ontbreken er de nodige ervaringscijfers, die de uiteindelijke complexiteit per type deliverable in uren kunnen helpen vertalen.


Smart use cases modelleren in een servicegeorienteerd project

Het zou een belangrijk stap voorwaarts voor servicegeorienteerde projecten kunnen zijn wanneer alle (functionele) deliverables op een en dezelfde schaal konden worden uitgedrukt, waarbij de complexiteit van zowel de webpagina’s, schermen, orchestratie als services op eenzelfde manier wordt uitgedrukt, middels een enkele eenheid van schatten, en misschien zelfs wel een enkele eenheid van werk. Immers, zo kunnen makkelijker ervaringscijfers worden verzameld, die weer kunnen worden toegepast om volgende projecten binnen hetzelfde programma beter in te plannen. Deze eenheid van werk dient zich aan door smart use cases te introduceren in service georienteerde projceten.

Use cases

Laat ik bij het begin beginnen. Wat zijn eigenlijk use cases? Meestal wordt een use case aangemerkt als een beschrijving van het gedrag dat software vertoont als reactie op een verzoek dat stamt van buiten de software. Vrij vertaald beschrijft een use case wie met de software wat kan doen. Een use case realiseert een bepaald doel voor uitvoerder van de use case. In jargon wordt deze uitvoerder wel de actor genoemd. Zo’n actor hoeft overigens niet perse menselijk te zijn, maar kan bijvoorbeeld ook andere software zijn of zelfs een batchverwerking.

Het uitvoeren van de use case vindt plaats als een opeenvolging van een aantal stappen. Deze stappen vormen tesamen een of meerdere scenario’s die uitmonden of in het realiseren van het doel, of, wanneer er iets mis gaat, in een uitzonderingssituatie. Deze eindresultaten worden wel de postcondities van de use cases genoemd. Use cases worden veelal beschreven in documenten, al dan niet geformateerd in een voorgeschreven sjabloon.


Voorbeeld van een use case diagram

Daarnaast bestaat er een aardige, relatief informele en veel toegepast modelleertechniek, waarin actor als poppetjes worden gerepresenteerd, en use cases als ovaaltjes. Deze modelleertechniek, die het use case diagram wordt genoemd, wordt ondersteund door een breed scala aan geautomatiseerde gereedschappen.

Traditionele use cases

Traditioneel worden reguliere use cases gebruikt voor het beschrijven van de functionele requirements van een regulier project, uitgaande van het doel dat de gebruiker (of actor) wil bereiken door de use case uit te voeren. Traditioneel worden use cases beschreven in een document, dat naast het doel, het resultaat ook alle mogelijke scenario’s beschrijft aan de hand waarvan de use case kan worden doorlopen.

Een interessant voorbeeld van een dergelijk use case kwam ik tegen in een service georienteerde project bij een interrnationale bank, waar een use case Wijzigen Adres een document van vijfenzestig pagina’s besloeg, waarin twaalf schermen voorkwamen, tientallen scenario’s en waarin diverse services werden aangeroepen. Een ander gelijksoortig voorbeeld is een use case Uitvoeren Kwartaalfacturering van een pensioenfonds, waarbij circa 1.3 miljoen factuurregels werden berekend.

Alhoewel dergelijke use cases  in service georienteerde meestal de te realiseren bedrijfsprocessen beschrijven, zijn ze niet bijzonder geschikt als eenheid van werk en van schatten in dit type projecten. Traditionele use cases verschillen te veel in omvang en complexiteit, om ze met een gerust hart op een lineare schaal uit te drukken. Ter ondersteuning: het realiseren van de use case Uitvoeren Kwartaalfacturering vergde ruim anderhalf jaar, terwijl het in hetzelfde project slechts enkele dagen kostte de use case Inloggen Gebruiker in te voeren.

Daarbij komt nog het bezwaar dat deze wijze van benaderen van use cases niet bijdraagt aan het identificeren en realiseren van de gewenste services, en dat hergebruik slechts sporadisch en incidenteel tot stand komt.

Smart use cases

Toch hebben we in de afgelopen jaren ervaren dat use cases een heel nuttig vehikel kunnen zijn in servicegeorienteerde projecten. En niet alleen om projecten in te kunnen schatten, maar ook als eenheid van werk, en zelfs voor het identificeren en hergebruiken van services. Om deze nobele doelstellingen te bereiken maken we intensief gebruik van wat we in de loop der jaren smart use cases zijn gaan noemen – genoemd naar de agile methodiek Smart en goed beschreven in mijn boek Pragmatisch modelleren met UML. Een korte introductie.

Alistair Cockburn, autoriteit op het gebied van use cases, beschrijft in zijn boek Writing effective use cases een model waarin use cases in vijf verschillende niveau’s van granulariteit – zeg maar grootte en complexiteit – worden uitgedrukt.


Deze niveau’s zijn:

  • Cloud. Use cases op dit hoogste niveau representeren veelal groepen van samenhorende bedrijfsprocessen, zoals Verkopen Producten.
  • Kite. Op dit tweede niveau worden in de regel individuele bedrijfsprocessen geposteerd, vaak workflow georienteerd.
  • Sea. Dit is het niveau waar het om draait, en waar bijvoorbeeld ook Wijzigen Adres toe behoort. De kernvraag op dit niveau zou kunnen zijn: hangt de performance van mijn organisatie af van hoeveel van deze kan ik per dag uitvoeren? Als richtlijn: deze use cases komen nagenoeg overeen met wat ook wel als elementaire bedrijfsprocessen wordt geduid.
  • Fish. Use cases op fish niveau worden gebruikt om op zichzelfstaande, maar aan sea niveau ondersteunende functionaliteit te modelleren. Denk bijvoorbeeld aan Ophalen Abonnement of Selecteren Product.
  • Clam. Soms modelleren projecten te ver door, en worden de use cases te klein. Hier spreekt men over clam niveau.

Ondanks de beknoptheid van deze introductie, moge het duidelijk zijn dat cloud en kite niveau in servicegeorienteerde project met name terug te vinden zijn in de te automatiseren bedrijfsprocessen, de visie van het projec en wellicht de bedrijfsarchitectuur van de organisatie.

De use cases op het sea en fish niveau worden samen smart use cases genoemd. Deze twee niveau’s vormen zo een goede basis van gelijke granulariteit zowel voor het uitdrukken van functionaliteit die direct zichtbaar is voor de gebruiker, zoals Selecteren Product, maar ook voor het identificeren van services, en het aanleggen van een repository van deze services, zoals Ophalen Abonnement.

Smart use cases modelleren

Veel meer dan in traditionele use cases het geval is, gebruiken we voor het vormgeven van smart use cases de bijbehorende modelleertechniek.

Uitgaande van de lijst te realiseren bedrijfsprocessen op kite niveau, modelleren we een use case diagram per elementair bedrijfsproces, op sea niveau derhalve. Ieder use case diagram bevat:

  • Sea niveau use case. Een enkele use case die het elementair bedrijfsprocess representeert, weergegeven als een ovaal.
  • Actoren. Een of meerdere partijen die gebruik maken van deze use case, om daar hun doel mee te bereiken, weergegeven als poppetjes.
  • Fish niveau use cases. Nul, een of meerdere use cases die ondersteunend zijn aan de sea niveau use case, eveneens weergegeven als ovalen.

Onderstaande figuur bevat een goed voorbeeld van een dergelijke use case diagram .


In dit use case diagram zijn de use cases Apply for Membership en Activate Membership sea nieuws use cases, de overige use cases zoals Send Confirmation en Validate Creditcard zijn fish niveau.

Om tot dit diagram te komen distilleren we normaliter de fish niveau use cases uit de sea niveau use case, door onszelf steeds opnieuw te vragen: wat is de volgende stap die we nemen bij het uitvoeren van deze use case? In sommige gevallen is het handig om deze stappen als individuele use cases op te nemen in het diagram, in andere gevallen weer niet. We hanteren hiervoor een set aan richtlijnen, zoals aan het identificeren van hergebruik – komen we deze use case mogelijk vaker tegen? Of denk het afhandelen van alle interactie rond een formulier of scherm, of het importeren en exporteren van bestanden.

Standaard typen smart use cases

Deze hierboven beschreven aanpak is inmiddels – met veel succes – toegepast in een diverse typen projecten, zoals reguliere webprojecten in .NET of Java, het implementeren van portals, business intelligence en zelfs pakketimplementaties.

Bij het uitvoeren van al deze projecten is vooral opgevallen dat steeds opnieuw dezelfde soorten smart use cases de revue passeren. Denk hierbij aan het selecteren, zoeken, of onderhouden van gegevens, het exporteren van een bestand, of het aggregeren van gegevens in een business intelligence situatie.

Deze standaardtypen use cases (in de wandelgangen stereotypen genoemd) helpen projecten enorm om de analyse van de requirements te versoepelen en standardiseren. Het jargon van smart use cases wordt tijdens workshops al snel overgenomen door opdrachtgever en gebruikers. “Ik stel voor dat hier hier een master-detail over klanten en orders gebruiken, met een search op producten”.

Belangrijk bijkomende voordelen van het toepassen van deze (of eigen) stereotypen is dat ook het schatten van de omvang van het project vergemakkelijkt, en dat ook de realisatie, inclusief testen, van dit soort standaard use cases eenvoudiger is. Immers, er is al eens eerder met hetzelfde bijltje gehakt. Een onderhouds-use case voor klanten verschilt niet wezenblijk van een onderhouds-use case voor producten.

Smart use cases modelleren in servicegeorienteerde projecten

Ook in servicegeorienteerde projecten hanteren we sinds enkele jaren smart use cases. Daarbij brengen we graag een tweedeling aan, we modelleren een front end use case diagram, en een service use case diagram.

Allereerst modelleren we een smart use case diagram vanaf de sea level use case die de interactie met de gebruikers en het elementaire bedrijfsproces vertegenwoordigt, zoals Aanvragen Subsidie. Daarbij identificeren we de bijbehorende fish level use cases, maar alleen  tot aan het aanroepen van de services of de orchestratie.


Use case diagram dat de interactie met de gebruikers modelleert tot aan de services.

In dit voorbeeld zijn alle gele use cases client facing, en representeren de rode use case de interactie met de service verlenende systemen.

Daarnaast modelleren we een tweede smart use case diagram, met de desbetreffende service, en alle achterliggende services als fish level use cases. In dit diagram beschrijft de sea level use case in het algemeen de orchestratie, en representeren de achterliggende fish level use cases de individuele services.


Use case diagram dat het uitvoeren van de service Leveren Product modelleert.

In bovenstaand diagram  wordt de orchestratie verzorgd door de use case Leveren Product (via SAP middleware), en leveren de overige use cases services die door door Leveren Product worden geconsumeerd. In feite is deze use case een samengestelde service, die (letterlijk) wordt hergebruikt in het front end use case diagram, vergelijkbaar met de rode use cases in het voorgaande voorbeeld.

Het toepassen van een dergelijke aanpak biedt zeer concrete voordelen:

  • Eenduidig. Er is een eenduidige manier voor het beschrijven en modelleren van alle functionele onderdelen van het project, inclusief de schermen, orchestratie en services.
  • Gelijke granulariteit. Wanner het project de hierboven beschreven richtlijnen correct toepast, hebben alle use cases een vergelijkbare granulariteit – ze zijn allemaal ongeveer even groot, of zo u wilt, even klein.
  • Technologie-onafhankelijk. Smart use cases zijn te modelleren onafhankelijk van de platforms en technologie die wordt gebruikt. Bovenstaande voorbeelden kunnen evengoed in .NET en SAP worden gerealiseerd, als in in Java en Oracle.
  • Inschatbaar. De smart use cases, met daarbij de onderkende stereotypen, maken een goede eenheid voor het inschatten van servicegeorienteerde projecten. Hiervoor is een eenvoudige schaal gedefinieerd die wordt uigedrukt in smart use case punten.
  • Goede eenheid van werk.  Tenslotte, smart use cases vormen een goede eenheid van werk in projecten. In de regel is iedere use case los van de andere te ontwerpen, te ontwikkelen en vooral: individueel te testen. Met name dit laatste aspect zorgt ervoor dat de acceptatie van de te ontwikkelen en hergebruiken componenten vergemakkelijkt.
  • Hergebruik. Omdat smart use cases technologie-onafhankelijk zijn te modelleren en te beschrijven, biedt de techniek de mogelijkheid om een repository aan te leggen van gebruikte services, uitgedrukt in smart use cases.

Schatten met smart use cases

Omdat smart use cases zo eenduidig en technologie-onafhankelijk beeld geven van de functionaliteit van een project, is het een goede eenheid om de complexiteit en omvang van het project in te schatten. Hiervoor is een eenvoudige schaal gedefinieerd; de meetlat waarlangs alle smart use cases in een project wordt gelegd. Deze schaal is als volgt gedefinieerd:

  • 1 – Piece of cake. Eenvoudige use cases, zoals selecties uit standaardlijstjes, of eenvoudige onderhoud, zoals Onderhouden Contracttypen.
  • 2 – Moderate. Reguliere use cases, bijvoorbeeld voor selecties uit iets uitgebreidere lijstjes. Denk hierbij aan Selecteren Account Manager per Regio.
  • 3 – Average. De gemiddelde complexiteit, die meestal wordt gegeven voor regulier onderhoud, zoeken, of eenvoudige rapportages. Voorbeelden zijn Zoeken Boek, of Beheren Klant. Dit is tevens de default complexiteit.
  • 4 – Hard. Wordt gegeven bij lastiger onderhoud of rapportages. Ook eenvoudige services, meestal zonder het wegschrijven van gegevens, krijgen vaak deze complexiteit. Denk aan Ophalen Contract of Overzicht Orders per Klant.
  • 5 – Very difficult. Use cases met deze complexiteit worden als lastig beschouwd. Meestal zijn dit uitgebreide rapportages, grafieken, al dan niet met drill-down, of complexere services waarbij gegevens worden weggeschreven. Denk aan Vastleggen Abonnement.
  • 8 – Extreme, but known. Deze complexiteit wordt bewaard voor de zeer lastige use cases. Het betreft hier bijvoorbeeld complexe berekeningen of samengestelde services die vaak het uitvoeren van een proces voor hun rekening nemen. In business intelligence projecten wordt deze complexiteit vaak gegeven aan use cases die datatransformaties uitvoeren. Denk maar aan Berekenen Prepensioen.
  • 10 – Extreme and unknown. Deze hoogste complexiteit wordt uitgedeeld om twee redenen. Enerzijds voor use cases die bewezen lastig zijn, zoals het importeren en exporteren van bestanden en berichten. Anderzijds geven we deze complexiteit op het moment dat we wel weten dat de use case complex is, maar nog niet goed kunnen definieren hoe complex dit precies is. In deze gevallen verplichten we ons deze use case nog nader onder de loup te nemen. Vaak komen hier nog additionele use cases uit naar voren.

Met behulp van deze snel toepasbare schaal, en de vele standaardtypen use cases die we in veel projecten zijn tegengekomen en die al eerder langs deze maatlat zijn gelegd, kunnen we snel en betrouwbaar de complexiteit van een project inschatten. Dit maakt smart use case schattingen herhaalbaar, en bovendien kunnen er gemakkelijk ervaringscijfers uit worden gedistilleerd voor komende projecten. Dit laatste is met name in organisaties die servicegeorienteerd gaan werken belangrijk, omdat daar meerdere automatiseringprojecten uitvoeren binnen eenzelfde programma. Ons huidige project beslaat 298 smart use case punten.

Niet zelden komen dit soort schattingen tot stand tijdens workshops, waaraan alle betrokken partijen deelnemen, zoals de klant, de gebruikers, de architect, analisten, ontwikkelaars en ook de testers.


Workshop waarin de complexiteit van smart use cases door het team wordt geschat

Tijdens dergelijke workshops krijgt het (toekomstige) projectteam een goed en vooral eenduidig beeld van het project en de complexiteit van de requirements. Met name voor de klant, die niet altijd een reeel beeld heeft hoe complex de realisatie van zijn of haar wensen eigenlijk is. “Oei. Dit wordt toch veel lastig en duurder dan we hadden verwacht,” is een veel gehoorde uitspraak, “misschien moesten we eens onderzoeken of er alternatieven zijn.”

Verlengen voordeeluren

Vooruit dan. Om mijn bovenstaande beweringen kracht bij te zetten een laatste anecdote. Tijdens een recent project bij een grote openbaar vervoersonderneming realiseerden we een aantal bedrijfsprocessen rondom een nieuw type abonnement. Deze processen waren uitgemodelleerd in smart use case diagrammen, zowel voor de front end als voor de services.

Ongeveer halverwege het project, terwijl we inmiddels al een deel van de processen hadden geimplementeerd als smart use cases, kwam de opdrachtgever schoorvoetend met een verzoek. “Zouden we, als we toch ook dit nieuwe type abonnement implementeren, ook eens kunnen kijken naar het verlengen van de voordeelurenkaarten?” Bijna verschoot de opdrachtgever hierbij van kleur.

Vrijwel onmiddelijk organiseerde de projectleider een workshop waarin het verlengen van voordeelurenkaarten onder de loup werd genomen. Na twee uur modelleren bleek dat bijna het gehele proces was te realiseren door hergebruik van smart use cases die we al hadden. We hoefden slechts vier nieuwe smart use cases toe te voegen, met een geschat totaal van 16 smart use cases punten. Het behoeft denk ik verder weinig uitleg dat de klant snel besloot het verlengen van de voordeelurenkaarten toe te voegen aan het project. Dit is hergebruik ten top.

Inzicht en overzicht

Servicegeorienteerde projecten kunnen, met name in grote organisaties, enorm bijdragen aan de effectiviteit en efficientie van de bedrijfsvoering. Een mooi voorbeeld hiervan maakte ik bij een bank mee. Wanneer een klant van deze bank het onzalige besluit nam om te verhuizen, moest dit oorspronkelijk in 36 verschillende systemen worden vastgelegd. Door steeds meer van deze systemen met behulp van services te ontsluiten, werd dit ogenschijnlijk eenvoudige bedrijfsproces in de loop van enkele jaren en projecten teruggebracht naar een enkele administratieve handeling.

Servicegeorienteerde projecten zijn echter ook zeer complex van aard. Bovengenoemde bank had een aantal projecten nodig om de beoogde verandering te bewerkstelligen. Alhoewel smart use cases, en de bijbehorende standaardtypen en schattingstechnieken natuurlijk niet alle problematiek van dit soort projecten tot nul reduceert, dragen ze zeer concreet bij aan het inzichtelijk maken van deze complexiteit, door een eenduidige eenheid van werk te introduceren, zowel voor de front ends, als voor de achterliggende orchestratie en services. Als klapper op de vuurpijl is deze uniforme eenheid van werk ook nog eens naar behoren in te schatten, en onafhankelijk te testen. Als ik het In een notedop zou moeten samenvatten: inzicht en overzicht. Precies dat wat veel servicegeorienteerde projecten ontberen.

October 26, 2009. Three lectures. “Software development methodologies and techniques through the years”

Vrije Universiteit, Amsterdam.

Earlier this year I was invited by prof. Arno Oosterhaven to do a series of lectures on software development at the post-doctoral program IT Auditor at the Vrije Universiteit in Amsterdam. The audience of IT Auditors is very mixed, ranging from accountants to actual software developers, which makes it difficult to address all interests of the students.


However, I managed to put together a nice program of six lectures, where I delved into the archives of software development. For the first three lectures, I did an overview of nice topics:

  • Software development methodologies, starting with Winston Royce’s famous white paper, going through SDM, spiral models, RUP and ending at agile methodologies, of course including DSDM, XP, Scrum, Smart.
  • Software analysis and design techniques, starting at DFD’s and PSD’s (do you stil remember these?), flow charts (did you know these were invented in 1921?) and on through UML and BPMN.
  • (Smart) use cases. Of course, would I leave home without them?

Although people came from very differte backgrounds, the students seemed to like the material offered. Got good response.

October 23, 2009. Talk. “How Smart Use Cases Drive Service-Oriented Projects “

International SOA Symposium, World Trade Center, Rotterdam. (www.soasymposium.com)

On October 22 and 23, 2009 the second international SOA Symposium will take place at the World Trade Center in Rotterdam, the Netherlands. Just coming out of a highly successful agile SAP service oriented project (likely the first in it’s type in the Netherlands or even a wider area), Twan van den broek (of Ciber) and I thought it would be a good idea to share our experiences at the SOA Symposium. And so did the organisation.

Twan and I wil do an inspiring talk on agile SOA projects on the first day; next we will both feature a panel discussion, and on the 23rd I will do a talk on how to model services using smart use cases, which works really fine!

Check out the conference description for this talk.

How Smart Use Cases Drive Service-Oriented Projects

Under normal circumstances, SOA projects would apply use cases to model and describe the interaction between the users and the services. "Smart" use cases extend this very basic technique and make more powerful use of UML use case diagrams, resulting in a collection of smaller, equally granular use cases.


This technique allows projects to easily define reusable assets, in both front and back end systems. Over the past years, the smart use case techniques have been enriched by many organizations and many types of SOA projects, including those built with .NET, Java and SharePoint. The smart use case technique nowadays comes with straightforward estimation, a collection of standard (stereo)types, many guidelines, and even code generation.

In his well-known enthusiastic presentation style, Sander Hoogendoorn, principal technology officer at Capgemini, will demonstrate how to identify and model smart use cases from business processes for SOA projects.

October 23, 2009 – 11:15

Read more: Sander at SOA Symposium 2009.

September 30 & October 1, 2009. Workshop. “Pragmatic modelling with UML”

Array Seminars, Amrâth Hotel Lapershoek, Hilversum

I will present an intense two day workshop in Hilversum that follows the pragmatic modeling approach presented in my book with the same title. During this highly interactive workshop participants will learn how the various modeling techniques from UML and beyond connect.


Learn everything about (smart) use cases and start working directly with UML in many exercises a pragmatic case – Dare2Date, an online dating site.

Topics include: UML overview, an agile approach to requirements, modeling smart use cases, testing use cases (with activity diagrams), user interface modeling, domain modeling (using class diagrams), modeling services, modeling in agile software development projects, and model driven development using UML.

Participants will receive a copy of the book Pragmatic Modelling with UML 2.0. This workshop always gets rave reviews.

See: www.arrayseminars.nl


Pragmatic model driven development. Part II. A pragmatic approach


Note. This series of posts is also published as a Capgemini group white paper and published in Software Release Magazine (in Dutch, in two parts).

In projects that are executed using the Accelerated Delivery Platform, Capgemini’s open knowledge platform for agile software development, a lightweight, pragmatic approach to model driven development is used.

This approach can be expressed in a small number of steps:

  1. Model smart use cases. We model our functional requirements using highly standardized smart use cases. A growing collection of over 30 standard types of smart use cases exist, making life easier when it comes to requirements analysis, project estimation, testing, but also code generation.
  2. Create the domain model. Next we create the domain model, containing the entities, value objects and other classes from the problem domain of the project.
  3. Decorate the model. To be able to generate code we combine the smart use cases with the elements from the domain model, and a the appropriate stereotypes. For instance, we associate the smart use case Search Customer  with the Customer class, and decorate this association with the stereotype «search».
  4. Import model. Then we import the model in Tobago MDA, our code generator of choice. Tobago MDA can apply text templates to the model, and generate any desired text based deliverable, ranging from Word documents and Excel spread sheet to the actual code.
  5. Generate code based on reference architecture. To sort maximum effect, we base most of the application we develop on a straightforward reference architecture, that is supported by a number of frameworks, both in Java and in .Net, although other technology also apply.

Modeling smart use cases

Primarily use cases are identified at user goal level. Here, each use cases typically captures a single elementary business process. Normally for this use case the successful scenario is described (also called the happy day scenario), and additionally all deviations to this scenario are described as alternative flows.


Using this approach, very limited use is made of the UML use case diagram modeling technique. Requirements are captured in text, and are mostly described in Word documents. As a good example of this type of use cases, at a large international financial institution a use case called Change Address was written. It covered 65 pages of text, 12 screens and numerous alternative flows. As these types of use cases vary enormously in scope, complexity and size, it is very hard, if not impossible to generate code from user goal level use cases.

Alternatively, when the use cases at user goal level are identified (even better: the elementary business processes for the project have been identified), it is possible to use the use case diagram technique to add use cases at fish level to the diagram. We have defined a number of clear guidelines on when these additional use cases apply. These include not handling more than one form per use case, handling complex calculations, handling services in service oriented projects, or even handling ETL in BI projects. The following diagram is a good example smart use case diagram. Please note that this model is not a work breakdown, the user goal level use case has it’s own responsibilities.


Using this approach each of the elementary business processes is modeled out in such as diagram with any number of actors, a single user goal level use cases, and a number of accompanying use cases at sub-function level. The collection of these use cases (at both levels) is referred to as smart use cases. Again, for each of these smart use cases a description is written. However, these are much more lightweight than in the previous scenario and often contain only a few (or even no) alternative flows. We not only model these smart use case diagram in traditional multi-tier scenario’s, but also host service oriented and even cloud scenario’s.

Stereotyping smart use cases

An important step towards generating code from use cases is the recognition of smart use case stereotypes, which describe standard behavior. This extreme requirements standardization streamlines the requirements analysis, but also enables us to define templates per stereotype that implement this behavior in for instance Java or C#. Currently we harvested over 30 of these smart use case stereotypes, including maintenance use case in Manage, Master Detail, Select or Search, such as in the depicted diagram, but also Collect in BI projects, and several types of service handling stereotypes in service oriented projects.

Trojan rigidity. Agile anti-patterns (I)

One of the characteristics of most traditional – linear, waterfall – styled organizations is the extremely rigid execution of their software development projects . “Our handbook says we need to fill in this form, so that’s what we do guys.” People is these projects live by the blind assumption that whoever invented or wrote down their software development process knew what he or she was doing. So we’ll just fill in the form, even though we’re not quite sure what it is for. And even better, all projects great and small, live under the same regime. This is where six weeks, three developer projects get stuck with a steering committee, an architecture board and a quality assurance work group. We need predictability in our projects more than anything else!

But enough laughter. One of the characteristics of agile software development projects is the flexibility and adaptability to only do what is necessary in the project. No matter which agile process we apply – be it Scrum, Smart, XP, FDD, or OpenUP – we try to delay the actual work to the latest possible moment in time that we actual need to do the work. And we delay decisions in the same manner. In both cases we do this so we have maximum knowledge over what we should and should not do. Thus, for example the design for a particular piece of functionality is done just before building the software.

We know better

These two approaches appear to be totally different or even orthogonal, and yes, they are. Still a lot of organizations cling to the rigidness of their waterfall processes. In most cases this is because they think it will make their projects more predictable and repeatable. Or sometimes just because they just don’t have a clue. In most of these poor organizations, we agile people laugh at this rigidness, because we think we know better. But do we?

I would say there’s also a dark side to our laughter. In fact, with the increasing popularity of agile software development a lot of newbie agilists entering our projects I predict that the freedom and flexibility we preach will slowly shift towards more rigidity and ceremony. And I don’t mean waterfall rigidity, but agile rigidity. Again, a lot of people will think that whoever invented or wrote down their software development process knew exactly what he or she was doing. A lot of people only have a vague clue to why he or she wrote down the process.

No modeling

This agile rigidity anti-pattern is easily recognizable in projects – or even better still: in blog discussions. These days there seem to be more blog and Twitter posts on agile than there are user stories in agile projects. Let me present you with a few examples of this new agile rigidity. In the agile process Smart (see www.smartusecase.com) it is suggested to add a number of work items right from the start of the project to the project backlog that deal with determining project scope, modeling requirements (in smart use cases), creating a sound estimate for the project’s complexity, and also maybe deliver a project proposal. Having a project proposal, is not a bad thing if you want to (sell and) run the project. In my day to day life this short list of suggested work items works quite well, and moreover, is totally compatible with processes such as Scrum and FDD. We have been using this approach in agile projects for about ten years successfully.

However, much to my surprise, when I recently elaborated on this approach – in a blog post – people comments on this post and accused me of actually promoted doing waterfall disguised as agile – just because I advised a few neat deliverables other than writing code during the first iterations or sprints of my projects. Come again? Since when does being agile mean not capturing requirements. I’m not promoting the big upfront design here. Who says I have to deliver code anyway? I’ve used agile principles, techniques  and best practices  in numerous projects, including projects that didn’t deliver any code at all (like code audits). A backlog contains work to be done, whether that’s “check software architecture”, “investigate namespace dependencies” or “write login screen”. My burn down is still valid, and so are my estimates.


Another example? I love to have my requirements modeled out in what we call smart use cases – small use cases of similar complexity and granularity that work pretty well in filling the project backlog and determine sprint backlogs (just to use the currently most popular terminology). But, standing at a coffee machine at a customers office  a Java developer came up to me, claiming that I should write user stories on post-its instead of modeling smart use cases in a UML modeling tool. And why? “Because that’s what Scrum dictates.” Eh.. “We do not do use cases in agile projects,” said my developer, long hair, goatee and all. “And besides, we do not promote modeling tools.” Come again?


That’s agile rigidity for you. In my honest opinion, with a huge crowd of people migrating into agile software development, agile rigidity will play an increasing role in our life. And it will definitely contribute to failure in near future agile projects. Now you should note that this anti-pattern is not a threat coming from the ever dangerous outside world. This threat will be coming at you from within your own project. It’s Trojan rigidity. But there’s hope for you: just follow the correct procedures.