Business Object Analysis

A business object is only one view of the data in a database. It only contains some of the data in the database. So you need to analyze many business objects to discover what the scope and elements of the problem are. It's an highly iterative process and begins by analyzing a stack of business object organized simplest, least cluttered, to most complex.

This approach works for me. You aren't me, so adapt it to yourself and your organization's culture, standards and biases. It begins by taking the simplest business object from the top of your pile, then:

Step 1 -- Name the business object and identify its structure and data groups:

The business object, Purchase Order, is a common structure containing heading, detail and footer data. Visually identify the business object's components. Here you see the heading and footer identified in blue and the details in red. Place this first artifact in your project binder.

Note that the data in the header and footer occur only once on the business object and the "line item details" occur more than once. They "repeat."

OK! Now that we know what the structure looks like, we want to identify the "big chunks" of data that appear on our business object. Circle the "big chunks on a fresh Purchase Order." You don't have to get this right. You don't know enough at this point anyway. After you've done a couple of dozen, you will have your arms around the customer's daya requirements. It's a highly ierative and learning process.

The groups of data circled are: Purchase Order, Company, Supplier, Employee, Department and Item. These data groups should be considered "candidate enntities." There may or may not be an "Office" and "Deliver To." We need to talk to the business user to find the answer.

At a minimum, in order to store and retrieve this business object we're going to need to know "what company, what department, What supplier, what employee and what item." There could be more. There could be less. Don't try to get it perfect here. You can't. Trust the iterative process. If there's two or more of you working the analysis, analyze the business objects independently and then compare notes. Don't be afraid of being wrong or being criticized. That's how you learn and grow. The big thing is to start!

2. List and color code "candidate" entities and attributes :

Spell the data names out. Use English (or your native language). Avoid acronyms, abbreviations and mnemonics. Don't be lazy. You should keep in mind that everything you produce should communicate to both business users and technicians. You want to build "self-documenting" products.

    Purchase Order -- data occurs once
            Number; Date; Status; Approved By; Requested By; DeliveryDate; Notes; Total

    Company (Office?) -- data occurs once
            Name; Street; Suite; City; State; ZipCode; Country; OfficeName; Phone;

    Supplier -- data occurs once
            Name; Street; Suite; City; State; ZipCode; Country; Terms; Phone; Email

    Employee -- data occurs once
            Name; Phone

    Department -- data occurs once

    Item -- data repeats
           Name; Code; Quantity; Price; Discount; Total

Even with a single business objecy we have enough to walk through the data modeling/normalization process.