Een goede IT-architect is een communicator die de ICT relevant kan maken voor een specifieke bedrijfsvoering. En die vertaling zou ook tot in de directiekamer moeten gebeuren.
Het is de kunst om het ontwerp te presenteren in de taal die de klant spreekt.
Wie voor de keus staat om een huis te kopen, stelt een wensen- en eisenpakket op voor het kunnen kiezen van het juiste object. Dat zijn al meteen twee termen: de koper heeft het over een huis (de emotionele koper zelfs over een thuis) en een makelaar heeft het over een object. Sommige makelaars spreken daadwerkelijk de taal van de koper. De kandidaatkoper staat voor een grote beslissing en wil graag relevante informatie hebben (conform het wensen- en eisenpakket) zodat hij gefundeerde keuzes kan maken.
Als de makelaar aangeeft dat voor de waterleidingpijpen in het toilet beneden een diameter is gebruikt van 12 mm met bijbehorende waterdruk, dan is deze informatie minder relevant dan het weten dat er een toilet op de begane grond aanwezig is met een oppervlakte van 1,50 × 1,20 vierkante meter. Ook het hebben van wandcontactdozen voor elektra is bijzonder handig als je bijvoorbeeld lampen wilt gebruiken. Dan is de plek van de contactdoos wellicht relevant, maar dat ze volgens NEN-normering zijn geïnstalleerd is overbodige informatie en eerder verwarrend. Want zijn er dan nog andere normeringen die je had kunnen of moeten kiezen?
Disciplines
Als IT-architect heb je ook zo’n rol waarbij je moet kiezen tussen het geven van technische details van een ontwerp, of relevante informatie die de beslisser nodig heeft om het besluit te kunnen nemen en onderbouwen. In het hele ketenproces van ontwerp naar realisatie zijn verschillende disciplines vertegenwoordigd en heeft iedere discipline eigen verantwoordelijkheden. De architect ziet toe dat iedere discipline de juiste detailgegevens verwerkt in het ontwerp en dat het ontwerp aansluit op het eisenpakket van de klant. Maar het detailontwerp is niet echt geschikt als communicatiemiddel. Te veel (technische) details kan verwarrend zijn en het is de kunst om het ontwerp te presenteren in de taal die de klant spreekt.
De architect zorgt dat iedere discipline de juiste detailgegevens verwerkt
Hoe doet een IT-architect dit? De communicatie over en weer met de systeemontwerper gaat bijvoorbeeld al gauw over systeemspecificaties, use cases en system context-diagrammen, terwijl de interacties met de technische specialisten gaan over hardwarespecificaties, netwerk- en firewallinstellingen enzovoort. Iedere discipline in de keten heeft te maken met technisch zeer complexe materie en de architect moet deze taal begrijpen. Maar dit is beslist niet de taal van de opdrachtgever die het eisenpakket (vertaald naar functionele en non-functionele requirements) heeft opgesteld. Vaak worden ontwerpen gemodelleerd en ondergebracht in ontwerpdocumenten met lange tabellen, technische kreten en het liefst complexe schematische voorstellingen.
Details
Hoe zorgt een architect ervoor dat diegene die een besluit moet nemen over een ontwerpvoorstel – en die dus ook verantwoordelijk is voor het geld dat uitgegeven gaat worden – voorzien wordt van de juiste (begrijpbare) informatie? De architectengemeenschap heeft al vele pogingen gedaan op dit gebied, maar te vaak worden belangrijke en grote ICT-projecten opgeleverd die niet aan de vraag voldoen. Techniek is ook emotie en een ICT’er heeft de kennis natuurlijk niet voor niets. Die demonstreer je natuurlijk! Het in lijn brengen van de vraag met de oplossing is een behoorlijk complexe aangelegenheid als je denkt aan alle mogelijke technische details waar je mee te maken hebt. De aanname dat een ICT-architect ook vanzelfsprekend de plek krijgt om deze rol uit te voeren is in veel gevallen onjuist. Een techneut in de directiekamer is natuurlijk ondenkbaar.
Wolkjes
De rol van ICT verandert snel. Erg snel. ICT is niet langer een enabler, zoals vaak wordt gezegd, maar een initiatiefnemer. ICT kan zorgen voor nieuwe businessmodellen en processen en kan daardoor directe impact hebben op de bedrijfsvoering. Met die gedachte is het helemaal niet gek om architectuur in de directiekamer te bespreken. Dit stelt natuurlijk eisen aan de architect. Hij moet ICT-capaciteiten kunnen vertalen naar de bedrijfsvoering, maar ook de ICT-impact op de gehele keten kunnen overzien. Stel je voor dat de Rijkscloud uiteindelijk resulteert in een aantal los ronddrijvende Rijksschapenwolkjes…
Een architectuur moet de ICT relevant maken voor zijn of haar specifieke bedrijfsvoering. Dit betekent dat de architect de koppeling moet kunnen maken tussen techniek en business. Enerzijds een businessarchitect en anderzijds een techneut.
Waar we nog vaak spreken over Business & IT Alignment moeten we nu eigenlijk spreken over IT als cruciale voorwaarde voor bedrijfsinnovatie. Wie vertegenwoordigt IT in dit proces? IBM heeft een grote architectencommunity die zich bekwaamt in de rol van enterprisearchitect. Een belangrijke randvoorwaarde is dat deze architect wel een zeer ruime achtergrond en ervaring moet hebben. En geschoold moet zijn in zowel bedrijfsactiviteiten als alle takken van ICT-sport. Zeg maar van ontwerp tot exploitatie, en dit kunnen vertalen naar begrijpbare taal in de directiekamer.
