ABSTRACT
The Bifurcated Architecture separates the volatile variability—business rules—from stable variability and commonality (see Glossary). Common definitions of business rules [e.g., 9] do not include volatile variability as a defining characteristic. Business rules have always been captured and analyzed with other requirements, whether implicitly or explicitly (see [58] for a detailed discussion). In a bifurcated architecture, developers would allocate the prescriptive rules implementing the business rules (see Tables 5.1 and 5.2) to an external repository (file or database; see Figure 5.1) where they can be maintained more efficiently and accurately than when they are embedded in code, because they are treated as data by the system. As external data, the business rules become more accessible for such purposes as analysis, audit, and training. In this way, the Bifurcated Architecture greatly simplifies adaptation in the current domain and extensibility in an evolving domain, because the features most likely to change—represented as business rules—can be easily modified, even in real time.
