Terug naar de kern van architectuur

ICT-architectuur is vaak kostbare flauwekul. Architecten sluiten
onvoldoende aan bij de praktijk, ze maken architectuurproducten
die niemand begrijpt en hun denkbeelden worden niet gedragen.
Veel organisaties zouden nauwelijks minder af zijn zonder hun architecten
en de architecturen die ze maken. Dat is jammer, want een
ICT-architectuur kan cruciaal zijn bij het begrijpen en veranderen
van de informatievoorziening.

Lees het volledige artikel.

Gepubliceerd in AG Connect, juni 2017.

Drie dingen die enterprise architecten van agile kunnen leren

Enterprise architecten kunnen iets leren van agile. Drie lessen.

1. Stel prioriteiten

Agile teams beperken zich tot datgene wat nu belangrijk is voor de klant. Niet meer, niet minder. De enterprise-architect heeft per definitie een enorme scope. Het is daarom zaak dat hij prioriteiten stelt. Het volledige landschap in kaart? Honderd principes? Een complete repository? You ain’t gonna need it.

2. Verkort de feedbackloop

Op papier is het makkelijk oplossingen verzinnen. Pas in de praktijk worden zowel de kracht als de beperkingen van een doelarchitectuur zichtbaar. Agile development betekent incrementeel en iteratief werken. Een agile enterprisearchitect lost de belangrijkste deelproblemen op en blijft betrokken tot en met de realisatie van zijn voorstellen. Hij vraagt actief om kritiek en leert ervan.

3. Wees een waterdrager

Een belangrijk principe van agile development is de nauwe samenwerking tussen klant en het ontwikkelteam. De agile enterprise-architect is noch van de business, noch van de techniek. Hij stelt zich in dienst van de onderneming om deze twee werelden beter te laten samenwerken.

Vier valkuilen rond architectuurprincipes

Architectuurprincipes zijn een populair, maar lastig te hanteren instrument. De volgende vier fouten worden te vaak gemaakt:

1. Te veel principes

Architecten zitten vaak vol goede ideeën en een nieuw principe is snel bedacht.
Maar met hoeveel principes kan een mens leven? Een handvol, misschien? Voor
organisaties geldt hetzelfde. Elk principe kent een prijs.

2. Bestaande principes negeren

Elke organisatie kent zo zijn ongeschreven regels. Vaak liggen aan die regels verborgen principes ten grondslag, die zelden hardop benoemd worden. Een voorbeeld is het voorkomen van gezichtsverlies bij leidinggevenden. Zulke principes negeren, leidt snel tot onverwachte en schijnbaar irrationele weerstand.

3. Comply or explain

Een bekende tactiek om de pijn van principes te verzachten, is ‘comply or explain’: wie zich niet voegt, moet uitleggen waarom niet. Maar een principe dat slechts af en toe geldt, is geen principe maar een vuistregel of een tip.

4. Principes verwarren met goede voornemens

Veel organisaties zeggen dat ze ‘de klant centraal stellen’ en worstelen daar vervolgens vreselijk mee. Gemeenten, ziekenhuizen, verzekeraars: ze zijn vaak niet ingericht om aan dit principe te kunnen voldoen. Hoe goed de bedoelingen ook zijn, zulke onhaalbare principes leiden enkel tot frustratie en cynisme. Ambitieuze doelen stellen is prima, maar gun de organisatie tijd om te groeien totdat ze eraan kunnen voldoen. Tot die tijd mag het geen principe heten.

Antipatronen ontmantelen

Antipatronen maken organisaties stram en belemmeren innovatie. Maar ze doorbreken kan een taai en lastig proces zijn. Hoe pak je dat aan?

Stel, een beheerteam blust continu brandjes en besteedt nauwelijks tijd aan proactief beheer. Een poging om het gedrag te veranderen heeft geen blijvend effect. Geen wonder, want dat is symptoombestrijding.

Stap 1 is herkennen dat er een antipatroon aanwezig is en dat dit geen probleem
van het team is, maar een organisatieprobleem dat veel breder speelt. Het is dus geen kwestie van mensen die iets verkeerd doen, maar een samenspel van krachten dat bepaald gedrag uitlokt en in stand houdt.

Stap 2 is daarom het uitvoeren van een krachtenanalyse. In kaart brengen hoe het antipatroon zichzelf in stand houdt, plaatst het gedrag van de betrokkenen in de juiste context. Brandjes blussen kost tijd en energie en gaat ten koste van aandacht voor preventie. Daarom ontstaan er steeds nieuwe branden. Bovendien werkt blussen verslavend: onder hoogspanning problemen oplossen geeft gewoon een kick. De inspanning en het effect van dergelijk werk zijn ook uiterst zichtbaar, wat schouderklopjes uitlokt van collega’s, maar ook van het management, zeker als er een ramp is afgewend. Samen kan dat leiden tot een cultuur waarin blussen als veel waardevoller wordt ervaren dan preventie.

Stap 3 is het krachtenveld aanpassen. Preventie moet stoer worden en brandjes blussen een uitzondering. Het kost tijd om zo’n verandering te bestendigen en het leidt onherroepelijk tot ontwenningsverschijnselen. Volhouden is het devies.

brandjes_antipatroon

Zeven waarschuwingssignalen voor innovatieve, risicovolle projecten

In ons artikel ‘Eerst proberen, dan doen‘ betogen collega’s Gert Florijn, Matthijs Maat en ik dat innovatieve, risicovolle projecten fundamenteel anders aangestuurd moeten worden dan  ‘normale’ projecten. Dit zijn zeven signalen die erop kunnen wijzen dat je met zo’n probeerproject te maken hebt.

1 Nieuwe wet- en regelgeving

IT-projecten starten vaak noodgedwongen voordat een op nieuwe wet- en regelgeving gebaseerde uitvoeringspraktijk is ontstaan. Het plaatsonafhankelijk bijhouden bij de basisregistratie personen, het toekennen en uitbetalen van PGB’s: uitzoeken en ervaren wat wel en niet werkt kost een nauwelijks te voorspellen hoeveelheid tijd, mede door de traagheid van regelgevings- en afstemmingsprocessen.

2 Nieuwe samenwerkingsverbanden

