|
Geschreven door Administrator
|
|
zondag 15 februari 2009 16:53 |
|
In het begin van de 90-er jaren heb ik voor het eerst kennis gemaakt met het fenomeen archITectuur, en het fascineerde me ogenblikkelijk. Het was de tijd van de productiviteits¬paradox. Er werd enorm veel in IT geïnvesteerd, maar de resultaten waren niet meetbaar. En de fameuze «Chaos Reports» van de Standish group toonden pijnlijk aan dat het overgrote merendeel van de IT projecten mislukten, althans niet binnen tijd- en budget de beloofde functionaliteit leverden. De trend van het moment was “projectmatig werken”. Overzichtelijk, afgebakend, zo min mogelijk risico’s. Maar ik dacht, dat is veel te kortzichtig. Op termijn gaat dat onvermijdelijk tot een onoverzichtelijk geheel leiden. Dat moet beter kunnen. Als je echt zoden aan de dijk wil zetten, als je echt wilt werken aan business-IT alignment, dan moet je groter durven te denken dan één project. Dan moet je denken aan de samenhang tussen de verschillende systemen, aan synergie. En dat was precies het idee achter het vakgebied archITectuur in business. |
|
Laatste aanpassing op zondag 22 februari 2009 18:03 |
|
|
Geschreven door Administrator
|
|
zondag 15 februari 2009 16:51 |
|
Die eerste jaren zijn we langzamerhand gaan ontdekken wat architectuur in de IT zou moeten inhouden. Software architecten waren druk met “component based development”; business architecten met “multi channel management” en iedereen met de opkomst van internet. Er werden hoog oplopende discussies gevoerd over de beste architectuurframeworks, en het verschil tussen functionele en niet-functionele requirements. Maar omdat de ongeduldige opdrachtgevers nooit de tijd hadden om de uitkomsten van dat soort debatten af te wachten, en omdat de investeringen in architectuur als extra projectrisico’s gezien werden, waren de echte successen teleurstellend schaars. Tot overmaat van ramp werd de slogan “IT doesn’t matter” het nieuwe adagium onder bedrijfskundigen. We hebben toen met z’n allen geleerd dat een mooi model, een goed doordacht verhaal en een indrukwekkende poster met een verzameling aansprekende visualisaties onvoldoende waren om echte veranderingen teweeg te brengen. Die beelden moesten in de praktijk ook gebruikt gaan worden. We moesten de aandacht verleggen van de architectuur naar het architectuurproces – in het Nederlands zo mooi: «Werken onder Architectuur». En dat zou natuurlijk niet mogen betekenen dat de oude archITectuurplaatjes nu als dictaat opgelegd zouden worden, maar dat er op z’n minst een goede afweging gemaakt zou worden van alle voor- en nadelen van de verschillende oplossingsalternatieven. Dat er niet meer alleen maar naar korte-termijn belangen gekeken zou worden. Dat er een weloverwogen en afgewogen besluitvorming plaatsvindt. |
|
|
De eerste teleurstellingen |
 |
 |
 |
|
Geschreven door Administrator
|
|
zondag 15 februari 2009 16:46 |
|
Bij sommige bedrijven is het «Werken onder archITectuur» al in een vroeg stadium doorgevoerd. Men ging aan de slag met ontwerpprincipes, project-start architecturen, bouwvergunningen en vrijstellingsprocedures. Maar wat zag je maar al te vaak gebeuren: «Werken onder archITectuur» werd vanuit de IT organisatie als een puur technisch onderwerp benaderd. Maar iedereen die bijvoobeeld wel eens op het landelijk archITectuur congres is geweest, of die een goed boek over archITectuur heeft gelezen, die weet toch dat archITectuur hoort te beginnen bij de business? Dat de business architectuur de kaders stelt voor de IT-architectuur? Dat je met werken onder archITectuur dus logischerwijs niet alleen het IT- maar ook het business-domein moet structureren? En er gebeurde nog iets. De medewerkers die jarenlang gepokt en gemazeld waren in ITIL processen werden ingezet voor het "beheer van de archITectuur", of zoiets. Uitgerekend de beheerders die geselecteerd zijn op het waarborgen van stabiliteit, die getraind zijn in het tegengaan van experimenten, waarvan al die tijd verwacht is dat ze zich star en risico-mijdend zouden opstellen, juist deze medewerkers kregen een cruciale rol bij het overbruggen van de tegenstellingen tussen business en IT. Hoe bedenk je het. En tot overmaat van deze bureaucratische ramp werden deze mensen niet eens fatsoenlijk geschoold of gecoached in het architectuurvak. Alsof architectuur een simpel klusje is dat iedereen er best even bij kan doen. Alsof je er geen analytisch en creatief vermogen voor nodig hebt. Alsof kennis van zaken iets overbodigs is. En wat was het voorspelbare gevolg? Een schrijnend gebrek aan flexibiliteit. Een enorme vraag naar meer agility. En zoveel mogelijk projecten die “zonder archITectuur” uitgevoerd werden. Want dan gebeurde er tenminste nog iets. |
|
|
|
|
<< Begin < Vorige 1 2 Volgende > Einde >>
|
|
Pagina 1 van 2 |
