Generic or specific models ?

There are many analysts who advocate for using generic ER models to build a system, while others favor building it costumer-specific.

Actually, I slightly disagree with both directions.

I have studied many generic models. One common denominator is that generic models try to capture everything imaginable in a certain field of business, like financials, production, etc. If you need to cover everything imaginable, you are probably already a customer of Oracle Financials, Peoplesoft, or some other high-end ERP system.

The reason for starting a project involving ER modeling, design, development and deployment of an application, is that the business wants to build something unique; a new way of treating customers, new supply logistics, or anything else that gives it a competitive edge. A generic model will involve many entities, relationships, and probably business rules that are not relevant to the business.

It means developing functions that will never be used, an extended database with tables that are never accessed, triggers that fire and execute nothing; Even this code;

begin
  null;
end;

will have some impact on performance if it is executed often enough each day. A model specifically designed for the business sounds good. However, you have a chance of narrowing your scope too much, so that you build inflexible limitations into the system. Refer to the keynote on Analysis Trap 2.

An experienced analyst brings with him into the project a perspective based on earlier experience: He is able to recognize patterns in different areas of the business domain.

The customer is an area for which a pattern can be given. There are many common questions regarding customers, which can be reflected in a recognizable pattern.

How we build a sales order is also a common pattern: At some point there is a customer involved, the order is about one or more products, it should be effectuated and delivered, someone’s has to pay, etc.

Patterns are studies of small, specific domains of a larger ER model, with one (or a few) in- and outgoing links to surrounding domains of the ER model. An experienced analyst will immediately recognize a given domain in the model as something he has studied before, and knows about. He can therefore bring added value into the ER model by discussing the domain with the business, and ask ‘difficult’ questions, based on limitations that are obvious with regards to the patterns of that domain, and which the analyst brings with him, in his experience.

Main point:

If you go through a development cycle for a new application, it is because you want something others do not have. You do it in order to gain some competitive edge, or you are realizing a very new business idea. Either way, copying something old is not too smart. However, keeping patterns, that cover separate smaller domains of the model, at work, may build you a system that is not only something unique, but also contains flexibility based on earlier, hard-earned experience.

Return to the Analysis Phase