Dilemma: Vernieuwing vs. Beheersing
Het beheersen van complexiteit wordt steeds belangrijker in het huidige IT landschap. In een poging om de complexiteit te beheersen, kiezen vele bedrijven voor het pad van “standaardisatie”, bijvoorbeeld op vlak van gebruikte softwares of middlewareplatformen. Hoewel standaardisatie een manier is tot simplificatie, mag de strategie niet beperkt worden tot één logisch niveau omdat dit de complexiteit kan verhogen ipv. te verlagen. Bovendien worden bedrijven geconfronteerd met een fundamenteel conflict, ten gevolge van de onstopbare technologische vooruitgang :
Vernieuwing vs. Beheersing
In deze blogpost pleit ik dan ook voor een verticaal-georiënteerde standaardisatie over de gehele stack hardware-OS-middleware-software, rekening houdend met zowel vernieuwing als beheersing. Noodzakelijkerwijs zal deze visie voor sommige lagen een destandaardisatie inhouden.
Standaardisatie kan de complexiteit verhogen
Samenspraak tussen de verschillende lagen in de stack (bv. OS, middleware, software) is noodzakelijk,omdat de beperking van de keuzes op een bepaald niveau (bv. OS), de complexiteit op een hoger niveau aanzienlijk kan verhogen. De realiteit is nu eenmaal dat bepaalde technologieën beter draaien en eenvoudiger integreren op een specifiek platform.
Behalve dat bij standaardisatie het luik “configuratie” over het hoofd gezien wordt (ook configuraties moeten gestandaardiseerd worden — het beheersen van configuraties is meestal moeilijker dan het beheersen van de software zelf), heeft standaardisatie op één bepaald logisch niveau tot gevolg dat de complexiteit op een hoger niveau toeneemt.
Stel bv. dat een bedrijf qua Web Server enkel IIS toelaat. Stabiele Out-Of-The-Box oplossingen zoals Drupal op een LAMP stack, worden hierdoor onnodig complex gemaakt omdat Drupal ontplooid wordt op een platform of in een configuratie waar het oorspronkelijk niet voor gebouwd is. Best-of-breed aanpakken, waarbij “de juiste aanpak” wordt gebruikt voor een specifiek probleem, worden hierdoor dus onmogelijk, waardoor we dus komen tot suboptimale oplossingen, die vaak ook nog complexer zijn.
Destandaardisatie kan dus de complexiteit verlagen, omdat de stack in zijn geheel eenvoudiger wordt.
Last but not least speelt er een cultureel aspect: met het steeds hoger tempo van technologische innovatie,is het misschien beter om werknemers deze realiteit te laten omarmen, eerder dan ze er van af te schermen?
Un discours de bon sens auquel j’adhère, et qui contribue à justifier ma position sur les architectures dites de référence.
Dans l’expression “architecture de référence”, le mot référence doit être bien compris. Par référence, il faut entendre la façon normale (communément admise) de faire et certainement pas la façon obligatoire de faire.
Les architectures de référence constitue un guide, et en aucun cas un dogme inaltérable.
Elles doivent pouvoir être adpatées à des contextes particuliers, par exemple au fait qu’un software (qui peut lui-même être érigé en standard) peut venir avec ses propres contraintes, parce que optimisé pour une architecture globale pas nécessairement 100% compatible avec l’architecture de référence concernée du moment.
C’est tout le travail de la cellule architecture que d’apporter les adaptations nécessaires aux architectures de référence en fonction des contextes (et en discussion avec les équipes de projet), dans les différentes couches, … et en veillant à les minimiser (sans quoi l’effort de standardisation se délite rapidement).
La démarche architecture doit être éclairée … et éclairante pour les équipes de projet.
Par rapport à tout cela serions-nous encore chez Smals dans le moyen-âge de la démarche architecture d’entreprise ?