The Software Architect Elevator By Gregor Hohpe

"Packaging change into projects reflects an organization’s belief that "no change" is normal, desired state and "change" is intermittent, unusual state."

"A software system’s first derivative is its build and deployment toolchain."

"Poor quality:
There’s a common misbelieve that good quality requires extra time and effort. The inverse is actually true: poor quality slows down software delivery. Changes to a poorly tested or poorly built system take more time and are more likely to break things. 

Fear: 
Often ignored, a programmer’s attitude has a major impact on the rate of change. Poor quality and low levels of automation make change a risky proposition. Developers will thus be afraid of making changes. This leads to code rot, which in turn increases the risk of change - a nasty spiral."

"Propose to a development team that they let you delete 20 arbitrary lines from their source code. Then, they’ll run their tests- if they pass, they’ll push the code straight into production. From their reaction, you’ll know immediately whether their source code has sufficient test coverage."

"Enterprise architecture is the glue between business and IT architecture"

"Prospect theory: when faced with an opportunity people tend to favor a smaller but guaranteed gain over uncertain chance for a larger one"

"When it comes to taking a loss, however, people are likely to take a (long) shot at avoiding the penalty over coughing up a smaller amount for sure. We tend to ‘feel lucky’ when we can hope to escape a negative event, an effect called loss aversions". 

"Architecture isn’t good or bad, it’s fit or unfit for a purpose."

"Assessing the context and identifying implicit constraints or assumptions in proposed design is an architect’s key responsibility. Architects are commonly described as the people dealing with nonfunctional requirements."

"One of an architect’s most important tasks is to eliminate irreversibility in software design." — Martin Fowler

"So, instead of entrusting all crucial decisions to one person, a project can be better off my minimizing the number of early and irreversible decisions. For example, choosing a flexible or module design can localize the scope of later change and thus minimize the extent of up-front decision making. "

"Luckily, IT architects need neither complex formulas nor a Nobel prize. All you need to do is design your system such that it defers decisions. You accomplish that by providing options that can be exercised in the future."

"Architecture options are rarely free. For example, you may pay with increased complexity or loss of another option"

"Minimizing the strike price - that is, switching cost from one vendor to another - is often seems as the architectural ideal, but it’s rarely the most economical choice."

"The more uncertain about the future I am, the more value I derive from deferring a decision. For example, the option to scale horizontally isn’t that valuable if my application is built for a small and constant number of users. However, if I’m building an internet facing application that could have 100 or 100000 users, the option becomes much more valuable."

"The business not wanting to be involved in technical decisions leads to suboptimal decision making because IT alone can’t judge the value of an option. Instead, it’s architect’s job to translate technical options into meaningful choices for the business."

"The value of both Agile methods and architecture increases with uncertainty, so they are friends, not foe."

"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."

"To test whether the visuals are just a thin veneer or really a better model. I
generally apply two tests when vendors provide a demo of visual programming
tools:
• I ask them to enter a typo into one of the fields where the user is expected
to enter some logic. Often this leads to cryptic error messages or obscure
exceptions in generated code later on. This is
"tightrope programming": as
long as you stay exactly on the line, everything is well. One misstep and the
deep abyss awaits you.
• I ask them to leave the room for two minutes while we change a few ran-
dom elements of their demo configuration. Upon return, they would have
to debug and figure out what was changed.
So far, no vendor has taken the bait; they presumably know that failure 
doesn't respect abstraction."

"Worse yet, there's no "business case" for updating the system technology. This widespread logic is about as sound as considering changing the ail in your car a waste of money after all, the car still runs if you don't. And it even makes your quarterly profit statement look a little better; that is, until the engine seizes."

"Often the inability to migrate cascades across multiple layers of the software stack: one cannot upgrade to a newerJDK because it doesn't run on the current application server version, which can't be updated because it requires a new version of the operating system, which deprecates some library or features software depends on."

