Building Evolutionary Architectures Quotes

“One of the key items the security fitness function checks is staleness of data,”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Holistic fitness functions run against a shared context and exercise a combination of architectural aspects. Developers design holistic fitness functions to ensure that combined features that work atomically don’t break in real-world combinations.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“we formerly considered all the different architecture verification mechanisms as separate—​code quality versus DevOps metrics versus security, and so on. Fitness functions unify many existing concepts into a single mechanism, allowing architects to think in a uniform way about many existing (often ad hoc) “nonfunctional requirements” tests. Collecting important architecture thresholds and requirements as fitness functions allows for a more concrete representation for previously fuzzy, subjective evaluation criteria. We leverage a large number of existing mechanisms to build fitness functions, including traditional testing, monitoring, and other tools. Not all tests are fitness functions, but some tests are—​if the test helps verify the integrity of architectural concerns, we consider it a fitness function.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“including requirements around performance, reliability, security, operability, coding standards, and integration, to name a few.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Consider something like a failover for a database from a hard failure. While the recovery itself might be fully automated (and should be), triggering the test itself is likely best done manually. Additionally, it might be far more efficient to determine the success of the test manually, although developers should still encourage scripts and automation.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“the fitness functions for evolutionary architecture may not be implementable in software (e.g., a required manual process for regulatory reasons). An architectural fitness function is an objective measure, but architects may implement that measure in a wide variety of ways.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Don’t mistake the function part of our definition as implying that architects must express all fitness functions in code.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“ArchUnit”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Security—​even if supervised by another part of the organization—”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“most companies bigger than a certain size have an entire department dedicated to managing domain evolution, called quality assurance: ensuring that existing functionality isn’t negatively affected by changes.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“software architecture is defined as “the parts that are hard to change later.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“practices invalidate that premise by making change less expensive”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Part of the traditional reasoning behind making long-term plans was financial; software changes were expensive.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Some dimensions fit into what are often called architectural concerns (the list of “-ilities” referred to earlier),”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“These are all examples of dimensions of architecture—”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Architectural decisions are ones in which each choice offers significant trade-offs.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“We use the term architecture characteristics throughout the book to refer to nondomain design considerations. However, many organizations use other terms for this concept, among them nonfunctional requirements, cross-cutting requirements, and system quality attributes.”
― Neal Ford, Building Evolutionary Architectures: Automated Software Governance

“Metrics are a common adjunct to the deployment pipeline in incremental change environments. If teams use this effort as a proof-of-concept, developers should gather appropriate metrics for both before and after scenarios. Gathering concrete data is the best way to for developers to vet the approach; remember the adage that demonstration defeats discussion.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“The other new role that evolutionary architecture creates has enterprise architects defining enterprise-wide fitness functions. Enterprise architects are typically responsible for enterprise-wide nonfunctional requirements, such as scalability and security. Many organizations lack the ability to automatically assess how well projects perform individually and in aggregate for these characteristics. Once projects adopt fitness functions to protect parts of their architecture, enterprise architects can utilize the same mechanism to verify that enterprise-wide characteristics remain intact.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“For any dimension in our architecture that requires protection from the side effects of evolution, we create fitness functions. A common practice in microservices architectures is the use of consumer-driven contracts, which are atomic integration architecture fitness functions.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“All too often architects make a decision that is the correct decision at the time but becomes a bad decision over time because of changing conditions like dynamic equilibrium. For example, architects design a system as a desktop application, yet the industry herds them toward a web application as users’ habits change. The original decision wasn’t incorrect, but the ecosystem shifted in unexpected ways.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“By placing an external tool or framework at the heart of the architecture, developers severely restrict their ability to evolve in two key ways, both technically and from a business process standpoint. Developers are technically constrained by choices the vendor makes in terms of persistence, supported infrastructure, and a host of other constraints.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“Even if the ecosystem doesn’t change, what about the gradual erosion of architectural characteristics that occurs? Architects design architectures, but then expose them to the messy real world of implementing things atop the architecture. How can architects protect the important parts they have defined?”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“Developers understand the benefits of everything and the tradeoffs of nothing!
Rich Hickey, creator of Clojure”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“This manifests in two ways. First, many senior developers start writing the infrastructure that other developers use, rather than using existing (often open source) software. We once worked with a client who had once been on the cutting edge of technology. They built their own application server, web framework in Java, and just about every other bit of infrastructure. At one point, we asked if they had built their own operating system, too, and when they said, “No,” we asked, “Why not?!? You built everything else from scratch!” Upon reflection, the company needed capabilities that weren’t available. However, when open-source tools became available, they already owned their lovingly hand-crafted infrastructure. Rather than cut over to the more standard stack, they opted to keep their own because of minor differences in approach. A decade later, their best developers worked in full-time maintenance mode, fixing their application server, adding features to their web framework, and other mundane chores. Rather than applying innovation on building better applications, they permanently slaved away on plumbing.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change

“DBAs who rarely genuinely restructure schemas build an increasingly fossilized world, with byzantine grouping and bunching strategies. When DBAs don’t restructure the database, they’re not preserving a precious enterprise resource, they’re instead creating the concretized remains of every version of the schema, all overlaid upon one another via join tables.”
― Neal Ford, Building Evolutionary Architectures: Support Constant Change