An introduction to reference models

An introduction to reference models. Models are ways of organised information so it can be used to answer questions. Reference models provide a consistent (and often best practice) way of organising information about something. They may be used a categorisation structure or they may be considered high level elements that are decomposed into more detail.

Determinants - few integrated sets of these exist in the public domain. Ideally one would have things such as: Legalislative and regulatory RM (LRM)

Enterprise strategy - RMs covering: goals, strategies, measures etc. some example include: FEAF's PRM (Performance RM) and one would ideally also have a Goals RM.

Enterprise operations - RMs covering: products, services, functions and processes, information and data, policies and rules, organisation structures and locations. Some examples include: NGOSS's eTOM, SID, FEAF's BRM) etc. So one would have: Functional RM (FRM), Rules and Policy RM (RRM), Information RM (IRM), Organisational RM (ORM), Services/Products (SRM).

Systems and facilities - RMs covering: systems and facilities performance (e.g. SLA templates, technology goals/principles). Some examples include service and application RMs: FEAF's SRM, NGOSS's TAM), Technology RMs: FEAF's TRM, TOGAF's TRM. The connection of these internally may be between the SRM and the functional modules/services associated with specific suites or services.

Suppliers - Some examples include: sector classification schemes; channel models; agreement topics (contract templates). This would include a Vendor and products RM (VRM)

The RMs should:
- connect within each level and between each touching levels.
- connect to detailed extant views of the enterprise e.g. the FRM may connect to existing detailed process models, the IRM may connect to data models, the PRM may connect to existing KPIs, etc.
- allow direct impact analysis to be undertaken
- allow inferential analysis to be undertaken (I will discuss this in latter entries).
- be treated a set and applied

RMs are:

1. Most useful when analysable - whenf they are related so as to allow impact analysis (both between domains, and within domains). Unfortunately many are often presented diagrammatically (great for communication, hopeless for analysis) or represented using inconsistent semantics, modelling paradigms that can't be related, or using arcane technology terms that are not meaningful to 99% of the world (e.g. use case, actor, cardinality etc.)
2. Not a silver bullet - but there is little doubt that using reference will often accelerate thinking and reduce the scope for oversight. However the value of this should not be underestimated. For many large organisations it may take a team or 1/2 people working for a year or so part time to come up with the above. More often than not they never complete anything useful.
3. Need to be tailored and used carefully - as with all things that represent purported best practice they need to instantiated in-situ (using experience and judgement) to produce something that is useful in the specific set of circumstances.
   
4. Need to be analysable from the top (and bottom) - this is why absence of Determinants RMs is so limiting as ideally these would allow one to relate the circumstances to the strategy, and then from that the strategy to the operations; and the suppliers to the systems and facilities. It is why compliance issues seem so hard (and produce such a good feeding frenzy for consultants).