Many have discussed the benefits of utilizing ADAM (Active Directory Application Mode) for their enterprise solutions.
With introduction of ADAM, developers now have the opportunity to utilize powerful directory capabilities without requiring extensive changes to a company's precious Active Directory environment. This is important for a couple of reasons:
ADAM offers to help provide for these capabilities while giving teams most of the benefits of mature AD systems (like good HA replication capabilities)
But there are trade offs which must be considered when we (as infrastructure architects) design, model, deploy and support these systems in our data centers.
You have decided to utilize ADAM in designing or modifying an infrastructure architecture to support the flexibility of application solutions.
How do we develop good infrastructure architectural designs with ADAM in large companies? What approaches might work to develop architectures which keeps the benefits of ADAM while limiting potential challenges?
Organizations want to keep the solution data and AD data separate while allowing the ADAM schema model to be more adaptive as the solution evolves.
Organizations expect sensitive information in AD to be controlled and managed especially if this information is utilized in less secure communication areas of the network.
Organizations want to keep AD environments stable, predictable, consistent experiencing less schema changes over time than schema adaptations for specific application solutions
Organizations might promote a new ADAM system for every .net solution This could significantly increase operating costs for an organization if such an event occurs. This issue might become more compounded if organizations develop unique monitoring, backup/recovery, instrumentation, provisioning, schema standards for every ADAM directory.
Furthermore, the more ADAM directories utilizing more information from AD, the more integration points which must be managed, monitored, and optimized. Furthermore, these systems must be sized for these integration complexities (especially the AD)
Organizations promoting significant amounts of duplicate data in the wrong communication area might violate security policies or worse (laws).
Organizations having duplicated data on different ADAM environments could create significant type integration/interpretation issues with other systems.
Keep your number of ADAM Systems to a small manageable number (example: 3-7). Application schemas could be consolidated into optimized ADAM execution zones.
Benefits: keeping the ADAM Execution Zones to a manageable number:
This represents a compromise allowing separation of concerns without giving up control of the directory resource tier operating environment.
Liabilities: Reducing unmanaged flexibility of developers to make any ADAM environment they want:
How do you separate the ADAM execution zones?
Instead of consolidating ADAM instances through functional characteristics, consolidate instances based on similar non-functional characteristics.
Examples of non-functional areas to utilize for consolidating ADAM Execution Zones:
It will be critical that the organization's ADAM Execution Zone architects maintain the spirit of original purpose by keeping the environment flexible, adaptable, and buildable for solutions to capably allow organizations to bring competitive solutions to market quickly.
I hope this was helpful for those considering developing large ADAM environments.