User:Tpriebe/Business information modeling

Business information modeling (BIM) is a holistic approach to structured business requirements definition and harmonization with the goal of facilitating model-driven implementation of data-intensive IT solutions.

Instead of modeling data and their structures, business information modeling aims at capturing the actual parts of business – customers, products, assets, transactions – and define how you view the information in business terms, not technical ones. As a result, IT and their business counterparts can collaborate and communicate on the requirements for reporting, analyzing and managing information across the enterprise. And, for data-intensive IT solutions, such as a data warehouse, the business information model documents everything that is in the database, so business users will know what’s available to them.

Sometimes also the term business data modeling is used rather than business information modeling, however, the approach clearly leaves the semiotic level of syntax towards semantics.

Overview
Logical or physical data models alone are not suitable to enable harmonization and reuse in data-intensive environments. In order to address those goals adequately, the technical data models have to be accompanied by a semantic business information model, capturing the definitions and business rules plus the mappings to the different representations of the corresponding data artifacts.

A business information model represents unambiguous, robust definitions of business concepts and the linking of data to these concepts. The model is an organization-wide and unique catalog of information pieces that represent the requirements of all relevant user communities.

(Extended) entity-relationship modeling
A business information model is usually based on the entity-relationship model as originally proposed by Chen [9] with some extensions. As depicted by the four colored symbols in the center of the BIM wheel in figure 1, the main elements of our modeling approach are Subject Areas, Entities, Attribute Definitions and Attributes.

Entities are assigned to subject areas just to structure project scope and modeling work (and potentially to define governance responsibilities); they do not affect the formal model itself. Relationships are captured as entities and/or reference attributes (see below). The concept of attribute definitions is covered in the next subsection.

Like in every modeling exercise, you need a graphical representation to discuss entities, their relationships and key attributes. As we want to keep the notation easy to understand for business users, we adopt the notation proposed by Chen [9]. Figure 3 shows a (simplified) excerpt of an example banking business information model using the main structures Customer, Employee and Account (with substructures based on the products the bank offers, in this case Current Account, Deposit Account and Loan Account). As you can see, entities are represented as boxes, relationships as diamonds and attributes as bubbles. Please note two things: Firstly, we would never show all attributes in a graphical diagram, as you may have over a hundred attributes on one entity (see also section III on using a glossary representation). Secondly, note the different color and naming used for the two types of relationships, Account Holder Reference and Account Manager Relationship. For the sake of the example, we assume that an account can have only one account holder, but more than one account manager. As we in our methodology break everything down into entities and attributes, the former (a one-to-many relationship) becomes just a reference attribute, while the latter actually becomes an entity.

Metapattern approach
Pieter Wisse introduces a third approach to conceptual modeling of information called metapattern. It is a technique for meta-information analysis and modeling that emphasizes reusability. Unlike other approaches, metapattern includes a finely grained concept of time stamping and a recursive concept of context.