Skip to content
#Architecture

An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023 (Category Architecture)

#Architecture #DistributedSystems #SystemDesign #Math #Engineering #SoftwareArchitecture #ComplexityTheory #Software #Processes

Interesting. speech Residuality theory by Barry O'Reilly, author of the theory. The author makes an approach to creating a theory that will help engineers pump into architecture not just by gaining experience, but using the achievements of complexity theory, but without immersing in all its complexity. To do this, the author begins with the definition of ordered and disordered systems, and then he shows how stressors (unknown) It can have a negative impact on architecture. Given the variability of the surrounding world, it is not possible to analyze all the states of the system and the effect of stressors on the system in this state. Therefore, the author proposes to consider the system not as a whole, but to study what remains of the system if there is a p... (stressor X). These residues determine the future of the system and can be used to manage the software architecture. For the modeling of stressors will help us Monte Carlo It's randomized, which we can apply to possible stressors.

Next, the author introduces the attractor They are the stable states into which the system slides. He comes through them. NK model Kauffman. We have a system with N elements that take on meaning. 0 or 1parameter K characterizing connectivity (For example, maximum connections of one element). The point is to show that as N and K grow, we have more attractors in the system. At the same time, there appears a probabilistic characteristic P, which characterizes the bias of the relations between the elements. The final reflection is the derivation of some convex criticality curve that emerges in space N and K, where we play with the number of elements and the connections between them. (Another way to determine the number of services and links between them).

So for every stressor that breaks our initial naive architecture, we come up with a redesign that allows the system architecture to survive the onset of this stressor. By running through all the stressors, we get a cool residual architecture for our system.

Next, the author gives cool examples from the design of the system for managing charging stations for electric vehicles. The guys took into account the corner cases that occur with charging electric cars and this helped to simplify the solution of problems with people who leave to charge cars for the whole day, as well as with guys who were engaged in sabotage. It’s a fun story and I recommend watching it. original.

In the end, the author talks about the compilation of matrices to describe the relationships between the components of the system and stress factors. These matrices help identify non-functional requirements and vulnerabilities in the system. In this matrix, we have stressors in the lines, and the components of the system in the columns. As a result, we analyze for each stressor whether it affects the component. If several components are affected by the same stressor, then they probably have an implicit connection. (implicit coupling)One that would be good to deal with.

In the end, the author gives a way to measure the coolness of our residual architecture compared to its naive version. The pattern looks like we need to count for each stressor. Does our naive architecture survive its onset? Does it survive the residual architecture? From the value of success for residual architecture, subtract the number of successes for naive architecture, and then normalize by the total number of stressors. The resulting number shows how well we as architects have pumped our initial architecture:)

All in all, it sounds quite logical and reminds me of the approach of generative-adversarial networks, but only to architecture. Next, I plan to read the whitepaper.Residuality Theory, random simulation, and attractor networksFrom the author of the report and tell about it:)

#DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes