<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Dood aan de standaardisatie!	</title>
	<atom:link href="https://www.smalsresearch.be/dood-aan-de-standaardisatie/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.smalsresearch.be/dood-aan-de-standaardisatie/</link>
	<description></description>
	<lastBuildDate>Thu, 26 Mar 2026 13:24:17 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: Jean-Pierre Latour		</title>
		<link>https://www.smalsresearch.be/dood-aan-de-standaardisatie/#comment-306</link>

		<dc:creator><![CDATA[Jean-Pierre Latour]]></dc:creator>
		<pubDate>Tue, 17 May 2011 11:22:55 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.smals-mvm.be/research/?p=2138#comment-306</guid>

					<description><![CDATA[Un discours de bon sens auquel j&#039;adhère, et qui contribue à justifier ma position sur les architectures dites de référence. 
Dans l&#039;expression &quot;architecture de référence&quot;, 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&#039;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&#039;architecture de référence concernée du moment.
C&#039;est tout le travail de la cellule architecture que d&#039;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&#039;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&#039;entreprise ?]]></description>
			<content:encoded><![CDATA[<p>Un discours de bon sens auquel j&#8217;adhère, et qui contribue à justifier ma position sur les architectures dites de référence.<br />
Dans l&#8217;expression &#8220;architecture de référence&#8221;, 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.<br />
Les architectures de référence constitue un guide, et en aucun cas un dogme inaltérable.<br />
Elles doivent pouvoir être adpatées à des contextes particuliers, par exemple au fait qu&#8217;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&#8217;architecture de référence concernée du moment.<br />
C&#8217;est tout le travail de la cellule architecture que d&#8217;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, &#8230; et en veillant à les  minimiser (sans quoi l&#8217;effort de standardisation se délite rapidement).<br />
La démarche architecture doit être éclairée &#8230; et éclairante pour les équipes de projet.<br />
Par rapport à tout cela serions-nous encore chez Smals dans le moyen-âge de la démarche architecture d&#8217;entreprise ?</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
