Comments on: The unbearable brittleness of data models http://andyonenterprisesoftware.com/2006/03/the-unbearable-brittleness-of-data-models/ Andy Hayler, founder of Kalido and The Information Difference, gives his views on the enterprise software market. Issues covered include data warehousing, master data management, business intelligence and data quality. Wed, 03 Dec 2008 08:47:59 +0000 http://wordpress.org/?v=2.0.3 by: Andy Hayler http://andyonenterprisesoftware.com/2006/03/the-unbearable-brittleness-of-data-models/#comment-106 Fri, 07 Jul 2006 07:53:00 +0000 http://andyonenterprisesoftware.com/2006/03/the-unbearable-brittleness-of-data-models/#comment-106 You are certainly right in that developers will always prefer to follow a less generic model. This is even more the case when the model is highly generic, as in the generic entity framework used in the ISO work that I reference in the blog. In Kalido we store master data in an ultra generic form, but then generate a "normal" star schema from this so that developers can see something familiar for reporting purposes. It may be that the resistance you accurately describe will make it hard for generic models to take root outside software packages, where their generic nature can effectively be shielded from developers. You are certainly right in that developers will always prefer to follow a less generic model. This is even more the case when the model is highly generic, as in the generic entity framework used in the ISO work that I reference in the blog. In Kalido we store master data in an ultra generic form, but then generate a “normal” star schema from this so that developers can see something familiar for reporting purposes. It may be that the resistance you accurately describe will make it hard for generic models to take root outside software packages, where their generic nature can effectively be shielded from developers.

]]> by: Karen Lopez http://andyonenterprisesoftware.com/2006/03/the-unbearable-brittleness-of-data-models/#comment-105 Thu, 06 Jul 2006 21:11:00 +0000 http://andyonenterprisesoftware.com/2006/03/the-unbearable-brittleness-of-data-models/#comment-105 The generic concept you are looking for is Business Party / Party Role in a data model. This generalization allows modellers to support customers that become suppliers and vice versa. However, the 2 biggest problems modellers have in getting this generalization into their database designs are: 1)Business change approval. changing business processes to actually recognize that the supplier is an existing customer is not just a technical problem -- it is much more of a business challenge. 2) Developer resistance: Many developers prefer very specific, application or window-driven tables. When presented with a generalization, they will resist the added complexity of having a concept transformed from a database object to a data value. In my two decades of experience, I have always found that it is not the modeller that wants more specific structures, it is the business and developers who feel more comfortable with a very specific, tightly coupled database structure. I'd love to produce models that follow your post. The generic concept you are looking for is Business Party / Party Role in a data model. This generalization allows modellers to support customers that become suppliers and vice versa.

However, the 2 biggest problems modellers have in getting this generalization into their database designs are:

1)Business change approval. changing business processes to actually recognize that the supplier is an existing customer is not just a technical problem — it is much more of a business challenge.

2) Developer resistance: Many developers prefer very specific, application or window-driven tables. When presented with a generalization, they will resist the added complexity of having a concept transformed from a database object to a data value.

In my two decades of experience, I have always found that it is not the modeller that wants more specific structures, it is the business and developers who feel more comfortable with a very specific, tightly coupled database structure.

I’d love to produce models that follow your post.

]]>