Thursday, August 7, 2008

Separating the data and the form of representation (models)

(based on recent discussion with clients looking at how to operationalise an EA model in an enterprise context)
For a solution to work in an enterprise context it is important to be able to separate the enterprise data from models which references the data. This is for two reasons – the nature of models and nature of organisations.

Models - Models are very useful particularly for design and planning (where often visual representations are very powerful). The way something is modelled depends almost entirely on the purpose of the model i.e. what you expect to learn from the model. Models consist of data elements related in fairly complex ways (object, properties, relationships between objects, calculated values etc,). As models are always designed to achieve a purpose i.e. no one model can achieve all purposes – so data-elements will usually exist in many models (each model with a different purpose).

Organisations - In an enterprise many people will be interested in things from many different perspectives (economic, operations, organisation, product, market, contracts, etc.) and at different times (now, next year, in the future). Usually most individuals while having a broad interest in many aspects on an enterprise only have a detailed interest in, and definitive knowledge of, the specific subset of the enterprise they are focused on. So while many people may be interested in the services an enterprise provides some will be interested in these at purely a business level and others interested in the technical aspects, some will be interested in costs associated with a service, some with how the service is delivered (procedures, policies, information), some more with who/what performs the service, some with what agreements are associated with the services. So while many people may be interested in the service – few people will have definitive knowledge about all aspects.

Often the data-elements may first be considered, and captured in a structured and semantically explicit way e.g. when something is being conceived of, planned or being changed. Obviously while the model suits this initial purpose (design, planning) the data-elements will be reused latter in different ways i.e. other models, reports etc. Eventually when things are operationalised the data-elements will be updated by different groups with different interests.

Therefore the model form (which relates to its purpose, and the modellers specific design or implementation) will militate against most people (other than the author or designer of the model), interacting with the underlying data-elements e.g. updating data associated a service object type. It is not that most people are not able to understand the model if it is explained to them – it is that they don’t want to understand a model created for a purpose different to the purpose they have (i.e. they don’t want to invest the time and energy learning about data and relationships that are, from their perspective, extraneous).

So for most people, only interested in a small subset of the data contained in most complex models, the model will be too complex for them to grasp, or contain too much extraneous data (i.e. it just seems like complex monolithic assemblage of data not necessarily well suited to harvesting the data for reuse). This is especially the case if the people are not modellers by nature and or don't use the modelling tool/technology employed.

Therefore it is important that people have other mechanisms for updating the data-elements that will be represented in a model. Ways that suit their interest and their level of understanding.

No comments: