Have you taken one of the schemas and looked at how much of it is data that has an interested audience?
All the data that goes to the outside world is market sensitive and very important to our customers.
I wasn't talking about an external audience. For the sake of argument lets take the role "user". There's a pretty good chance that the master for
User is Microsoft's Active Directory. The user object currently has over 400 attributes, not counting auxiliary classes or any schema extensions you've made. Within the Corporate space AD most likely replicates with your phone system (VoIP) and follow-me printing. Hopefully it's getting a feed from the master for
Employee your HRIS.
So we have four distinct schemas that we want to map between. You could get someone to sit down and populate a class element with all of the attributes (potentially Geert's add-in thingy would do it faster) but there's only a sub-set of the attributes that any one actually cares about. Your Finance people are going to care about cost centre information so they can apportion phone calls and printing costs to the right cost centres and the HR people care about role and position information. In addition your IT people may care about some extension or workstation attributes as they are the glue that makes the magic work. Once you understand the audience and the attributes you're likely to find that there are no more than thirty attributes that you need to model.
Then you reach out a bit further and find that there's a log on script that creates email signatures, and the super sekret LoB system uses the ManagedBy attribute to check a user's role in the system.
Then you can sit down and create a class for each user object from each system and map between just the relevant attributes to show how they replicate between each system. Which obviously takes far less time than creating the entire schema and mapping the related attributes in each object.
This is pretty powerful and allows you to answer questions quickly, which is obviously the point of modelling (apart from Archimate :-} ). for example if HR comes and long and tells you they're fun and zany guys and they're thinking of letting everyone choose their own job descriptions internally to create a fun and friendly atmosphere. You can then say well that's going to be visible on our external email signatures and will effect our brand, and will flow into the cost accounting and the bean counters will struggle to determine if people's usage is appropriate to their job role.
But you probably don't want to record the details of the email signature script on this class diagram as you'll over load it (that can be recorded on the component information flow view).
Your original question asked a number of things about data types. Unless we're speaking about different things, your class diagram has captured the data type for each attribute with sufficient detail for your average code monkey. If you need to go into greater detail you can use EA's standard data models you capture the system details (you need to change the logical diagram to a class diagram).
Would I customize anything? No I wouldn't. I'd try to stay as vanilla as possible, and I'd give the data analysts the freedom to play in their own sand pit to a certain extent.
I've rambled a bit but hopefully that helps.