"Otherwise, you may as well argue that the fire brigade should use a bucket chain because all those fire trucks and pumps are not economically viable given how rarely buildings actually catch fire."

"Without a map, any road looks promising"

"When an account manager starts the meeting with "please help us understand your environment," which roughly translates into "please tell me what I should sell to you," I typically preempt the exercise by asking the senior person about their product philosophy. It's a bit of a big word, but it's helpful in shifting the conversation to the vendor's world map."

"I prefer to ask vendors two key questions to understand their world map:
• What base assumptions did you have to make? No one can operate on a completely empty map without borders, so the vendor must have made choices and picked boundaries. The answer to this question tells you where the edge of their map is.
• What's the toughest problem you had to solve? The answer to this question will tell you where the center of their map is.

Discussing what base assumptions and decisions are baked into a product gives you great insight into a vendor's world map (see Figure 16-2), both about the center and the edge (remember the IT world is flat, so it has edges)."

"Naturally, this works only when talking to someone who is actually defining the vendor's corporate or product strategy. Looking at the company leadership page can help you identify the right people. Looking at the leadership's history can also help you understand "where they come from"; that is, under which assumptions they operate."

"Starbucks, like most other businesses, is primarily interested in maximizing throughput of orders because more orders equal more revenue. Interestingly, the optimization for throughput results in a concurrent and asynchronous processing model: when you place your order, the cashier marks a coffee cup with the details of your order (e.g., tall, nonfat, soy, dry, extra hot latte with double shot) and places it into the queue, which is quite literally a queue of coffee cups lined up on top of the espresso machine. This queue decouples cashier and barista, allowing the cashier to keep taking orders even if the barista is momentarily backed up. If the store becomes busy, multiple baristas can be deployed in a competing-consumer scenario, meaning that they work off items in parallel 
without duplicating work.

Asynchronous processing models can be highly scalable but are not without challenges. Still waiting for my hot chocolate, I started thinking about how Starbucks dealt with some of these issues. Maybe we can learn something from the coffee shop about designing successful asynchronous messaging solutions?"

"It's amazing how frequently a basic retry operation succeeds in systems that were built out of zeros and ones. The common saying that defines insanity as "doing the same thing over and over again and expecting different results" apparently doesn't apply to computer systems."

"Some might feel that excitement is a bit too frivolous for a serious workplace discussion. That's where you should look back at Aristotle, who gave us great advice in communicating, some 2,300 years ago. He concluded that a
good argument is based on logos, facts and reasoning; ethos, trust and authority; and pathos, emotion! Most technical presentations deliver 90% logos, 9% ethos, and maybe 1% pathos. From that starting point, a small extra dose of pathos can go a long way. You just have to make sure that your content can match the picture presented on the cover: pitching a pirate ship and not having the cannons inside the box is bound to lead to disappointment."

"Most of what we know we didn't learn from our school teachers, but from playing and experimenting. Sadly, most people seem to have forgotten how to play, or were told not to, when they entered their professional life. This happens due to social norms, pressure to always be (or appear) productive, and fear. Playing knows no fear and no judgment; that's why it gives you an open mind for new things."

"If you might add, add it. If it should be pointed out, point it out. If it is interesting to
note, make it interesting." — Walker Royce

"We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and
technical folks. By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate." — Ken Beck

"Grady Booch drew analogies between having teams depicting their architecture and family therapy,? which 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."

"You can't just ask people what their beliefs are because most are unaware of them."

"A brief look at contral theory sheds some light on where the illusion originates. Control circuits, such as a room thermostat, keep a system in a stable condition - in this example, keeping a room at a constant temperature. They do so based on sensors and feedback the thermostat senses the room temperature and turns the furnace on when the room is cold. When the desired temperature is reacher it turns off the furnace.

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."

"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."

