GSAS Talk: Pragmatic Approach to Architecture Metrics – Part 2

Apiumhub - Aug 28 '23 - - Dev Community

Continuing from Part 1, this article delves deeper into the insights of the talk “Pragmatic Approach to Architecture Metrics” presented by Sonya Natanzon and Vlad Khononov at the Global Software Architecture Summitlast year. This second part of architecture metrics focuses on the concepts of integration strength within software development and modularity.

Integration Strength

Integration strength refers to the degree of interconnectedness and interdependence among various components, modules, or systems.

Implementation Coupling

• How the parts of the system are implemented

• Private interfaces

• Not intended for inter-component integration

Functional Coupling

• Knowledge of what the system has to do

• Business logic

• Use cases

• Rules, invariants, and constraints

Model Coupling

  • Models of the business domain
  • Data structures
  • Software system-related aspects of the business domain
  • Understanding of the functional requirements

Contract Coupling

  • Components’ integration contracts
  • Integration-specific models, APIs
  • The minimal data needed for components to work together

| | Low strength | High strength |
| Low distance | Local Complexity | High cohesion |
| High distance | Loose coupling | Global complexity |

Loose coupling

• High cost of cascading changes

• Low shared knowledge

• Minimizes cascading changes

High cohesion

• High shared knowledge

• Frequent cascading changes

• Low cost of cascading changes

Local complexity

Low cost of cascading changes

• Low shared knowledge

• Co-located unrelated modules

Global complexity

• High cost of cascading changes

• High shared knowledge

• Frequent cascading changes

Modularity = strength XOR distance

When designing software systems, achieving modularity can have an impact on the system’s strength or distance between modules. By breaking down the system into modular components, developers can enhance the strength of each module by focusing on its specific functionality and ensuring its reliability. However, at the same time, there may be a trade-off in terms of the distance between modules, meaning that there might be increased communication or coordination overhead between modules.

It emphasizes the importance of finding the right balance between modularity, strength, and distance in software development. It highlights the need for careful design decisions to optimize the system’s robustness and maintainability while considering the interdependencies and communication requirements between modules.

Applying M=S^D

  1. Minimize integration strength as much as possible

  2. Balance integration strength and distance

• Both are high? — Reduce distance

• Both are low? — Increase distance

Pragmatic Approach to Architecture Metrics in a Nutshell

  1. Business need to evolve and scale should be supported by software architecture’s ability to change on two vectors: frequency and effectiveness

  2. Four metrics that can be used to evaluate the frequency and effectiveness of change: change lead time, deployment frequency, change failure rate, and mean time to recovery

  3. Cost of change is the total of four metrics and is directly correlated to change complexity

  4. Any two connected components share knowledge: implementation, function, model, or contract. The more knowledge is shared between two components, the stronger they are integrated

  5. Modularity = Strength XOR Distance

Some books recommended during the talk Pragmatic Approach to Architecture Metrics were:

CTA Software

Conclusion

Undoubtedly, the “Pragmatic Approach to Architecture Metrics” talk delivered valuable insights that warrant close attention, emphasizing the significance of pragmatism in software development, a factor often overlooked. Sonya and Vlad provided the audience with essential considerations for evaluating software and its potential transformations, encouraging a thoughtful and practical approach to architectural decision-making. It is imperative to grasp these key points, as they contribute to the overall success and sustainability of software projects.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player