Speakers: Mark Richards (markrichardssa) & Neal Ford (neal4d)

For more see the table of contents

Architectural Nexûs

• Need to recognize intersections (I didn’t type “intersection” repeatedly, but they used the word many times)
• How many architectures to screw in a lightbulb? None; it’s an implementation detail
• Implementation needs to be fault tolerant; not just architecture
• Engineering practices need to be agile
• Team topology makes hard to implement certain types of architectures
• Often ignore data topologies and system architecture
• “The enterprise” – processes, standards, frameworks from dept, division, enterprise enforcing for many reasons; usually good
• Business environment – ex: cost cutting mode vs aggressively expanding, rate of change in business or marketplace. Software must be flexible enough to change as business changes to achieve goals. Cannot be bottleneck
• Generative AI – can apply governance, find inefficiencies in architectures, etc. This is the fourth trend in this session
• Architecture can’t live along which is why often system just don’t work
• Mechanical sympathy – use tool so works at it’s best. ex: bytecode so small, avoid context switching. On prem storage is expensive and CPU is cheap so use CPU to break up data. The opposite is true in the cloud. CPU is more expensive. Ex: we don’t question normalizing data, but new topologies don’t always follow them.

Automated Governance and Fitness Functions

• We write tests every day. And if you don’t watch out for Venkat 🙂
• We do a good job testing functionality
• How do you test structural integrity of architecture? Elasticity? Maintainability?
• Fitness function – objectively evaluates an architectural characteristics
• Operational fitness functions – availability, scalability, etc. Scalability problems manifest as responsiveness problems
• Structural fitness functions – bridge is fine as cars drive over it. Until it’s not.
• ArchUnit in Java, ArchUnit and NeArchTest for .NET, PyTestArch for Python, TSArch for JavaScript/TypeScript. Get AI does a good job generating the tests
• ArchUnit example for structural integrity were the package dependency ones [these seem like the easiest ones to write]
• Data fitness functions – ex: foreign key constraint across databases, checksum to ensure data consistency
• Process fitness functions – ex: testability measured by error rates
• https://blog.hello2morrow.com/2018/12/a-promising-new-metric-to-track-maintainability/
• Architecture as code

Aspect oriented architecture

• Spring uses AOP as output
• Hexagonal architecture – loose coupling to separate plumbing from domain stuff. Alistair Cockburn drew a hexagon when talking about it, but too late, it stuck. Almost got it right. Can’t treat database as a separate thing. Most people use a shorthand for separating domain and plumbing.
• Don’t need hexagonal architecture anymore. [yet new book on it: Hexagonal Architecture Explained ]
• Need data to be in context. Microservices preserve this boundary
• Service mesh
• Data mesh – operational vs analytical data, However, can’t build an analytics sidecar. Instead build cooperative quantum
• Sidecar/mesh pattern – can build aspect oriented architecture.
• Governance mesh. Ad hoc governance/fitness function all over. ex: logging, monitoring, circuit breaker
• join point – governance mesh
• pointcut – holistic capabilities like observability
• advice – fitness functions

AI ∩ Architecture

• Updating thoughtworks tech radar.
• AI came up a lot, but only one is in adopt which requires maturity
• Categories – AI assistant software dev, local inference, fine tuning, inference, cloud services, evals and guard rails, structures outputs, prompts, information retrieval , observability for LLM, building agendas
• Easy to make a talking dog. Hard to get it to talk right in prod. Also hard to get the talking dog to call an API
• Vector database used for LLMs
• Guard rails – how prevent from doing something shouldn’t
• Eval – how well doing
• More expensive LLM can validate results of cheaper LLM

How four trends related

• Can use fitness functions to validate code generated by LLMs
• Architecture as code and fitness functions describe intersections. Need executable, not diagrams
• Once critical mass of fitness functions, have governance mesh
• Systems are too large; can’t manually validate
• When Log4J, people asked architects what in product and didn’t know [solution to that is a tool. don’t need governance mesh. I agree with the point, but not a fan of the example]

My take

I like that they covered a variety of topics while also getting into code for ArchUnit