Posts Tagged ‘Thoughtworks’
[DevoxxBE2025] Architecture as Code: Quantifying Architectural Trade-offs
Lecturer
Neal Ford occupies the role of Director and Software Designer at Thoughtworks, a worldwide tech advisory firm. He has penned multiple seminal texts on software design, such as Fundamentals of Software Architecture co-authored with Mark Richards. Neal routinely addresses global gatherings on nimble methodologies and design progression.
Abstract
This discourse probes the notion of architecture codified, a schema for articulating and supervising software blueprints via operable constructs like fitness evaluators. Stemming from current literary endeavors, it surveys intersections between design and diverse organizational facets, encompassing realization, provisioning, information layouts, procedural norms, group arrangements, amalgamation, commercial milieus, and institutional imperatives. The inquiry accentuates pseudo-script and generative intelligence for verifiable design intents, prioritizing response over stringent validation. Ramifications for nimble progression, expandability, and intelligent agent amalgamation are dissected, offering perspectives on alleviating compromises in intricate setups.
Setting and Progression of Design Conceptualization
Software blueprints have traditionally been conveyed via schematics and pictorial depictions, yet ascertaining congruence between blueprint and enactment persists as a enduring obstacle. Designers must not solely forge nascent setups but also perpetually oversee extant ones amid fluctuating technological and commercial terrains. This supervisory capacity situates designers distinctively, bridging proficiencies, commercial motivators, restrictions, and instrumental arrays. The convergences—junctures where blueprint overlaps with additional institutional aspects—constitute a intricate hub, or plural hubs, as manifold overlapping centers sway design resolutions.
Chronologically, blueprint delineations have depended on immobile relics, yet this tactic falters in fluid settings. The inception of blueprint fitness evaluators, initially elaborated in tomes like Building Evolutionary Architectures, signifies a transition toward operable supervision. These evaluators function as impartial authenticators for blueprint concerns, transcending unitary validations to incorporate functional gauges like expandability. By conceiving blueprint as script, designers can articulate intents declaratively, facilitating mechanized authentication and prompt response. This tactic harmonizes with nimble tenets, where premature divergence detection cultivates enlightened dialogues rather than corrective sanctions.
The impetus derives from measuring compromises, a central motif in antecedent works like Fundamentals of Software Architecture. Compromises are intrinsic; no selection lacks downsides, but operable delineations permit proactive downside attenuation. For example, in distributed services, information accuracy surfaces as a vital convergence, necessitating eventual coherence over transactional assurances. This setting highlights the necessity for platform-neutral tactics, where pseudo-script acts as an intentional schema, convertible into tangible enactments via instruments like generative intelligence.
Procedural Schema: Fitness Evaluators and Definition Dialect
Central to this tactic resides the blueprint fitness evaluator, a device for authenticating configurational, functional, and procedural elements. Diverging from conventional validations, which indicate lapses demanding instant rectification, fitness evaluators serve as discourse initiators. They furnish stand-ins for dialogue when enactments deviate from intent, assuring divergences are rectified swiftly—preferably contemporaneously, not belatedly in deployment.
To systematize these convergences, an Architecture Definition Dialect (ADD) is advocated: a slender, declarative pseudo-script devoid of formal syntax or compiler. ADD assertions delineate setups, realms, and validations, such as stipulating element affiliations or functional thresholds. For instance:
delineate setup ReservationSetup
delineate realm Reservation
delineate realm Patron
delineate realm Questionnaire
validate all elements inhabit Reservation, Patron, Questionnaire
This pseudo-script, when refined by generative intelligence like conversational AI, produces tangible fitness evaluators in dialects such as Java (utilizing ArchUnit) or .NET (utilizing NetArchTest). In Java:
Architectures.stratifiedArchitecture()
.stratum("Reservation").delineatedBy("com.sample.reservation")
.stratum("Patron").delineatedBy("com.sample.patron")
.stratum("Questionnaire").delineatedBy("com.sample.questionnaire")
.authenticate(classes);
Such conversions preserve platform neutrality while imposing configurational soundness, like assuring script resides in appointed folders to thwart unintended element expansion.
Provisioning convergences are managed analogously. For expandability stipulations—e.g., an interface managing 5,000 concurrent patrons with sub-600ms responses—ADD encapsulates results from Blueprint Resolution Logs:
delineate functional Expandability for OrderDispatchInterface
maxPatronLoad = 5000
avgResponseDuration = 600ms
validate avgResponseDuration <= 600ms at maxPatronLoad
Bespoke overseers or observability instruments then authenticate these, graphing patron load versus response durations to spot divergences prematurely.
Information layouts, intensified by distributed services’ per-service repositories, necessitate fitness evaluators for eventual coherence. Fragmenting a repository for resilience might require checksums or key hashes across realms:
delineate setup PatronRepository
delineate setup VoucherRepository
validate vouchers coherent across PatronRepository, VoucherRepository
Scripted authentications assure referential soundness sans relational repository enchantments, treating it as a supervisable pursuit.
Procedural norms, such as unified repository versus per-service repositories, entail attenuating recognized snares like dependency circumvention:
delineate reliances for RestService: Cardiac, Breathing
validate no additional reliances
Instruments like ArchUnit impose this, furnishing response on blueprint progression.
Scrutiny of Convergences and Compromises
Group layouts, as delineated in the homonymous tome, converge with blueprint through formations like flow-oriented, facilitating, intricate-subsetup, and foundational groups. Fitness evaluators gauge effects, such as merge request quantities from auxiliary groups to flow-oriented ones, assuring minimal resistance. Information origins extend to ticketing setups, expanding response scopes.
Setup amalgamation gains from unit scrutiny—delineating deployable entities and reliances:
delineate services: Interface, Generation, Allocation, PortableApp, Fulfillment
validate all reliances within enumerated services
Log dissection discloses lengthiest reliance chains, crucial for synchronous invocation efficacy.
Commercial milieu synchronization employs qualitative assessments of blueprint styles (e.g., stratified vs. microcore) against traits like sustainment:
delineate requisite: Expandability, Expandability, Interoperability
validate blueprint manifests these
This steers style choice predicated on motivators like vigorous growth.
Institutional supervision exploits fitness evaluators for inter-project norms, such as obligatory protection modules:
noDataEntry().ought().entryClassesThat().inhabitInAPackage("com.sample.protection")
Software Inventories augment this.
Generative intelligence’s function, notably agentic proficiencies and Multi-Cloud Protocol (MCP), addresses fragility in universal fitness evaluators. MCP fundamentals—utilities, origins, cues—abstract enactment particulars, permitting elevated intents like “authenticate referential soundness” to adapt across endeavors sans vulnerability.
Ramifications and Prospective Avenues
This response-oriented schema elevates blueprint from immobile to fluid, synchronizing with nimble’s swift-response ethos. It attenuates compromises by pinpointing load-sustaining elements, assuring merit surpasses enactment exertion. Tenets like “what information do I require and where does it reside?” steer proficient supervision.
Prospective ramifications encompass wider embrace of ADD-like dialects and profounder intelligence amalgamation for automated fitness evaluator fabrication. In agentic milieus, blueprints become more durable, with agents managing particulars while designers concentrate on intent.
In closure, blueprint codified metamorphoses supervision into an operable, authenticable procedure, nurturing congruence across convergences and enabling progressive blueprints in intricate milieus.
Links:
- Lecture video: https://www.youtube.com/watch?v=r9cfeOEgHrM
- Neal Ford on LinkedIn: https://www.linkedin.com/in/nealford/
- Neal Ford on Twitter/X: https://twitter.com/neal4d
- Thoughtworks website: https://www.thoughtworks.com/
[OxidizeConf2024] Safety Compliance of Rust Libraries
Navigating Automotive Safety Standards
The automotive industry’s shift toward software-defined vehicles has intensified the need for robust safety compliance, particularly for software components used in safety-critical applications. At OxidizeConf2024, Amit Dharmapurikar and Gnana Ganesh from Thoughtworks delivered an insightful presentation on qualifying Rust libraries for compliance with ISO 26262, a standard governing functional safety in automotive systems. With Thoughtworks’ expertise in software-defined vehicles, Amit and Gnana provided a comprehensive overview of the processes and tools required to ensure Rust libraries meet stringent safety requirements, focusing on the Rust Core library as a case study.
ISO 26262 mandates rigorous documentation, requirement coverage, and structural code coverage to ensure software reliability in electronic control units (ECUs). Amit emphasized that while the Ferrocene compiler, developed by Ferrous Systems, has already achieved safety compliance, libraries—both standard and third-party—must also be qualified. This involves producing formal specifications, verifying requirements through testing, and generating code coverage reports. The speakers highlighted the collaborative effort with Ferrous Systems to qualify the Rust Core library, underscoring the importance of aligning open-source tools with automotive standards.
Documentation and Requirement Coverage
A cornerstone of ISO 26262 compliance is comprehensive documentation, which serves as a formal specification of software components. Gnana detailed how Thoughtworks approaches this by deriving testable requirements from the Rust Core library’s standard documentation. This process involves translating descriptive text into precise, verifiable requirements, a task that poses challenges due to the library’s frequent updates as an open-source project. To address this, Amit and Gnana proposed developing tools to automate the interpretation of documentation changes, ensuring that requirements remain aligned with the library’s evolution.
Requirement coverage, as mandated by ISO 26262 Part 6, ensures that all functional requirements are tested. The speakers demonstrated a proof-of-concept where requirements for the Rust Core library were linked to test cases, providing traceability essential for audits. This approach leverages open-source tools like Sphinx, which facilitates bidirectional traceability by connecting requirements to code. By integrating these tools into the development pipeline, Thoughtworks ensures that compliance artifacts are generated iteratively, reducing manual effort and enhancing accountability.
Advancing Code Coverage with Rust Tooling
Structural code coverage is another critical aspect of ISO 26262 compliance, requiring developers to measure how thoroughly code is exercised by tests. Amit showcased a demo using the Rust toolchain’s coverage capabilities, specifically the --coverage flag in the test subcommand. This flag, combined with a custom bootstrap command (dotx), embeds profiler builtins into executables, generating profile files that tools like grcov process into coverage reports. The demo illustrated coverage analysis for the Rust Core library, excluding documentation to focus on executable code.
While statement coverage is already supported, Gnana noted that branch coverage is available in draft pull requests, and Modified Condition/Decision Coverage (MCDC) is in progress within the Rust community. These advancements, driven by initiatives like Ferrocene, demonstrate Rust’s growing maturity for safety-critical applications. The speakers acknowledged challenges, such as managing frequent library updates, but emphasized the potential of automated tools to streamline compliance, making Rust a viable choice for automotive software development.
Links:
[DevoxxUK2024] How We Decide by Andrew Harmel-Law
Andrew Harmel-Law, a Tech Principal at Thoughtworks, delivered a profound session at DevoxxUK2024, dissecting the art and science of decision-making in software development. Drawing from his experience as a consultant and his work on a forthcoming book about software architecture, Andrew argues that decisions, both conscious and unconscious, form the backbone of software systems. His talk explores various decision-making approaches, their implications for modern, decentralized teams, and introduces the advice process as a novel framework for balancing speed, decentralization, and accountability.
The Anatomy of Decision-Making
Andrew begins by framing software architecture as the cumulative result of myriad decisions, from coding minutiae to strategic architectural choices. He introduces a refined model of decision-making comprising three stages: option making, decision taking, and decision sharing. Option making involves generating possible solutions, drawing on patterns, stakeholder needs, and past experiences. Decision taking, often the most scrutinized phase, requires selecting one option, inherently rejecting others, which Andrew describes as a “wicked problem” due to its complexity and lack of a perfect solution. Decision sharing ensures effective communication to implementers, a step frequently fumbled when architects and developers are disconnected.
Centralized Decision-Making Approaches
Andrew outlines three centralized decision-making models: autocratic, delegated, and consultative. In the autocratic approach, a single individual—often a chief architect—handles all stages, enabling rapid decisions but risking bottlenecks and poor sharing. Delegation involves the autocrat assigning decision-making to others, potentially improving outcomes by leveraging specialized expertise, though it remains centralized. The consultative approach sees the decision-maker seeking input from others but retaining ultimate authority, which can enhance decision quality but slows the process. Andrew emphasizes that while these methods can be swift, they concentrate power, limiting scalability in large organizations.
Decentralized Decision-Making Models
Transitioning to decentralized approaches, Andrew discusses consent, democratic, and consensus models. The consent model allows a single decision-maker to propose options, subject to veto by affected parties, shifting some power outward but risking gridlock. The democratic model, akin to Athenian direct democracy, involves voting on options, reducing the veto power of individuals but potentially marginalizing minority concerns. Consensus seeks universal agreement, maximizing inclusion but often stalling due to the pursuit of perfection. Andrew notes that decentralized models distribute power more widely, enhancing collaboration but sacrificing speed, particularly in consensus-driven processes.
The Advice Process: A Balanced Approach
To address the trade-offs between speed and decentralization, Andrew introduces the advice process, a framework where anyone can initiate and make decisions, provided they seek advice from affected parties and experts. Unlike permission, advice is non-binding, preserving the decision-maker’s autonomy while fostering trust and collaboration. This approach aligns with modern autonomous teams, allowing decisions to emerge organically without relying on a fixed authority. Andrew cites the Open Agile Architecture Framework, which supports this model by emphasizing documented accountability, such as through Architecture Decision Records (ADRs). The advice process minimizes unnecessary sharing, ensuring efficiency while empowering teams.
Navigating Power and Accountability
A recurring theme in Andrew’s talk is the distribution of power and accountability. He challenges the assumption that a single individual must always be accountable, advocating for a culture where teams can initiate decisions relevant to their context. By involving the right people at the right time, the advice process mitigates risks associated with uninformed decisions while avoiding the bottlenecks of centralized models. Andrew’s narrative underscores the need for explicit decision-making processes, encouraging organizations to cultivate trust and transparency to navigate the complexities of modern software development.
Links:
[OxidizeConf2024] Continuous Compliance with Rust in Automotive Software
Introduction to Automotive Compliance
The automotive industry, with its intricate blend of mechanical and electronic systems, demands rigorous standards to ensure safety and reliability. Vignesh Radhakrishnan from Thoughtworks delivered an insightful presentation at OxidizeConf2024, exploring the concept of continuous compliance in automotive software development using Rust. He elucidated how the shift from mechanical to software-driven vehicles has amplified the need for robust compliance processes, particularly in adhering to standards like ISO 26262 and Automotive SPICE (ASPICE). These standards are pivotal in ensuring that automotive software meets stringent safety and quality requirements, safeguarding drivers and passengers alike.
Vignesh highlighted the transformation in the automotive landscape, where modern vehicles integrate complex software for features like adaptive headlights and reverse assist cameras. Unlike mechanical components with predictable failure patterns, software introduces variability that necessitates standardized compliance to maintain quality. The presentation underscored the challenges of traditional compliance methods, which are often manual, disconnected from development workflows, and conducted at the end of the development cycle, leading to inefficiencies and delayed feedback.
Continuous Compliance: A Paradigm Shift
Continuous compliance represents a transformative approach to integrating safety and quality assessments into the software development lifecycle. Vignesh emphasized that this practice involves embedding compliance checks within the development pipeline, allowing for immediate feedback on non-compliance issues. By maintaining documentation close to the code, such as requirements and test cases, developers can ensure traceability and accountability. This method not only streamlines the audit process but also reduces the mean-time-to-recovery when issues arise, enhancing overall efficiency.
The use of open-source tools like Sphinx, a Python documentation generator, was a focal point of Vignesh’s talk. Sphinx facilitates bidirectional traceability by linking requirements to code components, enabling automated generation of audit-ready documentation in HTML and PDF formats. Vignesh demonstrated a proof-of-concept telemetry project, showcasing how Rust’s cohesive toolchain, including Cargo and Clippy, integrates seamlessly with these tools to produce compliant software artifacts. This approach minimizes manual effort and ensures that compliance is maintained iteratively with every code commit.
Rust’s Role in Simplifying Compliance
Rust’s inherent features make it an ideal choice for automotive software development, particularly in achieving continuous compliance. Vignesh highlighted Rust’s robust toolchain, which includes tools like Cargo for building, testing, and formatting code. Unlike C or C++, where developers rely on disparate tools from multiple vendors, Rust offers a unified, developer-friendly environment. This cohesiveness simplifies the integration of compliance processes into continuous integration (CI) pipelines, as demonstrated in Vignesh’s example using CircleCI to automate compliance checks.
Moreover, Rust’s emphasis on safety and ownership models reduces common programming errors, aligning well with the stringent requirements of automotive standards. By leveraging Rust’s capabilities, developers can produce cleaner, more maintainable code that inherently supports compliance efforts. Vignesh’s example of generating traceability matrices and architectural diagrams using open-source tools like PlantUML further illustrated how Rust can enhance the compliance process, making it more accessible and cost-effective.
Practical Implementation and Benefits
In his demonstration, Vignesh showcased a practical implementation of continuous compliance using a telemetry project that streams data to AWS. By integrating Sphinx with Rust code, he illustrated how requirements, test cases, and architectural designs could be documented and linked automatically. This setup allows for real-time compliance assessments, ensuring that software remains audit-ready at all times. The use of open-source plugins and tools provides flexibility, enabling adaptation to various input sources like Jira, further streamlining the process.
The benefits of this approach are manifold. Continuous compliance fosters greater accountability within development teams, as non-compliance issues are identified early. It also enhances flexibility by allowing integration with existing project tools, reducing dependency on proprietary solutions. Vignesh cited the Ferrocene compiler as a real-world example, where similar open-source tools have been used to generate compliance artifacts, demonstrating the feasibility of this approach in large-scale projects.
Links:
[DevoxxBE2012] When Geek Leaks
Neal Ford, a software architect at ThoughtWorks and author known for his work on enterprise applications, delivered a keynote exploring “geek leaking”—the spillover of deep expertise from one domain into another, fostering innovation. Neal, an international speaker with insights into design and delivery, tied this concept to his book “Presentation Patterns,” but expanded it to broader intellectual pursuits.
He defined “geek” as an enthusiast whose passion in one area influences others, creating synergies. Neal illustrated with examples like Richard Feynman’s interdisciplinary contributions, from physics to biology, showing how questioning fundamentals drives breakthroughs.
Neal connected this to software, urging developers to apply scientific methods—hypothesis, experimentation, analysis—to projects. He critiqued over-reliance on authority, advocating first-principles thinking to challenge assumptions.
Drawing from history, Neal discussed how paradigm shifts, like Galileo’s heliocentrism, exemplify geek leaking by integrating new evidence across fields.
In technology, he highlighted tools enabling this, such as domain-specific languages blending syntaxes for efficiency.
Origins of Intellectual Cross-Pollination
Neal traced geek leaking to Feynman’s life, where physics informed lock-picking and bongo playing, emphasizing curiosity over rote knowledge. He paralleled this to software, where patterns from one language inspire another.
He referenced Thomas Kuhn’s “Structure of Scientific Revolutions,” explaining how anomalies lead to paradigm shifts, akin to evolving tech stacks.
Applying Scientific Rigor in Development
Neal advocated embracing hypotheses in coding, testing ideas empirically rather than debating theoretically. He cited examples like performance tuning, where measurements debunk intuitions.
He introduced the “jeweler’s hammer”—gentle taps revealing flaws—urging subtle probes in designs to uncover weaknesses early.
Historical Lessons and Modern Tools
Discussing Challenger disaster, Neal showed Feynman’s simple demonstration exposing engineering flaws, stressing clarity in communication.
He critiqued poor presentations, linking to Edward Tufte’s analysis of Columbia shuttle slides, where buried details caused tragedy.
Neal promoted tools like DSLs for expressive code, and polyglot programming to borrow strengths across languages.
Fostering Innovation Through Curiosity
Encouraging geek leaking, Neal suggested exploring adjacent fields, like biology informing algorithms (genetic programming).
He emphasized self-skepticism, quoting Feynman on fooling oneself, and applying scientific method to validate ideas.
Neal concluded by urging first-principles reevaluation, ensuring solutions align with core problems, not outdated assumptions.
His keynote inspired developers to let expertise leak, driving creative, robust solutions.