Business object

Every business is characterized by a specific set of Business Objects (e.g., Contract, Customer, Order, Claim). For IT teams, gaining a deep understanding of these objects is essential to becoming true partners with business stakeholders. Analysts recognize this, which is why most maintain a centralized business object catalog and include it in their architectural and analysis documentation. While it is vital to understand these objects before diving into detailed documents, it is inefficient to redefine them repeatedly across different projects.

A business object often serves as the foundation for business rules, meaning the same governance practices should apply:

1. They should be stored in a central, easily accessible repository.
2. They should be organized hierarchically or by domain rather than in a flat list.
3. They should be referenced by link, never duplicated.

Unique storage is even more critical for business objects than for rules. While business rules are often specific to one organization, business objects are frequently shared across an entire industry (e.g., the structure of an IBAN or a Standard Insurance Policy). This is particularly relevant for software companies specializing in a specific sector. Since these objects are used throughout the industry, the object catalog should be unified and shared among all teams developing software within that domain.

Despite similarities with business rules, several principles apply exclusively to Business Objects:

1. More than a definition: A business object is rarely just a text description. It consists of attributes (the data it carries), states (its lifecycle), relationships to other objects, and associated synonyms or abbreviations.
2. Contextual Navigation: Users must be able to navigate quickly between related objects (e.g., moving from an Invoice to its Line Items or associated Payment).
3. Unambiguous Specification: The definition and boundaries of an object must be precise. Every stakeholder reading the specification must interpret the object's scope and meaning identically.
4. Separation of Concerns: Object specifications should not include lists of IT systems or technical descriptions. While the inventory of Application Components (APPs) is vital, it belongs to a separate architectural layer that maps to business objects rather than being embedded within them.

Documentation

Business terms,, similarly to business rules, should be stored in a repository, not in a text format in Word or Excel. This way, they can be easily managed, referenced, and exported. However, business terms are not just "words" and their explanations. As mentioned previously, terms might be entities with attributes, states, and relationships to other entities. While the text form is sufficient for simple definitions and abbreviations, capturing the attributes and relationships is better done visually, for example, using a domain model. In Part III, we are going to demonstrate how to automatically create glossary by combining the textual descriptions with the information included in the domain models, as shown in the following picture:

The above picture illustrates that the glossary is not just a simple list of business terms and abbreviations, but it is a rich representation of the business objects which could be automatically generated and could include visual elements or virtually anything which helps understand the business language.

Besides attributes and relationships, a very important aspect of the business entities is their possible states, which should be part of the documentation too. The following picture shows an example, in which the states are stored in the repository, modeled using a state machine diagram and automatically generated into the documentation:

Good Practices

The good practices are essentially the same as those for business rules; here, however, they are explicitly applied to business objects and attributes.

Don't include business definitions in artifacts

Inserting descriptions of the business objects directly into specifications leads to duplications. Store them in the central repository and reference them.

Don't include business definitions in diagrams

Inserting descriptions of the business objects directly into diagrams leads to duplications. Store them in the central repository and reference them.