The Software Architect Elevator

My personal notes on the book The Software Architect Elevator by Gregor Hohpe.

The Architect

• Architects deal with non-requirements: it refers to requirements that aren’t stated anywhere. This includes context, tacit assumptions, hidden dependencies, and other things that were never spelled out.
• Architects play a critical role as a connecting and translating element, especially in large organizations where departments speak different languages, have different viewpoints, and drive toward conflicting objectives.
• Architects can fill an important void in large enterprises: they work and communicate closely with technical staff on projects, but are also able to convey technical topics to upper management without losing the essence of the message. Conversely, they understand the company’s business strategy and can translate it into technical decisions that support it.
• Periodic gluing, gardening, guiding, impressing, and a little bit of all-knowing every now and then can make for a pretty good architect.
• Defining a system’s architecture is a balancing act between many, often-conflicting goals: flexible systems can be complex; high-performing systems can be difficult to understand; easy-to-maintain systems can take more effort to construct initially.
• Rate of change is a major driver of architecture’s value and architectural decisions.
• A software system’s first derivative is its build and deployment toolchain.
• Knowing that the software toolchain is the first derivative, increasing a software system’s rate of change requires a well-tuned toolchain
• When designing a system for change, it’s again helpful to think about the opposite - the aspects that impede change:
  • Dependencies: too many interdependencies between a system’s components will result in small changes needing adjustments in many places, increasing both effort and risk.
  • Friction: both cost and risk of change increase with friction, generated, for example, by long lead times for infrastructure provisioning or numerous manual deployment steps.
  • Poor quality: There’s a common misbelief that good quality requires extra time and effort. The inverse is actually true: poor quality slows down software delivery.
  • 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. If fear slows you down, confidence should speed you up.
  • Automated tests 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.
• The business architecture essentially defines the company operating model, including how business areas are structured and integrated, derived from the business strategy. Meanwhile, the IT architecture builds the corresponding IT capabilities.
• The best way to learn something is to apply it to a real-world problem.
• Making decisions is a critical part of an enterprise-scale architect’s job. Being a good architect therefore warrants a conscious effort to becoming a better decision maker.
• “The law of small numbers”; people tend to jump to conclusions based on sample sizes that are way too small to be significant. Alas, not all data leads to better decisions.
• Prospect theory: when faced with an opportunity, people tend to favor a smaller but guaranteed gain over the 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 aversion.
• Decision trees are very simple models that help us make more rational decisions.
• With all this science behind decision making, what’s the best decision? It’s the one that you don’t need to take! That’s what Martin Fowler indicated when he observed that “one of an architect’s most important tasks is to eliminate irreversibility in software designs.”
• Five Whys
  • It’s a technique to get to the root cause of an issue by repeatedly asking why something happened.
  • The technique can be quite useful but requires discipline because people can be tempted to inject their own preferred solutions or assumptions into their answers.
  • When conducting architecture reviews, “why” is a useful question because it helps draw attention to the decisions that were made as well as the assumptions and principles that led to those decisions.
  • Uncovering the assumptions that led to a decision can provide much insight and increase the value of an architecture review.
  • Unstated assumptions can be the root of much evil if the environment has changed since the assumptions were made.
• Asking questions in traditional organizations might not get you insights but defensiveness to cover up the lack of decision discipline. For example, you can redefine the expectations for architecture documentation and obtain management buy-in for doing so; for example, to increase transparency. If satisfactory documentation isn’t produced before the meeting, the workshop must be canceled. The actual workshop becomes more effective when you moderate and work off a list of concrete questions.

Architecture

• Three Kinds of Architecture: when speaking about architecture, people routinely refer to three quite different concepts, all of which relate to IT but are very different in nature:
  • A system’s architecture, defined by its structure, as in “microservices architecture”.
  • The act of defining a system’s structure, as in “the architecture committee”.
  • A team that is involved in defining architecture, as in “we’re setting up enterprise architecture”.
• There always is an architecture: it’s simply a matter of whether you consciously choose your architecture or whether you let it happen to you.
• Good architecture can also make a team more productive by allowing concurrent development and testing of components. Generally, good architecture buys you flexibility. In a rapidly changing world, this seems like a smart investment.
• Principles Drive Decisions Architecture is a matter of trade-offs: there rarely is one single “best” architecture.
  • Architects therefore must take the context into consideration when making architectural decisions, because that context will help them weigh the trade-offs against one another.
