Kevlin Henney - Architecture as Knowledge

Transcript

1. @KevlinHenney Architecture as Knowledge
2. Kevlin Henney @KevlinHenney @kevlin@mastodon.social about.me/kevlin linkedin.com/in/kevlin kevlinhenney.medium.com kevlin@curbralan.com
6. To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge. Grace Hopper
9. We demand rigidly defined areas of doubt and uncertainty!
10. A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable. Leslie Lamport
11. twitter.com/cdmo/status/1188806227079389184
19. x p  h 2 _
21. 0. lack of ignorance 1. lack of knowledge 2. lack of awareness 3. lack of process 4. meta-ignorance Phillip G Armour Five Orders of Ignorance
22. 0. lack of ignorance 1. lack of knowledge 2. lack of awareness 3. lack of process Phillip G Armour Five Orders of Ignorance
23. known knowns known unknowns unknown unknowns unknowable unknowns
24. known knowns known unknowns unknown unknowns unknowable unknowns
25. I know that I know nothing. Socrates * Possibly *
26. known knowns known unknowns unknown unknowns unknowable unknowns
27. The planning fallacy is a cognitive bias first proposed by Daniel Kahneman and Amos Tversky in 1979. They defined this phenomenon as “the tendency to underestimate the amount of time needed to complete a future task, due in part to the reliance on overly optimistic performance scenarios.” entrepreneur.com/article/350045
29. The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. Douglas Ross
30. And that is where most of our troubles come from. Douglas Ross
31. The design process is an iterative one. Andy Kinslow
33. Plan Do Act Study
34. Plan Do Act Check
35. Plan Do Act Study
36. Plan Do Adjust Study
37. You have to finish things — that’s what you learn from, you learn by finishing things. Neil Gaiman
38. known knowns known unknowns unknown unknowns unknowable unknowns
40. Driverless racecar drives straight into a wall reddit.com/r/formula1/comments/jk9jrg/ot_roborace_driverless_racecar_drives_straight So during this initialization lap something happened which apparently caused the steering control signal to go to NaN and subsequently the steering locked to the maximum value to the right.
41. twitter.com/KevlinHenney/status/1252952622128128000
42. The connections between modules are the assumptions which the modules make about each other. David Parnas “Information Distribution Aspects of Design Methodology”
44. Our position is that an architectural definition is something that answers three questions: ▪ What are the structural elements of the system? ▪ How are they related to each other? ▪ What are the underlying principles and rationale that guide the answers to the previous two questions?
45. One of the hardest things to track during the life of a project is the motivation behind certain decisions. A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision. Michael Nygard cognitect.com/blog/2011/11/15/documenting-architecture-decisions
46. Without understanding the rationale or consequences, this person has only two choices: 1. Blindly accept the decision. 2. Blindly change it. It’s better to avoid either blind acceptance or blind reversal. Michael Nygard cognitect.com/blog/2011/11/15/documenting-architecture-decisions
47. We will keep a collection of records for “architecturally significant” decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques. Michael Nygard cognitect.com/blog/2011/11/15/documenting-architecture-decisions
48. An architecture decision record is a short text file in a format similar to an Alexandrian pattern. Each record describes a set of forces and a single decision in response to those forces. Note that the decision is the central piece here, so specific forces may appear in multiple ADRs. Michael Nygard cognitect.com/blog/2011/11/15/documenting-architecture-decisions
49. «system» Library Member Librarian ▪ A member can borrow up to 10 books at a time ▪ A member cannot borrow any more books if they have any overdue loans ▪ A book loan lasts for 4 weeks before becoming overdue ▪ When an overdue book is returned, the member is fined an amount based on the number of days overdue ▪ Members can pay off all or part of their balance of fines ▪ A loan can be renewed up to 3 times by a member ▪ A librarian is responsible for registering new members with the system ▪ A librarian is responsible for registering new books with the system ▪ Persistence is based on an in-memory database that maps directly to the object model of the library ▪ Security is with respect to the OS
50. «system» Library Member Librarian Feature Backlog ▪ Support child membership for the library — children pay less for overdue books ▪ Add a reference section to the library, with books that remain in the library and cannot be borrowed ▪ Support additional services for members at the library, such as email access ▪ Add other media for borrowing, such as DVDs ▪ Allow members to reserve books that are not currently available for loan ▪ ...
51. Loan Member Book Library System * * * 1 1 1 1 1 * 0..1
52. Loan Member Book Member Manager Loan Manager Book Manager Library System * 1 * 1 * 1 1 1 1 1 1 1 1 1 * 0..1
53. Loan Member Book Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 * 0..1
54. Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0..1 There will be more classes than shown here, such as for simple value types (e.g., ISBN, money, date) and exceptions, as well as infrastructure classes
55. Which packaging (A or B) would be best for the library system? Feature Backlog ▪ Support child membership for the library — children pay less for overdue books ▪ Add a reference section to the library, with books that remain in the library and cannot be borrowed ▪ Support additional services for members at the library, such as email access ▪ Add other media for borrowing, such as DVDs ▪ Allow members to reserve books that are not currently available for loan ▪ ... Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0 . . 1 A Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0 . . 1 B
56. Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0 . . 1 B is the most appropriate packaging, because the changes () listed in the backlog will be more localised. Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0 . . 1 Feature Backlog ▪ Support child membership for the library — children pay less for overdue books ▪ Add a reference section to the library, with books that remain in the library and cannot be borrowed ▪ Support additional services for members at the library, such as email access ▪ Add other media for borrowing, such as DVDs ▪ Allow members to reserve books that are not currently available for loan ▪ ... A B                           
57. Main Catalogue Loans Members Loan Member Book Copy Book Title Membership Loaning Catalogue Library * 1 * 1 * 1 1 1 1 1 1 1 1 1 1 * * 0..1
58. # Title Partition packages according to subdomain ## Context We are developing a library system and have an object model that contains classes for members, loans, book copies and book titles, the core of the model, plus library and associated aggregate management objects for membership, loaning and catalogue. We can package according to technical role or 'layer' in system, i.e., have a manager layer above the entity layer, or we can package according to the subdomain, e.g., membership, loaning and catalogue. ## Decision We partition the packages according to the subdomain, because this is most likely to localise changes already found in the backlog, i.e., changes are localised to membership or to catalogue rather than cutting through all layers. ## Status Accepted ## Consequences - Local package and, therefore, deployment stability in the face of most anticipated changes. - Some responsibilities can be easily moved from entity to aggregate or vice versa without affecting other packages. - As it stands, this design results in cyclic dependencies between packages. - If we change manager or entity policy, that will affect more packages than the alternative design.
59. Title Partition packages according to subdomain Context We are developing a library system and have an object model that contains classes for members, loans, book copies and book titles, the core of the model, plus library and associated aggregate management objects for membership, loaning and catalogue. We can package according to technical role or 'layer' in system, i.e., have a manager layer above the entity layer, or we can package according to the subdomain, e.g., membership, loaning and catalogue. Decision We partition the packages according to the subdomain, because this is most likely to localise changes already found in the backlog, i.e., changes are localised to membership or to catalogue rather than cutting through all layers. Status Accepted Consequences ▪ Local package and, therefore, deployment stability in the face of most anticipated changes. ▪ Some responsibilities can be easily moved from entity to aggregate or vice versa without affecting other packages. ▪ As it stands, this design results in cyclic dependencies between packages. ▪ If we change manager or entity policy, that will affect more packages than the alternative design.
60. Title Partition packages according to the technical role of classes Context We are developing a library system and have an object model that contains classes for members, loans, book copies and book titles, the core of the model, plus library and associated aggregate management objects for membership, loaning and catalogue. We can package according to technical role or 'layer' in system, i.e., have a manager layer above the entity layer, or we can package according to the subdomain, e.g., membership, loaning and catalogue. Decision We partition the packages according to the technical role, i.e., the relative layer in the code, because this groups similar code concepts, styles and dependencies together: manager objects are separated from entity objects, which are a lower layer. Status Rejected Consequences ▪ Changes to manager or entity policy are localised with respect to a manager package or entity package. ▪ The system, manager and entity packages form a strict hierarchy, with no cyclic dependencies between packages. ▪ Changing responsibilities between managers and entities will affect both packages. ▪ All packages will be affected — and hence have to be redeployed — for any of the anticipated changes.
62. When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes “How do I design so that the choice between A and B is less significant?” The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B. Kevlin Henney “Use Uncertainty As a Driver” kevlinhenney.medium.com/https-medium-com-kevlinhenney-use-uncertainty-as-a-driver-493ebebd575d
63. We propose [...] that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. David Parnas “Information Distribution Aspects of Design Methodology”
64. known knowns known unknowns unknown unknowns unknowable unknowns
65. All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. Grady Booch
66. Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other. Ralph Johnson
67. Niels Bohr * Possibly * Prediction is very difficult, especially about the future.
68. slideteam.net/roadmap-seven-c1304-ppt-powerpoint-presentation-infographic-template.html
70. slidemodel.com/templates/curved-roadmap-poles-milestones-powerpoint-timeline/
71. prioritise by business value
72. prioritise by estimated business value
74. Responding to change over following a plan
76. Properly gaining control of the design process tends to feel like one is losing control of the design process.