In my last post I made a reference to a “Data Exchange Agreement” or DEA, and I’ve since been asked a couple of times about this. So I thought it would be worth while writing a post about what it is, why it’s of value to you and to your business.
So what’s a DEA? Well in simply terms it’s exactly what the name states, it’s an agreement that defines the parameters in which data is exchanged between Service A and Service B. Service A being the Producer of Attributes X and Services B, the consumers. Now I’ve intentionally used a vague example here as a DEA is used amongst many services in business and or government and is not specifically related to IT or IAM Services. But if your business adopts a controlled data governance process, it can play a pivotal role in the how IAM Services are implemented and adopted throughout the entire enterprise.
So what does a DEA look like, well in an IAM service it’s quite simple, you specify your “Source” and your “Target” services, an example of this could be the followings;
| Source |
| ServiceNow |
| AurionHR |
| PROD Active Directory |
| Microsoft Exchange |
| Target |
| PROD Active Directory |
| Resource Active Directory Domain |
| Microsoft Online Services (Office 365) |
| ServiceNow |
As you can see this only tells you where the data is coming from and where it’s going to, it doesn’t go into any of the details around what data is being transported and in which direction. A separate section in the DEA details this and an example of this is provided below;
| MIM | Flow | Service Now | Source | User Types | Notes |
| accountName | –> | useraccountname | MIM | All | |
| employeeID | –> | employeeid | AurionHR | All | |
| employeeType | –> | employeetype | AurionHR | All | |
| <– | Microsoft Exchange | All | |||
| department | –> | department | AurionHR | All | |
| telephoneNumber | –> | phone | PROD AD | All | |
| o365SourceAnchor | –> | ImmutableID | Resource Domain | All | |
| employeeStatus | –> | status | AurionHR | All | |
| dateOfBirth | –> | dob | AurionHR | CORP Staff | yyyy-MM-dd |
| division | –> | region | AurionHR | CORP Staff | |
| firstName | –> | preferredName | AurionHR | CORP Staff | |
| jobTitle | –> | jobtitle | AurionHR | CORP Staff | |
| positionNumber | –> | positionNumber | AurionHR | CORP Staff | |
| legalGivenNames | <– | firstname | ServiceNow | Contractors | |
| localtionCode | <– | location | ServiceNow | Contractors | |
| ManagerID | <– | manager | ServiceNow | Contractors | |
| personalTitle | <– | title | ServiceNow | Contractors | |
| sn | <– | sn | ServiceNow | Contractors | |
| department | <– | department | ServiceNow | Contractors | |
| employeeID | <– | employeeid | ServiceNow | Contractors | |
| employeeType | <– | employeetype | ServiceNow | Contractors |
This might seem like a lot of detail, but this is actually only a small section of what would be included in a DEA of this type, as the whole purpose of this agreement is to define what attributes are managed by which systems and going to which target systems, and as many IAM consultants can tell you, would be substantially more then what’s provided in this example. And this is just an example for a single system, this is something that’s done for all applications that consume data related to your organisations staff members.
One thing that you might also notice is that I’ve highlighted 2 attributes in the sample above in bold. Why might you ask? Well the point of including this was to highlight data sets that are considered “Sensitive” and within the DEA you would specify this being classified as sensitive data with specific conditions around this data set. This is something your business would define and word to appropriately express this but it could be as simple as a section stating the following;
“Two attributes are classed as sensitive data in this list and cannot be reproduced, presented or distributed under any circumstances”
One challenge that is often confronted within any business is application owners wanting “ownership” of the data they consume. Utilising a DEA provides clarity over who owns the data and what your applications can do with the data they consume removing any uncertainty.
To summarise this post, the point of this wasn’t to provide you with a template, or example DEA to use, it was to help explain what a DEA is, what its used for and examples of what parts can look like. No DEA is the same, and providing you with a full example DEA is only going to make you end up recreating it from scratch anyway. But it is intended to help you with understanding what is needed.
As with any of my posts if you have any questions please pop a comment or reach out to me directly.