This month I hope to round off the work on my new book Dit Is Agile (in Dutch). Last reviews are coming in, and I’m very happy with the results of my hand-drawn illustration for this new book.
The idea of drawing the illustrations by hand instead of using PowerPoint or Visio is working out fine, and also allows me to add some cartoons to the book as well.
I hope and trust the book will be in shops soon.
In the framework ADF.NET state can be temporarily stored by calling the StateManager. The StateManager is an static façade that holds three different instances of the IStateProvider interface. These instances are:
To facilitate easier use of state, we’ve added two overloaded extension methods that operate on the interface IStateProvider.
1: public static T GetOrDefault<T>(this IStateProvider provider, string key, Func<T> value)
2: {
3: if (!provider.Has(key)) { provider[key] = value.Invoke(); }
4:
5: return (T)provider[key];
6: }
7:
8: public static T GetOrDefault<T>(this IStateProvider provider, string key, T value)
9: {
10: if (!provider.Has(key)) { provider[key] = value; }
11:
12: return (T)provider[key];
13: }
Using these extension methods will allow you to get the value for a specific key, and in case it doesn’t exist yet, first add it to the state and afterwards return it. The first overload can be used to only evaluate the func when the key is not yet present, similar to the following code example.
1: public static DomainCollection<Company> GetAll()
2: {
3: lock (cacheLock)
4: {
5: return StateManager.Personal.GetOrDefault(key, () => List(CompanyGateway.GetAll()));
6: }
7: }
Here, the List() method is only invoked if no key is present.
The second overload is best used when the value does not need to be evaluated, but rather already exists.
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.
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:
Een servicegeorienteerd project kent vele stakeholders
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:
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.
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.
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.
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.
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:
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.
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:
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.
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.
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:
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:
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.”
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.
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.
Later this week I will be doing a talk at the Microsoft DevDays conference at the Congrescentrum in Den Haag. This talk is titled Navigating through the hypes, Software architectures and patterns to help avoiding your projects to crash. Read more about it at www.devdays.nl.
Please fill in the little survey I’m conducting at
Survey: Which frameworks do you use in .Net projects?
In short, during this talk I will address both the benefits and pitfalls of applying frameworks to your projects. Be it Microsoft frameworks, open source frameworks or even self developed frameworks, there’s always a catch.
What if you require additional features that aren’t implemented in the framework? What if you decide that another framework would have been better and want to switch halfway your project? What if the author of your favorite open source framework suddenly stops developing? What if the framework contains bugs or omissions? And what if a new version of the framework is released that is implemented totally different? These and many more everyday problems will cause your project to come to a halt, or at least make you perform serious refactoring.
So, I will address some pragmatic software architectures and patterns that will help your projects to stay away from framework problems, and how to make your code less dependent of framework choices.
This brings me to my question to you. I’m curious to which frameworks you use – Microsoft, open source and / or own developed, and what your experiences are with these frameworks. Where they helpful, challenging or just plain crap?
Please fill in the little survey I’m conducting at
Survey: Which frameworks do you use in .Net projects?
Despite the current economic crisis – or maybe because of the current economic crisis – my upcoming workshop on modeling in software development projects using UML and beyond, which is held on March 4 and 5 in Hilversum, is still fully booked!
Hopefully nobody had to be disappointed. If so, the workshop will be repeated on September 30 and October 1 in the Netherlands. If you don’t mind driving to Antwerp – and who does – the workshop UML is also organized there on March 12 and 13 by IT Works (see www.itworks.be). there are still a few seats available.
YAGNI is a well known acronym in agile software development, which is short for You Ain’t Gonna Need It. Originally this acronym suggests to programmers that they should not add functionality until it is really necessary.
"Always implement things when you actually need them, never when you just foresee that you need them," says Ron Jeffries. Quite often developers think of writing generic code; code that foresees in features that is likely to be required in the future. However, writing code that might be desirable in the future has a number of disadvantages, for instance in the time that is needed to write your future code, you will not be able to write the code you need now. Also, the current code base becomes unnecessarily more complicated to extend and test. And moreover, you can never really be sure that this generic code will actually meet future features, as features will change over time during any project.
A much better approach to write code would be to just write the code that you need to get your current work items done. Or slightly better put: only write the code you need to get to the next steps. In other words, in projects we try to maximize the amount of code not written.
Although the YAGNI principle is best known when applied to writing code, it can be in fact very effectively applied to all kinds of activities executed in projects, such as analyzing requirements, step up software architecture, or design smart use cases. Just follow the following simple procedure will help you out:
Applying this basic procedure to all work items in projects has a number of benefits.
First of all, when you are doing work items to get to the next step, you can be quite sure that this next step will be actually taken. To clarify, compare a traditional waterfall styled project to an agile Smart project. In the traditional project, all functional requirements are analyzed well before they are actually implemented. This means that if somehow some of these requirements change during the course of the project, most work regarding these changing requirements is done unnecessarily. And it gets even worse if any requirements are dropped. In this case, all work associated these requirements was useless.
Secondly, suppose your analyzing requirements early in a project. Analyzing a particular requirement might take you 30 hours. In a YAGNI requirements approach, requirements will not be analyzed before they are realized.
In the agile methodology Smart, YAGNI becomes a very powerful principle. YAGNI guides the projects in each of the different types of iterations and all deliverables resulting. At each of Smart’s iteration types, and each of the deliverables and acitivities proposed, the project team needs to identify what the next steps is, and what the minimal amount of work is, to help get there.
For instance, the primary goal of the Propose iterations is to derive a project proposal. In Smart projects there is no need to do a extensive requirements analysis during the early stages of the project.
The question should be: what activities do we need to run to be able to write the project proposal. And just run these activities. In Smart one of these proposed activities during Propose is to create an estimate for the project. This (initial) estimate again will be based on the smart use cases that need to be realized during the project. So you will need to establish either the smart use case model, or a relevant list of smart use cases. And there you are. There is no need to do a full analysis of your requirements, but just enough to help you get to the next step, which is creating the estimate.
It also needs to be noted that during a software development project there is only one single moment when the requirements are actually fixed. And that is at the end of the project, when the software is delivered. Any stage earlier in the project that tries to do a full requirements analysis is doomed to fail. As research shows, on average requirements change 20% up to 25% during the project.
Another example of the effective use of the YAGNI principle in Smart is found in implementing smart use cases during Realize and Finalize iterations. It is not until here that the project team analyzes and (test) designs the individual smart use cases. But the team only does this for the current smart use case at hand. Only analyze one single use case at a time, design it, test design it and implement it. And only after this smart use case was accepted, start with the next.
Thus all work on smart use cases is done as late as possible, which make the work lighter, as later on during the project, the team will have more knowledge on the project domain, and need less time to do the design. Moreover, when starting the analysis and design for a particular smart use case, the team will be very sure that this use case will actually be built, and is unlikely subject to change, as it will be built right after the design is done.
For more information, check www.accelerateddeliveryplatform.com.