The mainstay of a corporation is the data that it possesses. By data, I mean its customer base, information about the use of its products, employee roles and responsibilities, the development and maintenance of its product lines, demographics of supporters and naysayers, financial records, projected sales ... It is in the organization of this data that advancements to the bottom line are often realized i.e. the nuggets of gold are found. Defining what is important, properly cataloging the information, developing a comprehensive protocol to access and update this information and discerning how this data fits into the corporate venacular is basis of this data organization and may be the difference between moving ahead of the competition or being the one to fall behind.

Whenever we attempt to develop an Enterprise Rule Application, we must begin by harvesting the data upon which those rules are built. This is by no means an easy feat as it requires a thorough understanding of the business, industry, the players and their respective roles and the intent of the application. Depending upon the scope of this undertaking, it is almost always safe to say that no one individual is completely knowledgeable to all facets needed to comprise the entire application.

Teaching You Tools to Become Empowered

To build a successful business and career, you must always keep up with changes in the IT Marketplace. AWS, Office 365, LinkedIn, Sales Force, SEO, Social Media are just a few examples of where knowledge is a huge factor for success.

Training with HSG addresses your knowledge gaps and provides you with the requisite tools to outpace the competition.

The intial stage of this endeavor is, obviously, to decide upon the intent of the application. This requires knowledge of what is essential, what is an add-on and which of all these requirements/options can be successfully implemented in the allotted period of time. The importance of this stage cannot be stressed enough; if the vision/goal cannot be articulated in a manner that all can understand, the knowledge tap will be opened to become the money drain. Different departments may compete for the same financial resources; management may be jockeying for their day in the sun; consulting corporations, eager to win the bid, may exaggerate their level of competency. These types of endeavors require those special skills of an individual or a team of very competent members to be/have a software architect, subject matter expert and business analyst.

Once the decision has been made and the application development stages have been defined, the next step is to determine which software development tools to employ. For the sake of this article, we will assume that the team has chosen an object oriented language such as Java and a variety of J EE components, a relationsional database and a vendor specific BRMS such as Blaze Advisor. Now, onto the point of this article.

Gathering data in order to create an object model requires the expertise of a variety of individuals often those that work outside of the realm of software development. The vernacular they employ to describe the business, data, forms, work flow, activities, roles and responsibilities is often greek to the IT development staff while the inverse holds as well; conversations about class diagrams, objects and data types are completely foreign to many not tasked with the responsibilities of information gathering or writing code. To come to a comprehensive understanding, it is at this phase of development that a data dictionary is required.

A data dictionary is a list of business terms used to describe the data, a definition of each term, the type of the data i.e. an int, string, char, etc., the constraints on the data (item can only equal one value; item can equal a range of values; item is limited to anyone of four values), the default value and how this item relates to other data values. As an example, pretend that we are working on an application that handles some sort of bidding requests. The table below illustrates a simple example of a data dictionary and User type entries:

The reader should be aware that a data dictionary can be quite extensive, often detailing hundreds, if not thousands, of entries. Perhaps a considerable amount of this information already exists within database tables in one or a number of databases within the organization. In this case, it may be more appropriate to print and include the metadata of these tables and follow this approach to create the data dictionary. Nonetheless, it is important that all of those involved in the application's development are provided with this repository of terms, realize their use, are able to make changes/recommendations and can glean business decisions/rules from the constraints and use of this data. A review board is an obvious requirement.

Once the data dictionary has been created or at least detailed to the satisfaction of many involved, a uml model should be created that incorporates the object model, the relationship of objects to one another and their quantities. When needed, activity diagrams should also be supplied to picture the context in which these objects are to be used.

Since these objects will be used within business rules, it is important that the object model be stable before rules are developed as even the slightest changes to the model may introduce considerable compiler errors which can result in hours of waisted time spent chasing the bug(s). A solid understanding of uml, object design, data isolation and software architectural expertise is required to avoid these pitfalls as it may not be feasible to generate a stable object model prior to rule development.

The purpose of a data dictionary is to act as a development aid used to successfully create applications. As such, the user should not be mired in confusion as a result of too much extranious information or too little substantive information being included. Avoid the development bottle necks by creating a clear and concise description of the business data. A good guage of a quality data dictionary and resulting uml diagrams is how easily they can be read and understood by a new hire. If this individual can the require expertise from these publications in very little time to become a productive team member, job well done!