Created
January 2, 2024 06:44
-
-
Save tvhong/8249259d10e80c466c5e263e370c17ae to your computer and use it in GitHub Desktop.
Kindle Notes for Hohpe2020
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?xml version="1.0" encoding="UTF-8"?> | |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "XHTML1-s.dtd" > | |
| <html xmlns="http://www.w3.org/TR/1999/REC-html-in-xml" xml:lang="en" lang="en"> | |
| <head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></meta> | |
| <style> | |
| .bodyContainer { | |
| font-family: Arial, Helvetica, sans-serif; | |
| text-align: center; | |
| padding-left: 32px; | |
| padding-right: 32px; | |
| } | |
| .notebookFor { | |
| font-size: 18px; | |
| font-weight: 700; | |
| text-align: center; | |
| color: rgb(119, 119, 119); | |
| margin: 24px 0px 0px; | |
| padding: 0px; | |
| } | |
| .bookTitle { | |
| font-size: 32px; | |
| font-weight: 700; | |
| text-align: center; | |
| color: #333333; | |
| margin-top: 22px; | |
| padding: 0px; | |
| } | |
| .authors { | |
| font-size: 13px; | |
| font-weight: 700; | |
| text-align: center; | |
| color: rgb(119, 119, 119); | |
| margin-top: 22px; | |
| margin-bottom: 24px; | |
| padding: 0px; | |
| } | |
| .sectionHeading { | |
| font-size: 24px; | |
| font-weight: 700; | |
| text-align: left; | |
| color: #333333; | |
| margin-top: 24px; | |
| padding: 0px; | |
| } | |
| .noteHeading { | |
| font-size: 18px; | |
| font-weight: 700; | |
| text-align: left; | |
| color: #333333; | |
| margin-top: 20px; | |
| padding: 0px; | |
| } | |
| .noteText { | |
| font-size: 18px; | |
| font-weight: 500; | |
| text-align: left; | |
| color: #333333; | |
| margin: 2px 0px 0px; | |
| padding: 0px; | |
| } | |
| .highlight_blue { | |
| color: rgb(178, 205, 251); | |
| } | |
| .highlight_orange { | |
| color: #ffd7ae; | |
| } | |
| .highlight_pink { | |
| color: rgb(255, 191, 206); | |
| } | |
| .highlight_yellow { | |
| color: rgb(247, 206, 0); | |
| } | |
| .notebookGraphic { | |
| margin-top: 10px; | |
| text-align: left; | |
| } | |
| .notebookGraphic img { | |
| -o-box-shadow: 0px 0px 5px #888; | |
| -icab-box-shadow: 0px 0px 5px #888; | |
| -khtml-box-shadow: 0px 0px 5px #888; | |
| -moz-box-shadow: 0px 0px 5px #888; | |
| -webkit-box-shadow: 0px 0px 5px #888; | |
| box-shadow: 0px 0px 5px #888; | |
| max-width: 100%; | |
| height: auto; | |
| } | |
| hr { | |
| border: 0px none; | |
| height: 1px; | |
| background: none repeat scroll 0% 0% rgb(221, 221, 221); | |
| } | |
| </style> | |
| </head> | |
| <body> | |
| <div class='bodyContainer'> | |
| <h1><div class='notebookFor'>Notes and highlights for</div><div class='bookTitle'>hohpe2020_software_architect_elevator | |
| </div><div class='authors'> | |
| Gregor Hohpe | |
| </div></h1><hr/> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Location 14</div><div class='noteText'>roles. Any person outside of the architecture practice, especially the ones dealing with architects, will benefit from reading this book</h3> | |
| <h3 class='noteHeading'>Note - Location 15</div><div class='noteText'>oiohoo</h3> | |
| <h2 class='sectionHeading'>Foreword by David Knott</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Location 91</div><div class='noteText'>Architecture has been intermittently in and out of fashion within enterprise technology, and architects are sometimes accused of “not making anything.” I believe that architects make two things that are of vital importance and in short supply: they make sense and they make decisions. Whenever architects help their organizations understand a world that is increasingly difficult to grasp, figure out what decisions need to be taken, and help take those decisions in a rational way at the right time, then they have had a good day at the office. And, as this book explains, if you’re not taking meaningful decisions (see Chapter 6), making them explicit, and helping people understand them, you’re not doing architecture.</h3> | |
| <h3 class='noteHeading'>Note - Location 96</div><div class='noteText'>What does an architect make?</h3> | |
| <h2 class='sectionHeading'>About This Book</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - A Chief Architect’s Life: It’s Not That Lonely at the Top > Location 127</div><div class='noteText'>lot is expected from IT leaders and chief architects: they must maneuver in an organization in which IT is often still seen as a cost center, operations means “run” as opposed to “change,” and middle management has become cozy neither understanding the business strategy nor the underlying technology. All the while they are expected to stay up to date with the latest technology, manage vendors, translate buzzwords into a solid strategy, and recruit top talent.</h3> | |
| <h3 class='noteHeading'>Note - A Chief Architect’s Life: It’s Not That Lonely at the Top > Location 130</div><div class='noteText'>What are expected of an architect?</h3> | |
| <h2 class='sectionHeading'>I. Architects</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Architects Deal with Nonrequirements > Location 278</div><div class='noteText'>It’s commonly assumed that developers deal with functional requirements, whereas architects deal with nonfunctional requirements, often referred to as the “ilities”: scalability, maintainability, availability, interoperability, and so on.</h3> | |
| <h2 class='sectionHeading'>1. The Architect Elevator</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Location 339</div><div class='noteText'>Many layers of management only exacerbate the problem as communicating up and down the corporate ladder resembles the telephone game.1 The worst-case scenario materializes when people holding relevant information or expertise aren’t empowered to make decisions, whereas the decision makers lack relevant information.</h3> | |
| <h3 class='noteHeading'>Note - Location 342</div><div class='noteText'>Who should make decisions?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Some Organizations Have More Floors Than Others > Location 363</div><div class='noteText'></h3> | |
| <h3 class='noteHeading'>Note - Some Organizations Have More Floors Than Others > Location 364</div><div class='noteText'>What failure mode does this prevent? ALso, doesn't that mean small or flat orgs don't need an architect?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Not a One-Way Street > Location 387</div><div class='noteText'>Allowing architects to only enjoy the view from high up invariably leads to the dreaded authority without responsibility antipattern.2 This pattern can be broken only if architects have to live with, or at least observe, the consequences of their decisions.</h3> | |
| <h3 class='noteHeading'>Note - Not a One-Way Street > Location 390</div><div class='noteText'>Is this the same as Kosta's comment for the managers?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Dangers of Riding the Elevator > Location 429</div><div class='noteText'>I was once criticized by the engine room for pushing corporate agenda against the will of the developers while at the same time corporate leadership chastised me for wanting to try new solutions just for fun. Ironically, this likely meant I found a good balance.</h3> | |
| <h3 class='noteHeading'>Note - The Dangers of Riding the Elevator > Location 431</div><div class='noteText'>What are the forces of the engine room and the penthouse?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Dangers of Riding the Elevator > Location 438</div><div class='noteText'>Other corporate denizens not content with you riding the elevator can be found on the middle floors: seeing you whiz by to connect leadership and the engine room makes them feel bypassed. Thus, the organization has an “hourglass” shape of appreciation for your work: top management sees you as a critical transformation enabler, whereas the folks in the engine room are happy to have someone to talk to who actually understands and appreciates their work. The folks in the middle, though, see you as a threat to their livelihood, including their children’s education and their vacation home in the mountains. This is a delicate affair. Some might even actively block you on your way: being stopped at every floor to give an explanation—aka aligning (Chapter 30)—makes riding the elevator not really faster than taking the stairs.</h3> | |
| <h3 class='noteHeading'>Note - The Dangers of Riding the Elevator > Location 446</div><div class='noteText'>What is the solution for this?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Flattening the Building > Location 456</div><div class='noteText'>Flattening the building little by little can be a sound long-term strategy, but it would take too long because it requires fundamental changes to the company culture. It also changes or eliminates the role played by the folks inhabiting the middle floors, who will put up a fierce resistance. This isn’t a fight an architect can win. However, an architect can start to loosen things up a little bit; for example, by getting the penthouse interested in information from the engine room or by providing faster feedback loops.</h3> | |
| <h3 class='noteHeading'>Note - Flattening the Building > Location 460</div><div class='noteText'>I like how he knows which battle to fight and not aspire to do everything</h3> | |
| <h2 class='sectionHeading'>3. Architects Live in the First Derivative</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Rate of Change Defines Architecture > Location 571</div><div class='noteText'>Although as an architect this isn’t a natural question to ask (nor to answer), it can reveal what system property makes architecture valuable. In my mind, the only system that wouldn’t benefit from architecture is one that doesn’t change at all. If everything about a system is 100% fixed, just getting it working somehow seems good enough.</h3> | |
| <h3 class='noteHeading'>Note - Rate of Change Defines Architecture > Location 573</div><div class='noteText'>When do we need an architect?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Change = Business as Unusual? > Location 591</div><div class='noteText'>Thus, many organizational systems are designed to control and prevent change: budgeting processes limit spending on change; quality gates limit changes going to production; project planning and requirements documents limit scope changes. Transforming a software delivery organization such that it embraces constant change requires adjusting these processes to support rather than prevent change without ignoring the (generally useful) motivation for setting them up in the first place. That’s not an easy task and is the reason why this book devotes an entire part to transformation (Part V).</h3> | |
| <h3 class='noteHeading'>Note - Change = Business as Unusual? > Location 595</div><div class='noteText'>This is interesting idea on change vs project planning.</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Confidence Brings Speed > Location 654</div><div class='noteText'>If fear slows you down, confidence should speed you up. Automated tests do just that: they give teams confidence and thus increase the rate of change. That’s why determining whether a system has sufficient test coverage shouldn’t be measured in the percentage of lines of code covered. Rather, it should be measured by whether teams can make changes confidently.</h3> | |
| <h3 class='noteHeading'>Note - Confidence Brings Speed > Location 656</div><div class='noteText'>How does the author suggest measuring code coverage?</h3> | |
| <h2 class='sectionHeading'>5. An Architect Stands on Three Legs</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Skill, Impact, Leadership > Location 865</div><div class='noteText'>When asked to characterize the seniority of an architect, I apply a simple framework: a successful architect must stand on three “legs”: Skill The foundation for practicing architects. It requires knowledge and the ability to apply it to solve real problems. Impact The measure of how well an architect applies his or her skill to benefit the company. Leadership Determines whether an architect advances the state of the practice.</h3> | |
| <h3 class='noteHeading'>Note - Skill, Impact, Leadership > Location 870</div><div class='noteText'>How does the author evaluate architects?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Skill, Impact, Leadership > Location 882</div><div class='noteText'>Knowledge is like having a drawer chest full of tools. Skill implies knowing when to open which drawer and which tool to use.</h3> | |
| <h3 class='noteHeading'>Note - Skill, Impact, Leadership > Location 883</div><div class='noteText'>What is knowledge vs tools?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Skill, Impact, Leadership > Location 885</div><div class='noteText'>Impact is measured by the benefit achieved for the business, usually in form of additional revenue or reduced cost. Faster times to market or the ability to incorporate unforeseen requirements late in the product cycle also positively affect revenue and therefore count as impact.</h3> | |
| <h3 class='noteHeading'>Note - Skill, Impact, Leadership > Location 887</div><div class='noteText'>How to measure impact?</h3> | |
| <h2 class='sectionHeading'>6. Making Decisions</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Model Thinking > Location 1087</div><div class='noteText'>The best overview of models and their application I have come across is Scott Page’s Coursera course on Model Thinking. He also recently published the content in his book The Model Thinker.6</h3> | |
| <h3 class='noteHeading'>Note - Model Thinking > Location 1089</div><div class='noteText'>Good model to learn about decision making</h3> | |
| <h2 class='sectionHeading'>7. Question Everything</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Whys Reveal Decisions and Assumptions > Location 1179</div><div class='noteText'>An architecture review is not only looking to validate the results but also the thinking and decisions behind it all. To emphasize this fact, one should request an architecture decision record1 from any team submitting an architecture for review.</h3> | |
| <h3 class='noteHeading'>Note - Whys Reveal Decisions and Assumptions > Location 1182</div><div class='noteText'>What is an assumption decision record? How can it help with architecture reviews?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Whys Reveal Decisions and Assumptions > Location 1186</div><div class='noteText'>If you want to change the behavior of the organization, you often need to identify and overcome outdated assumptions first (Chapter 26).</h3> | |
| <h3 class='noteHeading'>Note - Whys Reveal Decisions and Assumptions > Location 1188</div><div class='noteText'>What else is missing wrt changing an org?</h3> | |
| <h2 class='sectionHeading'>II. Architecture</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Beyond Software Architecture > Location 1234</div><div class='noteText'>In my view, this covers only one aspect of architecture. First, IT architecture is much more than software architecture: unless you outsourced all your IT infrastructure into the public cloud, you need to architect networks, datacenters, computing infrastructure, storage, and much more. And even if you did, you still need a deployment architecture, a data architecture, and a security architecture. Second, defining which “components” you are focusing on constitutes a significant aspect of architecture.</h3> | |
| <h3 class='noteHeading'>Note - Beyond Software Architecture > Location 1237</div><div class='noteText'>WHat other types of arcvitecture exists beside software?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Principles Drive Decisions > Location 1277</div><div class='noteText'>Architects should also strive for conceptual integrity, that is, uniformity across system designs. This is best accomplished by selecting a well-defined set of architecture principles that are consistently applied to architectural decisions. Deriving these principles from a declared architecture strategy assures that the decisions support the strategy.</h3> | |
| <h3 class='noteHeading'>Note - Principles Drive Decisions > Location 1279</div><div class='noteText'>How are architecture priciples and strategy differ?</h3> | |
| <h2 class='sectionHeading'>8. Is This Architecture?</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Fit for Purpose > Location 1401</div><div class='noteText'>Assessing the context and identifying implicit constraints or assumptions in proposed designs is an architect’s key responsibility. Architects are commonly described as the people dealing with nonfunctional requirements. I generally refer to hidden assumptions as nonrequirements—requirements that were never explicitly stated</h3> | |
| <h3 class='noteHeading'>Note - Fit for Purpose > Location 1405</div><div class='noteText'>How does hidden assumption play into the role of an architect?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Passing the Test > Location 1411</div><div class='noteText'>Systems architecture doesn’t need to be something terribly complicated. It must include, however, significant decisions that are well documented and are based on a clear rationale.</h3> | |
| <h3 class='noteHeading'>Note - Passing the Test > Location 1412</div><div class='noteText'>WHat is the author's test on what is considered an architecture?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Passing the Test > Location 1415</div><div class='noteText'>Instead, when discussing architectures, let’s talk about what isn’t obvious. For example, “do you use a service layer and why?” (some people may find even this obvious) or “why are you spreading your application across multiple cloud providers?” A good test is whether the chosen option also has downsides—decisions without downsides are unlikely to be meaningful.</h3> | |
| <h3 class='noteHeading'>Note - Passing the Test > Location 1417</div><div class='noteText'>How to tell if a decision is obvious or not?</h3> | |
| <h2 class='sectionHeading'>9. Architecture Is Selling Options</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Reversing Irreversible Decision Making > Location 1457</div><div class='noteText'>Martin Fowler concluded some time ago that the opposite is actually true: “one of an architect’s most important tasks is to eliminate irreversibility in software designs.”1 So, instead of entrusting all crucial decisions to one person, a project can be better off by minimizing the number of early and irreversible decisions.</h3> | |
| <h3 class='noteHeading'>Note - Reversing Irreversible Decision Making > Location 1460</div><div class='noteText'>What is the best thing to do about one-way door decisions?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Deferring Decisions with Options > Location 1472</div><div class='noteText'>Decision making is a common activity in financial services, especially in stock trading. Buying shares in a company requires you to put up cash now in hopes of a future return—somewhat</h3> | |
| <h3 class='noteHeading'>Note - Deferring Decisions with Options > Location 1473</div><div class='noteText'>WHat is the core idea of architects sell options? WHat does price represent? What represent the curent price? Wt about strike price? </h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Deferring Decisions with Options > Location 1480</div><div class='noteText'>The closest approximation to time travel in financial services is the concept of a financial option. An option is defined as “the right, but not the obligation, to execute a financial transaction at fixed parameters in the future.” It’s a lot simpler to understand with an example: You may acquire the option to buy a stock for $100 (the “strike price”) in a year’s time (assuming a European option). After a year passes, it’s trivial to decide whether to exercise this option: if the stock price trades higher than $100, you can instantly make money by exercising your option to buy the stock for $100 and selling it at a profit. If the actual stock price is less than $100, you let the option expire, meaning you don’t use your right to buy at $100. Coincidentally, this doesn’t mean buying the option was a bad decision (see Chapter 6). An option allows you to defer a decision: instead of deciding to buy or sell a stock today, you can buy the option today and thus acquire the right to make that decision in the future.2</h3> | |
| <h3 class='noteHeading'>Note - Deferring Decisions with Options > Location 1487</div><div class='noteText'>What is a financial option?</h3> | |
| <h2 class='sectionHeading'>10. Every System Is Perfect…</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - System Effects > Location 1697</div><div class='noteText'>Bounded rationality, a term coined by Nobel laureate Herbert A. Simon, captures the effect that people will generally do what is rational, but only within the context that they observe. For example, if an apartment building has a central heating system without consumption-based billing, people will leave the heater on all day and open the windows to cool down the apartment as needed. Obviously, this is a giant waste of energy and leads to pollution, resource depletion, and global warming. However, if your bounded context is just that of the temperature in your apartment and your wallet, this behavior is the rational thing to do, whether you like it or not: keeping the heater running allows you to control the room temperature more easily as you avoid the inertia of the heating system having to warm up.</h3> | |
| <h3 class='noteHeading'>Note - System Effects > Location 1703</div><div class='noteText'>What is bounded rationality?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Influencing System Behavior > Location 1747</div><div class='noteText'>For example, people react to overly full work calendars by setting up “blockers,” which make the calendars even fuller. Instead, we need to understand and fix what causes the full calendars; for example, a misaligned organizational structure that requires too many alignment meetings. You can’t fix a system by merely addressing the symptoms.</h3> | |
| <h3 class='noteHeading'>Note - Influencing System Behavior > Location 1749</div><div class='noteText'>Wht are alignment meetings? How can we reduce them ?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Influencing System Behavior > Location 1750</div><div class='noteText'>example, transparency is a useful antidote to the bounded rationality effect because it widens people’s bounds. An example from Donella Meadows’s book illustrates that having the electricity meter visible in the hallway caused people to be more conservative with their energy consumption without additional rules or penalties.</h3> | |
| <h3 class='noteHeading'>Note - Influencing System Behavior > Location 1752</div><div class='noteText'>What is an antidote for bounded rationality?</h3> | |
| <h2 class='sectionHeading'>11. Code Fear Not!</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Levels of Abstraction: Simplicity Versus Flexibility > Location 1836</div><div class='noteText'>When raising the level of abstraction, you face a fundamental dilemma: how do you make a really simple model without losing too much flexibility? For example, if a developer needs rapid direct-access to any file location, the file stream abstraction actually gets in the way because it requires reading files sequentially. The best abstractions are therefore those that solve and encapsulate the difficult part of the problem while leaving the user with sufficient flexibility.</h3> | |
| <h3 class='noteHeading'>Note - Levels of Abstraction: Simplicity Versus Flexibility > Location 1839</div><div class='noteText'>What is the main tradeoff when creating an abstraction? What is the main goal of an abstraction?</h3> | |
| <h2 class='sectionHeading'>12. If You Never Kill Anything, You Will Live Among Zombies</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Legacy > Location 1976</div><div class='noteText'>With a bit of luck, the systems don’t have to be updated anymore, so IT might be inclined to “simply let it run,” following the popular advice to “never touch a running system.” Unfortunately, changing regulations or security vulnerabilities in old versions of the application or the underlying software stack are likely to interfere with such an approach.</h3> | |
| <h3 class='noteHeading'>Note - Legacy > Location 1979</div><div class='noteText'>WHat is the problem of simply let it run approach for legacy systems?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Hoping for the Best Isn’t a Strategy > Location 2014</div><div class='noteText'>Traditional organizations “hope for the best” by relying on ways to maximize MTBF, whereas modern organizations also “prepare for the worst” by minimizing MTTR.</h3> | |
| <h2 class='sectionHeading'>13. Never Send a Human to Do a Machine’s Job</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - It’s Not Only About Efficiency > Location 2115</div><div class='noteText'>Just like test-driven development is not a testing technique (it’s primarily a design technique), automation is not just about efficiency but primarily about repeatability and resilience. A vendor’s architect once stated that automation shouldn’t be implemented for infrequently performed tasks because it isn’t economically viable. Basically, the vendor calculated that writing the automation would take more hours than would ever be spent completing the task manually (the vendor also appeared to be on a fixed-price contract).</h3> | |
| <h3 class='noteHeading'>Note - It’s Not Only About Efficiency > Location 2120</div><div class='noteText'>What is the other benefit of automation apart from reducing boring work?</h3> | |
| <h2 class='sectionHeading'>15. A4 Paper Doesn’t Stifle Creativity</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Platform Standards > Location 2393</div><div class='noteText'>Platform standards essentially split the IT into two parts: a lower layer that standardizes those elements that are unlikely to form a competitive differentiator and an upper layer of in-house-developed software that provides direct business value and competitive differentiation. This concept of platforms has long been known to the car industry where multiple, outwardly distinct vehicle models share the same “infrastructure” of chassis, suspension, safety equipment, and engine options. Because these components require significant engineering effort and cost but are less visible to the end customer, it makes sense to reuse them across as many models as possible. Meanwhile, interior and exterior elements differ among models as they often serve as differentiating factors across market segments. For a nice model that allows plotting elements by how visible and how commoditized they are, I highly recommend Wardley maps.3</h3> | |
| <h3 class='noteHeading'>Note - Platform Standards > Location 2395</div><div class='noteText'>What are pllatforms? Where do we draw tge line?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Digital Discipline > Location 2434</div><div class='noteText'>Digital companies are great examples of high velocity necessitating discipline (Chapter 31). They realized that strictness in some aspects actually boosts the rate of innovation. Often, this strictness comes in form of an A4-style platform. For example, Google, which is well-known for rapid innovation, has very strict platform standards (Chapter 32) for application deployment and operations: there’s essentially one way to deploy an application, on one type of operating system, observed by one monitoring framework. Google found the exact level at which to abstract to allow people to innovate where it matters without exercising needless creativity.</h3> | |
| <h3 class='noteHeading'>Note - Digital Discipline > Location 2441</div><div class='noteText'>This is interesting when compared to Amazon</h3> | |
| <h2 class='sectionHeading'>16. The IT World Is Flat</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Product Philosophy Compatibility Check > Location 2613</div><div class='noteText'>When plotting vendor offerings onto your map, it’s not enough to just understand the vendor’s current product portfolio, but also where it is headed—the world of IT never stands still. That’s why I first like to understand whether a vendor’s and our worldviews align. Meeting with vendors’ senior technical staff, such as a CTO, is most effective when discussing worldview and comparing maps because too many “solution architects” are just glorified technical salespeople, who navigate purely off the vendor’s map, the “middle kingdom” so to speak. I need a world map, though.</h3> | |
| <h2 class='sectionHeading'>17. Your Coffee Shop Doesn’t Use Two-Phase Commit</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Exception Handling > Location 2726</div><div class='noteText'>Compensating Action The final option to put the system back into a consistent state after a failed operation is to undo the operations that were completed so far. Such “compensating actions” work well for monetary transactions that can recredit money that has been debited. If the coffee shop can’t make the coffee to your satisfaction, it will refund your money to restore your wallet to its original state. Because real life is full of failures, compensating actions can take many forms, such as a business calling a customer to ask them to ignore a letter that has been sent or to return a package that was sent in error. The classic counter-example to compensating an action is sausage making. Some actions are not easily reversible.</h3> | |
| <h3 class='noteHeading'>Note - Exception Handling > Location 2732</div><div class='noteText'>WHen is undo more appropriate than recover whole state?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Conversations > Location 2750</div><div class='noteText'>Conversations The coffee shop interaction is also a good example of a simple but common conversation pattern4 that illustrates sequences of message exchanges between participants. The interaction between two parties (customer and coffee shop) consists of a short synchronous interaction (ordering and paying) and a longer, asynchronous interaction (making and receiving the drink). This type of conversation is quite common in purchasing scenarios. For example, when an order is placed on Amazon, the short synchronous interaction assigns an order number, whereas all subsequent steps (charging credit card, packaging, shipping) are performed asynchronously. Customers are notified via email (asynchronous) when the additional steps complete. If anything goes wrong, Amazon usually compensates the customer (refunds payment) or retries (resends the lost goods).</h3> | |
| <h3 class='noteHeading'>Note - Conversations > Location 2758</div><div class='noteText'>What's the name for sync + async pattern?</h3> | |
| <h2 class='sectionHeading'>18. Explaining Stuff</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Mind the Gap > Location 2906</div><div class='noteText'>This effect is known as the curse of knowledge: once you know something, it’s very hard to imagine how someone else learns it.</h3> | |
| <h3 class='noteHeading'>Note - Mind the Gap > Location 2908</div><div class='noteText'>What is the curse of knowledge and how does it affect teaching?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Mind the Gap > Location 2908</div><div class='noteText'>At a discussion about network security, a team of architects presented their requirement that servers located in the untrusted network zone have separate network interfaces, so-called NICs, for incoming and outgoing network traffic to avoid a direct network path from the internet to trusted systems.</h3> | |
| <h3 class='noteHeading'>Note - Mind the Gap > Location 2910</div><div class='noteText'>Why does active have two enis?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Consistent Level of Detail > Location 2943</div><div class='noteText'>Drawing the line at the correct level of detail depends on you knowing your audience. If your audience is mixed, building a good ramp is ever more important because it allows you to catch up folks who aren’t familiar with the details without boring those who are. The highest form is building a ramp that audience members already familiar with the subject matter appreciate despite not having learned anything new. This is tough to achieve but is a noble goal to aim for.</h3> | |
| <h3 class='noteHeading'>Note - Consistent Level of Detail > Location 2946</div><div class='noteText'>What to o when your audience expertise is mixed?</h3> | |
| <h2 class='sectionHeading'>19. Show the Kids the Pirate Ship!</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Product Box > Location 3057</div><div class='noteText'>Thinking of your product like a retail item can help focus on tangible benefits instead of technical features.</h3> | |
| <h3 class='noteHeading'>Note - The Product Box > Location 3058</div><div class='noteText'>What is the common pit fall when sailing technical products ?</h3> | |
| <h2 class='sectionHeading'>20. Writing for Busy People</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Writing Scales > Location 3120</div><div class='noteText'>written word has enormous advantages over the spoken word or slide presentations: It scales You can address a large audience without gathering everyone in one room (podcasts, admittedly, can also accomplish that). It’s fast People read two to three times faster than they can listen. It’s searchable You can find what you want to read quickly. It can be edited and versioned Everybody sees the same, versioned content.</h3> | |
| <h3 class='noteHeading'>Note - Writing Scales > Location 3125</div><div class='noteText'>How tre are thrse benefits of writing?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Writing Scales > Location 3126</div><div class='noteText'>is Richard Guindon’s insight that “Writing is nature’s way of telling us how sloppy our thinking is.”</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Quality Versus Impact > Location 3138</div><div class='noteText'>So, you want to get the quality of your writing into the “sweet spot” and then focus on content instead of polishing further.</h3> | |
| <h3 class='noteHeading'>Note - Quality Versus Impact > Location 3139</div><div class='noteText'>How can you tell where is the sweet spot for decision / design docs?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - A Good Paper Is Like the Movie Shrek > Location 3181</div><div class='noteText'>Technical papers that address a diverse audience should aim to do the same. They need to supply technical detail while also highlighting important decisions and recommendations, so they can be read at two levels. A few simple techniques can help make reading your paper a little bit like watching Shrek: Storytelling headings These replace an executive summary: your reader should get the gist of the paper just by reading the headings. Headings like “introduction” or “conclusion” aren’t telling a story and have no place in a short paper. Anchor diagrams These provide a visual cue for important sections. Readers who flip through a paper likely pause at a diagram, so it’s good to position them strategically. Sidebars These are the short sections that are offset in a different font or color, indicating to the reader that this additional detail can be safely skipped without losing the train of thought. This way, executives can just read the headings and look at the diagram to get the essence of your paper in a minute or two (Figure 20-2). Most readers will read the paper but might skip the callouts, whereas specialists will pay particular attention to the detail in the callouts. This way, you can help break the curse of linearity a tiny bit by giving different readers different paths through the document.</h3> | |
| <h3 class='noteHeading'>Note - A Good Paper Is Like the Movie Shrek > Location 3195</div><div class='noteText'>How to structure the pages of a book chapter?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - In der Kürze liegt die Würze4 > Location 3265</div><div class='noteText'>Saint-Exupéry’s adage that “perfection is achieved not when there is nothing more to add, but when nothing is left to take away”</h3> | |
| <h3 class='noteHeading'>Note - In der Kürze liegt die Würze4 > Location 3266</div><div class='noteText'>Between comprehnsiveness and conciseness, where should we land?</h3> | |
| <h2 class='sectionHeading'>24. Sketching Bank Robbers</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Architecture Therapy > Location 3916</div><div class='noteText'>asks children to draw a picture of their family in a method referred to as Kinetic Family Drawings (KFD). The drawings give therapists insight into the family dynamics, such as proximity, hierarchy, or behavioral patterns. I have experienced the same with development teams, so you shouldn’t outright discard their drawings as meaningless or incomplete, but derive insight into the team’s thinking and hierarchy from them: is the database in the middle of it all? Maybe the schema designer is calling the shots in the team (I know a case of that happening). Are there many boxes, but no lines? Probably the team’s thinking is focused on structural concerns but ignores system behavior. This is often the case when the architect is too far removed from code and operational aspects.</h3> | |
| <h3 class='noteHeading'>Note - Architecture Therapy > Location 3921</div><div class='noteText'>This is a cool trick for diagnosing the teams understanding of te systrm architecture. Can I use it at work?</h3> | |
| <h2 class='sectionHeading'>25. Software Is Collaboration</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Always Be Ready to Ship > Location 4025</div><div class='noteText'>tend to ask my teams: “what if we had to present in one hour?” Do we have a core storyline and some essential slides to support it? When you are at that point, you can refine and improve slides with much less stress.</h3> | |
| <h3 class='noteHeading'>Note - Always Be Ready to Ship > Location 4026</div><div class='noteText'>What does CI have to do with my documnts, slides and CVs?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Always Be Ready to Ship > Location 4027</div><div class='noteText'>Always being ready to ship highlights the difference between working iteratively and incrementally.4 Many people make slides incrementally and have only half a slide deck after half the time elapsed. They are not ready to present.</h3> | |
| <h3 class='noteHeading'>Note - Always Be Ready to Ship > Location 4029</div><div class='noteText'>What is the diff between working iteratively and incrementally?</h3> | |
| <h2 class='sectionHeading'>27. Control Is an Illusion</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Control Circuits > Location 4372</div><div class='noteText'>The feedback loop compensates for external factors such as the outside temperature or someone opening the window. This runs counter to many project planning approaches that attempt to predict all factors up front and then look to execute according to plan. It’s like running the heater for exactly two hours and then blaming the cold weather for the room not being warm enough. Embarrassingly, a cheap thermostat can give us better control than some project managers.</h3> | |
| <h3 class='noteHeading'>Note - Control Circuits > Location 4375</div><div class='noteText'>What is the fallacy that the project manager make here?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - A Two-Way Street > Location 4382</div><div class='noteText'>When we portray large organizations as “command-and-control” structures, we often focus only on the top-down steering part, and less on the feedback from the “sensors.” But not using the sensors means one is flying blind, possibly with a feeling of control, but one that’s disconnected from reality. It’s like driving a car at night without headlights and turning the steering wheel with no clue where the car is actually headed—a very dumb idea. It’s shocking to see how such behavior, which borders on absurdity, can establish itself in large organizations.</h3> | |
| <h3 class='noteHeading'>Note - A Two-Way Street > Location 4386</div><div class='noteText'>This is a great analogy for top-down control without feedback </h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Saupreiß, ned so Damischer > Location 4420</div><div class='noteText'>In his book The Art of Action,3 Stephen Bungay extends this concept into three gaps, as illustrated in Figure 27-1: the knowledge gap between what you’d like to know and actually do know, the alignment gap between plans and actions, and the effects gap between what you expect your actions to achieve and what actually happens. Figure 27-1. The three gaps that can make control an illusion (adapted from Bungay) You can recognize organizations that believe they can close these gaps by the methods they apply. They try to close the knowledge gap by generating thick requirements documents, which are often outdated by the time they are completed. They try to tackle the alignment gap by developing extensive project plans and micro-managing according to them. Lastly, the effects gap is a bit more difficult to close. Such organizations try nonetheless, either through the aforementioned watermelon status reports or by using proxy metrics (Chapter 40), things that are easily measured but don’t quite reflect reality. Essentially, these organizations create their own reality, or illusion. Note Many IT organizations believe they can close the knowledge, alignment, and effects gaps, an approach that has been disproven some 200 years ago. Unlike some IT organizations, the Prussians already knew that the gaps couldn’t be eliminated. Instead, they accepted the gaps and adjusted their management style accordingly, replacing a concrete order with the concept of Auftragstaktik, best translated as “mission command” or “directive.” Understanding the purpose of the mission enabled the troops to adjust to unforeseen circumstances (knowledge or effects gaps) without having to report back to central command. This would save valuable time and lead to better decisions in the local context.</h3> | |
| <h3 class='noteHeading'>Note - Saupreiß, ned so Damischer > Location 4438</div><div class='noteText'>Wat are te gaps mentioned in the book? Why can't they be closed? What to do if they indeed cannot be closed?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Actual Control: Autonomy > Location 4472</div><div class='noteText'>This system won’t work if you omit one or more elements: strategy without enablement will lead to zero progress but lots of frustration. Autonomy without strategy or feedback will resemble anarchy as teams can’t judge the appropriateness of their decisions. And enablement without strategy will only make anarchy more efficient.</h3> | |
| <h3 class='noteHeading'>Note - Actual Control: Autonomy > Location 4474</div><div class='noteText'>How does this enablement, feedback and stratfegy view for autonomous team relate to control, competence, clarity framework from turning the ship around? What problems arise when we skip one pillar?</h3> | |
| <h2 class='sectionHeading'>28. They Don’t Build ’Em Quite Like That Anymore</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Building Pyramids from the Top > Location 4589</div><div class='noteText'>While too much duplication may be undesired, we must keep in mind that avoiding duplication isn’t free (Chapter 35).</h3> | |
| <h3 class='noteHeading'>Note - Building Pyramids from the Top > Location 4591</div><div class='noteText'>What does avoiding dup cost?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Living in Pyramids > Location 4624</div><div class='noteText'>Some organizations are looking to speed things up by overlaying communities of practice over their structural hierarchy, bringing people with a common interest or area of expertise together. Communities can be useful change agents, but only if they are empowered and have clear goals (Chapter 27). Otherwise, they run the risk of becoming communities of leisure, a hiding place for people to debate and socialize without measurable results.</h3> | |
| <h3 class='noteHeading'>Note - Living in Pyramids > Location 4628</div><div class='noteText'>Another example for workgroup must have authority</h3> | |
| <h2 class='sectionHeading'>29. Black Markets Are Not Efficient</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Black Markets to the Rescue > Location 4675</div><div class='noteText'>Such black markets often take the innocuous form of needing to “know who to talk to” to get something done quickly. You need a server urgently? Instead of following the standard process, you call your buddy who can “pull a few strings.” Setting up an official “priority order” process, usually for a higher price, is fine. Bypassing the process to get special favors for those who are well connected is a black market.</h3> | |
| <h3 class='noteHeading'>Note - Black Markets to the Rescue > Location 4678</div><div class='noteText'>What is a black market?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Beating the Black Market > Location 4722</div><div class='noteText'>The only way to avoid a black market is to build an efficient “white market,” one that doesn’t hinder progress but enables it. An efficient white market reduces people’s desire to maintain an alternate black-market system, which does take some effort after all. Trying to shut down the black market without offering a functioning white market is likely to result in resistance and substantial reduction in productivity.</h3> | |
| <h3 class='noteHeading'>Note - Beating the Black Market > Location 4726</div><div class='noteText'>This sounds like music and movie industry</h3> | |
| <h2 class='sectionHeading'>30. Scaling an Organization</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Avoid Sync Points—Meetings Don’t Scale > Location 4798</div><div class='noteText'>In some organizations finding a meeting time slot among senior people can take a month or longer. Such resource contention on people’s time significantly slows down decision making and project progress (and hurts economies of speed; see Chapter 35). The effect is analog to locking database updates: if many processes are trying to update the same table record, throughput suffers enormously as most processes just wait for others to complete, eventually ending up in the dreaded deadlock.</h3> | |
| <h3 class='noteHeading'>Note - Avoid Sync Points—Meetings Don’t Scale > Location 4802</div><div class='noteText'>Why does meetings kill progress?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Asynchronous Communication—Email, Chat, and More > Location 4855</div><div class='noteText'>favor a chat/channel paradigm, also enable asynchronous communication without email. Systems architects would liken this approach to tuple spaces, which, based on a blackboard architectural style, are well suited for scalable, distributed systems thanks to loose coupling and avoiding duplication.</h3> | |
| <h3 class='noteHeading'>Note - Asynchronous Communication—Email, Chat, and More > Location 4857</div><div class='noteText'>What Is tuple space and how does it relafte to slack?</h3> | |
| <h2 class='sectionHeading'>31. Slow Chaos Is Not Order</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Fast Versus Agile > Location 4947</div><div class='noteText'>My first annoyance about the widespread abuse of the word agile is repeatedly having to remind people that the method is called “Agile,” not “fast,” and for a good reason. Agile methods are about hitting the right target through frequent recalibration and embracing change rather than trying to predict the environment and eliminating uncertainty.</h3> | |
| <h3 class='noteHeading'>Note - Fast Versus Agile > Location 4950</div><div class='noteText'>Why isn't agile about eliminating uncertainties?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Slow-Moving Chaos > Location 5003</div><div class='noteText'>why would it take two weeks to provision a virtualized server? For one, because most of this time is spent in queues (Chapter 35), and second, because of “thorough testing.” Hold on, why would you need to test a virtual server that should be provisioned in a 100% automated and repeatable fashion? And why would it take two weeks? Usually because the process being followed isn’t actually 100% automated and repeatable: a little duct tape is added here, a little optimization is done over there, a little script is edited, and someone forgot to mount the storage volumes. Oops. That’s one reason to never send a human to do a machine’s job (Chapter 13).</h3> | |
| <h3 class='noteHeading'>Note - Slow-Moving Chaos > Location 5008</div><div class='noteText'>Wgat should we hav spent in M1 of QQ to address te needs fr thorough testing?</h3> | |
| <h2 class='sectionHeading'>V. Transformation</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Bursting the Boiler > Location 5243</div><div class='noteText'>I compare this to a steam engine that is surpassed by a fast electric train. In an attempt to speed up, the steam-engine operator throws more coals onto the fire to increase the boiler pressure. While it may initially speed up the steam engine, soon the boiler will burst. You can’t compete with an electric train by putting more pressure on the boiler. Instead, you need to devise a new engine that can keep up. That’s what architects do.</h3> | |
| <h3 class='noteHeading'>Note - Bursting the Boiler > Location 5246</div><div class='noteText'>Incremental changes vs. Transformation</h3> | |
| <h2 class='sectionHeading'>33. No Pain, No Change!</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Wishful Thinking Sells Snake Oil > Location 5315</div><div class='noteText'>Digital natives have it easy because, as the name suggests, they were born on the upper levels of the digital transformation scale and never had to make it through this painful change process. Others feel the pain and tend to search for an easy way out.</h3> | |
| <h3 class='noteHeading'>Note - Wishful Thinking Sells Snake Oil > Location 5316</div><div class='noteText'>What advantges do younger generations have?</h3> | |
| <h2 class='sectionHeading'>34. Leading Change</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Leaving Your Island Will Get Your Feet Wet > Location 5497</div><div class='noteText'>In your view, the organization might live on a tiny molehill while you know of a high mountain of gold somewhere else. However, between the molehill and the mountain is a muddy swamp. Because you won’t be able to leap straight to the mountain of gold, you first have to get folks off the molehill, convincing them to keep moving after their feet get wet and muddy. That’s why you must communicate a clear vision and prepare them for tougher times ahead before the new optimum can be reached.</h3> | |
| <h3 class='noteHeading'>Note - Leaving Your Island Will Get Your Feet Wet > Location 5500</div><div class='noteText'>What is the importance of selling a vision?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Country of the Blind > Location 5503</div><div class='noteText'>H. G. Wells’s short story “The Country of the Blind” comes to mind: an explorer falls down a steep slope and discovers a village in a valley that is completely separated from the rest of the world. Unbeknownst to the explorer, a genetic disease has rendered all of the villagers unable to see. Upon realizing this peculiarity, the explorer feels that because “the one-eyed man is king” in this town he can teach and rule them. However, his ability to see proves to be of little advantage in a place designed for blind people, without windows or lights. After struggling to take advantage of his gift, the explorer is to have his eyes removed by the village doctor to cure his strange obsessions.</h3> | |
| <h3 class='noteHeading'>Note - The Country of the Blind > Location 5507</div><div class='noteText'>The Country of the Blind is a good storyh to illustrate what characteristic of the system?</h3> | |
| <h2 class='sectionHeading'>35. Economies of Speed</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Old Economies of Scale > Location 5574</div><div class='noteText'>In the digital world, the limiting factor for an organization’s size becomes its ability to change. While in static environments being big is an advantage thanks to economies of scale, in times of rapid change economies of speed win out and allow startups and digital-native companies to disrupt much larger companies. Or as Jack Welch famously stated: “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”</h3> | |
| <h3 class='noteHeading'>Note - Old Economies of Scale > Location 5577</div><div class='noteText'>When shoul we focus more on flow/speed vs scale/batch?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Value and Cost of Predictability > Location 5627</div><div class='noteText'>Chasing predictability causes another well-known phenomenon: sandbagging. Project and budget plans sandbag by overestimating timelines or cost in order to more easily achieve their target. Keep in mind that estimates aren’t single numbers but probability distributions: a project may have a 50% chance of being done in four weeks’ time. If “you are lucky and all goes well,” it may be done in three weeks, but with only a 20% likelihood. Sandbaggers pick a number far off on the other end of the probability spectrum and would estimate eight weeks for the project, giving them a greater than 95% chance of meeting the target. Even worse, if the project happens to be done in four weeks, the sandbaggers idle for another four weeks before release to avoid having their time or budget estimates cut the next time. If a deliverable depends on a series of activities, sandbagging compounds and can extend the time to delivery enormously.</h3> | |
| <h3 class='noteHeading'>Note - The Value and Cost of Predictability > Location 5634</div><div class='noteText'>What is a problem with demanding predictability in projects?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - The Value and Cost of Avoiding Duplication > Location 5639</div><div class='noteText'>The primary cost involved in de-duplication is coordination: to avoid duplication you first need to detect it. In a large codebase this can be done efficiently through code search. In a large organization, it can require many “alignment” meetings—synchronization points—high up in the hierarchy, which we know not to scale (Chapter 30) in both computer systems and organizations.</h3> | |
| <h3 class='noteHeading'>Note - The Value and Cost of Avoiding Duplication > Location 5642</div><div class='noteText'>What is the reasoning behind 2>0?</h3> | |
| <h2 class='sectionHeading'>36. The Infinite Loop</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Build-Measure-Learn > Location 5678</div><div class='noteText'>Eric Ries eternalized this concept in his book The Lean Startup1 as the Build-Measure-Learn cycle: a company builds a minimum viable product and launches it into production to measure user adoption and behavior.</h3> | |
| <h3 class='noteHeading'>Note - Build-Measure-Learn > Location 5680</div><div class='noteText'>What is the main loop in the lean startup book?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Digital RPMs > Location 5684</div><div class='noteText'>The critical KPI for most digital companies is how much they can learn per dollar or time-unit spent, i.e., how many revolutions through the Build-Measure-Learn cycle they can make.</h3> | |
| <h3 class='noteHeading'>Note - Digital RPMs > Location 5686</div><div class='noteText'>Why i learning an org KPI?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Old-World Hurdles > Location 5700</div><div class='noteText'>Unfortunately, traditional companies aren’t built for rapid feedback cycles. They often still separate “run” from “change” (Chapter 12) and assume a project is done by the time it reaches production.</h3> | |
| <h3 class='noteHeading'>Note - Old-World Hurdles > Location 5702</div><div class='noteText'>What is a problem with considering a project as "done"?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Pivoting the Layer Cake > Location 5726</div><div class='noteText'>To speed up the feedback engine you need to turn the organizational layer cake on its side by forming teams that carry full responsibility from product concept to technical implementation, operations, and refinement. Often such an approach carries the label of “tribes,” “feature teams,” or “DevOps,” which is associated with a “you build it, you run it” attitude. Doing so not only provides a direct feedback loop to the developers about the quality of their product (pagers going off in the middle of the night are a very immediate form of feedback), but it also scales the organization (Chapter 30) by removing unnecessary synchronization points: all relevant decisions can be made within the project team.</h3> | |
| <h3 class='noteHeading'>Note - Pivoting the Layer Cake > Location 5733</div><div class='noteText'>What is the main advantage of creating a feature team?</h3> | |
| <h2 class='sectionHeading'>38. Money Can’t Buy Love</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Innovator’s Dilemma > Location 5885</div><div class='noteText'>Most innovative products can’t match established products’ performance or profitability during early stages. Traditional budgeting processes may therefore reject new and promising ideas, a phenomenon that Christensen coined the Innovator’s Dilemma.1</h3> | |
| <h3 class='noteHeading'>Note - Innovator’s Dilemma > Location 5887</div><div class='noteText'>What is t Innovator's dilemma?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Beware of the HiPPO > Location 5895</div><div class='noteText'>Many rich companies have a different decision process: that of the highest paid person’s opinion, or HiPPO. This approach isn’t just highly subjective but also susceptible to shiny, HiPPO-targeted vendor demos, which peddle incremental “enterprise” solutions as opposed to real innovation. Because those decision makers are far removed from actual technology and software delivery, they don’t realize how fast new solutions can be built on a shoestring budget.</h3> | |
| <h3 class='noteHeading'>Note - Beware of the HiPPO > Location 5898</div><div class='noteText'>What are some problems with relyibg on HiPPO to make decisions?</h3> | |
| <h2 class='sectionHeading'>39. Who Likes Standing in Line?</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Looking Between the Activities > Location 5992</div><div class='noteText'>If a machine is working well and almost 100% utilized but a widget must wait three months to be processed by that machine, you may have replicated the public healthcare system, which is guided by efficiency but certainly not speed. Many statistics show that wait times in typical IT processes, such as ordering a server, make up more than 90% of the total elapsed time. Instead of working more, we should wait less!</h3> | |
| <h3 class='noteHeading'>Note - Looking Between the Activities > Location 5994</div><div class='noteText'>Why do people focus on 100% utilization of resources? What is the tradeoff when doing that?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - A Little Bit of Queuing Theory > Location 6002</div><div class='noteText'>if we remember only one thing from his class, it should be Little’s Result. This equation states that in a stable system, the total processing time T, which includes wait time, is equal to N, the number of items in the system (the ones in the queue plus the ones being processed) divided by the processing rate λ; in short T = N / λ .</h3> | |
| <h3 class='noteHeading'>Note - A Little Bit of Queuing Theory > Location 6005</div><div class='noteText'>What is Little's results?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - A Little Bit of Queuing Theory > Location 6011</div><div class='noteText'>the average number of items in the system is equal to ρ / (1 – ρ), where ρ designates the utilization rate, or the fraction of time the server is busy (we make the assumption that arrivals are independent, which is described as a memoryless system). From the equation you can quickly gather that high levels of utilization (ρ moving closer to 100%) lead to extreme queue sizes and therefore wait times. Increasing utilization from 60% to 80% almost triples the average queue length: 0.6/(1 – 0.6) = 1.5 versus 0.8/(1 – 0.8) = 4. Driving up utilization will drive away your customers because they get tired of standing in line!</h3> | |
| <h3 class='noteHeading'>Note - A Little Bit of Queuing Theory > Location 6016</div><div class='noteText'>How to calculate the number of items in queue based on utilization?</h3> | |
| <h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Making Queues Visible > Location 6048</div><div class='noteText'>“You can’t manage what you can’t measure,” goes the old saying, apparently falsely attributed to W. Edwards Deming.</h3> | |
| <h3 class='noteHeading'>Note - Making Queues Visible > Location 6048</div><div class='noteText'>What is the saying that you need visibility to change things?</h3> | |
| <h2 class='sectionHeading'>40. Thinking in Four Dimensions</h2><h3 class='noteHeading'>Highlight (<span class='highlight_yellow'>yellow</span>) - Living Along a Line > Location 6084</div><div class='noteText'>IT architecture is a profession of trade-offs: flexibility brings complexity; decoupling increases latency; distributing components introduces communication overhead. The architect’s role is often to determine the “best” spot on such a continuum, based on experience and an understanding of the system context and requirements. A system’s architecture is essentially defined by the combination of trade-offs made across multiple continua.</h3> | |
| <h3 class='noteHeading'>Note - Living Along a Line > Location 6087</div><div class='noteText'>What is the technical role of a system architect?</h3> | |
| </div> | |
| </body> | |
| </html> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment