De omslachtige manieren die IT organisaties hebben bedacht om verbeteringen in architectuur te realiseren voor de business, gaat overboord!
Een van mijn laatste klussen voor mijn leven bij AvenQure betrof een advies over de staat van IT architectuur. Het was een klant uit Den Haag, in de technologiesector. Voor de eerste ontmoeting besloot ik mijn TOGAF kennis op te frissen om een duidelijk, samenhangend en overzichtelijk beeld van de nut en noodzaak te kunnen schetsen.
Voor de mensen die niet op de hoogte zijn van de inhoud van TOGAF, een korte definitie. TOGAF is een architectuurraamwerk dat organisaties helpt bij het opbouwen van een architectuur-gedreven IT organisatie teneinde de business zo goed mogelijk van dienst te kunnen zijn.
TOGAF
TOGAF levert een cyclisch proces om architectuur te ontwikkelen en onderhouden (TOGAF ADM). Van business visie tot implementatie. Het proces doorloopt een aantal stappen waarbij de organisatie en doelstellingen worden bekeken vanuit de invalshoeken business, data, applicatie en tot slot technologie. TOGAF onderkent dus de noodzaak van wijzigingen in de technologie ten behoeve van wijzigingen in de business. Populair gezegd, je moet langs IT om je business processen aan te passen.
Je kunt onderscheid maken tussen twee type wijzigingen:
- wijzigingen binnen een applicatie (functionaliteit)
- wijzigingen in samenwerking tussen applicaties (interoperabiliteit).
Wijzigingen in samenwerking vereisen dezelfde technologie en dezelfde taal op gegevensniveau. Wijzigingen binnen een applicatie vereisen vertaling van business requirements naar IT implementatie.
Het overleg met de klant stond gepland voor 9 uur ’s ochtends. Ik was een kwartier onderweg toen mijn gedachten begonnen af te dwalen naar het aanstaande gesprek. Ik begon de stappen en deliverables van TOGAF ADM nog eens door te lopen toen het bij mij daagde. Of beter gezegd; ik begreep het niet meer. Volgens TOGAF ADM doorloop je via business-architectuur naar gegevens- en applicatiearchitectuur naar technologie-architectuur. Maar waarom eigenlijk? Waarom moeten we langs applicatiearchitectuur en technologiearchitectuur? Waarom moesten we voor wijzigingen aan functionaliteit langs de IT organisatie? Waarom waren er überhaupt nog applicaties? Om een lang verhaal kort te maken. Uit deze gedachtekronkel is uiteindelijk Conduct in haar huidige vorm ontstaan.
Conduct
Conduct is een platform waar, op een simpele manier, nieuwe functionaliteit kan worden toegevoegd, zonder dat daar een IT afdeling aan te pas komt. Conduct richt zich op samenwerkingsverbanden. Samenwerking tussen mensen, tussen afdelingen, groepen en organisaties. Het concept van applicaties is volledig losgelaten. Binnen Conduct bestaan geen applicaties meer, alleen samenwerkingsverbanden. Dat betekent dat in TOGAF bewoording, de applicatiearchitectuur ook niet meer bestaat. Er is slechts de business-architectuur en de gegevensarchitectuur. En die gegevensarchitectuur kan direct door de business-mensen, en ook niet onbelangrijk non-intrusive, worden geïmplementeerd. Dus ja, ook over technologie-architectuur hoeft men zich geen zorgen meer te maken.
Kortom, voor de alledaagse wijzigingen in business logic hoeft u dus niet meer langs IT. Dit bespaart u kosten aan IT én maakt uw organisatie extreem wendbaar.