Variants of services

Towards a new pattern

To increase agility of SOA, we encourage the implementation of organizational rules in a Business Rules Management System (BRMS). This is an architectural pattern that we named “NOA pattern”, stands for Nimble Organizational Architecture. The 'organizational architecture' gathers organizational structures, human resources, business processes, rules regarding organization, etc. and leaves core business rules in an other aspect of the enterprise topology: the core business, also named "semantic aspect" in Praxeme method.

Using NOA pattern, pre- and post-conditions of services that deal with organizational concerns are implemented via rules rather than hard-coded in programming languages. With help from the BRMS, business users and IT specialists may change rules of services without inflations of new software versions. Beyond the NOA pattern, it remains possible to take profit of rules system at other points of the architecture (body of services, core logic business). Indeed, if rules are complex and/or will frequently change, the use of BRMS is candidate. At this stage, the use of BRMS is reliant on people that make the design. This design dependency is not true at the level of NOA pattern since it is an architectural principle.

The BRMS tool allows users to manage numerous rules set that are running according to various contexts of execution: versions, dates, organizations, etc. A same service may have several variants (configurations) according to contexts of its execution. These variants may be functional or technical. Do not confuse variant and version: a variant doesn’t involve a new version of the software, just new rules configurations and data parameterization; version is an actual new version of software, the code has changed. SOA will be actually agile if we are able to manage several variants for each version of service. This agility is achieved by the ACMS principle which gathers MDM, BRMS and BPM.

The powerful of BRMS is limited by lack of attention to data quality

To be nimble, rules must be written without hard-coding! More precisely, if reference data and parameters that are utilized by rules are hard-coded then rules will not be agile enough. Each new variant of reference data and parameters would involve a copy / paste of rules! It is more relevant to foresee a binding between rules and databases that contain the reference data and parameters. Unfortunately, in most cases, these data and parameters are scattered across existing information systems and their quality is bad: data duplication with different values (not one version of the truth for reference data), several data structures of same data (lack of “Canonical Information Model”), etc.

To fix this problem, we may try either to build several connectors between the BRMS and existing databases or copy reference data and parameters into the BRMS repository with enumeration types and/or decision tables. These approaches are not sustainable because connectors are complex to maintain and data replication is not easy. Furthermore, the quality of reference data and parameters is still reliant on the quality of its patrimony. Low data quality means low rules quality!

The MDM leverages BRMS capabilities in SOA landscape

A more reliable architecture is based on Master Data Management (MDM).

MDM provides us with a central data repository that manages reference data and parameters. This solution enhances data quality and relies on a complete data governance: one version of the truth for reference data and parameters, strong Common Information Model (CIM), versionning data, a user friendly tool to enter and validate data by contexts (data may have several values according to contexts of utilization: versions, dates, organizations, channels, etc.), permission management, etc.

Once MDM solution is ready to use, we can provide the BRMS with a single point of contact to retrieve reference data and parameters that are utilized by rules. Moreover, with help from the context management featured by the MDM, rules may handle different values of reference data and parameters according to various contexts of execution (version, data, organization, channel…). Rules are nimbler than before! The Master Data Management leverages BRMS at a large-scale of information systems. Point-to-Point connections to reference data and parameters (spaghetti approach) are removed.

With help from the ACMS principle: no processes without rules and no rules without reference data and parameters management. See more about ACMS in our book "Sustainable IT Architecture" and here.

Pierre Bonnet - Reponsible for S-IT-A community
To put remarks, please use our group.