"The difference between an order and a mission command becomes clear with a
simple example. Suppose that a small platoon is given the order to take a hill. As it climbs up the hill, the soldiers realize that there's no resistance at all and progress easily. Should they march to the top? If they have been given a simple command, they'll do so. This might be correct if the intent, the Auftrag, was to take the hill as a strategic position. However, if the intent was to attack troops positioned on the hill, advancing to the top makes little sense."

"Ironically, it turns out that giving teams decision autonomy actually increase
control as it accepts the gaps and avoids operating in an illusion. But be careful many organizations equate autonomy to "everyone does what they think is best." Now, unfortunately, that's not autonomy, that's anarchy: whether we like it or not, anarchists do what they believe is right."

"Another insight might surprise traditional organizations that are looking to give teams more autonomy: autonomous teams need better management. Managing nonautonomous teams is comparatively easy: they'll largely do as told. Autonomous teams, in contrast, require leadership: they need to be told the overall intent and goals. So, ironically, organizations that are looking to increase
autonomy in their teams might need to strengthen management first."

"You can't eliminate black markets with more control and governance. After all those are the very mechanisms that caused the black market in the first place."

"Meetings are synchronization points - a well-known throughput killer."

"In many large IT organizations, top decision makers don't use the very tools they standardize. For example, they rarely use the standard workplace or HR tools (Chapter 29), because they're entitled to special solutions or they have admins who do this work for them. They hence can lack both the situational context and a critical feedback cycle."

"It's more beneficial to standardize connecting elements, such as monitoring or source control, than endpoints such as laptops or IDEs. Google took this to the extreme by storing (almost) all of its source code in a single version control system."

"A specific challenge is posed by users who also use a standard, in addition to their own solution. They thus will correctly proclaim "yes, we do drive BMW cars," in line with a corporate standard that they do so, despite the parking lot being full of Mercedes, Rolls-Royces, and Yugos. In another phenomenon, users employ a standard, but for the wrong purpose. For example, they may use the standard BMW as a meeting room for four people, and don't actually drive it (they prefer Mercedes for that). Sounds absurd? I have seen many similarly absurd examples in corporate IT!"

"A colleague of mine once attended a
"digital showcase" event in his compony, which highlighted many innovative projects and emeral hackathons the company had organized. Upon returning to his desk, though, be found himself in the same old corporate IT world where he is forced to dock tine annot
server in less than three weeks, and isn't allowed to install solitware.on He was wondering whether he was caught in some twisted incarnation of two speed IT, but that made little sense; after all. his project was
moving "digital" speed."

"If the rate of change on the outside exceeds the rate of change on the inside, the end is near." — Jack Welch

"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."

"Digital transformation begins with changing HR and recruiting practices." - I could not agree more with author. 

"Google is famous for dogfooding its products, meaning its employees get to try alpha or beta versions of new products. While the name doesn't make it sound too appealing, Google's "food" includes pretty exciting products, some of which never reach the eyes of the consumer."

"At Google, getting a USB charger cable was a matter of 2.5 minutes: I minute to walk to the nearest Tech Stop, 30 seconds to swipe your badge and scan the cable at the self-checkout, and I minute to walk back to your desk. To do this in corporate IT, I had to mail someone, who mailed someone, who asked me the type of phone I use and then entered an order, which I had to approve. Elapsed time: about 2 weeks. Speed factor: I4 days × 24 hours/day × 60 minutes/hour / 2.5 minutes = 8064, in the same league as setting up a source code repository."

"After transitioning from a Silicon Valley company to a traditional business, my new coworkers frequently reminded me that we're a large corporation, implying that what works for Google wouldn't apply here. My routine retort was that by applying the standard measure of market capitalization, I joined a corporation 10 times smaller. More interesting, my coworkers also pointed out that Google can do pretty much whatever it wants thanks to all the money it has. My view, in contrast, was that many successful traditional businesses suffer from exacily this problem of having too much money."

