Data Model Layer

We are now straying, for many, into more mysterious territory in our next business architecture routemap step…….the data model.  Data models, also known as entity relationship diagrams, define the relationships between the different pieces of data of interest to the organisation, as well as some others which are just there for technical housekeeping purposes.

The data model, with the help of its brethren, the data dictionary enable the orderly storage, search and retrieval of data stored in various types of database.  The format of a data model, using a simple example, looks as in the figure below.

While our business architecture approach recognises and accepts the utility of a data model layer, it does not provide one of its own.  This is in keeping with our emphasis on an 80/20 style of approach and the principle of pre-packaging and re-using knowledge when-ever feasible to do so.

Here, in terms of the rapid, value-for-money delivery of the things that really matter in a business transformation initiative we have assumed the use of off-the-shelf package software sourced from either proprietary or open source providers where-ever possible.

As such the corresponding data models are by definition already defined by those applications as part of their design and function.  This leaves package software ‘gaps’, a need to develop additional bits of bespoke functionality, or inter-application interfaces as the only areas potentially in need of any sort of independently developed data model (or fragment there-of).

Fortunately the sorts of areas just noted are normally not too large or significant for most organisations.  In any event the development of fully bespoke solutions is both difficult and expensive, requiring significant specialist skills to do well.  For this reason we DO NOT recommend that most organisations undertake a bespoke style of approach unless the need is extremely urgent or the reward exceptionally high.

It is also our experience that organisations who do need to undertake a modest amount of this type of development (e.g. an inter-application interface) can normally do so without explicitly developing a separate data model.  Rather they start with the data models from the applications they have and develop only those elements needed to ‘stitch’ those data models together, often using EAI tools or equivalent that make this easier, and hiring specialist help as needed.

In the main, full data models are really only required by those developing significant software applications from scratch…….a fair description of a software vendor, but not of your typical business organisation!

However, there is one data related area that you ignore at your peril!  That is the area of data classification, coding and cleansing.  In other words it is about how you structure and categorise the codes used in the software applications you employ and then keep that data accurate.

Although a software vendor may provide significant guidance and a constrained range of choices for how to do this you will still need to define static structures such as ‘charts of account’, assign accounting codes to departments, give part numbers to products and services, and have a system for the allocation of invoice numbers to name just a few examples.

Once you’ve done this and everything is up and running you will have to enter more dynamic data on suppliers, customers, orders, inventory levels and so on as well as have the means to keep this data accurate over time.  If you do not do this the garbage-in / garbage-out principle will quickly begin to take hold……and in due course you will have to undertake a painful data cleansing exercise to put it right…….perhaps as part of an audit compliance action!

A particular, and common, instance of this problem occurs when two different applications are replaced by a newer single application that does the job of both of the old ones.  Great!….but not quite so great if you find (as many do) that the two older systems used different structures, codes and numbers to describe and reference the same things (e.g. products).

A new system WILL NOT have a sense of humour and it will not empathise with you or take care of the problems arising for you.

Your organisation will have to sort it out the old fashioned way (although there are tools that can help)……by harmonising (an example of data restructuring and cleansing) the two different coding schemas into a single unified coding schema compatible with the new application.

Not much fun, but it is essential!

If the content of this webpage makes you feel that being a member of our Biz4ge Network, or a Certified Affiliate within it, would be of benefit to you please Contact Us and we will get in touch by return. Your contact will be treated as confidential and will be at no cost or obligation to you.