Each discipline needs a process or methodology to follow, and modeling is no different. This is a basic methodology to be used when developing logical data and process models.
1.) Develop Business Case with Customers (Business Experts and IS)
Identify business subject experts if a team is not already available. The Business Case usually contains a description of the problem or situation to be addressed and the set of most important facts known about the problem or situation. This case will be used in the development of the Statement of Work, the contract between the modeling team and the business-IS team(s).
2.) Write Statement of Work
The Statement of Work is the contract between the modeling team and the business-IS team(s). It defines the business problem or situation to be addressed, the purpose of the logical model development, the scope the modeling process will encompass, the products to be produced, the steps that will be used to develop the products and, usually, a set of estimated durations or deadlines for completion of each step in the modeling process, given a series of assumptions. This Statement of Work should be accepted by the business-IS team leader or other responsible authority before any modeling work is begun.
3.) Conduct First Interviews (Singly and / or Joint)
Identify who must be consulted to understand the subject. The list can include end-user (business subject experts) and technical staff. Ensure that these interviewees represent all aspects of the problem or situation to be modeled – both the ways things are done now AND the ways things should be done. It is essential that business staff as well as technical staff be included in the interview processes.
The differences between one-on-one interviews and joint sessions are based on time, availability and preference. One-on-one interviews can be the first steps and validation can come at a joint session, or vice versa. Each modeling effort will have its own dynamic and the interview process can and probably will vary from effort to effort. It is most important to have interviews, it is less important to have a specific type of interview.
4.) Produce Draft Logical Models (data and process)
The draft logical models are produced during the interview process and are documented as quickly as possible. This eliminates the possibility of not accurately representing the interview results or forgetting pieces of information. Also, it maintains momentum and a sense of importance to the modeling process, which is necessary when working with application development.
5.) Review Draft Logical Models with Interviewees
The review of the draft models can occur in the interview process immediately or it can be done at subsequent sessions. This depends on the scope of each interview and the modeling skill of the analyst and interviewee. Reviews are essential to the final acceptance of the model; interviewees “own” the models if they have been involved in the entire process and have validated the models during their development.
6.) Revise Logical Models
Reviews usually result in revisions, and the revisions must be delivered to the interviewees quickly to maintain the interest and momentum. Delays imply that modeling can be postponed or eliminated from the analysis phase in development, an implication all modelers must strive to avoid.
7.) Review Revisions
Revisions are reviewed just as drafts are, usually with fewer changes required. As modelers and user-IS teams become more familiar with the modeling process the need for multiple revisions is diminished. Remember to document the revisions and revise the models.
** Continue steps 4 through 7 until the logical model accurately reflects the business at a point in time or the scope intended in the Statement of Work. Subsequent changes will be handled through a change control process and possible continuing interviews.
8.) Conduct Acceptance and Validation Exercise (Walk-through) with business and IS representatives
Acceptance and validation is the step in which the business-IS team formally states the logical model is complete, accurate and adequate within the scope of the Statement of Work for the project. Acceptance is done by the team’s representatives in advance of a more public presentation by the modeling team. After acceptance, the modeling team presents the completed logical models to an audience of interested users and technical staff and management. This presentation should focus on the purpose of the project, scope of the modeling effort, and an overview of the resulting models. An entity-by-entity description of the model is usually not appropriate. Such detail should be explained in a different, more informal presentation to the relevant users and technicians; it can often be accomplished by having full documentation of the models and definitions in either hard copy or an electronic format accessible to the interested persons.
This presentation should allow for questions and answers, but they should be within the scope and purpose of the logical model under discussion. Tangential discussions can detract from the modeling acceptance by focusing on areas that were not under the scope of the modeling Statement of Work or are not under the jurisdiction of the involved teams.
9.) Begin logical-to-physical transformation process involving Database Administration
Physical database design consists of building a database schema from the logical process and data models for a specific systems environment. At its conclusion, the database schema may bear little resemblance to the logical models, but both are valid and essential to the success of the development effort. This step requires the involvement of a database administrator, preferably one who has been associated with the modeling effort so he/she can understand the underlying rationale for the modeled objects.
After the database schema has been created, developers can begin the process of screen design, programming and associated development tasks. The developers will use the models as documentation and validation of their work, and should consult the modelers with any questions or points of clarification.
Using a development methodology such as this will enable both the business and IS communities to plan objectives, measure progress, and avoid serious complications in the use of data in application development.
