De veranderende rol van architecten

In een Blog van Henry Cheung stelt hij de vraag “Zijn architecten nodig als je agile gaat werken?”, zie https://lnkd.in/eMEwNKa. Hij komt tot de conclusie “Ja, voorlopig wel”. Ik durf te stellen dat “voorlopig” wel weggelaten kan worden en dat er zelfs een uitgebreidere bemoeienis van verschillende architecten op verschillende fronten nodig is. Weliswaar, bij het hanteren van dezelfde architectuur- en ontwerp-omgevingen, in steeds mindere mate omdat veel taken automatisch overgenomen worden naarmate de omgevingen verder automatisch of door ontwerpers ingevuld worden. In het begin is de behoefte aan architecten echter hoog.

Historie

Na de slag die gegevensmodelleerders min of meer verloren hebben in de jaren ’90, waarbij de focus veel meer gericht werd op processen is na enige aarzeling duidelijk geworden dat een volledig procesgerichte aanpak niet voldeed. Er ontstond teveel eilandautomatisering waarbij de koppelingen verzorgd moesten worden door kleine programmaatjes die later door Gartner Services (SOA) genoemd werden. Veel organisaties stortten zich hierop en de introductie van een ESB of Enterprise Service Bus bood soelaas. De rol van gegevens- en IT-architecten, maar ook die van systeemprogrammeuers veranderde naar Data-, ICT- en Technische Architecten.

De behoefte aan meer integrale “beelden” zoals een klantbeeld, etc. ontstond. Veel organisaties die verschillende klantpakketten voor producttypen hadden aangeschafd konden zo een dergelijk klantbeed leveren. Denk vooral aan telecom-organisaties die voor vaste-lijn telefonie een COTS (Commercial of the Shelf) pakket hadden en waarbij internet als nieuw dienstpakket zijn intrede deed. Voor allerlei nieuwe producttypen werd het nodig om COTS pakketten aan te sluiten voor Provisioning van het netwerk, Internet klanten, TV klanten die nu verschillende kanalen aangeboden kregen, e-mail klanten met verschillende e-mailboxen, etc. Soms was integratie van meer dan vijf verschillende klantbeelden noodzakelijk via services en API’s.

Er ontstond behoefte aan Informatie Architecten, naast de al bestaande architectrollen. Hier en daar ontstond de (verkeerde) term enterprise architecten voor architecten die het hele ICT-domein van van de “enterprise” beheerden. Soms werd de (meer correcte) term Enterprise ICT Architect gebruikt. Ook werd nagedacht over hoe processen onder architectuur konden komen en de term Procesarchitect ontstond rond die tijd.

Ondertussen deden DSDM, Rational, en later SCRUM en andere agile methoden hun intrede. Een Product Owner, veelal iemand met veel kennis van de ‘business’ bepaald welke behoeften er zijn om producten geleverd te krijgen en zo worden Epics, User Stories, etc. ontwikkeld. En het liefst parallel met andere productontwikkelingen. Let wel, Productontwikkelingen, niet het ontwikkelen van voorzieningen voor Producttypen. Aan het SCRUM-team werden Solution Architecten toegevoegd terwijl op een hoger echelon Enterprise en Bedrijfsarchitecten werden onderkend.

Rond die tijd ontstond ook het fenomeen “App”. Inmiddels zijn er tools waarmee razendsnel Apps gebouwd kunnen worden voor elk separaat probleem en waarbij de gegevens van de presentatielaag (de User Interaction gegevens) eenvoudig gekoppeld kunnen worden met de gegevens uit databases of COTS pakketten. Fluitje van een cent. Kunnen we goed gebruiken. Probleem is natuurlijk dat we concepten als “loosely coupled”, etc. wel kunnen vergeten.

Er zijn echter voorbeelden te over, ook in Nederland, waaruit blijkt dat nadat een bepaald aantal Apps, Services en Messages zijn ontwikkeld, het beheer steeds moeilijker wordt zonder de juiste tools. Op een gegeven moment gaat het sneller om een volledig nieuwe App of Service te bouwen, dan te achterhalen of er al Apps maar vooral Services bestaan die geheel of bijna geheel dezelfde functionaliteiten bieden. Het hek is dan van de dam…

Stand van Zaken

