Developing Entity/Class Definitions Using Business Event Analysis
This article deals with two issues. First, it proffers a set of criteria for what constitutes a good entity/class definition. And second, it shows how business event analysis (BEA) can aid entity/class definition by providing a structured vehicle to elicit this information from those who know the business best- business area subject matter experts (SMEs).
During the scoping and analysis phases of the systems development life cycle (SDLC), much of the detailed business knowledge required to develop systems that meet the business need are to be found in entity/class definitions. Unfortunately, most methodologies, and most CASE tools, offer little guidance as to how to write these definitions. This is a shame because poor entity/class definitions during the scoping and analysis phases are basically a waste of time for all those involved. Furthermore, this lack of precision in the entity/class definitions will eventually have to be dealt with at some point further along the SDLC, or after the system is put into production. And as we have learned from the quality movement, the later in the process a problem is corrected, the higher the cost.
Developing precise, accurate and thorough entity/class definitions becomes even more important when a project team attempts to re-engineer the business. As new business processes and computer systems replace well-entrenched business practices, which have developed over many years, it is easy to miss things. Remember the system you are trying to develop in six months may be replacing a system that took six years to develop (six months of development and five-and-a-half years of maintenance). Often, system development projects get themselves in trouble because they do a good job with 95 percent of the requirements, but completely miss the other five percent of the business' requirements. This may be perfectly fine if the 95 percent are useful while the other five percent are developed as part of a second release; or it can be quite embarrassing if it is not. Remember what boxers say: it is the punches they don't see that hurt them. Often, missing requirements or opportunities is the direct result of working from excessively simplistic models of the business (including the definitions section).
Another real consideration is that many organizations start and stop several large systems development efforts over the course of a couple of years. Although technology changes, as do business practices (e.g., EDI, Internet, and intranet replacing paper), core business definitions do not. So, if a project is canceled some time after the analysis phase and that project team has done a poor job writing entity/class definitions, those definitions will be thrown on the corporate waste pile, with the corporation receiving no benefit for the work performed. However, well-documented knowledge about the business becomes a corporate asset and a component that can be useful to later systems development efforts. This, of course, has been the unrealized dream of corporate repositories.
The Problem Inherent In Natural Language
Traditional data models, as well as object models, consist of diagramming techniques and narrative descriptions. Volumes have been written on data/object modeling diagramming. But the diagramming symbols are not where all the confusion arises in real projects. For example, the fact that a rectangle represents an entity, or a line a relationship, causes no confusion. These symbols have only one meaning, and that meaning is always the same. On the other hand, the definitions section of an entity or class object relies upon the English language (or your language of choice); and natural language is subject to multiple interpretations and confusion. The same term can have different meanings depending upon the context in which it is used, as well as a person's prior experience with that term.
The problem really is not so much that words are subject to more than one interpretation; the problem is more often that we assume the other person is using the term the same way we are using it. There are linguistic philosophers who believe that no two people have the same definition for any word. According to this epistemology, words by their very nature are only concepts that each of us has formulated in our mind. Each person has created his or her own mental picture for each of the words in his or her vocabulary. Since there is no way to copy one person's mental image of a term to another person's mind, no two concepts of what any word means are exactly the same. Since words are the building blocks from which our entity/class definitions are to be built and each person's concept of any given word is slightly different at best, specific attention must be taken to ensure that we are communicating clearly when we are defining new entities/classes. In essence, we are defining a new term or word that we want everyone on the team to understand and define in the same way, yet we are using words or language, inherently ambiguous, as our building blocks.
It does not take a linguistic philosopher to recognize that we are often confused, or have different understandings, as to the meaning of any given entity or class. Anyone who has participated in Joint Application Development (JAD) sessions has experienced walking away with a different understanding as to the meaning of an entity or class than someone else who attended the same meeting. For example, a word like "Account" can have attributes and be related to several different entities on an entity-relationship diagram (ERD), and yet conjure up very different meanings to different people. Often this is manifested by detailed discussions (arguments) over the use of a given entity or class, only later to learn that both people had a slightly different "picture" in their mind as to what was intended by the entity or class. The best way to avoid confusion is to have very specific (detailed) entity/class definitions.
Guidelines For Good Entity/Class Definitions
First, include a topic sentence, which concisely, but accurately, defines the entity or class. For example, the topic sentence for the entity or class labeled "Corporate Contracts" might be: "Legally enforceable agreements between ABC Corp and an employee, customer or supplier."
Second, include a detailed description, which provides the rules for distinguishing between an occurrence of this entity or class from those which are not. The definition should be expressed as a series of single statements which affirmatively, or negatively, posit what will and will not be an occurrence of the entity/class. Examples include:
- Agreements reviewed and approved by the corporate legal department.
- Agreements entered into outside the corporate legal department which are now the subject of litigation.
- Agreements drafted by the corporate legal department, as well as contracts drafted by other parties.
- Agreements which are under preliminary negotiation.
Third, include examples of occurrences of this entity or class. For example, this entity/class includes employment contracts, supply contracts, rental agreements, equipment leases, etc.
Fourth, include examples of occurrences that do not fit within this entity or class. For example, this entity/class does not include: oral contracts, purchase orders, promissory notes and miscellaneous minor agreements entered into every day which do not rise to the level necessary to be reviewed by corporate counsel, such as rental car agreements.
Fifth, make sure you have considered the life cycle of the entity or class in drafting your definition. When does an occurrence of this entity or class come into existence (birth); what are all the uses of it (life); and when does an occurrence cease to exist (death).
Sixth, deal with those occurrences which fall on the boundary line between being within the scope of the entity or class and being outside of its scope. These will be occurrences where the SME will probably be unsure as to whether or not they should be included and will often be recorded as open issues in JAD sessions. It is important to force a decision on these points, even if only initial decisions, so that the choice can be documented. Often it is good to record the reason why a particular domain has been included or excluded.
Seventh, identify synonyms. Include other words used in the company to refer to the same thing and identify terms that are often confused (i.e., those thought to have the same meaning although their meaning is slightly different).
Eighth, define any term used in your definition that is subject to more than one interpretation, or any term not commonly known by the general reader in your organization.
Ninth, cross- reference to all business events, which act on or rely on this entity/class
How Business Event Analysis Aids In The Development Of Entity/Class Definitions
If one has all of this information, it is a relatively easy task to organize it into a definition that satisfies these requirements. But typically, it is the person with the modeling skills, but without the business knowledge, who is responsible for writing the entity/class definitions. The SMEs, who possess the most detailed knowledge of how the business works, are not the ones writing the definitions.
BEA aids the data modeler in extracting information from SMEs. First, BEA provides a structure to the information gathering process; and second, BEA provides a method for determining when an analysis is complete. From the perspective of a practitioner, these are two very important and practical benefits. If you find that your facilitated sessions lack focus, wander or go over the same ground, you will find BEA very helpful.
BEA focuses on the business events that drive the business, such as: Customer inquires about Product Offerings, Customer places Order, Customer inquires about the status of an Order, Customer makes a change to an Order, etc. It is easier to have a discussion with SMEs regarding business events because they are real things that happen in the real world. By listing the business events, the modeler can then ask the SME whether or not they have taken into account everything that a customer does related to an Order. For example, we did not list the business event "Customer cancels Order" or "Customer calls up and gives an incomplete Order" (e.g., they don't have their billing information, and they want to call back with just this information instead of repeating the entire order). The data modeler can then move on to Order Fulfillment or Management Reporting and list all the business events related to the entity/class labeled Order for these business processes. In summary, analyzing entities/classes using BEA helps data modelers ask the right questions, and asking the right questions is what drives a good analysis.
One of the problems that surfaces in discussions regarding models is that the discussions can flounder due to a lack of structure. For example, how do we know we have captured all of the business requirements for the entity or class labeled Corporate Contracts? The only way to know is to put together a list of business events that make use of that entity or class, make sure that we understand these business events, and make sure that our list of business events is exhaustive. When we have done this with a reasonable degree of certainty, and with enough review, then we can be pretty sure we have collected all of the business requirements related to that entity or class object. Without a structured approach, all we know is that we have had a discussion, or discussions, regarding the entity/class labeled Corporate Contracts, but we have no test to make sure we have everything we need. Having an event list mapped to the entities or class in our model takes care of this problem.
BEA has been used for years by experienced practitioners to validate the relationships in a data model or to review a process model for completeness; but it is also useful to apply this approach when reviewing an individual entity or class definition. Making sure that the model has been rigorously analyzed from all angles is the best way to ensure it accurately reflects the business it is trying to model. Using BEA to work through all the possible uses of an entity/class ensures that everyone truly has the same definition for that entity/class. And, having everyone working from the same precise definitions leads to more efficient and effective delivery of application systems.
For more information on related topics visit the following related portals...
Dennis J. Glacken is a principal consultant with ZYGA Corporation, a consulting company specializing in knowledge management and data warehousing. Glacken was previously associated with Sea-Land Service Inc. and Deloitte and Touche. Glacken, who is also an attorney, can be reached at (908) 604-9000, (908) 756- 4767 or Dglacken@ZYGA.com< /A>.
Provided by IndustryBrains
|Analytics for Oracle Applications|
Get sophisticated analytics and real-time reporting for Oracle and MFG Pro ERP systems based on a packaged data warehouse. Immediate results from packaged Business Solutions from Jaros Technologies.
|Autotask: The IT Business Solution|
Run your tech support, IT projects and more with our web-based business management. Optimizes resources and tracks billable project and service work. Get a demo via the web, then try it free with sample data. Click here for your FREE WHITE PAPER!
|See Enterprise Business Intelligence in Action|
See how business intelligence can be used to solve real business problems with this live demo from Information Builders
|Free Business Intelligence articles & webcasts|
BetterManagement helps decision makers connect issues with answers, problems with solutions, and ideas with perspectives from other business and government leaders, analysts, consultants and academics.
|OutlookSoft Business Intelligence & BPM Software|
OutlookSoft is real-time, Microsoft-based business intelligence and BPM software that unifies query, reporting, analysis & OLAP with planning, budgeting, forecasting, consolidation, reporting & scorecarding. Free demo & white paper
|Click here to advertise in this space|