Zowel bij de aansturing als bij de uitvoering van IT-projecten zijn vaak meerdere partijen betrokken. Op vlakken zoals eisen en wensen, methodes en technologie is het ook zonder de verschillende belangen van verschillende organisaties al moeilijk genoeg om goed af te stemmen. Samenwerking tussen nieuwe partijen, of tussen partijen in nieuwe rollen, zorgt voor veel onzekerheid en dus risico’s.

3 Nieuwe methodes, tools en technieken

Ontwikkelingen gaan snel. Van iteratief ontwikkelen via XP en Scrum naar DevOps was een kwestie van jaren. Nieuwe ontwikkelhulpmiddelen en raamwerken volgen elkaar – zeker in de opensourcehoek – nog sneller op. Veel tijd gaat op aan het goed op elkaar laten aansluiten van methodes, tools en technieken. Bij elk nieuw element begint dat spel opnieuw.

4 Nieuwe technologie

Legacy is voor organisaties geen probleem, maar een oplossing. Bewezen technologie, voorspelbaar toepassen, is dat niet precies wat je wilt in een project? Nieuwe technologie lijkt een kans om iets beter, sneller of goedkoper te doen, maar is in de praktijk ook een risico.

5 Politieke zichtbaarheid

Hoe saaier het project, hoe groter de kans op een onverstoorde uitvoering in de luwte. Zodra een project speelbal wordt van de politiek – en daarvoor is de suggestie van een ‘mislukt project’ al voldoende – leidt de waan van de dag tot extra complexiteit.

6 Grote ambitie

Zeker in overheidsland doemt af en toe het idee van een nieuw integraal generiek hyperflexibel systeem op dat alle bestaande oplossingen kan vervangen. Dat leidt gemakkelijk tot tunnelvisie en vaak tot serieus falen.

7 Onduidelijk doel

Bij verrassend veel projecten is het achterliggende doel onduidelijk. Welk probleem is er eigenlijk? Hoe manifesteert zich dat voor de verschillende belanghebbenden? Zonder antwoord op dit soort vragen is het lastig te bepalen wanneer een oplossing goed genoeg – en een project klaar – is. Al deze zaken raken aan mensen, een factor met grote impact op de snelheid en kwaliteit van IT-projecten. Scrum is allang niet nieuw meer, maar begrijpt de beoogde product owner zijn rol wel? Is de functioneel analist bekend met de wetgeving? Hebben de ontwikkelaars ervaring met de raamwerken en tools? Het is moeilijk het belang van goede en ervaren mensen en ingewerkte teams te overschatten.

Eerst proberen, dan doen

Dit artikel verscheen in AGConnect. (PDF-versie.)

Vergroot de kans op succesvolle projecten

IT-projecten hebben een slechte reputatie. Ze duren te lang, kosten te veel en leveren te weinig op. Welbeschouwd is het een wonder dat er nog zoveel IT-projecten slagen. Wat de manier waarop grote IT-projecten worden aangestuurd, moet fundamenteel anders.

door Gert Florijn, Matthijs Maat en Eelco Rommes

Veel projecten worden gestuurd op een vooraf bepaalde begroting in tijd en geld: dít moet het resultaat zijn, het mag zoveel kosten en dán moet het af zijn. Dat kan werken, maar alleen als er een realistische planning en schatting is gemaakt en er onderweg niet te veel verandert. En dat is zelden het geval.
Te vaak is een projectbegroting gebaseerd op magisch denken: als we hard genoeg hopen, wordt het vanzelf waar. Neem de minister die onder druk in de kamer een datum noemt waarop ‘het probleem is opgelost’. Of een projectgroep die een bedrag in het ‘project initiation document’ zet waarmee de stuurgroep kan leven. Of de leverancier die een scherpe offerte afgeeft om concurrenten de loef af te steken. Met een goed beeld van het eindresultaat en van wat er nodig is om dat te bereiken, heeft zo’n begroting weinig te maken.

DOE-PROJECTEN

Niet dat schatten en plannen voor ieder IT-project onmogelijk is. Van een leverancier die in het derde ziekenhuis een ERP-implementatie uitvoert, mag je verwachten dat hij een beeld heeft van hoe lang zoiets duurt en wat het gaat kosten. Er is duidelijk met welk soort systemen er gekoppeld moet worden en wat de impact is voor medewerkers – en de leverancier brengt mensen mee die ervaring hebben opgedaan in vergelijkbare projecten.
Dat betekent niet dat zo’n project eenvoudig is. Er gebeuren altijd onverwachte dingen. Maar in de regel volstaan degelijk projectmanagement en aanverwante maatregelen daarvoor. Dit zijn ‘doe-projecten’: projecten met weinig onzekere factoren, die je met vertrouwen kunt aanpakken.
Veel IT-projecten kennen echter onzekere factoren die het schatten bemoeilijken. Een grote ambitie, een nieuwe leverancier, hippe technologie of veranderende werkprocessen zijn maar enkele voorbeelden. In zo’n situatie schieten de foutmarges in de schattingen omhoog. Stug vasthouden aan een vooraf bepaalde begroting leidt dan vanzelf tot mislukking. De controlemechanismes verder opschroeven werkt averechts: strenger toezicht, meer controle, vaker rapporteren, het stuurt het project alleen maar sneller zijn ondergang tegemoet.

PROBEERPROJECTEN

Voor zulke projecten is een aanpak nodig waarin je niet schematisch maar verkennend te werk gaat. Dat betekent: kleine stappen zetten. Alternatieven uitproberen om te kijken welke kansrijk zijn. Het doel bijstellen op basis van de opgedane ervaringen. Niet krampachtig doorgaan, maar (liefst vroeg) durven stoppen en de investering zien als vergoeding voor een leerervaring. En vooral: niet op dag één een einddatum en bedrag afgeven en je daarop blindstaren.
Dit gaat verder dan agile werken. De verkennende aanpak van ‘probeerprojecten’ betekent dat de opdrachtgever en andere belanghebbenden onzekerheid accepteren en daarmee om kunnen gaan. Het is cruciaal voor het succes van een project om te weten of je met een doe- of een probeerproject te maken hebt. Doe-projecten kun je gewoon doen – hoewel je onderweg scherp moet blijven op nieuwe onzekere factoren waardoor je afdwaalt naar onbekend terrein. Probeerprojecten moet je niet doen, maar proberen.
Dit moet ook terugkomen in de projectaanpak: goede (en continue) risico-inschattingen, inzetten van mitigerende maatregelen en regelmatige reflectie op fundamentele vragen: is de aanpak nog goed? Moeten we andere stappen nemen? Moeten we wellicht stoppen? Dat gaat niet zozeer om lef – stoppen moet een normale en realistische uitkomst kunnen zijn.
Het is ook cruciaal om te herkennen of de cultuur klaar is voor een probeeraanpak. Zo niet, vlucht dan niet in schijnzekerheid, maar neem onzekerheden weg tot er een doe-project overblijft dat wel planbaar is. Bijvoorbeeld door niet de nieuwste technologie te kiezen, maar genoegen te nemen met technologie waarmee de organisatie vertrouwd is. Door opnieuw met een bekende leverancier samen te werken. Of door het project op te breken in meerdere kleine projecten en die na elkaar uit te voeren. Elk kleiner doe-project kan een deelresultaat opleveren en onzekerheden verkleinen of wegnemen.
Weersta in elk geval de verleiding om een complex project op te breken en de kleinere projecten parallel uit te voeren in een programma. Dan neem je de onzekerheden niet weg, maar verplaats je ze naar het programmaniveau.

