Referentiearchitecturen zijn belangrijk voor bedrijven, zij bieden houvast. Toch blijven veel mogelijkheden onbenut. Het veelal hoge abstractieniveau, zeggen…
Source: www.automatiseringgids.nl (complete artikel alleen voor abonnees)
Mooi dat dit artikel een aantal belangrijke “pijnpunten” van referentiearchitecturen aanstipt.
Een aantal wil ik er graag uitlichten. Te beginnen met de herkenbaarheid door de “business” (niet voor niets tussen aanhalingstekens vermoed ik, maar een definitie van wat dat precies is wordt niet gegeven). Veel modellen kijken eenzijdig naar de organisatie (een bepaald perspectief), waarbij het vaak bij één perspectief blijft (bijv. processen) en het gekozen perspectief niet expliciet benoemd wordt. Hierdoor worden ook de tekortkomingen (aspecten van het domein die eenvoudig door het gekozen perspectief niet zichtbaar zijn) niet expliciet en dreigt het gevaar dat de indruk ontstaat dat deze niet relevant zijn. Een criterium voor een geslaagde referentiearchitectuur, of moet ik zeggen een geslaagde business referentiearchitectuur, is dat de betrokken personen uit de business (soms met enige hulp) in staat zijn hun rol te herkennen in de modellen.
Ten tweede de afbeelding van applicatielandschappen op de bedrijfsfuncties. Het lijkt mij dat hier een “probleem” wordt benoemd dat er niet is. Wat is er mis met bedrijfsfuncties die heterogeen afbeelden op applicaties? Als de relaties duidelijk zijn kunnen deze modellen toch zonder problemen gebruikt worden voor procurement?
Ten derde de suggestie, rampzalig in mijn optiek, bepaalde kritische applicaties onderdeel te laten zijn van de referentiearchitectuur. Ik merk in mijn werk als enterprise architect ook dat de “business” vaak denkt in termen van deze applicaties, maar ik voel het zelf als mijn opdracht hen daar van af te begeleiden en meer te gaan denken in de daadwerkelijke knelpunten en behoeftes en minder in oplossingen.
Ten vierde de suggestie, eveneens rampzalig in mijn optiek, metamodellen en architectuurtheorie over te slaan. Het is evident dat we daarin niet dóór moeten slaan (en dat te vaak doen) maar de theoretische omlijsting van de keuze voor een bepaalde architectuurstijl, bijvoorbeeld Distributed Objects, is onontbeerlijk om de consequenties van deze keuzes inzichtelijk te maken en de juiste afwegingen te kunnen maken.
Tenslotte zijn er een aantal suggesties in de punten die aangereikt worden om meer pragmatiek te realiseren waar ik het zeker mee eens kan zijn. Bijvoorbeeld de “algemene architectuurwaarheden”. Misschien moeten we die maar eens op een algemene wiki zetten zodat we het er niet meer over hoeven te hebben 😉
Een belangrijke vind ik ook het gebruik van perspectieven. Voor de communicatie is het zeker niet zo moeilijk als sommigen het doen voorkomen om visualisaties te maken die wél kloppen maar toch leesbaar zijn door leken.
Hi Rob,
Ik ben ook niet helemaal enthousiast over het artikel. Mijn belangrijkste opmerkingen daarbij:
– Het is te simpel om te stellen dat referentie-architecturen te abstract zijn. Detail is niet per definitie beter; beter een goed abstract model dan een gedetailleerd model dat rammelt. Bij het opstellen van de HORA kwam ik erachter dat we er zoveel details in hadden gestopt dat het breed en in detail valideren al erg lastig bleek.
– Het creëren van specifieke views is inherent lastig in een referentie-architectuur omdat deze veel verschillende toepassingen kent. De primaire doelgroep van een referentie-architectuur zijn architecten die er een specifieke architectuur van moeten maken en die de vertaalslag naar de organisatie-specifieke context moeten maken.
Ik sluit me aan bij jouw opmerking dat het op zich geen probleem is als functies en applicaties niet 1-1 op elkaar te plotten zijn. Referentie-architecturen dienen vooral gebruikt te worden om inzichten te genereren. Een inzicht dat een applicatie meerdere functies realiseert is heel waardevol.
Ik vind het wel terecht dat wordt voorgesteld om algemene waarheden en metamodellen zoveel mogelijk te vermijden. Dit is echter tevens een open deur. Daarnaast heb je natuurlijk gelijk dat er wel een goede methodische basis dient te zijn. In HORA hebben we bewust een separaat document met implementatiehulpmiddelen opgesteld waarin meer achtergrond, theorie en toepassing wordt beschreven.
Tot zover!
Groetjes,
Danny