Een nieuwe manier van ontwikkelen vraagt om een nieuwe manier van samenwerken

De rol van een Business Architect binnen Pega Constellation

Jeroen Memelink is Business Architect bij BPM Company. Hij helpt organisaties om bedrijfsprocessen te vertalen naar werkende oplossingen binnen het Pega-platform. Samen met collega Jordi Recasens bouwt hij voort op de technische basis die eerder werd gelegd door de Lead Business Architect. Hun samenwerking en taakverdeling laat zien hoe de rol van de Business Architect binnen Pega Constellation fundamenteel verandert.

Memelink: “Wat mij het meest aanspreekt aan dit project is de manier waarop we samenwerken. Veel organisaties werken volgens de klassieke Pega-aanpak. Daarin bepaalt een Lead System Architect grotendeels hoe nieuwe functionaliteit eruit moet komen te zien. Hij maakt een ontwerp, zet een prototype neer en daarna gaat de ontwikkeling van start.

Binnen Pega Constellation verschuift dat zwaartepunt steeds meer richting de Business Architect. Dat is precies de richting die Pega voor ogen heeft. De business komt dichter op de ontwikkeling te zitten, waardoor oplossingen sneller beschikbaar komen en beter aansluiten op de praktijk.”

 

Het begin bij het proces

“Binnen Constellation is het proces leidend. Pas daarna volgt de techniek. De organisatie gebruikt Pega voor drie belangrijke domeinen. Sales ondersteunt autobedrijven bij het afsluiten van nieuwe garanties. Claims verzorgt de afhandeling van garantieclaims. Finance zorgt voor de financiële verwerking en facturatie. Achter de schermen werken we samen met een internationaal ontwikkelteam, aangevuld met subject matter experts en proceseigenaren uit de business.”

 

Van procesprobleem naar slimme oplossing

“Onze rol begint óók bij het proces. Een mooi voorbeeld daarvan is een recente uitdaging bij de afdeling Sales. Daar worden iedere dag nieuwe garanties geregistreerd. In de praktijk bleek dat gegevens regelmatig achteraf moesten worden aangepast, bijvoorbeeld doordat informatie verkeerd was ingevoerd. Dat bleek echter onmogelijk. Zodra een garantie eenmaal was aangemaakt, kon deze niet meer worden gewijzigd. De enige oplossing was de bestaande garantie te annuleren en het volledige proces opnieuw te starten.

Dat kost tijd, zorgt voor extra administratief werk en vergroot de kans op fouten. Samen met de business hebben we daarom voorgesteld een volledig nieuw casetype te ontwikkelen: ‘Garantie wijzigen’. Daarmee kunnen medewerkers bestaande garanties gecontroleerd aanpassen zonder het hele proces opnieuw te hoeven uitvoeren.”

 

Pega Blueprint als eerste stap

“Het interessante is niet alleen dát we deze functionaliteit bouwen, maar vooral hóé: waar vroeger de System Architect zo’n oplossing zou ontwerpen, bouwen Jordi en ik tegenwoordig een groot deel van de oplossing zelf. De eerste stap is altijd Blueprint. Daar modelleren we samen met de business het volledige proces. We bepalen de verschillende persona’s, leggen de processtappen vast, definiëren de benodigde gegevens en ontwerpen de volledige case lifecycle. Vervolgens zetten we dat vrijwel één-op-één over naar App Studio.

Daar leggen we de volledige structuur van de applicatie vast. We maken de case lifecycle, voegen de verschillende stappen toe, richten de datamodellen in en zorgen dat de oplossing grotendeels zichtbaar wordt voor de business. De volledige functionele structuur staat dan al. De ontwikkelaars hoeven vervolgens niet meer na te denken over hoe het proces eruit moet zien. Zij kunnen zich richten op de technische configuratie: beveiliging, integraties en andere technische componenten.”

 

Een nieuwe manier van samenwerken

“Dat verandert de samenwerking enorm. Doordat de Business Architect veel dichter op de business zit, worden keuzes eerder gemaakt. We kunnen de oplossing veel sneller laten zien. Refinement-sessies worden korter omdat vrijwel iedereen al hetzelfde beeld heeft. En ontwikkelaars hoeven veel minder terug naar de business om verduidelijking te vragen.

Die aanpak levert voordelen op voor alle betrokkenen. De business krijgt meer eigenaarschap en kan veel eerder feedback geven. Ontwikkelaars ontvangen een veel concreter ontwerp en kunnen zich volledig richten op de technische realisatie. En voor de organisatie als geheel betekent het dat nieuwe functionaliteit sneller ontwikkeld kan worden, met minder afstemming en minder herstelwerk achteraf.

Het nieuwe casetype voor het wijzigen van garanties is daar een mooi voorbeeld van: een concreet praktijkprobleem wordt opgelost, terwijl tegelijkertijd een compleet nieuwe manier van samenwerken wordt geïntroduceerd.

Voor mij is dat misschien wel de grootste verandering die Constellation brengt. Business Architects bouwen actief mee aan de oplossing. Daarmee verandert niet alleen onze rol, maar ook de manier waarop organisaties software ontwikkelen.”

Leestip: ‘Waarom Pega Constellation belangrijk is: snellere UX en toegankelijkheidsvoordelen’