Preamble
Enterprises are governed by rules, some set at corporate level, others under external authorities. Whereas the former are set along enterprises objectives and culture, intents for the latter are supposedly detached from specific agendas, making room for interpretative latitudes between the letter and the spirit of the law.
Given the generalization of digital environments and the blurring of enterprises boundaries, information systems are to play a new role between regulations and risks, the former based on reliable information, the latter on partial and uncertain one mined from data.
Enterprise architectures must bring them together if decision-making is to combine compliance policies with risks management.
Regulations: The Need to Know
Enterprises are supposed to conform to rules, some set at corporate level, others by external entities. If one may assume that enterprises have a comprehensive, up-to-date and consistent understanding of the former, that’s not necessary the case for the latter, which means that information and understanding are prerequisites for regulatory compliance :
- Information: the relevant regulations must be identified, collected, and their changes monitored.
- Understanding: the meanings of regulations must be analyzed and the consequences of compliance assessed.
Given the pervasive sources of external regulations and their potentially crippling consequences, the challenge will be to circumscribe the relevant sources and manage their consequences with regard to architectures capabilities.
Regulations & Capabilities
Whatever the nature, scope, or granularity of regulations, compliance policies must be defined with regard to current and planned enterprise capabilities.
That can be done using the well established Zachman’s taxonomy crossing architectures functionalities (Who,What,How, Where, When) and layers (business and organization, systems functionalities, platforms and technologies).
Of particular importance for regulatory impact on architectures is the distinction between actual (aka physical) and symbolic (aka logical) capabilities.
As it’s safe to assume that regulations are to cut across capabilities, the next step is to define the footprints of the rules with regard to domains (what is to be considered) and co-domains (what is to be affected).
Regulations’ Footprint
Insofar as architecture capabilities are concerned, regulations could be characterized by the homogeneity of their footprint. On that account, and taking EU GDPR (General Data Protection Regulation) as an example, four categories are especially relevant:
Symbolic constraints (aka logical) on how data and activities are to be defined:
- Record of data subjects and roles (a).
- Categories of personal data and activities (b).
Symbolic (aka logical) constraints on processing activities (c):
- Consent of data subjects.
- Justification of processing activities.
Execution constraints on processing activities (d):
- Data breaches notification to data subjects.
- Notifications to controllers.
Actual constraints on locations and resources (e)
- Transfers of personal data
- Security of communication channels.
As this classification can be applied to any kind of rules independently of their nature, its generalization could significantly enhance the integration of regulatory constraints, and consequently the transparency and traceability of compliance policies.
Regulations’ Context
Typically, regulations aren’t supposed to take specific capabilities into consideration, which means that, lobbying notwithstanding, adjustments go one way, from authorities to enterprises. But that takes a too narrow perspective because regulations can also be seen as a particular subset in a broader mix of governance-driven and context-defined constraints and rules, to be set and managed according to their context and the nature of their governance:
- Statutory, when set in institutional contexts.
- Agreed upon, when set in professional contexts.
- Governance, when set in corporate contexts.
- Customary, when set in social contexts.
- Specific, when set in personal contexts.
That taxonomy would significantly improve the transparency and traceability of regulations and standards across architecture layers.
Risks: The Will to Know
Risk management being about unknown or partially known circumstances, it can be seen as the opposite of regulatory compliance:
- Information: instead of dealing with well-defined information from trustworthy sources, risk management must process raw data from ill-defined or unreliable origins.
- Understanding: instead of mapping information to existing organization and business logic, risk management will also have to explore possible associations with still potentially unidentified purposes or activities.
In terms of governance risk management can therefore be seen as the symmetric of regulatory compliance: the former relies on processing data into information and expanding the scope of possible consequences, the latter on translating information into knowledge and reducing the scope of possible consequences. The role of business intelligence is to make sense of these threads.
Not surprisingly, that understanding coincides with the traditional view of governance as a decision-making process balancing focus and anticipation.
Decision-making: Framing Risks and Regulations
As noted above, regulatory compliance and risk management rely on different knowledge policies, the former restrictive, the latter inclusive. That distinction also coincides with the type of factors involved and the type of decision-making:
- Regulations are deontic constraints, i.e ones whose assessment is not supposed to be affected by enterprises decision-making. Nonetheless, compliance policies will may try to circumscribe their business footprint.
- Risks are alethic constraints, i.e ones whose assessment is subject to enterprise decision-making. Risks management policies will therefore try to prepare for every contingency.
Yet, once set on a governance perspective, a grey area appears in the black-and-white picture because regulations are not always mandatory, and even mandatory ones may left room for compliance adjustments. And when parts of regulations are elective, compliance is less driven by sanctions or penalties than by opportunity costs and benefits.
Conversely, risks do not necessarily arise from unidentified events and upshots but can also come from well-defined outcomes with uncertain likelihood. Managing the latter will not be very different from dealing with elective regulations except that decisions will be about weighted opportunity costs instead of business alternatives. Similarly, managing risks from unidentified events and upshots can be compared to compliance to mandatory regulations, with insurance policies as compliance costs.
What to Decide: Shifting Sands
As far as large and diversified businesses are concerned, compliance policies encompass portfolios of options combining statutory constraints and business compensations, risks and opportunities, all weighted by variable likelihood and costs.
As regulations can be elective, risks can be interpretative: with business environments morphing into virtual realms, decision-making may easily turns to crisis management driven by conjectural and ephemeral web-driven semantics. In that case ensuing overlaps between regulations and risks can be best-managed if operational intelligence, information systems, and knowledge management are brought into a common decision-making framework:
On the assessment side (a), compliance policies will have to conciliate statutory and managed constraints, the former for arbitrage the latter for business options.
On the prospective side (b), business intelligence would have to determine the opportunities and risks associated with compliance policies, and weight them with regard to costs, returns, and likelihood.
In between (c), governance will have to rely on descriptive, predictive, and prescriptive models ensuring transparency and traceability of options across processes (business and engineering), architecture layers (organizations, functions, operations), and governance issues.
Decision-making processes could then be defined with regard to scope, visibility, and timing:
- Scope of decision-making: mandatory regulations, negotiations, managed alternatives.
- Visibility: accuracy and reliability of information bearing out decision-making for operations, processes, and strategies.
- Timing: time-frame set by the costs of delayed decisions against the benefits of improved visibility.
When to Decide: Last Responsible Moment
Finally, with regulations and risks duly assessed, one have to consider the time-frames of decision-making for compliance and commitments.
That can be neatly expressed using the OODA (Observation, Orientation, Decision, Action) loop:
- Data analytics (a)
- Compliance scope and risks assessment (b).
- Compliance policies (c).
- Commitments (d).
Regarding elective regulations and defined risks, time-frames are set at symbolic (i.e enterprise) level providing that the options can be directly linked to business strategies and policies. That is not to be the case for compliance with mandatory regulations or commitments exposed to undefined risks since both are subject to actual (i.e external) contingencies. Decision-making will have to be timed with regard to both types of time-frames.
On the symbolic side the time-frame of assessments is to depend on the nature of constraints: fixed (regulations), negotiated with business entities, or managed.
On the actual side the time-frame of commitments is to depend on footprints: resources, processes, or assets.
Deciding when to decide should follow the “last responsible moment”, i.e not until taking side could change the possible options:
- Whether elective or mandatory, the “last responsible moment” for compliance decision is static because the parameters are known.
- Whether defined or not, the “last responsible moment” for commitments exposed to risks is dynamic because the parameters are to be reassessed periodically or continuously.
One step ahead along that path of reasoning, the ultimate challenge of regulatory compliance and risk management would be to use the former to steady the latter.
Further Readings
- Thread: Systems, Information, Knowledge
- Data Mining & Requirements Analysis
- Operational Intelligence & Decision Making
- Enterprise Governance & Knowledge
- Risks
- Events & Decision-making
- Sifting through a web of things
- Ontologies & Models
- Caminao Ontological Kernel (Protégé/OWL 2)
- GDPR Ontological Primer
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- EA Documentation: Taking Words for Systems
- Governance, Regulations & Risks
- EA: Entropy Antidote