March 2, 2016

Principle-based Architecture: What We Can Learn from the Regulatory World

BY :     March 2, 2016

Which is the better principle: all data exchange must be secure or all electronic messages must be encrypted by P2PE? Principles are a very powerful mechanism to communicate and apply architectural directions. Carefully formulated principles are well-understood by all stakeholders and provide clear direction to decision making and design. It is not easy, however, to arrive at a well-balanced set of principles that sufficiently covers all relevant topics. One of the questions I am asked frequently, is: how many principles do we need and how detailed should they be?

I am a great fan of looking at other disciplines for finding answers to impossible questions. And I was delighted when my colleague, Ton Eusterbrock, pointed out that, within the regulatory world, a debate is going on, discussing the respective merits of  a principle-based approach versus a rule-based approach. The distinction is summarized in an inspiring paper by Burgemeestre et al. [1].

The core distinction is that rules are more specific than principles. Principles express a desired outcome: data exchange must be secure. Rules express a way of achieving a desired outcome: all messages must be encrypted. Thus, a rule can be seen as an operationalization of a principle. Usually, one of various possible operationalizations. Burgemeestre et al. discuss a number of differences between the use of principles and rules. For one thing, principles usually last longer than rules: means change faster than desired outcomes. Also, compliance checking differs between the two. Whether an organization complies with a principle, can only be checked after the organization has translated the principle into measures (rules) that fit the specific context of the organization. This also implies that the organization needs to possess the requisite knowledge to make this translation. In the case of centrally defined rules, the organization applying the rules needs less knowledge and it is clear beforehand how compliance will be achieved.

One of the conclusions in Burgemeestre et al. is that regulatory directives can be positioned on a continuum ranging from abstract principles to detailed rules.

Doing this for each directive, provides us with insight into the nature of the total set of directives.

In my previous blog I argued that architects must start to focus on differentiation instead of uniformation. Translating the ideas of Burgemeestre et al. to architecture and regarding architectural directives as being on a continuum, offers a perspective that supports this need for differentiation. The principle-side of the continuum holds for the organization as a whole. It reflects the desired outcomes of the architecture. It needs a fair amount of interpretation to be applied in specific contexts. The rule-side of the continuum is very specific and needs little interpretation to be applied. This is probably very efficient in predictive and stable environments, but too restrictive in unpredictive and changeable environments. Hence the conclusion that we must differentiate between the areas for which we want to centrally translate principles into rules and the areas for which we want to leave the situation-specific translation to the designers.

 

One limited set of principles, defined at enterprise level, may spawn off a number of different sets of rules, each set applicable to its own subsystem of the organisation. Depending on circumstances, some of these rule sets are defined centrally by the architects, while others are defined locally by the area specialists.

Interesting? Ton and I think it is. That’s why we worked out the idea in a white paper. Of course, we are very much interested to hear what you think of it.

References:

[1] Rule-based versus Principle-based regulatory compliance. Burgemeestre, Brigitte, Hulstijn, Joris en Tan, Yao-Hua. Vrije Universiteit Amsterdam, 2009, http://homepage.tudelft.nl/w98h5/Articles/jurix.pdf

[2] Principle-based approach in Enterprise Architecture practice; finding the sweet spot. Eusterbrock, Ton and Steenbergen, Marlies van, Sogeti, 2016. Published on 4th of March

 

Marlies van Steenbergen

About

Marlies van Steenbergen started her career with Sogeti Netherlands in the role of service manager enterprise architecture in 2000. After working as a consultant for a few years, she became Principal Consultant Enterprise Architecture in 2004. In this role, she is responsible for stimulating and guaranteeing the development of the architectural competence of Sogeti Netherlands. Since 2012 she is the main proponent of enterprise architecture and DYA within Sogeti Netherlands.

More on Marlies van Steenbergen.

Related Posts

Your email address will not be published. Required fields are marked *

8 + 3 =


    *Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group