n.data that delineate the structure, behavior, and processes of an entity in an information system, developed and maintained separately from the programs and applications that run the systemKesner 1998, 77Simply put, the multitier model is an electronic network design that separates the sources of data (i.e., electronic databases, corporate data stores/warehouses, or transaction system data), from the business process, and from the interface (i.e., electronic access points) to the end user. In many respects this multilayer model resembles the world of paper record creation as well, where the user creates the document in an operational setting, but according to the “metadata constructs” of a business process, and then passes it on to records storage and/or the archives once the initial administrative purpose for its creation has been addressed. ¶ Since all three component layers will change over time, the organization’s information systems implementation must afford the flexibility to swap out components without affecting the remaining pieces. This is a sound practice in that it allows for the best use of each component without marrying the organization to any particular interface, business process, or transaction system for life. In this new environment, the business rules are developed and maintained separately from the transaction system/database layer. The infrastructural separation between layers allows for a more flexible and responsive development environment. Business processes no longer have to be dedicated to one application (i.e., transaction system). Processes that are common throughout the enterprise can be developed as shareable programming objects for many applications.Von Halle 2001The ultimate payback of a business rules methodology is twofold. The first is a system development methodology that enables the discovery of essential intellectual process flow. The second is a system specifically designed to enable more spontaneous business change. A business rules methodology leads to the delivery of a system designed to change its rules, add new ones and retire old ones. A business rules approach puts the business back in charge of its destiny.US CWM 2004, 39The IRS and their industry partners agreed on a business rules approach for CADE [Customer Account Data Engine] in a contract awarded in December 1998. Simply put, a business rule is any statement that defines how a business conducts its business. For the IRS, business rules are principally representations of tax laws and tax forms. The potential benefit of a business rules system is the separation of the business logic from program logic. For example, a business rules approach would allow the IRS to easily change the rules to reflect new tax year changes without affecting the underlying computer environment.Zhang 2012, 180The PeDALS [Persistent Digital Archives and Library System] system is designed to process electronic records that are generated from similar business processes and are associated with existing metadata used by records creators to manage and access their records. The assumption is that the records creator has established an order or an access system so that records stored can be retrieved. After the records are transferred to the archives, archivists can exploit the received metadata instead of spending time recreating them. The system that has thus been built requires appropriate records sets that are large enough and consistent enough to allow business rules to function. The model is not immediately appropriate for processing less-structured records. The ideal scenario would be to store and index records in an electronic document management or recordkeeping system. Certain pilot records series generated during routine business by state government agencies might be suitable for transfer to the PeDALS system; for example, marriage certificates, e-mail records, death certificates, and litigation case files.Cook 2020, 189Our CEO sends out thousands of electronic mail messages in a year; determining which ones have long-term value to the corporation and to archives rests not on reading each such message—and by extension the millions of other such messages sent by everyone in the corporation. Rather it rests on understanding which functions, programmes, processes, and activities are important (central, core, mission- or mandate-driven) and which are not (peripheral, supportive, administrative), and then building into the software and business rules precise methods of separating the former from the latter, keeping one and destroying the other. To do this, we must study the context of our sponsor’s functions, business processes, and work cycles, and then help them to decide what key acts and transactions within that functions-process matrix need to be captured and when; encourage them in system design to distinguish information from records; and convince them to preserve as “records” the most vital evidence of important transactions, activities, and functions.Duranti 2020, 69The model [for PaaST, or Preservation as a Service for Trust] defines a comprehensive set of functional and data requirements that support preservation of digital information regardless of the technologies used or who uses them. The requirements are intended to enable authentic digital preservation in the cloud, but they are valid in other scenarios as well, including in-house preservation and situations in which digital preservation includes both in-house and contracted services. ¶ In addition, PaaST requirements are applicable to cases that include heterogeneity in the types of information objects being preserved; variety in applicable directives, such as laws, regulations, standards, policies, business rules, and contractual agreements—including varying conditions of ownership, access, use, and exploitation; variation in institutional arrangements and relationships between or among the parties involved; and a wide spectrum of circumstances from best practices to worst cases.
