Dataflow Design Concepts

Applies To: Windows Server 2003 with SP1

Previous Topics in This Guide

• Overview of designing a system dataflow model

The dataflow model is a set of"policies and diagrams representing the design requirements" that you need to implement in order to meet the goals in your solution proposal. Dataflow model policies are simple statements of the business requirements found in your solution proposal. You refine each statement so that it evolves into a precise policy of your business requirements. For example, the following shows how one simple statement can evolve into a precise business policy:

• The solution proposal might contain a business requirement such as: “Contracted labor should not be incorporated into the human resources database but should be given Active Directory accounts.”

• During the current design stage — the dataflow model design stage — the statement evolves into a logical-level policy: “Contracted labor will be provisioned to Active Directory but not human resources.”

• During the metaverse planning stage, you refine the statement to become physical-level policies that define the rules needed to implement the desired business policies. The metaverse plan describes the steps that are required to implement the policies in the metadirectory. Continuing the current example, the metaverse planners use the logical-level policy to create the physical-level policies as follows:

  • “A new attribute called samAccountName needs to be added to the person object type in the metaverse to facilitate the provisioning of new accounts in Active Directory.”

  • “An import attribute flow rule needs to be created for the SQL Server management agent that combines the First and Last name attributes of data imported from the contractor database and stores the new value in the samAccountName attribute of the person objects in the metaverse.”

  • “An export attribute flow rule needs to be created that exports the samAccountName attribute of the person objects in the metaverse to the samAccountName attribute of the user objects in the Active Directory management agent’s connector space to provision new accounts in Active Directory for new contractor accounts.”

    Note

    A single logical-level policy does not always map directly to a single physical-level policy. In fact, as in this example, a single logical-level policy can easily result in multiple physical-level policies.

You document the logical level policies in your system dataflow design document. When the dataflow designer and the design team complete this process, you have documented the list of policies that are required for your solution. The dataflow designer passes this list to the rules planner, who develops the physical level policies and creates the rules to enforce the policies. A copy of the system dataflow design document is also passed to the metaverse planner, who plans and documents modifications to the metaverse schema.

To complete the dataflow model, the dataflow designer can use the data that the project team collected and documented for the solution proposal. For example, the dataflow designer is interested in the following data, Real-world identity type: staff member.

During the dataflow design process, the dataflow designer must determine the following:

• The connected data sources that already store information related to this identity type and the object type those data sources use to store that information. The following are possibilities:

  • Active Directory® directory service, which has a User object type.

  • A SQL Server-based human resourcessystem that uses an Employee object type.

  • A Lotus Notessystem that uses a Personobject type.

All these connected data sources represent a staff memberidentity type in the real world.

• The policies that apply to this identity type. For example a business rule that specifies that staff members can only be created in the SQL Server-based human resources system, and that Active Directory and Lotus Notes are then to be provisioned automatically with corresponding Userand Person objects.

• The list of attributes that need to import or export data into or out of the metadirectory in order to meet the requirements defined by the various business rules. The list must also include information indicating any special requirements of these attributes. For example, of the countless attributes stored in Active Directory, only the following attributes might be listed because they store the data that is to be managed by the metadirectory: displayName, userPrincipalName, samAccountName, telephone, fullName, sn, givenName and mail.

A similar list would exist for the other connected data sources.

Figure 2 illustrates how the Fabrikam scenario appears if you would diagram it for the first step in the design process. Attribute lists for each object type are shown. Note that the mail attribute on the User object in Active Directory is marked so that you do not include it in any outbound flows. Be sure to record this type of information about the appropriate worksheets.

Figure 2: Policies on the Staff Member Object

The subsections that follow describe concepts that you need to be familiar with before you begin to design your system dataflow model:

• Filtering dataflow to control what goes into and comes out of the metadirectory.

• Constraints on design due to uniqueness requirements, such as metaverse globally unique identifiers (GUIDS), anchors, distinguished names, and data validity.

• Authority and precedence as it relates to objects and attributes, including object creation and deletion.

• Identity resources such as data sources, objects, and attributes, and how they map the real-world identities.

• Identity integration policies and rules, including how policies become rules.

Next

• Filtering Metadirectory Dataflow

See Also

Concepts

Overview of designing a system dataflow model
Filtering Metadirectory Dataflow
Design Constraints
Authority and Precedence
Process Steps for Designing the System Dataflow