System Design System Design

My notes from the pdf

  1. Source : https://dl.feenk.com/docs/2021-03-20-feenk-explainable-systems.pdf
  2. You do not lack the ability to solve the problem. You lack the ability to see the problem.
  3. Visualizing the system reveals a different picture.
  4. It becomes evident that tackling the code in isolation is not the appropriate path.
  5. If the original diagram was someone’s view or opinion, this picture represents reality.
  6. Of course, this is just one case. Making problems tangible is a skill you want to be available all the time. All facets of a system can be made explainable.
  7. When we think of software development, we often think of the active part of creating the system. Yet, the largest cost is spent on assessing the current state of the system. Developers alone spend 50% or more of their time reading code to know what to do next. These are only the direct costs. The indirect costs can be seen in the consequences of the made decisions.
  8. Figuring out the system is the single most expensive activity in development.
  9. How explanations are created matters. They are useful only when they relate to reality.
  10. Put it into perspective: Your system is much larger than humans can read in a reasonable amount of time.
  11. All decisions about your system must relate to the reality of that system. Everyone must care about how reliable and representative the information is.
  12. software assessment becomes a strategic skill.
  13. It’s like data science for software. Automating how information is gathered from the system reduces risks and frees energy that can be used for experimenting and acting.
  14. You want automation that serves that context because that is where value is.
  15. Screenshot 2021-09-14 at 12.51.08 PM
  16. As the ability to change is of critical importance, it follows that the architecture becomes a business asset. And, like any business asset, you should treat it as an investment, too.
  17. Explain your architecture explicitly. Steering it is a continuous investment. 18. The only architecture that matters is the one that gets reflected in code. A key challenge is to steer the architecture while the code changes continuously. This implies at least three things:
    1. know where you are,
    2. choose where you want to go,
    3. ensure you go there.
    
    1. Explain the strategic problems that make a difference.
    2. Architecture is a commons; a negotiation between different perspectives. Design the organization to facilitate this negotiation explicitly.
    3. In this standup only people that have data-based results can speak.
  18. Explain your understanding of the domain in an executable form.
    1. The domain knowledge is too often buried in implementation details.
    2. . A domain-driven ubiquitous language is important for bridging the gap between business and technology.
  19. Explainability is not a recipe. It is a systematic discipline requiring dedicated skills.
  20. Scenario: Guiding a migration
    1. Migrations are alluring. And they are risky. The are alluring because of the promise of the new technology. They are risky because of the messy reality of the existing system. Yet, the success of a migration depends on the ability to assess that reality.
    2. Migrations are indeed risky, but the risks can be mitigated when they are visible.
  21. Scenario: Splitting a monolithic application
    1. The splitting strategy must not only take into account the functional side of the system, but its internal structure, too.
    2. The clusters reveal splitting options.
  22. feenk
    1. . A new system requires discovery guided by a ubiquitous language that bridges the technical and business worlds
    2. We are consultants. We are researchers. We are authors. We bring a unique experience. We cover the whole spectrum, from a single line of code to decisions made at the company executive level. Our work is based on state-of-the-art scientific work, much of which we personally authored. We actively create new tools and techniques for thinking with and about software systems. Our work has been validated for more than a decade of working with highly difficult problems in legacy systems.
  23. Glamous Toolkit
    1. . It is a software analysis platform. A live notebook. A knowledge management platform. A rich visualization engine. A powerful query tool. A fancy editor.

Referenced in:

All notes