Antwoord.

De achtergrond van de vraag:

In klassieke projecten ontstonden vaak conflicten tussen analisten en architecten, evenals tussen systeem- en businessanalisten: iedereen probeerde een deel van de verantwoordelijkheden te ‘kapen’ of juist af te schuiven. Een duidelijke afbakening van verantwoordelijkheden is een teken van een rijp team.

Het probleem:

Het gevaar ligt in de overlapping en duplicatie van werkzaamheden, wat leidt tot misverstanden, verlies van verantwoordelijkheid, vertragingen en in sommige gevallen tot parallelle en tegenstrijdige werkzaamheden bij het beschrijven van hetzelfde deel van het systeem.

De oplossing:

Artefacten en eindproducten voor elke rol worden gedefinieerd (bijvoorbeeld: de businessanalist is verantwoordelijk voor de bedrijfsdoelen, de systeemanalist voor functionele specificaties, de architect voor architecturale oplossingen)
Aan het begin van het project worden workshops/vergaderingen gehouden met een duidelijke bespreking van verantwoordelijkheden en afstemming van regulerende documenten (bijvoorbeeld RACI-matrices)
Het is belangrijk om regelmatig de grenzen te bespreken en aan te passen naarmate het project zich ontwikkelt en de context verandert.

Belangrijke kenmerken:

Transparante rolverdeling en verantwoordelijkheden
Duidelijke definitie van artefacten en ingangen/uitgangen tussen deze
Continue communicatie en controle over de interfaces tussen taken

Vragen met een valkuil.

Moet de systeemanalist het niveau van systeemarchitectuur ontwerpproces bereiken?

Nee, de architect is verantwoordelijk voor architecturale oplossingen. De analist verduidelijkt de vereisten die de architect kan gebruiken, maar ontwerpt de architectuur niet in zijn geheel.

Kan de businessanalist rechtstreeks technische beperkingen beschrijven?

In de regel niet — de businessanalist formuleert de bedrijfsvereisten. Technische beperkingen vallen onder de verantwoordelijkheid van de systeemanalist of architect.

Als de taakomschrijving van een businessanalist komt, moet de systeemanalist dan de vergadering met het bedrijf dupliceren?

Nee, maar de systeemanalist moet ervoor zorgen dat hij alles correct begrepen heeft en bij onduidelijkheden vragen initiëren.

Typische fouten en anti-patronen

Bias naar verantwoordelijkheden ‘standaard’ verschuiven
Onduidelijke beschrijving van eindproducten (artefacten)
Conflicten door gebrek aan regelmatige communicatie tussen rollen

Voorbeeld uit het leven

Negatieve case:

Twee teams werkten parallel aan hetzelfde deel van het systeem: analisten schreven pseudo-architectuur, en architecten beschreef bedrijfsprocessen. Uiteindelijk raakten de specificaties uit elkaar, en de implementatie liep vertraging op.

Voordelen:

Poging om het werk te versnellen.

Nadelen:

Duplicatie, discrepantie van documenten, verlies van deadlines.

Positieve case:

Een gezamenlijke workshop aan het begin, waarin werd afgestemd wie waarvoor verantwoordelijk was, met documentatie van de grenzen en intersecties. Later in elke fase werden deze overeenkomsten herzien.