"My small team of architects was loaded with enormous overhead cost ranging from office space and cafeteria subsidies to workplace charges (computers, phones), which I couldn't influence. In comparison, free meals offered by digital companies are a trivial expense."

"A particularly dangerous pitfall for wealthy organizations looking to transform the belief that any required skill can be bought at will. Years ago, many companies considered IT a commodity: a necessity, but not one that created a competitive advantage. That's why they didn't perceive any risk in keeping IT skills outside of the company. Instead, they valued the flexibility in ramping external IT staff up and down as needed just as they would with administrative or cleaning staff. They perceived this model as more efficient."

"However, outsourcing software delivery has severe drawbacks in the digital age: first, it prevents the organization from effectively participating in the Build-Measure-Learn cycle because externals typically work on a pre-negotiated scope of work and therefore have little incentive to keep iterating on products or to shorten release cycles. Second, the organization won't be able to develop a deep understanding of new technologies and their potential, thus stifling innovation. Worse yet, in many cases knowledge of a company's existing system landscape rests with external contractors, rendering the organization unable to make rational decisions based on the status quo. If you don't know your starting point, it's difficult to get on the road to change."

"But then everything changed: hardly any industry was overrun by internet companies as spectacularly as telecommunications. Telecoms used to "own" communication but completely failed to see the potential of the smartphone and digital consumer services. Telecoms used to generate billions of dollars in profits from short message service (SMS) products, a market that dropped significantly in just a few years thanks to WhatsApp, Facebook Messenger, and others.

Existing IT contracts focused on improving efficiency in backend processing, such as billing; no internal skill was available to design and deliver new services to customers; and existing organizational structures and processes squashed any innovation that was living to happen. Eventually , telecoms were left with providing "dumb data pipes" in a downward price spiral while digital companies enjoyed almost trillion dollar valuations and rich profit margins. Experience software architects know that too many external dependencies get you in trouble. The same is true for organizations."

"Other factors surely played a role in telecoms missing the "digital boat," but believing that technology skills can be acquired as needed is particularly dangerous. Just like you cannot buy friends, a company cannot buy motivated employees. Candidates with highly marketable skill sets, such as cloud architecture or machine learning, are attracted to teams with strong, like-minded people. This presents traditional companies with a chicken-and-egg problem.

Many companies try to overcome this hurdle by paying higher salaries, However, compensation is often not the main motivator for top candidates; they are looking for an employer where they can learn from their peers and have the freedom to implement projects rapidly. That's why it's difficult for companies to "buy" skilled employees.

Worse yet, trying to attract talent by offering higher salaries can backfire because it will attract "mercenary" developers who work for the money alone. My experience is that people who come for money leave for more money. It won't attract passionate developers who want to be part of a high-performing team to change the world. I compare this pitfall to the unpopular kid handing out candy at school: the kid won't make friends, but will be surrounded by children who are willing to pretend to be a friend in exchange for candy."

"Email
Inboxes fill up with items that would take you a mere three minutes to take care of, but that you don't get to for several days because you are highly "utilized" in meetings all day. Stuff often rots in my inbox queue for weeks.

Software releases
Code that is written and tested but waiting for a release is sitting in a queue, sometimes for six months.

Workflow
Many processes ranging from getting an  invoice paid to requesting a raise for employees, have excessive wait times built in. For example, ordering a book takes large companies multiple weeks, as opposed to having it delivered the next day from Amazon.

To get a feeling for the damage done by queues, consider that ordering a server often takes four weeks or more. The infrastructure team won't actually bend metal to build a brand-new server just for you: most servers are provisioned as VMs these days (thanks to software eating the world). If you reasonably assume that there are four hours of actual work in setting up a server consisting of assigning an IP address, loading an operating system image, and doing some nonautomated installations and configurations, the time spent in the queue makes up 99.4% of the total time! That's why we should look at the queues. Reducing the four hours of effort to two won't make any difference unless you reduce the wait times."