We hebben nu een snelle methode genaamd agile in verschillende hoedanigheden, en een snelle ontwikkelomgeving genaamd ApaaS (Application Platform as a Service). De verantwoordelijkheid voor het ontwikkelen of aanpassen van Producten, en daaraan gekoppeld de Diensten, Contracten, Partijen, Bedrijfsprocessen, Bedrijfsfuncties, etc. inclusief Life Events en Value Creation kunnen niet enkel bij een of soms meer Product Owners belegd worden. Zij hebben daar, net zoals sommige enterprise architecten en de meeste bedrijfs- en informatiearchitecten individueel en collectief onvoldoende kennis en ervaring mee. Competenties die natuurlijk wel ontwikkeld kunnen worden, maar het vraagt voor m.n. enterprise- en bedrijfsarchitecten om een “Paradigm Switch”.

Vaak wordt ook geen vijflagenarchitectuur gehandhaafd waardoor oplossingen, weliswaar snel, toch weer aangepast moeten worden als er voor de ene oplossing een attribuut in de database opgenomen of aangepast moet worden. Resultaat is dat we nu voor (bijna) elk product een nieuwe geautomatiseerd oplossing ontwikkelen binnen een fractie van de tijd, maar waarbij dubbelingen van dezelfde producten binnen hetzelfde producttype niet uitgesloten kunnen worden, de waardecreatie suboptimaal is, redundatie op elk niveau ontstaat, etc. Door het herhaald uitvinden van het wiel stijgen de kosten exponentieel en wordt de doorlooptijd dramatisch omdat ook onvoldoende rekening wordt gehouden met verdere integratiebehoeften.

Ook het managen van Apps, Applicaties en geautomatiseerde bedrijfs- en technische functionaliteiten, inclusief gebruikte services en messages, is vaak niet op orde. Het probleem uit zich in peilloze budget- en planningsoverschrijdingen, gefrusteerde bestuurders en executives, maar ook ontwikkelaars.

Hoe moeten we verder

Om dit op te lossen is een gedegen architectuur nodig. Die begint bij de strategie van de organisatie die vertaald wordt in een strategische architectuur(* die ruimer is dan in Archimate gehanteerd wordt. Denk daarbij ook aan een transformatie aanpak die verder gaat dan agile, SCRUM of SAFe en waarbij DEVOPS plaats maakt voor een verdere integratie van strategie tot aan beheer.

• Waarbij impact analyses vooraf een duidelijk inzicht geven in de te verrichten werkzaamheden en de daarbij gepaard gaande kosten en doorlooptijd.
• Waardoor vooronderzoeken eenvoudig worden en PSA’s grotendeels gegenereerd kunnen worden.
• Waarbij vanuit een Product/Dienst concept patronen van diensten, processen en functionaliteiten onderkend kunnen worden zodat het wiel niet meer dan één keer ontwikkeld hoeft te worden.
• Waarbij de gegevenselementen van bedrijfsobjecten en data objecten aan elkaar gerelateerd (data mapping) kunnen worden waardoor zowel aan de business layer (information services) als aan de persistency layer (data services) via gegenereerde messages nieuwe services ontwikkeld kunnen worden.
• Waarbij, zelfs voor complexe logica als Vpb-aanslagen, subsidieberekeningen of nieuwe productsamenstellingen, gebruik gemaakt kan worden van bedrijfsregels die in natuurlijke taal worden vastgelegd.

Door gebruik van bedrijfsregels wordt het mogelijk om de functionaliteiten na het modelleren zonder source code direct uit te kunnen voeren (DME of Direct Model Execution) om ze functioneel te kunnen testen en eventueel aan te passen. Elk zo’n verrijkte bedrijfsfunctionaliteit wordt opgeslagen in een structuur waarvan de eerste twee lagen identiek zijn voor elke organisatie. Zodat de verrijkte bedrijfsfunctionaliteiten intuïtief hervonden kunnen worden om ze “aaneen te rijgen” tot, wederom executeerbare bedrijfsprocessen. 

Omdat architectuur (TOGAF: Architecture Continuum) en voortbrengingsproces (TOGAF: Design Continuum) logisch geïntegreerd zijn is het mogelijk om direct inzage te krijgen in de Eindarchitectuur. Beheer kan door de integratie uitgroeien tot een volwaardig Lifecycle Management Capability, waarbij Applicatie Rationalisatie maar ook Product Lifecycle Management volledig ondersteund worden. De termen voor de verschillende rollen zullen daarom ook veranderen. 

Idée fixe? Deze methoden, technieken en tools zijn er…

Paul van Wely

Oprichter Enterprise Architects

This email address is being protected from spambots. You need JavaScript enabled to view it.

+31 (0)655 388 220