Op de een of andere manier bekruipt mij het idee dat ‘het proces’ en ‘de inhoud’ steeds vaker los van elkaar bewegen. Het is wonderlijk te merken dat mensen die enkel met het proces bezig zijn, of ‘bewaken’ zoals de gangbare term is, best tevreden kunnen zijn, terwijl de medewerkers die puur met de inhoud bezig zijn, erg ontevreden zijn binnen één en hetzelfde project. Andersom gebeurt trouwens ook wel eens.
Door alle lagen van de organisatie heen wordt er voortdurend nagedacht over hoe ‘het beter kan’. Dit resulteert meestal in uitspraken als: ‘we moeten Lean zijn’ of ‘we moeten Scrum introduceren’ of ‘we moeten het technisch beheer outsourcen’ of ‘we moeten zorgen dat er goed getest wordt alvorens we nieuwe software in productie zetten’. Op zich is dat allemaal goed en aardig, maar de kwaliteit van een product wordt daar niet per se beter van. En wie bewaakt nu de kwaliteit? Juist, dat zouden de architecten moeten doen.
Lage tevredenheidsscore
In veel organisaties is de afstand tussen het bestuur en de werkvloer veel te groot. Neem bijvoorbeeld de Vrije Universiteit in Amsterdam. De goede reputatie van vroeger ten spijt kent het de laatste paar jaar een lage student- (en docent)tevredenheidsscore. De afstand tussen het college van bestuur en de faculteiten blijkt onoverbrugbaar, iets wat een leek van verre had kunnen zien aankomen toen het bestuur en staf in 2008 een apart pand in Amstelveen betrok en de afstand dus zelfs fysiek creëerde.
Iets soortgelijks zie ik helaas maar al te vaak in de architectenwereld. Sommige architecten proberen zich zeer bewust te onderscheiden van ‘ontwerpers’, proberen afstand te creëren door tegen het topmanagement aan te schurken, terwijl de inhoud van het domein van architecten uit het zicht raakt. Dat managers de inhoud uit het oog verliezen is treurig maar enigszins begrijpelijk vanuit hun rol. Maar alsjeblieft, laat een architect zich nou niet als een manager gedragen. Bij elke grote organisatie en elk groot project zijn er al zovelen enkel met het proces bezig. Je zou denken dat het proces afhankelijk is van wat je wilt bereiken, maar het lijkt alsof het proces en de inhoud zich los van elkaar bewegen.
Interne it-systemen
Iedereen moet zich natuurlijk verantwoordelijk voelen voor goede diensten of producten die een organisatie levert, maar juist architecten, of het nu applicatie-, solution-, informatie-, enterprise of wat-dan-ook architecten zijn, zouden de kwaliteit moeten bewaken van de producten die de organisatie levert. En hiermee bedoel ik niet alleen de producten voor de klanten, maar juist ook de interne it-systemen.
Maar waarom is iedereen nu toch altijd bezig met de werkprocessen? Naar mijn mening komt dat omdat dit uiteindelijk makkelijker is dan het beoordelen van de inhoud. Het is nu eenmaal makkelijker om na te gaan dat het systeem getest is dan om te beoordelen of het goed getest is. Het is makkelijker te beargumenteren dat een component getest moet worden, dan omgaan met nuances en trade offs. Het is makkelijker om te zeggen dat er services gemaakt worden dan om een service gerichte architectuur te ontwerpen en te beargumenteren waarom hij zo goed is of juist niet goed is. Het is makkelijker om het aantal bevindingen of incidenten te tellen, dan hieruit conclusies te trekken over de kwaliteit van de software ontwerpen. Het is makkelijker om een proces te volgen, dan om je proces aan te passen aan de inhoud.
Architecturale keuzes
Of het nu de watervalmethode, Prince2, Agile methods, Continuous Deployment, of whatever nieuwe uitvinding betreft, de aandacht is dusdanig ver naar het proces toegegroeid dat er geen aandacht meer is voor een goed ontwerp, of een kloppende architectuur waarin de trade-off tussen kwaliteitsattributen (ja, ja, ISO9126) nu juist zo belangrijk is, en waarin architecturale keuzes objectief en kwalitatief onderbouwd worden.
ISO9126 is inmiddels vervangen door ISO25010. Verder een goed verwoord artikel over de hedendaagse (ict-)praktijk.
Prima, maar wat lange stelling. Wat is nu de oplossing? Gaan we architecten opleiden om meer met de inhoud bezig te zijn? Of gaan we zorgen dat er een bewaker bijkomt die de inhoud kan bewaken? Of gaan we testers/business opleiden om te rapporteren naar architecten over de inhoud?
Volgens mij moet iedereen zich met het (juiste) proces bezighouden en zijn er inhoudverantwoordelijken die zich tegen de inhoud bemoeien. Ik zie niet in waarom bv een Enterprise Architect zich tegen de inhoud moet bemoeien.
Volgens mij is de conclusie van jouw verhaal dat de business zijn werk niet doet of kan doen en dat de architect zich (ondanks zijn beperkingen) daarmee gaat bemoeien.
Ik herken dat er in sommige organisatie veel en lang over ‘het proces’ wordt gepraat. Processen zijn er om te doen, en al doende te reflecteren en te verbeteren. En wie bepaald of het beter is geworden? Dat is de klant, de opdrachtgever, de gebruiker! Diegenen die baat hebben bij het product of de dienst die geleverd wordt. Wat het belangrijk maakt om een duidelijke verbinding te hebben tussen de processen en het resultaat.
Helaas vervallen mensen soms te veel in de processen, en verliezen daarbij het resultaat uit het oog. Daar kunnen kwaliteits- en procesmensen bij helpen. Bij agile is dat de rol van de agile coach en/of van de scrum master. Die zorgt voor de verbinding tussen alle betrokkenen en effectieve samenwerking. En voor feedback, zowel op het product (sprint reviews) als op het proces (retropsectives).
Ik werk regelmatig samen met architecten, en zie ook hoe ze een bijdrage leveren aan de kwaliteit van de producten. Om te zeggen dat de architect de kwaliteit bewaakt gaat mij te ver. Kwaliteit is eenieders veranwoordelijkheid, en er wordt ook van iedereen een bijdrage verwacht. Dat geldt ook voor de ‘kwaliteitsbewaking’, van een professional mag je verwachten dat ie zijn eigen bijdrage bewaakt, en anderen m.b.v. feedback helpt om ook bij te dragen.
Definieer eerst architectuur in haar context voordat er over architectuur deliverables en architectuur govervance wordt gesproken. Indien een juiste holistische aanpak wordt gebruikt dan zullen de processen onderdeel uitmaken van de architectuur…en niet vanuit een silo zoals het bovenstaande doet vermoeden, want dan gaat het inderdaad mis.
Methodes en middelen zijn onontbeerlijk om architectuur te kunnen doen. Als architect val ik vaak terug op de theorie om iets in de praktijk te kunnen bewerkstelligen. Processen kunnen dienen om stuk governance te krijgen over het te leveren werk. Niet elk proces, middel of methode werkt bij elk op te lossen probleem. Je moet het inderdaad bij de inhoud de juiste methode kiezen. Daarentegen moet een architect ook creatief zijn om een richting te kunnen bepalen.
@Arno, dat is niet helemaal wat ik bedoelde met het stuk. Het ging mij er met name om dat ik merk dat de balans tussen het (voortbrengings)proces en inhoud wat verstoord lijkt te zijn. Dat bedrijfsprocessen juist de inhoud vormen voor specifieke rollen (misschien wel voor enterprise architecten) doet hier niets aan af. Over een oplossing heb ik op zich ook wel een mening, maar ik moet eerst ’s kijken of mijn verhaal uberhaupt herkenbaar is voor anderen.
@Ben, ik ben het er helemaal mee eens dat iedereen vanuit zijn eigen rol en verantwoordelijkheid zijn eigen bijdrage levert aan de kwaliteit van producten.
Ook denk ik dat methoden en middelen noodzakelijk zijn en dat het heel goed is dat er specifieke managers, facilitators of coaches zijn die het proces bewaken.
Waar het echter een beetje eng wordt is als de kwaliteit van een product of dienst bepaald wordt door het proces of door mensen die enkel met het proces bezig zijn geweest.
Friso,
Een herkenbare ontwikkeling, architecten die geen kennis meer hebben van de werkelijkheid maar beslissen op basis van een proces. De kern van het probleem ligt echter niet zo zeer in de kwaliteitsbewaking maar het ontlopen van de verantwoordelijkheid. Ontwerpen langs rails van processen is nu eenmaal veel veiliger dan advocaat van de duivel spelen. In reacties komt ook governance naar voren wat meestal toch niet veel anders betekent dan het volgen van een gedragscode, de conformiteitsdwang die ook al weinig ruimte laat voor een ander geluid.
Waarde van architectuur devalueert dan ook al gauw tot een kwaliteitsstempeltje zonder inhoud als principes niet als de steen van Rosetta gezien worden om requirements te vertalen maar als de tien geboden. En ondanks kwaliteitsattributen in ISO-9126, nu omgenummerd naar 25010 ken ik eigenlijk maar drie gradaties waarop je kunt ontwerpen: Fit-for-business, Fit-for-purpose en Fit-for-budget. Ontwerpen langs de strakke lijnen van een proces doet uiteindelijk alleen het eerste terwijl het laatste toch vaak gewenst is.
En ‘Don’t shoot the messenger’ maar de wet van Archimedes lijkt dus inderdaad van toepassing op sommige architecten. Compleet inhoudsloos drijven ze al snel aan de oppervlakte van een organisatie omdat ze alleen het proces bevredigen. Maar dat zijn dan ook geen architecten maar catalogusbouwers, de projectontwikkelaars die vooral werken vanuit een portfolio. Architectuur is dus soms ook meer een geloof dan werkelijkheid en het licht aan het einde van de tunnel is dan vaak een aanstormende trein.
De inhoud, zelf, zou het proces moeten afstemmen met behulp van een rule engine en semantische technologie. De architect moet dit technisch mogelijk maken. Niets meer, niets minder.
Een droevig verhaal is dit dat je als architect helemaal in de processen verzeild raakt en de inhoud uit het oog verliest. Dat is ook een probleem met deze procesmethodes, de inhoud komt het in het geheel niet aan bod.
Wat je trouwens schrijft over architecten lijkt me iets wat voor veel meer rollen opgaat en niet alleen voor de ict sector. Het lijkt er inmiddels wel op dat de de ene helft van de werkenden de andere helft controleert en procesbegeleidt. Voor uitvoerenden is het een verschrikking en het kost bakken met geld.