My suggestion is that as well as EnvironmentConstraint in EnvironmentConstraints defined in a NodeTemplate, it can be defined under a TopologyTemplate. So, the one defined in a TopologyTemplate can be referred by several NodeTemplate. The following is an example. Two applications are respectively deployed on two application servers. The two servers employ a same security setting, which is defined in an EnvironmentConstraint. So, the shared EnvironmentConstraint (named "SecuritySetting") included in an EnvironmentConstraints can be defined under the "webApplication" TopologyTemplate, and then be referred by the two servers' NodeTempalte (see those words in red). <TopologyTemplate id="webApplication"> <EnvironmentContraints> <EnvironmentContraint name=" SecuritySetting", contraintType="example.com/securitysetting"> constraint type specific content </EnvironmentContraint > </EnvironmentContraints > <NodeTemplate id="MyApplication1", name="My First Application ", nodeType="Application" /> <NodeTemplate id="MyApplication2", name="My Second Application ", nodeType="Application" /> <NodeTemplate id="MyAppServer1", name="My First Application Server", nodeType="AppServer"> <EnvironmentContraints> <EnvironmentContraint name="MySecuritySetting1", ref="SecuritySetting"> </EnvironmentContraints > </NodeTemplate> <NodeTemplate id="MyAppServer2", name="My Second Application Server", nodeType="AppServer"> <EnvironmentContraints> <EnvironmentContraint name="MySecuritySetting2", ref="SecuritySetting"/> <EnvironmentContraint constraintType="example.com/AuthenticationSettings/MyAuthenticationSetting"/> </EnvironmentContraints > </NodeTemplate> <RelationshipTemplate id="MyDeploymentRelationship1", relationshipType="deployedOn"> <SourceElement id=" MyApplication1"/> <TargetElement id="MyAppServer1"/> </RelationshipTemplate> <RelationshipTemplate id="MyDeploymentRelationship2", relationshipType="deployedOn"> <SourceElement id=" MyApplication2"/> <TargetElement id="MyAppServer2"/> </RelationshipTemplate> </TopologyTemplate>