TE SNEL TE GROOT

Voor veel van de IT-projecten die als mislukt in het nieuws komen, is de vraag gerechtvaardigd of ze niet ten onrechte als doe-project zijn aangepakt. Vanaf dag één gingen ze in volle omvang voor jaren aan de slag, terwijl er zoveel onzekere aspecten speelden dat proberen beter op zijn plaats was geweest. In plaats daarvan is doormarcheren de norm, tot de begrote tijd en het geld op zijn en het hele project als falend IT-project wordt afgeblazen. Bij een probeeraanpak was er niets ‘mislukt’, maar hadden we tegen beperkte inspanning en kosten kunnen leren wat in ieder geval niet werkt. Om vervolgens constructief verder te zoeken naar oplossingen die wél succesvol zijn. Maar vaak wordt achteraf vooral naar zondebokken gezocht: de minister belooft beterschap, de projectgroep heft zichzelf op, de leverancier gaat op zoek naar zijn volgende klus.
Erkennen dat er onzekerheden zijn, is moeilijker dan het lijkt. In de politiek wordt professionele nuance nogal eens verward met een gebrek aan daadkracht. In de pers scoren pittige oneliners beter dan mitsen en maren. Kritisch tegengeluid laten horen is slechter voor je cv dan een gefaald miljoenenproject. In offertetrajecten leggen realistische bandbreedtes het af tegen een lage, vaste prijs. Zo blijven we de mislukte IT-projecten krijgen die we verdienen.

 

 

Why they just don’t get it

Communicating about architecture with business stakeholders

Jochem Schulenklopper and Eelco Rommes

This article was published in IEEE Software (PDF.)

Having been exposed to IT architecture descriptions of many kinds and flavors, we noticed that many IT architects don’t really speak their business stakeholders’ language. (In this article, we address the rather broad group of IT architects because they’re particularly lucky to have businesspeople in their stakeholder group. Nevertheless, architects of all kinds and backgrounds will discover valuable lessons here.) Common architecture languages favor correctness and completeness over expressiveness and clarity. The models and descriptions created using these languages fulfill the architect’s needs well but can be understood only by those with a similar mindset and background. Other stakeholders are often dazzled by the abstract symbols and terminology.

Here, we present visual-communication practices that have served us well to bridge the gap with business stakeholders. These practices stem from disciplines such as psychology, graphic design, communication science, and cartooning. They’re intended to aid all architecture stakeholders in understanding, analysis, and discussion.

What’s the Problem?

Over the past five years, we’ve trained about 300 novice and experienced IT architects in all kinds of organizations— from enterprise architects in the airline industry to infrastructure architects in municipalities. One problem that keeps popping up is how to communicate effectively with “the business.” “These businesspeople just don’t get it,” our trainees tell us. “What’s wrong with them?”

Our usual answer is that businesspeople aren’t the problem. The architects are. The architect’s tools for communicating with stakeholders are blunt and often unsuitable.

How Architects (Try to) Communicate

As birds come in flocks and sheep come in herds, so IT architects come in discussions. We architects love to communicate. We’ve even invented new languages and tools for it. But what happens when we use these languages to communicate with nonarchitects? Imagine you’re an IT architect, walking into a meeting room packed with managers. You don’t stress; you’ve done your homework. You connect to the projector, bring up the ArchiMate model of the company’s architecture, and start talking happily. But just when you reach the really juicy bits, someone interrupts. Usually, it’s a senior manager who asks with some level of politeness what on earth you’re talking about. Only now do you notice that half the audience looks irritated or puzzled— or both—and the rest are fiddling with their phones. Slightly panicking, you try to talk them through the model. “This stick man is called an actor. He’s a user of an application, but he might also be another system. Ellipses are services provided by the application. They’re used as a step in the business process shown here.” More frustrated faces. More fiddling with phones. You could have known: meetings with pointy-haired bosses are useless. They just don’t get it.

But why don’t they get it? Because you tried to explain a language instead of an architecture.

Effective communication means adapting the message to the audience, speaking their language, and selecting only the relevant information and presenting it accessibly. To make matters more interesting, architects communicate with a diverse set of stakeholders: end users, developers, operators, financial professionals, and business managers, to name a few. Each of them speaks a slightly different language, has his or her own interests, and has a different level of understanding of the system. Gregor Hohpe calls this “riding the elevator”: architects “[move] up and down between the board room and the engine room of a large enterprise.”

The information that’s relevant changes with every audience and occasion. Sometimes it’s budgets. Sometimes it’s risk. Sometimes it’s technical details. But it’s never your modeling language’s syntax. So, what’s a savvy IT architect to do?

Bridging the Communication Gap

One common approach is to simply ignore the differences and use a language that we as architects are familiar with. We might draw UML on a whiteboard, make jokes in Klingon, and answer questions with “42.” Implicitly, this means we expect the audience to learn our language, watch Star Trek, and read up on their Douglas Adams before speaking to us. Another approach is to become a polyglot by learning all their languages. That takes time you might not have, and it’s hard work. The question remains whether you’ll be able to communicate your thoughts, analysis, and solutions in a language that’s not grounded in IT. You’ll probably feel uncomfortable, not the trusted advisor you’d like to be. A third way is to create a common language together with your stakeholders that you use to communicate about IT architecture and their concerns. If the topic is important and sufficiently complex, this is your best option. This doesn’t mean you invent a completely new language that covers all business concerns from scratch. Rather, borrow from languages you all already speak to cocreate a language that suits your and your stakeholders’ specific concerns.

