De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op de site van Via Nova leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?
Het debat
Als je nuchter kijkt naar de bedrijfsprocessen in IT-afdelingen, dan zijn het er eigenlijk niet zo heel veel. Het onderstaande rijtje zal in de meeste gevallen al behoorlijk dekkend zijn.
Het ontwikkelen van nieuwe applicaties / systemen / functies / oplossingen
Het implementeren van op de markt verkrijgbare applicaties / systemen / functies / oplossingen
Het verbeteren van bestaande applicaties / systemen / functies / oplossingen
Het in stand houden van applicaties / systemen / functies / oplossingen
Het ontwikkelen en bewaken van beleid voor (een specifiek domein van) applicaties / systemen / functies / oplossingen
Het organiseren van een handvol bedrijfsprocessen zou dus moeten volstaan om IT-afdelingen in te richten. Hoeveel standaard processen, methodieken en raamwerken zouden er moeten zijn om deze 5 bedrijfsprocessen professioneel in te vullen...?
Denk dan eens aan de keuzerijkdom van instrumenten zoals ASL, BiSL, CMMI, COBIT,Cocomo, Demo, DSDM, DYA, EUP, FPA, IAF, IEEE-1471, ITIL, ITSMI, JBF, MArch, MSP, Pino, PMBOK, Prince2, RUP, SEBOK, Scrum, SDM, TMap, TOGAF, XP, Zachman en vele, vele anderen. Het is natuurlijk goed om iets te kiezen te hebben, maar is het allemaal niet een beetje veel en onoverzichtelijk geworden? Begrijpen we wel goed hoe de verschillende methodieken op elkaar aansluiten? Wie doorziet de methodologica nog?
Als je goed kijkt naar de verschillende methodieken, dan valt op dat de meeste zich niet richten op een proces, maar op een subdiscipline. Ze gaan over testen, project management, governance of beheer. Nog preciezer: ze beschrijven de bedrijfsprocessen vanuit het perspectief van de tester, de project manager, de IT manager of de beheerder. De makke van de huidige methodiekenstrijd is dat deze vooral binnen subdisciplines woedt. Testers debatteren over de beste aanpak om te testen, functioneel beheerders zijn vooral met hun eigen best practices bezig en voor project managers, ontwikkelaars en architecten geldt al niet veel anders. Ieder specialisme zijn eigen manier van werken.
Dit geldt net zo goed voor TOGAF. De Architecture Development Methodology, het beeldmerk van TOGAF, is architect-centric. Het beschouwt de wereld vanuit de bril van de IT-architect en de discussie daarover woedt louter in het architectenwereldje. Deze discussie vertroebelt tot mijn verdriet het zicht op de bal. Wat was ook al weer het verheven doel van werken onder architectuur? Waar doen we het voor? Om architectuur te produceren? Ter meerdere eer en glorie van architecten? Of om de informatievoorziening van bedrijven te stroomlijnen? Om de chaos van werken zonder architectuur te bestrijden?
Als we dát willen, dan zullen we toch de samenwerking moeten zoeken met de professionals uit die andere subdisciplines. Dan hebben we weinig aan een methodiek voor architecten. Dan hebben we nood aan een methodiek die multi-disciplinaire samenwerking ondersteunt en bevordert.
Unified view
De vijf geschetste bedrijfsprocessen vragen elk voor zich om een multidisciplinaire aanpak, waarbij dezelfde subdisciplines in meerdere processen een rol spelen. Die bedrijfsprocessen verschillen van bedrijf tot bedrijf niet wezenlijk van elkaar. Dat schreeuwt om een standaard aanpak, om een overkoepelende methodiek. Maar het debat over de samenhang tussen de verschillende methodieken binnen één voortbrengingssproces is merkwaardigerwijs nog nauwelijks van de grond gekomen. Zouden IT-ers te betrokken zijn bij hun eigen werk om hun eigen manier van werken goed te kunnen analyseren en structureren?
Als je nog iets verder denkt, dan is het niet persé handig als een professional die een rol speelt in meer dan één soort bedrijfsproces telkens zou moeten overschakelen op een andere methodiek. Maar waarom is er dan niet één methodiek die de vijf genoemde bedrijfsprocessen in hun onderlinge samenhang beschrijft? Zo moeilijk kan dat toch niet zijn? Zouden we dáár als architectuurcommunity eigenlijk onze energie niet in moeten steken?
Zo'n integraal procesmodel hoeft heus geen one-size-fits-all te zijn. Er mogen best een stuk of drie scholen zijn, die elk een principieel andere weg kiezen voor de invulling van de bedrijfsprocessen in de informatievoorziening. Laten we zeggen, de Engelse school – gebouwd op ITIL en DSDM – de Rationele school – gebouwd op de unified processes – en de Rode school waaraan Oracle ongetwijfeld naarstig werkt. Dan blijft er iets te kiezen en zou zo'n keuze te baseren zijn op de mate van synergie met de eigen bedrijfsprincipes.
Er zijn wat hoopvolle tekenen dat er meer mensen in deze richting denken. Wim Hoving en Jan van Bon pleiten in een artikel in de Automatiseringgids bijvoorbeeld voor een fusie van ITIL, ASL en BiSL. Eén methodiek voor het in stand houden van applicaties / systemen / functies / oplossingen. Ook het unified process is van nature multidisciplinair. Het kán dus wel degelijk.
Oproep
Als architectencommunity zouden we een bijdrage moeten leveren aan de verbetering van de organisatie van de bedrijfsprocessen in de informatievoorziening. Het concept “Ontwikkelen onder Architectuur” is alvast een goed begin, zij het dat het dan wel als een volwaardig ontwikkelproces uitgewerkt zou moeten worden (ik heb het altijd een merkwaardig fenomeen gevonden dat iets wat we betitelen als “Ontwikkelen” als een primair architectuurproces wordt gepositioneerd, maar dat terzijde). Zo zouden we ook voor “Implementeren onder Architectuur”; “Evolueren onder Architectuur”; “Beheren onder Architectuur” en “Beleidsontwikkeling onder Architectuur” modelprocessen kunnen ontwerpen. Uiteraard zouden die processen zoveel mogelijk voort moeten bouwen op de de-facto standaarden die al in gebruik zijn, waarbij het een behoorlijke uitdaging wordt om die qua terminologie en qua systematiek goed op elkaar te mappen. En uiteraard moeten deze modelprocessen inzicht bieden in de plaats van architectuur binnen die bedrijfsprocessen.
Zou dat nou niet een interessant thema zijn voor een workshop tijdens het komende LAC als opmaat naar een nieuw NAF-boek?
In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 15de in een reeks die op dit weblog gepubliceerd zal worden.
Posts
1 opmerking:
ik ben rijk geworden met deze geprogrammeerde gehackte pinautomaat
Nadat ik klaar was met studeren, was er geen werk, dus besloot ik een klein bedrijf te beginnen, maar het geld was niet genoeg, ik sloot het bedrijf, het werd erg moeilijk voor mij, ik was het enige kind van mijn ouders en mijn ouders. Ze zijn allebei oud, ze geloven in mijn dagelijkse voeding, op een dag zag ik tijdens het surfen op internet een bericht over hoe deze NIEUWE VERVANGEN ONTVANGEN ATM-KAART een geldautomaat kan hacken en een groot bedrag kan opnemen, dus nam ik contact op met het bedrijf via uw e-mail. Tot mijn grootste verbazing ontving ik de kaart een paar dagen nadat ik een kleine vergoeding voor de kaart had betaald. Deze blanco ATM-kaart is een geweldig en prachtig product. Ik zou nooit geloven dat al deze dingen die ik vandaag heb kunnen worden verworven met deze grote vreugde in mijn hart, daarom breng ik het goede nieuws over ... Het leven is positief en geduldig zijn, in de overtuiging dat grote dingen mogelijk zijn en kan gebeuren in seconden. .. BRAIN HACKERS TECH WORLD heeft mijn leven veranderd ... Godzijdank kun je een e-mail sturen naar VIA (brainhackers@aol.com)
Een reactie posten