Business Object Model (BOM)

The Business Object Model (BOM) provides business content and guidance for SOA analysts, designers, and systems developers. It is used to clearly capture any business requirements at a detailed level. An analysis of reusable elements within business processes defined by the APM allows the identification of candidate business services that support these processes. For example, the business process for Account Opening requires the retrieval of “customer details”. Other business processes, elsewhere in the financial institution, have the same requirement. It is possible to identify a single solution that satisfies both these requirements and can be reused across the financial institution. This solution is a business service. The BOM allows reusable elements within business processes to be explored further with the aim of identifying actual business services.

The business object model brings the notions of structure and behavior together.

• It is a bridging artifact that articulates business concerns in a way that’s similar to how software developers think, while still retaining a purely business content. It is a consolidation of what we know about the area of business concern expressed in terms of objects, attributes, and responsibilities.
• It explores the essence of business area knowledge in a way that provides a transition from thinking about business issues to thinking about software applications.
• It is a way of firming up requirements to be enabled or supported by the information system that will be built.
• The process of agreeing to business object definitions, relationships between objects, and the names for the objects and relationships between objects, permits business area knowledge to be represented in a precise manner that can be understood and validated by business area experts.

Elements of Business Object Model
The key elements of the business object model are:

• Business workers show the set of responsibilities a person may carry.
• Business entities represent deliverables, resources, and events that are used or produced.
• Business use-case realizations show how collaborating business workers and business entities perform a workflow. The business use-case realizations are documented with::
  • Class diagrams that show participating business workers and business entities.
  • Activity diagrams where swimlanes show the responsibilities of business workers and object flows show how business entities are used in the workflow.
  • Sequence diagrams that depict the details of the interaction among business workers, and business actors, and how business entities are accessed, during the performance of a business

The Business Object Model and Information Systems
In the business object model, business workers represent the roles that the employees will act whereas business entities represent those things the employees will handle. Using a business object model, you define how the employees of the business need to interact to produce the desired results for the business actor. The system use-case model and design model, on the other hand, specify the business’ information systems.

Business modeling and system modeling address two different problem areas, at two different abstraction levels. Therefore, the general rule is that information systems should have no direct presence in the business models.

On the other hand, the employees acting as business workers use information systems to communicate with each other, and with the actors, and to access information about business entities. Whenever there is a link, association or attribute, there is also some potential information-system support.

These two modeling contexts have the following relationships:

• An employee acting as a certain business worker corresponds to a system actor of the information system. She is probably best supported if the information systems are structured so that her entire work in a business use case is supported by one system use case.
• Alternatively, if the business use case is large, long-lived, or combines work from several independent areas, an information-system use case could support one operation of the business worker instead.
• The things the employees work with—modeled as business entities—often have representations in the information systems. In the object model of an information system, these business entities occur as entity classes.
• Associations and aggregations between business entities often give rise to corresponding associations and aggregations between entity classes in the design model.
• Therefore, a system use case accesses and manipulates entity classes in the design model that represent the business entities accessed by the supported business use case.
• Finally, a business actor that directly uses a business’ information system also becomes a system actor of the information system.

These relations are essential when identifying requirements on the information systems that support the business.

See Also

A Business Object Model (BOM) is a conceptual representation that captures the business entities' structure, relationships, behavior, and attributes within an organization's domain. The BOM serves as a blueprint for understanding and analyzing a business's functional and informational aspects, facilitating the design and development of business processes, systems, and applications. It's an essential tool for aligning IT systems with business objectives, ensuring that technological solutions accurately reflect and support the business operations, strategies, and goals. By abstracting real-world business entities into models, organizations can more effectively communicate requirements, design integrated systems, and implement changes.

• Enterprise Architecture (EA): Discussing the practice of analyzing, designing, planning, and implementing enterprise analysis to successfully execute on business strategies, of which BOM is a component.
• Object Oriented Analysis and Design (OOAD): Explaining the approach in software engineering that models applications using objects and their interactions, closely related to the principles used in creating BOMs.
• Unified Modeling Language (UML): Covering a standardized modeling language used in object-oriented software engineering, which can be applied to create Business Object Models.
• Business Process Modeling (BPM): Discussing the activity of representing processes of an enterprise, so that the current process may be analyzed and improved, where BOM provides the underlying business entities and rules.
• Data Modeling: Explaining the process of creating a data model for the data to be stored in a database, which complements BOM by detailing the structure of business data.
• Systems Development Life Cycle (SDLC): Covering the process of creating or altering systems, and the models and methodologies that people use to develop these systems, within which BOM plays a critical role in the analysis and design phases.
• Software Requirements Specification (SRS): Discussing the document that captures complete description about the behavior of a system to be developed, where BOM can help define business requirements.
• Domain-Driven Design (DDD): Explaining the approach to software development that centers the development on the domain model and its logic, similar to how BOM focuses on representing the business domain.
• Integration Patterns: Covering the design patterns used in the context of integrating systems, where BOM can ensure that integrations align with business structures and processes.
• Business Intelligence (BI): Discussing technologies, applications, strategies, and practices for the collection, integration, analysis, and presentation of business information, supported by insights derived from BOM.
• Change Management: Explaining the methods and manners in which a company describes and implements change within both its internal and external processes, where BOM helps identify impacted business entities.
• Service Oriented Architecture (SOA): Discussing an architectural style that supports service orientation, where BOM can guide the definition of service boundaries based on business concepts.
• Analysis Process Model (APM)
• Financial Services Data Model (FSDM)
• Financial Services Function Model (FSFM)
• Financial Services Workflow Model (FSWM)
• Business Model
• Component Business Model (CBM)