This is best done using an incremental approach in which you develop visualizations and their language in parallel. Typically, we use a series of workshops to show the visualization in intermediate stages and get feedback on its correctness, its effectiveness in making the architecture understandable, and whether it shows the right information at the right level. We bring large printouts to these workshops, distribute pens and markers, and stimulate the audience to enhance the visualization according to their insights and wishes. One advantage of this approach is that the resulting language is suited to the audience. Not everyone who makes financial decisions has an economics degree. In a technology company such as Philips or Siemens, many engineers and physicists hold senior management positions; they’ll bring metaphors, analogies, and metrics from their domain to the table.

Between workshops, we use the feedback to create a better version of the architecture description: clearer, more complete, and more effective.

Example: Information Flowing through a Landscape of Applications

archisurance

Here is an example of where this might lead to. Part of the IT-landscape of an imagined insurance company, inspired by the standard ArchiMate example. You might wonder how this differs from other architectural models you’ve seen and created. This is still boxes and lines, right?

Actually, instead of being generic items, these boxes, lines, colors, and symbols are loaded with meaning for the intended audience. The people in this company know exactly why the large red box in the middle is large and red: this IT application is at the heart of their company, and all the money flows through it. That’s also why it’s in the middle. The amount of persistent data determines the application’s size—that’s why the box is so large.

Most organizations have similar connotations in their internal vocabulary. For example, in the Dutch Tax Administration, blue, red, and green symbolize distinct parts of the organization. Even the outbound envelopes have colors matching these business domains. It would be foolish not to take this aspect into account when creating a visual model for the organization. But you can also create such connotations while creating visualizations. (As a rule, though, critical information shouldn’t depend on colors alone because color blindness is more common than you might think. For example, as many as 8 percent of men and 0.5 percent of women with Northern European ancestry have the common form of red-green color blindness.)

Typically, IT architects present images of the IT landscape as a collection of applications, connections, and databases. This is hardly interesting to business users. In financial terms, you’re showing a company’s assets and liabilities. This might be a necessity for the yearly report but doesn’t really tell you how the stuff is being used, by whom, and when and where. For the business, these latter aspects are way more interesting than applications and technology.

One of our more successful visual patterns shows the actual use of an IT landscape by employing “metro” lines to illustrate flows of information or the execution of business processes. Anyone who has seen a metro or train map immediately interprets this correctly: the metro lines bring data or state from one place to another. A circle indicates a metro station: that’s where the application is used to process information. This is another example of tapping into an existing language to retrieve elements that the audience already understands, instead of demanding them to learn a new syntax.

Example: Visualizing Quality Attributes Dynamically

dynamic_landscape

In some internal projects, we’re experimenting with letting business metrics determine an application’s size in a visualization, discovering whether that helps effectively communicate the crux of the matter. Here are groups of applications layered in blue, green, and orange. According to the “number of database records” metric, an application landscape might look like the upper left. The other landscape views differ according to some other metric—for example, each application’s yearly maintenance budget on the upper right. The applications’ colors and relative position remain stable, but the applications’ size tells a different story.

Some other metrics might reveal even more interesting views of that landscape: the number of users (lower left) or the number of availability incidents (lower right). This gives stakeholders a way to compare and reason about the landscape. Here are some examples:

  • The application crucially positioned in the center of the landscape has the lowest availability. Why?
  • The applications serving the most users don’t receive proportional budgets. Is that aligned with our plans?
  • The application managing the most data has the highest availability, but that plagued application in the center provides the only pathway to that data. How problematic is that?

In our experiments, the IT landscape on display isn’t a static image. A UI lets stakeholders select different business-oriented metrics. In response, the landscape view dynamically changes as applications grow or shrink according to the selected metric. Of course, there are as many business metrics as there are decision makers. Some are universal; others are domain or even stakeholder specific. The examples shown here are intended to spark creativity. Every architect must find the right language for his or her stakeholders.

Example: Visualizing How IT Availability Impacts Business Processes

availability_impact

This is adapted from our work for an application-hosting provider that manages mission-critical IT landscapes for businesses. Business and IT personnel share this view to answer, how do IT defects impact the business? The view shows the main business processes and the underlying IT applications but leaves out less relevant aspects such as integrations and application technology. The business processes drive the layout, showing the main processes as value streams through the organization. IT applications are ordered according to their place in these processes.

The hosting provider has a range of monitoring tools that gather realtime information on the applications’ performance and availability.

Business process status—ranging from all okay, to hindered operations, to unavailable—is dynamically updated, on the basis of the underlying applications’ availability.

This shared view means that problems are better understood and therefore less likely to cause stress. The IT department sees the impact of a failure and understands the need to solve problems quickly. Businesspeople see the colors of a process change before they notice any problems in their actual work. The knowledge that IT has the same view and is working on it builds trust.

Challenges with This Visualization Approach

This approach clearly has its drawbacks, especially from the traditional IT architect’s perspective. The visualizations need hard work because you can’t generate them from an architecture repository. They are incomplete and can be hard to maintain. Sometimes, the semantics are ambiguous, and they certainly don’t adhere to any standard.

We accept these drawbacks because we get something in return that’s much more valuable: visualizations that enable architects and the rest of the organization to communicate with each other about content, instead of having to explain or decipher the form. A shared language for describing the organization’s IT enables both architects and businesspeople to reason about it from their own disciplines and backgrounds, and make decisions that affect the architecture. In hindsight, we corroborate that our examples fit Grady Booch’s idea of “predicative and actionable [architecture] diagrams,” although they’re meant for not only colleague architects and developers but also business managers, end users, and other nonarchitects.

Further research and practice will increase our knowledge of how people with and without a technical background perceive and understand architecture visualizations. When we learn to speak the languages of our target audiences, they might, finally, get what we were trying to say all along.

Vier antipatronen die innovatie belemmeren

Artikel in de Automatiseringgids van 29 april (PDF.)

Een modern IT-systeem staat niet stil

