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.

Advertenties

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.