• Architecture can be defined as the set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity. Rarely is an architecture simply “good” or “bad.” Rather, architecture is fit or unfit for purpose.
• 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.
• 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. A good test is whether the chosen option also has downsides - decisions without downsides are unlikely to be meaningful.
• All meaningful decisions have downsides.
• Instead of entrusting all crucial decisions to one person, a project can be better off by minimizing the number of early and irreversible decisions.
• Architecture options are rarely free. For example, you may pay with increased complexity or loss of another option.
• You need an architecture that can evolve along with your increased understanding of technology and customer needs - an approach that’s described as evolutionary architecture.
• A system’s structure is simply a means to achieve a desired behavior.
• Understanding complex interrelationships between system components and influencing them to achieve a desired behavior is what architects do. Often a good diagram will help.
• Most complex configuration really is just programming, albeit in a poorly designed, rather constrained language without decent tooling or useful documentation.
• Raising the level of abstraction is one of the primary techniques that makes developers’ lives easier. If an abstraction takes away too many or the wrong things, it becomes overly restrictive and no longer applicable. If it takes away too few things, it didn’t accomplish much in terms of simplification and hence isn’t very valuable.
• Rather than trying to anticipate changes for configuration, you may want to invest in your tool chain to allow incremental, rapid deployment.
• Legacy systems are built on outdated technology and are often poorly documented but (ostensibly) still perform important business functions. In many cases, the exact scope of the function they perform is not completely known.
• In today’s environment, the inability to change a system becomes a major liability for IT and the business. The reluctance to upgrade or migrate software is similar to the reluctance to build and test software often. Martin Fowler issued the best advice to break this cycle: “If it hurts, do it more often.”
• Dealing with constant change is painful at times - every piece of code you write could break at any time because of changes in its dependencies. But living this culture of change allows Google to keep up the pace, which is the most important of today’s IT capabilities.
• 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.
• Self-service gives you better control, accuracy, and traceability than semi-manual processes.
• Self-service portals are a major improvement over emailing spreadsheets. However, the best place for configuration changes is the source code repository, where approvals can be handled via pull requests and merge operations.
• Tacit knowledge is knowledge that exists only in employees’ heads but isn’t documented or encoded anywhere. Encoding tacit knowledge, which existed only in an operator’s head, into a set of scripts, tools, or source code makes these processes visible and eases knowledge transfer.
• Software developers don’t undo, they re-create: this mindset stems from software being ephemeral - re-creating it from scratch isn’t a major effort.
• There’s much more to being software defined than a few scripts and configuration files. Rather, it’s about making infrastructure part of your software development life cycle (SDLC). First, make sure your SDLC is fast but disciplined, and automated but quality oriented. Second, apply the same thinking to your software-defined infrastructure;

Communication

• Architects need to focus on a communication style that emphasizes content, but in an engaging and approachable manner.

• Architects must help close the gap between technical knowledge holders and high-level decision makers by clearly communicating the ramifications of technical decisions on the business; for example, through development and operational cost, flexibility, or time-to-market.

• Documentation provides value in numerous ways:

  • Coherence: agreeing on and documenting design principles and decisions improves consistency of decision making and thus preserves the conceptual integrity of the system design.
  • Validation: structured documentation can help identify gaps and inconsistencies in the design.
  • Clarity of thought: you can write only what you have understood.
  • Education: new team members become productive faster if they have access to good documentation.
  • History: decisions are based on a specific context, which may have changed since. Documentation can help you understand that context.
  • Stakeholder communication: architecture documentation can help steer a diverse audience to the same level of understanding.

• Useful documentation doesn’t imply reams of paper, rather the opposite: short documents are more likely to be read. That’s why most technical documents that my teams write are subject to a five-page limit.

• Your source code is highly unlikely to explain your value proposition and your critical decisions to your executive sponsors.

• Every interaction with senior management is also a teaching opportunity. Use it!

• Your role as an architect is to build a broad understanding of the ramifications of decisions and assumptions that were made.

• Technical papers should use a clean layout, insert a handful of expressive diagrams, and, above all, keep it short and to the point!

• In technical writing, your readers are not out to appreciate your literary creativity, but to understand what you are saying. Therefore, less is more when it comes to word count.

• What’s the right scope? One that’s big enough to be meaningful, small enough to be comprehensible, and cohesive enough to make sense.

• Diagrams are models: when discussing architecture diagrams, it’s good to remind ourselves why we draw them in the first place. Architecture diagrams are models of reality. Models, whether maps or architecture diagrams, aren’t about being right or wrong. In fact, they’re all wrong because they aren’t reality. Thus, instead of trying to make models right, you should think about whether your models are useful - for a model to be useful, it needs to help you answer a question or make a better decision.

• To change a system’s observed behavior, you need to change the system itself

• For organizational systems, the systemic behavior is primarily guided by its culture. A significant portion of this culture derives from shared beliefs held by the organization’s members. So, to permanently change an organization’s observed behavior, you need to identify and change those beliefs.

• A good starting point for reverse-engineering an organization’s hidden beliefs are popular slogans.

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