IT-beheerafdelingen staan niet bekend om hun voorliefde voor veranderingen. Vaak gaat het grootste deel van hun tijd en energie op aan het in stand houden van de bestaande situatie, wijzigingen worden dan al snel gezien als een bron van problemen. Maar omdat innovatie en IT hand in hand gaan, is stilstand geen optie. Daarom ontwikkelen organisaties manieren van werken om met deze tegenstelling om te gaan. Vaak zijn dergelijke manieren van werken terug te vinden bij andere organisaties en dan spreken we van patronen. Kiest een organisatie bijvoorbeeld voor agile ontwikkelen, dan worden patronen als daily standups of pair programming geïntroduceerd. Wie PRINCE2 omarmt, zal stuurgroepen in het leven roepen die gaan sturen op businesscases. Zulke organisatiepatronen kunnen ook vanzelf ontstaan in de dynamiek van alledag. Door herhaald gebruik slijten ze steeds dieper in en worden ze onderdeel van de organisatiecultuur (‘zo werken wij hier’).

Een patroon waarvan de effecten schadelijker zijn dan de problemen die het oplost, noemen we een antipatroon. Zulke antipatronen bieden slechts tijdelijk soelaas waarna het probleem verergerd terugkeert, of ze verplaatsen de pijn naar een ander deel van de organisatie zonder de werkelijke oorzaak weg te nemen. Antipatronen ontstaan onder invloed van krachten die in elke organisatie een rol spelen, zoals macht, cultuur, leiderschap en beloningssystemen. Juist omdat alle betrokkenen doen wat zij in de gegeven situatie het beste vinden, kunnen antipatronen hardnekkig zijn. Vaak zijn de betrokkenen zich wel bewust dat er iets niet goed zit, maar overheerst een gevoel van machteloosheid: in mijn eentje kan ik er toch niets aan veranderen. Er zijn vier antipatronen rond IT-beheer te beschrijven die innovatie in de weg staan.

1. Keuzestress

Hoewel sommige organisaties meer veranderingen aankunnen dan andere, heeft zelfs de meest flexibele organisatie een beperkte verandercapaciteit. Als de grens bereikt wordt, komen veranderingen piepend en knarsend tot stilstand.

Toch proberen organisaties vaak veel te veel veranderingen tegelijk door te voeren. Dat leidt tot projecten die jaren doorsudderen, geen wezenlijke resultaten bereiken en toch niet worden stopgezet; tot afdelingen waar iedereen het razend druk heeft terwijl er zelden zaken worden afgerond; of tot leidinggevenden die verzuchten dat ze het zicht kwijt zijn op wat er op hun afdeling speelt.

Het simpelweg op een rij zetten van alle lopende programma’s, projecten en initiatieven werkt ontnuchterend. Niet zelden blijkt het aantal parallelle veranderingen in de honderden te lopen, rijp en groen door elkaar. Door zo’n lijst vervolgens af te beelden op het IT-landschap, worden risico’s zichtbaar en ziet men waar veranderingen elkaar in de weg zitten of zelfs tegenwerken. Het is dan essentieel om prioriteiten te stellen: vol inzetten op een paar echt belangrijke veranderingen en al het andere stopzetten, geeft lucht.

2. Problemen en oplossingen isoleren

Informatiemanagers in gemeenten kennen het gezegde wel: ‘ieder wetje een pakketje’. Voor elke wetswijziging waar een gemeente mee te maken heeft – en dat zijn er nogal wat – wordt er een nieuw softwarepakket aangeschaft. Deze tactiek biedt op de korte termijn verlichting en het stelt een gemeente in staat om tenminste aan de nieuwe wet te voldoen. Maar het heeft ook een dramatisch effect op het IT-landschap, dat langzaam verandert in een archipel van geïsoleerde applicaties. Het uitwisselen van informatie tussen deze losse pakketten wordt almaar moeilijker en de integratieproblemen kosten steeds meer tijd en inspanning. Dat maakt nieuwe veranderingen riskanter en de isolatietactiek des te verleidelijker.

Een stap richting een oplossing is om het bestaande landschap in kaart te brengen voor alle beslissers, IT-landschapsfotografie is daarvoor een geschikte techniek. Problemen en oplossingen kunnen vervolgens in samenhang worden beoordeeld.

3. De loopgraven in

IT-beheer wordt doorgaans afgerekend op de beschikbaarheid van systemen. Op de beheerafdeling van een bank bijvoorbeeld, was het hoogste doel verwoord als: ‘niet in de krant komen’. Zolang de belangrijkste klantapplicaties niet omvallen, doen we het goed, was de gedachte. Zo’n focus op het voorkomen van storingen leidt tot risicomijdend gedrag en bijna als vanzelf ontstaan dan tactieken om veranderingen te blokkeren. Elke verandering kan het evenwicht immers verstoren en we willen vooral niet in de krant komen.

De onderliggende overtuiging lijkt te zijn dat een onbeweeglijk landschap makkelijker kan worden beheerd, maar dat is een illusie. Het kan langzaam gaan of sneller, maar geen modern IT-systeem staat stil. Zelfs niet voor heel even. Toch graven beheerafdelingen zich in om op allerlei manieren ongewenste veranderingen te vertragen. Door een overschot aan bureaucratie te creëren, bijvoorbeeld: processen worden naar de letter gevolgd, voor elk hulpverzoek is een projectcode nodig en er worden handtekeningen geëist van steeds hogere managers. Spelen op de macht is een andere tactiek: berucht zijn de e-mails met kopieën aan een trits leidinggevenden. Als iemand persoonlijk verhaal komt halen, is vervallen in IT-jargon een beproefd middel om niet-techneuten af te bluffen.

Hoe kinderachtig zulk gedrag ook lijkt, de bedoelingen zijn doorgaans goed. Zulke tactieken komen voor als beheerders worden aangesproken op de continuïteit van het IT-landschap terwijl hun geen invloed gegund wordt op de veranderingen die dat landschap vormgeven of aantasten. IT-beheer zou als volwaardig gesprekspartner de veranderingen mede vorm moeten bepalen: samen uit, samen thuis. DevOps is een voorbeeld van een aanpak in die richting, al is die enkel gericht op organisaties die hun eigen software ontwikkelen.

4. Doe-het-zelf-IT

