Data modeling is a critical piece in the system analysis and design process. At least this is what is being taught in the System Analysis and Design class when I was in college. You can use the data model to represent the user requirements and you can use data model to represent the your system design. A data model is a communication tool to allow you to use diagram to explain the complex data relationship. The data modeling is a critical piece but we also know that it is not everything. A lot of things cannot be communicated by the data modeling tools. Many design aspects cannot be considered if you only do data modeling.
I learned that many people with the various roles can use the data modeling techniques. However, if we talk about the application development process design or talking about the development organization design, should we centralize the data modeling work to a "Data Modeling" group?
The organizations I have been working with follow different approaches. It is basically a balance of business domain knowledge and the data modeling discipline.
1. Centralized data model group
All the data model can only be created by the central group. The table, index, etc. are only created by the central group. The product groups are consumers of the data model. If they want to change the model, they need to submit the request to the data model group and provide the business requirements and justifications. All the data model reference guides are produced centrally.
This is the extreme case. The organization followed this model has a strong support from their tool. Their developers do not really need to deal with SQL, and do not need to deal with the physical database directly. Developers write the codes which deal with the business components. The programming language incapsulate the SQL logic by the object model - Getters, Setters, methods, etc. All the database upgrade scripts are delivered centrally.
The resulted model they produce is cohesive and consistent. The standards and best practices are followed and documentations are well prepared. I think that this is a sucessful model. However, I really doubt if they can really understand the different business domain area. Part of their success is because of the size of their products are not really big. They are only concentrating in the CRM area.
2. Logical Model group - but only after the fact
All the logical data model "diagrams" are produced centrally, but the diagrams are created after the design is completed and coding is almost done. The deliverables are helping the consultants, implementors, and customers understand the model. They do not really have the authority to mandate how the data model should be created. If they don't like it, they can "escalate" to management. The result won't be good for both the product team and the central group. The manaegment has no idea what the design issue is and was pushed to make such decision. Very bad for management as well.
I have worked with such group before. I like to work with them a lot, but unfortunately they do not really get much upper management supports. Their work is like to creating an art work from the collections of garbages. This is a failure model, in my opinion. Lacking the upper management's support is the key problem. If the upper management do not value the conhesive design of data model, and is not willing to invest on the team, no matter how good the data modelers are, the result won't be good.
3. Centralized data model creation - the release engineering group
I worked with such group several years ago. They never claim that they are the data modeling group and they are actaully not. However, they are in charge of the delivery of the data model, and thus becomes a good gatekeeper. Bascially all the data model schema are created and delivered by the them. They do not have domain knowledge for any of the functioanl area and they never pretend they have.
However, they contribute a lot in term of standardization and documentation. When any product team is asking for adding a new column, although they do not know every individual business requirements, they at least ask the team to provide the document. They ask the product teams to provide the names and descriptions and they ask people to acquire all the approvals, for example, they ensure that product managers are involved in the process, and they ensure that documentation writors are involved.
I think that this is a sucessful model and can be more sucessful if the group#3 and the group#2 can be combined together. Unfortunately they are two separate groups at that time.
SUMMARY
A good data model can be a product on itself. Data model CAN be separately and owned by a central group. One of the critical sucessful factors is to enprower the group and make them as a mandatory piece as part of the development process. The data model group should not only be a design team. The data model group should not be just "review" and "document" the model created by the product teams. It should own an deliver the codes even they do not really understand all the business requirements. The design should, actaully, be proposed and driven the individual projects and driven by the customer requriements. However, the central team should fully understand the proposals and proatively "protect their model" by ensuing the conhesiviness and consisteny. They should only the deliver pieces as a way to balance the powers between the individual product team and the central data model group.
I learned that many people with the various roles can use the data modeling techniques. However, if we talk about the application development process design or talking about the development organization design, should we centralize the data modeling work to a "Data Modeling" group?
The organizations I have been working with follow different approaches. It is basically a balance of business domain knowledge and the data modeling discipline.
1. Centralized data model group
All the data model can only be created by the central group. The table, index, etc. are only created by the central group. The product groups are consumers of the data model. If they want to change the model, they need to submit the request to the data model group and provide the business requirements and justifications. All the data model reference guides are produced centrally.
This is the extreme case. The organization followed this model has a strong support from their tool. Their developers do not really need to deal with SQL, and do not need to deal with the physical database directly. Developers write the codes which deal with the business components. The programming language incapsulate the SQL logic by the object model - Getters, Setters, methods, etc. All the database upgrade scripts are delivered centrally.
The resulted model they produce is cohesive and consistent. The standards and best practices are followed and documentations are well prepared. I think that this is a sucessful model. However, I really doubt if they can really understand the different business domain area. Part of their success is because of the size of their products are not really big. They are only concentrating in the CRM area.
2. Logical Model group - but only after the fact
All the logical data model "diagrams" are produced centrally, but the diagrams are created after the design is completed and coding is almost done. The deliverables are helping the consultants, implementors, and customers understand the model. They do not really have the authority to mandate how the data model should be created. If they don't like it, they can "escalate" to management. The result won't be good for both the product team and the central group. The manaegment has no idea what the design issue is and was pushed to make such decision. Very bad for management as well.
I have worked with such group before. I like to work with them a lot, but unfortunately they do not really get much upper management supports. Their work is like to creating an art work from the collections of garbages. This is a failure model, in my opinion. Lacking the upper management's support is the key problem. If the upper management do not value the conhesive design of data model, and is not willing to invest on the team, no matter how good the data modelers are, the result won't be good.
3. Centralized data model creation - the release engineering group
I worked with such group several years ago. They never claim that they are the data modeling group and they are actaully not. However, they are in charge of the delivery of the data model, and thus becomes a good gatekeeper. Bascially all the data model schema are created and delivered by the them. They do not have domain knowledge for any of the functioanl area and they never pretend they have.
However, they contribute a lot in term of standardization and documentation. When any product team is asking for adding a new column, although they do not know every individual business requirements, they at least ask the team to provide the document. They ask the product teams to provide the names and descriptions and they ask people to acquire all the approvals, for example, they ensure that product managers are involved in the process, and they ensure that documentation writors are involved.
I think that this is a sucessful model and can be more sucessful if the group#3 and the group#2 can be combined together. Unfortunately they are two separate groups at that time.
SUMMARY
A good data model can be a product on itself. Data model CAN be separately and owned by a central group. One of the critical sucessful factors is to enprower the group and make them as a mandatory piece as part of the development process. The data model group should not only be a design team. The data model group should not be just "review" and "document" the model created by the product teams. It should own an deliver the codes even they do not really understand all the business requirements. The design should, actaully, be proposed and driven the individual projects and driven by the customer requriements. However, the central team should fully understand the proposals and proatively "protect their model" by ensuing the conhesiviness and consisteny. They should only the deliver pieces as a way to balance the powers between the individual product team and the central data model group.
No comments:
Post a Comment