Business Object Binders allow for controlled access to complex data-oriented objects whose persistence is maintained and managed by one or many external systems. The Business Object Binder module provides an abstraction over the retrieval and storage of such objects. Consumers of the services offered by Business Object Binders will request objects by type and identifying elements (specific or search oriented) and receive either a specific instance of an object or a list of possible objects. The Business Object Binder will manage data retrieval, transactional boundaries, data transformation, and enrichment.
Identification
Business Object Binders live between data consumers and interfaces that provide the data. The nature of Business Object Binders makes them very close to IT. The objects represented are of interest to the business, but the structures and sources of the data are not. These more technical aspects are likely to be specific to the system environment in which the application resides. It is likely to change as IT initiatives change underlying systems of record and as architectural imperatives drive change of underlying access methods. Because the Business Object Binder is more intimate to details of surrounding systems (some of which will certainly be custom made or legacy systems), the details of the plumbing of integrations requires the ability to interact directly with IT stakeholders. These modules can be specified fairly easily following message standards and ETL specifications. Core development can therefore be done offshore. However, actual integration into the environment should be done onsite or at least by time-zone equivalent remote staff.
Design
A Business Object Binder is heavier-weight module which requires that the solution demand more complex orchestration of integration and transformation tasks that transcend the context of use. It makes a convenient place to implement common, complex processes related to data maintenance, hiding the “hard job” from the simple consumer modules such as Process Flows. Business Object Binders may include limited User Interface components related to data enrichment. Knowledge of context should be limited. A Business Object Binders is not a replacement for simple interfaces. It will provide an interface that is likely to be reusable across an enterprise or at least a department. The implementation, however, is more likely to be bound directly to a specific group and period of time. It is intimate with the details of surrounding systems even if it is not intertwined with the context of data use.
Usage & Implementation
Business Object Binders will be used by Process Flows and Functional Components through a set of façade activities that implement create/read/update/delete (CRUD) type operations on complex objects in the system. The objects will be represented by a single, nested clipboard page. Interaction with the page, once instantiated by the Business Object Binder, is standard. Implications of manipulations on the persistent objects underlying the represented instance can be managed by the consumer through explicit façade calls through the Business Object Binder or by the Business Object Binder itself. Implicit operations implemented without the knowledge of the consumer will be needed to enforce contracts between the managing systems and the Business Object Binder outside the scope of a consumer’s interest.
