Le diagramme suivant illustre l'architecture d'Identity Manager recommandée par Sun en l'absence d'infrastructure d'application Web existante.
Dans un développement réel, l'infrastructure de serveur d'application redondante existante doit être utilisée autant que possible. L'avantage de cette architecture est qu'elle utilise uniquement des équilibreurs de charge pour assurer la redondance au niveau du serveur d'application. Les équilibreurs de charge avec affinité de session détectent les instances de serveur d'application en panne et basculent sur des instances actives. Les équilibreurs de charge sont également utilisés pour fournir une mise à l'échelle horizontale dans l'environnement Web en répartissant les demandes des utilisateurs dans un cluster de serveurs.
Même s'il s'agit là d'une architecture simple, les caractéristiques de temps de disponibilité sont comparables à celles de déploiements plus complexes. Compte tenu par ailleurs de cette simplicité, il y a moins d'éléments logiciels à actualiser et contrôler et moins d'éléments risquant de tomber en panne. Par ailleurs, l'erreur humaine étant la première cause d'indisponibilité, une solution relativement simple peut permettre d'obtenir de meilleures caractéristiques de temps de disponibilité qu'une autre plus complexe. Ces réponses ne sont toutefois pas universellement valides. L'essentiel est de comprendre toutes les causes d'indisponibilité et de choisir l'architecture se traduisant par la meilleure disponibilité pour l'investissement envisagé.
Il serait impossible de décrire toutes les architectures HA différentes possibles avec une application Web telle qu'Identity Manager.
Étant donné qu'Identity Manager peut être déployé selon tout un éventail de combinaisons, il pourra être plus économique d'identifier l'infrastructure existante et de l'utiliser le plus possible pour déployer Identity Manager.