Geconfronteerd met de loopgraven van IT-beheer, ontstaat gemakkelijk de neiging om het dan maar zelf te doen, met name in organisaties met zelfstandige professionals. Een logistiek bedrijf dacht miljoenen euro’s te besparen door een verouderde boekhoudapplicatie te vervangen door een moderne variant. Kort na de start van het project kwamen gebruikers in opstand: in de loop der jaren hadden ze tientallen Excel-macro’s geschreven die van de oude applicatie afhankelijk waren. De IT-afdeling wist nergens van. Die macro’s bleken zo belangrijk te zijn voor het financiële proces dat het verstandiger bleek om die dure boekhoudapplicatie nog enkele jaren in stand te houden terwijl de macro’s een voor een werden gemigreerd. Weg miljoenenbesparing. Ook de anekdotes over managers die op de golfbaan enthousiaste verhalen horen over een nieuw stuk software en het de volgende dag zonder overleg aanschaffen, passen in dit patroon, net als de gebruikers die op eigen houtje via Dropbox werkdocumenten uitwisselen. Doe-het-zelf-IT ontstaat uit een behoefte en domweg verbieden is geen effectieve oplossing. Wie zich netjes aan zo’n verbod houdt, voelt zich gestraft, terwijl overtreders nog dieper wegduiken in de schaduw. Het is beter om een hobbyruimte te creëren aan de rand van het IT-landschap waar gebruikers hun gang kunnen gaan en hun successen met elkaar kunnen delen. Binnen die hobbyruimte geldt een losser regime, maar de ondersteuning is er ook beperkt. Geslaagde ideeën kunnen via een formeel proces richting het normale landschap worden geleid. Mislukkingen worden gedoogd of opgeruimd. Op die manier wordt de innovatiekracht van eindgebruikers ingezet voor het belang van de hele organisatie en kan een antipatroon worden omgebogen naar een waardevolle samenwerking.

Geef de projectarchitect de ruimte

Collega Rob Berentsen en ik leggen in dit artikel uit waarom het vaak wringt tussen architecten en project managers en wat je eraan kunt doen. In maart 2016 verschenen in de Automatiseringgids (PDF.)

Voorkom dat projectmanagers en -architecten vanaf dag één in de clinch liggen

De kans dat een IT-project slaagt is groter als de projectarchitect en de projectmanager goed samenwerken. Een oplossing en de weg ernaartoe hangen immers nauw met elkaar samen. In de praktijk komen we te vaak projectmanagers en projectarchitecten tegen die vanaf dag één met elkaar in de clinch liggen. De projectmanager wordt typisch verweten dat hij zich te veel met de techniek bemoeit, bij elk wissewasje met escalatie dreigt en procedures en afspraken negeert. Op zijn beurt geeft de projectarchitect altijd ‘dat hangt ervan af’ als antwoord, kan hij niets zelf beslissen en ziet hij overal beren op de weg. In het beste geval weet zo’n tweetal nog iets van het project te maken, maar de verstoorde verhouding kan ook bijdragen aan een mislukking. In de ideale wereld trekken de projectmanager en -architect vanaf de eerste dag samen op. Dan schrijft de projectmanager zijn plan van aanpak terwijl de architect direct aan het ontwerp begint. In de praktijk begint de projectarchitect echter vaak op achterstand omdat de architectuurkaders ontbreken. Zoals de projectmanager met zijn opdrachtgever afspraken maakt over tijd, scope en middelen, zo heeft ook de projectarchitect niet de absolute vrijheid om een oplossing te ontwerpen. De staande organisatie legt beperkingen op, verwoord in architectuurkaders, om te voorkomen dat het bedrijfsbelang ondergeschikt raakt aan projectbelangen. Zulke architectuurkaders horen al bekend te zijn voordat het project start. Als ze er niet of niet tijdig zijn dan heeft het project, in theorie, carte blanche om een oplossing te kiezen die het beste past. In de praktijk staan in zo’n geval op onverwachte momenten alsnog belanghebbenden op die de projectarchitectuur kunnen afwijzen. Dat kan leiden tot wijzigingen in de architectuur en het kan projectplannen in de war schoppen. Denk aan een security officer die blokkerende risico’s ziet of een beheerafdeling die aangeeft dat de nieuwe servertechnologie te laat beschikbaar zal zijn. Veel projectarchitecten kiezen er daarom voor om zelf de kaders op te halen waarbinnen ze moeten werken. Dat mondt al snel uit in een langdurig proces van informatie verzamelen, concepten schrijven en reviewrondes organiseren. Terwijl de architect daar zoet mee is, gaat de project- manager door met zijn plan van aanpak – hij heeft immers een deadline te halen. Daarmee richt hij zich al op de oplossing terwijl de architect nog bezig is de vraag te verkennen. Geen wonder dat er spanningen ontstaan. De projectarchitect bevindt zich op zo’n moment in een spagaat. Hij is medeverantwoordelijk voor het slagen van het project, maar tegelijkertijd wordt van hem verwacht dat hij optreedt als hoeder van de (overkoepelende) enterprise-architectuur. Een onmogelijke positie, omdat de belangen van de staande organisatie en die van het project lang niet altijd in elkaars verlengde liggen.

Twee principes

Om dit patroon te doorbreken, moet een aantal zaken goed geregeld worden. Ten eerste moet het proces worden afgesproken om een project op te starten. Op zijn minst moet dat proces mijlpalen definiëren met hun entry- en exitcriteria en wie daarvoor verantwoordelijk is. Duidelijk is dat de projectarchitect zijn handen vrij moet hebben om voor zijn project het best mogelijke resultaat te behalen. Regels en richtlijnen ophalen hoort niet bij zijn takenpakket: kaders worden gesteld aan het project, niet door het project. Wanneer een project wordt opgestart, hoort het die kaders direct mee te krijgen en vanaf dat moment moeten ze ook stabiel zijn: de spelregels mogen niet zomaar worden veranderd als het spel eenmaal is begonnen.

De architectuurkaders voor een project zijn vrijwel altijd gebaseerd op algemene regels en richtlijnen. Veel organisaties hebben zulke richtlijnen wel, maar ze zijn niet altijd opgeschreven en wat er wel op papier staat, is vaak verspreid over verschillende documenten die zich schuilhouden in een hoekje van het intranet of op een gedeelde harde schijf. Ze samenvoegen in een set basisregels en die centraal beschikbaar stellen, maakt duidelijk wat de afspraken zijn waaraan een project zich heeft te houden. Twee principes moeten leidend zijn bij het opstellen van zulke algemene architectuurkaders: ‘concreter is beter’ en ‘minder is meer’. ‘Concreter is beter’ wil zeggen dat direct toepasbare richtlijnen en vuistregels meer waard zijn dan vage principes. Bijvoorbeeld: we ondersteunen deze versies van MySQL en SQL Server als databases; met deze leveranciers werken we graag samen; in koppelingen met externe partijen gebruiken we protocollen X, Y en Z. Wie van zulke regels wil afwijken, moet toestemming vragen. Wie ze volgt, kan ongehinderd voortgaan.

