newerLogo3WhyWhitemarshProductsAndServicesWhatsNewAboutWhitemarsh

2.0 Solution Approach

The data-centric solution approach includes the development of the following key work products:

  •   Mission Model
  •   Database Domain Model
  •   Database Object Model
  •   Data Element Model
  •   Function Model
  •   Organization Model
  •   Business Information System Generation
  •   Cycles of Requirements Iterations
  •   Requirements Model

Mission Model. The mission model consists of identifying and then describing the essential missions of the enterprise. The result can be 20 to 40 pages, and these become the overall architecture within which all projects must exist. The mission statements become short, hierarchically organized paragraphs that express the enterprise's mission in an ideal form. A Holy Grail "target" of long range accomplishment. The critical test of whether a topic is included is whether the enterprise can effectively exist without the topic. If yes, then the topic not needed. If not, then the topic is essential.

Database Domain Model. Database domains are noun-intensive paragraphs of sentences formed from the leaves of the Mission Model. If a database domain paragraph contains sentences that describe complex objects then they must be subdivided into subordinate database domain paragraphs.

Once completed across all the Mission Model leaves, the database domain paragraph sentences are transformed into Subject-Entity to Relationship to Object-Entity statements. Here every noun becomes an entity no matter how simple or complex. Once the Entity-Relationship statements are complete, they are combined into larger scale diagrams, each corresponding to the database domain paragraphs.

At that point, the nouns are all triaged into complex nouns that become Database Object Classes, business Data Elements that represent single valued business facts, and property classes that become policy-homogeneous collections of single-valued data elements.

Database Object Model. Ultimately constructed is a higher level data diagram of just Database Object Classes and their relationship to other Database Object Classes. Property classes become candidate tables that ultimately are allocated to Database Object Classes. These data elements within each property class become a business data element.

Data Element Model. Data Elements become a non-redundant set of business facts that become semantic templates for database table columns. These come from the triage exercise and also the data elements from within the property classes.

Function Model. The Mission model is again used as the basis for a verb-based model that describe the essential business processes that must occur across the enterprise. The goal of the function model is to validate the data models, that is, Database Domain, Database Objects, and Data Elements. If there are business essential functions without corresponding data models then the data models are insufficient. Similarly, if there are data models without corresponding essential function models then the function model is incomplete.

Organization Model. The organization model flows from identifying the various enterprise business units involved in the specification of the function model.

Business Information System Generation. The real proof of subsets of the data model and subsets of the function model is a generated business information system. The functional subset becomes the major to minor menu items.

The subset data model is created by engineering columns for each property class that is transformed into a database table. The scope of the database table merely has to be primary key, foreign keys, and a few important columns that clearly set out the purpose of the table within the scope of its host database object.

Cycles of Requirements Iterations. The data model is defined to the business information system generator and from that, the prototype business information system is generated. After a reasonably small quantity of changes to the generated business information system it is demonstrated to the stake holders. Their comments typically result in both data and process changes. The data models are transformed and the business information system is regenerated. The stake holder demonstration is performed again.

This requirements iteration process is repeated four or so times. Once stable, work begins on the next functional subset, an proceeds until all the functional subsets are represented by business information system prototypes. The final set of business information system requirements become the specifications that are stored in the Metabase.

Requirements Model. The purpose of the Requirements Model is to act as a common collector of all the requirements that surface during the development of the models above. In addition to being a collector, the Requirements Model supports the interrelationship of all the other models based on their common requirement specifications. Finally, the Requirements Model enables the direct viewing of the object that is the subject of the requirement.

Data Centric Development Summary. The overall objective of this data-centric development is to arrive at an enterprise data model in third normal form where each table consists of only the primary key that addresses granularity and precision, and enough database table columns to validate scope and purpose. This overall process is quick, effective, and becomes the foundational blueprint for the entire enterprise.

For Sales and Corporate: 1-301-249-1142 Whitemarsh@Wiscorp.com

Whitemarsh Information Systems Corporation

 Bowie, Maryland 20716 USA

Copyright 1981 - 2020 Whitemarsh Information Systems Corporation
Proprietary Data, All rights Reserved