A key tenant of good software design is to separate the definition of a ‘thing’ (in technical terms an abstraction) - what it is and what it does - from the specifics of how it works or how it is implemented. In this way, your code works with (or depends on) the definition of a ‘thing’ rather than how the ‘thing’ works - making your code easier to understand and more adaptable to change.
Here’s a real-world analogy. Consider the concept of insurance (any type). The definition of the insurance that is provided is defined in a policy. How a policy is executed varies by the insurance provider, but this is irrelevant to the insured. They only work with or depend upon the definition provided by the policy. This separation of definition and implementation makes it easy for them to compare policies offered by different insurance providers so that they can choose the policy that best meets their goals. It also allows the insurance provider to execute the policy in a way that is the most cost-effective to them, without disrupting the terms provided by the policy and thus the goals of the insured.
This same approach should be taken with your business rules for data. Typically though, business rules are defined and implemented together - within the business systems, processes, and stewardship processes (data agents) that touch your data. This approach increases complexity and limits flexibility. Consider when you migrate aging business systems to modern systems in the cloud, you have to understand and translate all of your rules from the proprietary implementation of the old system to that of the new system - increasing the time and risk to the data migration project. But much of the time, the context around the rule (such as why it was put in place to begin with) is not captured in the data agent, making it harder to properly migrate data.
Or consider if your business is called upon to demonstrate compliance with the General Data Protection Regulation (GDPR), the Regulation mandates that any data that can be used to identify a citizen or resident of the European Union, "personal data," must be kept up-to-date and accurate, thus requiring the enforcement of business rules. Since personal data likely exists across a wide variety of your data agents, you’d have to locate and examine them all to demonstrate whether or not you are taking the proper steps to comply with the Regulation. That’s time-consuming, and most likely, a single rule is not defined consistently across these enforcement agents, making it difficult to ascertain what the rule is actually supposed to do.
This approach also limits your strategic flexibility. You end up forcing your business strategy to depend on the technical aspects of data agents, rather than on aspects of the business that carry out the strategy. This limits your ability to connect the business strategy to activities in data and shape it so that it impacts business results.
A better approach would be to separate the definition of business rules from the way in which they are implemented in data agents. With our Information Governance Cloud, you define all your business rules once in a single place, and then orchestrate their implementation across the data agent technologies that meet your needs. The rules are system agnostic, and they are defined in natural language and business terminology that all data contributors understand. With a clear specification of a rule, your technical resources, be them people or machines, then implement them within your data agents. In this way, a clear definition of a business rule can stay the same even as data agents that implement the rule change and evolve.
A variety of contextual information about the rule is captured in its definition - such as the implications for the business and its owner if the rule is violated. And, you can directly link a rule to defined business goals that the rule supports, thus maintaining alignment between business goals and activities in data.
As an example, the Information Governance Cloud provides you with a single location within which you define a business goal of compliance with the GDPR. Directly link to the supporting business rules that define quality requirements for personal data and you can see that they are implemented within all of your data agents across all organizations of your business. This dramatically simplifies compliance efforts.
System agnostic business rules all in one place and aligned with your business strategy leads to better data. And ultimately, better data results in better business.
About the AuthorMore Content by Kevin Larsen