The Plan

The "Plan" consists of multiple components. Each component is required to complete the entire process. This is an "already established" and "in place" plan that works, so there is no reason to change it. The "Plan" will encompass the entire process from requests to implementation and finally maintenance of the environment. Once the entire plan has been established I will begin building the source code.

I. Security
The first part to consider is security.
This will control access to the administrative website where all of the manual work takes place.
Though it would be nice to allow the ability for self service I do not recommend it.
You want a few select group of individuals who truly understand LDAP and how it works. Trust me, after actually controlling this environment for numerous years you do not want people creating queries who do are not proficient at it. Not only does it lend itself to invalid or inefficient queries, it can possibly affect your directory services if someone were to create a runaway query. Another consideration is to insure there are not two processes dynamically processing a group, this can end up in a loop situation.
For our initial configuration basic group membership will be used and we will control that membership using a dynamic process.

Normally you would not create dynamic groups with individual user queries, it is not what it is designed for. It is designed for controlling large, unmanageable groups. Because it only runs every hour, from a security perspective that is really too long someone could be placed in a group before they are removed.
My original source code was written based on roles which were applied via directory services.
This can be leveraged by SSO and is probably the most secure method of control. Since this would require rewriting the entire role based SSO system, I have decided to leave that part out (for now) and will use ldap and ldap queries to control access via an administrative global security group.

II. Management Interface or DMI - (Dynamic Management Interface)
This is the meat and potatoes of controlling each dynamic process and should be able to run in either an IIS or apache web server environment.
It controls basic CRUD operations of all the dynamic processes, group changes and criteria.
The current environment is c#, .net and an IIS back-end web server.

III. The Processing Application DPI - (Dynamic Processing Interface)
This is a console application and does all of the dynamic magic. It is fired either via a scheduled tasks in a windows environment or cron in Linux environments.

IV. Management
Though DynaGroups are mostly "Set and Forget", management is a crucial step. This includes things like monitoring groups are still available, queries are still applicable and contacting the owners of the groups to insure the criteria for the queries is still needed. Basic house keeping duties. It will also include some type of request system where end users will be able to request new Dynagroups. My current environment for requests are SQL Server Reporting Systems (SSRS).

V. Reporting
Reporting can be in-band or out-of-band. Since DynaGroups are based on Directory Services you can use any of your existing reporting but will probably need to attest to the criteria of your DynaGroups. Screen shots of queries, ownership reports, etc.

VI. Maintenance
This will include maintenance of the management interface, updates to servers and basic database maintenance.