Het aantal kaders beperken is belangrijk omdat concrete regels en richtlijnen altijd pijn doen. Door grenzen te stellen, beperkt de staande organisatie de vrijheid van het project om de beste oplossing te kiezen. Hoe ruimer de grenzen zijn, hoe groter de kans dat er een haalbare en maakbare oplossing gevonden wordt: minder kaders betekent meer vrijheid. Daarom moet de staande organisatie de verleiding weerstaan om het denkwerk van projecten over te nemen en moet zij alleen keuzes maken om hogere organisatiebelangen te bewaken.

Eén board

Om te voorkomen dat een project bij allerlei gremia en loketten om toestemming moet bedelen, moeten de verschillende belanghebbenden van de projectarchitectuur zoveel mogelijk worden samengebald. Laat een enkele board de belangen van bijvoorbeeld enterprisearchitectuur, beheer en het security office vertegenwoordigen. Een effectieve board houdt zich verre van peer reviews en inhoudelijk advies, maar toetst alleen aan de vooraf afgesproken kaders. Hij richt zijn aandacht met name op projecten die iets nieuws proberen of onvoorziene wegen inslaan. Dat zijn namelijk de projecten waarvan de organisatie kan leren en die kunnen leiden tot het radicaal verbeteren en aanvullen van de architectuurkaders. Door op deze manier de architectuur in de staande organisatie te scheiden van die in projecten wordt vertraging voorkomen en krijgen projecten de kans om te doen waar ze voor bedoeld zijn: snel en betaalbaar IT-oplossingen realiseren waar de staande organisatie mee uit de voeten kan.

Zes suggesties voor een wendbaar IT-landschap

Dit artikel, geschreven met collega Gert Florijn, verscheen als ‘Complex IT-landschap is één systeem’ in de Automatiseringgids.

Vrijwel iedere organisatie is afhankelijk van informatietechnologie, maar lang niet elke organisatie ontwikkelt haar eigen software. Ziekenhuizen, gemeenten, middelgrote bedrijven en allerlei andere organisaties schaffen voornamelijk standaardpakketten aan, die ze vervolgens zo goed mogelijk in hun bestaande informatievoorziening inpassen. Omdat informatie altijd op meerdere plekken ontstaat en nodig is, worden tussen die applicaties koppelingen aangelegd in soorten en maten. Zo ontstaan zeer complexe landschappen die steeds moeilijker aan te passen zijn. Tegelijkertijd neemt de druk om de informatievoorziening snel te kunnen veranderen toe. De overheid digitaliseert, klanten en gebruikers worden veeleisender, leveranciers komen vaker met updates en ketenintegratie wordt belangrijker. Dat wringt.

Wie zelf software ontwikkelt, probeert wendbaar te worden door agile development te omarmen. Voor organisaties die niet of nauwelijks zelf bouwen, is dat geen logische optie. Zelfs DevOps – kort gezegd: agile voor beheerders – werkt niet zomaar, omdat het een nauwe samenwerking tussen ontwikkelaars en beheerders voorstaat en niet iedere organisatie met iedere leverancier een innige relatie kan hebben.

Wij zijn ervan overtuigd dat als business en IT het echt willen, de wendbaarheid van ogenschijnlijk traag bewegende IT-landschappen sterk kan worden verbeterd. Dat vereist wel de moed om buiten gebaande paden te treden en om vanzelfsprekendheden ter discussie te stellen. Hoe zou het sneller kunnen dan ons standaardproces voorschrijft? Hoe kunnen we continu nieuwe functionaliteit beschikbaar stellen in plaats van enkele malen per jaar? Hoe kunnen we die grote, slecht begrepen verandering in een serie kleine stappen doorvoeren? Hoe kunnen organisaties met complexe IT-landschappen, maar met geen of weinig zelfbouw, wendbaarder worden? We doen zes suggesties.

1 Beschouw het landschap als één systeem

In veel organisaties wordt het IT-landschap gezien als een verzameling losse applicaties die zo goed mogelijk beheerd moeten worden. Eigenaarschap en regie worden ook op dat niveau geregeld, met koppelingen als de lelijke stiefkinderen waar eigenlijk niemand voor wil zorgen. Deze manier van kijken lokt investeringen uit in losse systemen of op zijn best in clusters van applicaties die onder dezelfde afdeling vallen. Maar informatie laat zich niet in een hoek drijven – die stroomt door de gehele organisatie.

Veranderingen resulteren daarom vaak in een hagelschot projectjes, soms samengebald in programma’s, die elkaar in de weg zitten en soms tegenwerken. In een complex landschap hebben lokale veranderingen echter altijd gevolgen op allerlei andere plaatsen: gekoppelde applicaties en de onderliggende platformen en middleware moeten worden aangepast, informatiestromen verlegd, kennis bijgespijkerd, werkprocessen vernieuwd.

Door het landschap te beschouwen als een enkel, samenhangend systeem, kan op een hoger niveau worden gestuurd en ontstaat meer grip op veranderingen.

2 Breng het landschap als geheel in beeld

Als klant heeft een organisatie weinig invloed op de architectuur van de applicaties die hij aanschaft, maar op het landschap als geheel valt wel winst te behalen. Daarvoor is inzicht en overzicht cruciaal: wat is er in huis aan technologie, functionaliteit en data? Hoe hangt alles samen? Hoe lopen processen en waar wordt informatie gecreëerd, gedeeld en gebruikt? Een gedeeld begrip van het grote geheel is daarbij vele malen belangrijker dan formele correctheid en uitwerking tot op het kleinste detail. IT-landschapsfotografie is een goede manier om dat gedeelde begrip te laten ontstaan.

