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:

 

  1. Active Directory solutions require good planning and impact analysis for large customers.   As such, Active Directory architects like to limit schema changes that might make their ecosystem brittle.

 

  1. Security Managers generally like to  reduce the amount of sensitive data exposure for systems providing solutions through the DMZ.   While there are plenty of powerful security approaches to reduce risk with AD information utilized in less secure areas, having an intermediate system to buffer that exposure often provides some comfort for security teams

 

  1. Solution Architects/Developers generally like more a fluid capability to store unique information for the application solution on a separate system to create more abstractions and separation of concerns from other company systems.  This generally reduces time to  market and allowing for great flexibility in the design.

 

 

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.

 

Context

You have decided to utilize ADAM in designing or modifying an infrastructure architecture to support the flexibility of application solutions.

 

Problem

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?

 

 

Forces

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.

 

Solution option:

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:

  1. Allows organizations to minimize the number of integration points to the AD environment (which can be more precisely controlled and monitored
  2. Allows developers to have flexibility to adapt schema models of the ADAM instance while reducing complex impact issues on the AD infrastructure.  This could reduce schema type variations, reduce duplicate data issues, sensitive data exposure.
  3. Allows the Infrastructure Architects to minimize the complexity of instrumentation, backup/recovery, data management, naming systems, monitoring and troubleshooting systems, provisioning and patch management solutions, etc..

 

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:

  1. This could increase time to market if the ADAM execution zones are too rigid in systemic quality performance for specific ADAM instances on the nodes.
  2. This could constrain developers from utilizing newer techniques if the ADAM execution zone architectures/tools become dated in relation to the need of the instances on zone.

 

 

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:

  1. Security authorization levels with which the instance will operate at and what sensitivity level the data it has is rated at for a specific communication area network.  This includes the security role levels of the external actors interfacing with the ADAM instance.
  2. Manifest Performance Attributes:   Throughput / Capacity / and point in time availability issues, etc...
  3. Manifest Management Attributes: Instrumentation, monitoring, backup/recovery, provisioning, patch management, operating skill teams, etc…
  4. Evolutionary Performance Attributes: (examples: Scalability, availability in the future, etc...)
  5. Technical capability Attributes:  Some ADAM instances might rely on newer technical capability than others.   Therefore, some ADAM Execution zones might require faster refresh rates than others.

 

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.