Het begint bij een overzicht van wat er allemaal is aan applicaties en hoe ze min of meer samenhangen. Dat maakt het domino-effect van lokale veranderingen direct inzichtelijk. Vervolgens kan zo’n basisplaat verrijkt worden met informatie die op een bepaald moment voor bestuurders relevant is. Denk aan risico’s, kosten of achterstallig onderhoud. Omdat landschapsfoto’s bedoeld zijn voor beslissers, moeten ze ook voor hen begrijpelijk zijn. Niet de IT is eigenaar van de informatiesystemen en de daarin opgeslagen informatie, de organisatie is dat. Landschapsfoto’s worden daarom opgesteld in een visuele taal die voor alle belanghebbenden begrijpelijk is (zie Automatisering- Gids, 9 augustus 2007, ICT-landschapsfoto onmisbaar voor besluitvorming).

3 Breng de technische schuld onder controle

Ervaren softwareontwikkelaars weten dat ze voortdurend aandacht moeten besteden aan de kwaliteit van hun broncode. Als de broncode vervuilt, wordt het moeilijker om aan te passen. Dit mechanisme staat bekend als technische schuld: wie de kwaliteit laat glippen, bouwt een steeds zwaardere schuldenlast op. Datzelfde mechanisme is aanwezig op het niveau van IT-landschappen. De technische schuld van een landschap zit bijvoorbeeld in het gebruik van verouderde platformen, in handmatige koppelingen, ingewikkelde inregelingen, gebrekkige documentatie, of slechte datakwaliteit – eigenlijk al het achterstallig onderhoud dat veranderen risicovol of moeilijk maakt.

Veel IT-landschappen zijn belast met een torenhoge technische schuld. Meestal is die schuld onvoldoende in kaart gebracht, waardoor het lastig is er verstandig mee om te gaan. De schuld op hoofdlijnen inzichtelijk maken is cruciaal, landschapsfoto’s zijn daarvoor een goed vertrekpunt. Vervolgens kan die schuld in stapjes worden afgelost, terwijl tegelijkertijd het ontstaan van nieuwe schuld aan banden wordt gelegd. Enkele tips: lifecyclemanagement en tijdig upgraden van systemen helpt om problemen met legacy te voorkomen. Kiezen voor standaardoplossingen en het beperken van specials dammen complexiteit in. Investeren in ontkoppelen van applicaties op technisch niveau maakt het landschap flexibeler – denk aan bussen, brokers en standaardprotocollen. Bronsystemen aanwijzen, gebruiken, verbeteren en bewaken helpen om de datakwaliteit op te schroeven.

4 Zoek de pijn op

Een van de redenen dat de technische schuld in een landschap oploopt, is dat mensen van nature geneigd zijn om pijn te vermijden. Als het veel moeite kost om een nieuwe versie van het CRM-systeem te implementeren, is het verleidelijk om de volgende upgrade maar een keertje over te slaan. Als het aansluiten op een servicebus veel ellende oplevert, is de kans groot dat nieuwe koppelingen die bus zullen omzeilen. Zo ontstaan langzaam maar zeker no go-areas in het landschap – systemen die niemand durft aan te passen omdat de risico’s te groot zijn dat er iets misgaat.

Het is zaak om door de zure appel heen te bijten en juist de dingen die moeilijk zijn, veel vaker te doen. Daarvan worden ze elke keer iets gemakkelijker en dat maakt de risico’s kleiner. De traditioneel defensieve IT-beheerorganisatie wordt hiermee offensief.

Grote taken kunnen het beste in kleine brokken worden verdeeld, om de pijn te verzachten. Dus niet in één keer van versie 1.3 naar versie 10.5 springen, maar eerst leren wat het betekent om naar 2.0 over te gaan. Het is verstandig om voor elke verandering een vangnet te creëren dat in staat stelt om snel fouten te detecteren en in het ergste geval terug te keren naar de uitgangssituatie. Herhaalde handelingen zoveel mogelijk automatiseren is daarbij een vereiste. Dat vergt investeringen in tools voor bijvoorbeeld automatische regressietesten, deployment en continue monitoring van de gebruikservaring van het landschap. Voor een systeem als SAP zijn tools beschikbaar om regressietesten te automatiseren en testdata synchroon te houden met productieomgevingen. Een vakman werkt met professioneel gereedschap.

5 Beleg eigenaarschap op het juiste niveau

In veel organisaties is eigenaarschap van IT belegd op het niveau van losse applicaties of hooguit groepjes. Vaak zijn er talloze applicaties aan te wijzen waarvoor niemand zich verantwoordelijk voelt. Soms is eigenaarschap een synoniem voor ‘de licentiekosten betalen’ en wordt het iets om te vermijden. Informatie heeft zelden een eigenaar, of het moet zijn ‘wij allemaal’.

Met een IT-landschap dat voortdurend beweegt, is dat een onwenselijke situatie. De kans is groot dat projecten elkaar in de weg zitten in een slecht begrepen landschap met veel technische schuld en wederzijdse afhankelijkheden.

Om toch grip op veranderingen te krijgen en ze in goede banen te kunnen leiden, moet er op landschapsniveau gestuurd worden. Dat vraagt om een eigenaar op bestuurlijk niveau die strategische keuzes maakt en prioriteiten stelt. Die eigenaar kan niet bij de IT-afdeling zitten: IT is niet de eigenaar van de informatie en de informatiesystemen, maar de beheerder/ leverancier ervan. De eigenaar zit bij de business (of daar in ieder geval dicht tegenaan). Omdat de scope al snel te groot wordt om op detailniveau het overzicht te houden, kan de landschapseigenaar worden ondersteund door anderen die op tactisch niveau sturing geven aan de veranderingen in een organisatiedomein. Dat vraagt wel een duidelijke afbakening van applicaties en afspraken over wie verantwoordelijkheid neemt voor welke informatie.

6 Zorg dat de juiste mensen aan de juiste tafel zitten

Om weloverwogen keuzes te kunnen maken over de informatievoorziening van een organisatie, zijn kennis en ervaring nodig uit verschillende invalshoeken. De juiste mensen moeten daarom aan tafel zitten als er richting wordt gegeven aan de veranderingen in een IT-landschap. Zowel het bedrijfsmanagement als IT-management hoort daarbij, maar ook inhoudelijke experts die de realiteit van de huidige situatie kennen en weten waar de pijn zit. Alleen zo’n multidisciplinair gezelschap, gevoed met informatie uit landschapsfoto’s, heeft alle kennis paraat die nodig is om realistische besluiten te nemen. En om het passende tempo van continue ontwikkeling en innovatie te bepalen.