Software Architecture Conference Highlights 2020

Image by Speedy McVroom from Pixabay

I recently had the chance to attend the O’Reilly Software Architecture Conference NYC 2020. I think the goal of that conference is to remind us to make software architecture matter. These days software architecture is at the core of nearly every branch of technology. Besides, it seems that the breadth of knowledge I need, to not seem extra perplexed during architectural reviews, is expanding every year. Regularly sharpening the saw is a necessity.

This conference strikes a nice balance. It introduces the latest in architecture and design, while at the same time providing guidance for legacy software that needs to be modernized. It merges topics related to micro-services, cloud computing, and serverless, with nascent trends in AI, machine learning, and data analytics.

The top themes this conference discussed:

• How to deal with the challenges of deciding to migrate micro-services.
• What is the plan when actually migrating to micro-services.
• How to extract and wrap your mind around system architectural complexity.
• What is the vocabulary to talk constructively about the complexities of the system you are working on.
• How to focus on the business value systems bring to the table, and using that to guide the organization towards all the great ilities needed to scale software products.

Here are some super summarized highlights from the sessions I liked:

Day 1

Designing Great APIs Tutorial — Mike Amundsen

• Know your audience. Internal devs with a deadline, Partner with an SLA, or Third-party users that you will never talk to
• The REST dissertation is 20 years old and still the workhorse of the internet

• Avoiding “Norman’s doors” is important to reduce confusion
• API design: Interview each stakeholder separately, record their thoughts, and then interview them as a group. Similar to what would happen in event storming.Focus on Purpose, Data, Actions, and Processes.

USE THE AUDIENCE’S LANGUAGE: Remember to find the “Ubiquitous Language” from DDD.

• Publish all the docs as they are getting built.

Day 2

The Elephant in the Architecture — Martin Fowler

• Learn about your business.
• Find the business impact of the software you are building.

Determine how much value depends on the system. However, value is not only about money.

• Use tools such as the Value Stream Mapping and Customer Journey to map the value of the software you work on.
• Value is not only about money: Online Engagement, and Airlines timely flight info are also valuable.
• Determine where things can go wrong, and what is the impact of that? What is the impact on a retailer of a variable-length DB restore on Black Friday?
• Make Technical decisions towards helping Business decision.
• The CAP Theorem is a business decision. Determine the value of double bookings vs. cancellations vs. refunds.
• The divorce between the business side and the technical side is a sad state of affairs.
• Tech Radar 2020: https://assets.thoughtworks.com/assets/technology-radar-vol-21-en.pdf

Report from the Trenches — Rachel Laycock

Get to know the team. It is much easier to talk to infra guys at 2 AM when you previously met them personally and got them comfortable with you.

• Avoid the anti-pattern silver bullet thinking. There are only tradeoffs, there are no silver bullet solutions.
• What is the next big thing?
• Less than 8% of workloads are on the cloud: Cloud migrations.
• Carbon emission non-functional cross functional concern of architecture: Carbon emission.
• Rising impact of uncontrolled open source inclusion on software maintainability due to cyclic dependencies.

Technical Debt: A Master Class — R0ml Lefkowitz

• Hard to get advice inside existing organizations: Ignaz Semmelweis ended up in a mental hospital for trying to convince doctors to wash their hands between patients to avoid cross-infections.

Tech Debt metaphor was built to make IT relevant to the C-suite.

• Martin Fowler: Unlike money, it is impossible to measure. We CannotMeasureProductivity
• The latest crystal ball estimates are at 2.82$ per line of code of technical debt. :)
• Software Tech Debt is really about Software Tech Risk
• The borrowing comes from using open source code.

During a bug report or an outage, does the external OSS code you include in your application count as your responsibility?

• The goal is to remove dependencies.
• The number of lines of code in your systems divided by 25000 equals the number of people in your technology organization.
• The useful life of a software engineer is 2 years. Enough time to write the 25000 lines of code, and the rest is maintaining the 25000 lines of code they wrote.
• Extreme measures: Vendoring. Add all the dependencies to your repo. Take ownership.
• Vendoring was popularized with GO language but caused riots.
• Frameworks are all about bringing the familiar with you.
• Duplicate tech: Any use of Redis in a project that has a database is tech debt.
• How to choose what to keep? Lindy effect: Future life expectancy of a technology or an idea is proportional to its current age.
• Refactoring helps code understanding.

Go faster, be safer: Release velocity and psychological safety — Heidi Waterhouse

• How to convince orgs about the importance of Continuous Deployment?
• Automation allows for Smaller deltas and Smaller bets.
• NON-REQUIREMENTS: all the stuff that product does not know about.

Deployment is different than Release!

• Deployment is the mechanics of moving a new application version to a production-ready runtime.
• Release is a business decision. Should we make this new version the live version?
• Microsoft method: Code not done until it is released, and returning metrics.

Serverless architecture patterns: The awkward early years

• Distinction between Backend as a service BaaS and Functions as a service FaaS.

Serverless is new enough that we’re still learning new ways of doing things

• Bag of patterns from the 5 years of working with serverless infra.

• Feature patterns: Image Resizer. Issues with latency and cost at high throughput.

• Architecture patterns: API. Issues with latency and cost at high throughput.

• Architecture patterns: Serverless Data Pipeline. Minor issues with latency and cost at high throughput. Go to pattern.

• Service & Function Patterns: Idempotent functions. Using a db to keep state and only-once guarantees. YAGNI.

• Development Patterns: FaaS-free unit tests

• Deployment patterns: Serverless app.

Maturing an Agile organization with intentional architecture — Nimisha Asthagiri

• Contrasting emergent design and intentional architecture.

• Spectrum of options for the arch decisions

• Using Fitness Functions + Incremental Change + Multi-Dimensional to build high performance architectures

• Interesting attempt at an architecture manifesto:

Day 3

Intellectual Control — George Fairbanks

• Distinction between Intellectual control and Statistical control

• Testing numbs us to our loss of reasoning.
• Loss of IC is usually a one way street. SC is contagious. Dependents of an SC component also become SC even if they started their life as IC.
• Zombie projects are dead but they don’t know it yet.

• Statistical control numbs to our loss of Intellectual control.
• We want a balance between IC and SC.

Architecture.Next: Invalidating old axioms Michael Richards

Talk Slides

• Myth buster session.
• Software architecture is a separate activity from software development. NOT.

• Software architects should adopt and follow best practices in software architecture. NOT. There are no best practices, only tradeoffs.

• Software architecture is the foundational structure of a system and therefore should not undergo frequent change. NOT.

• Use the concept of Architecture Stories.
• Reference book:

Microservices migration patterns:

Talk Slides

• Don’t move classes, move components.
• Identify component dependencies using the metafor of: golf ball, basketball, airliner
• Analysing system dependencies

• Fancy code city tooling:

• Service-based vs micro-services:

• Migration pattern:

• Breaking Data dependencies is the hardest step. Cross-over tables, multi-table joins. Split, Orchestrate, Consolidate, repeat.

Metrics for Software-Architects — Alexander von Zitzewitz

Software metrics can be used effectively to judge the maintainability and architectural quality of a code base.

• ACD Average Component Dependency: Measures Coupling relationship with dependency inversion
• PC Propagation Cost: Average fan in but depends on the size of the system. Considered a good smell test.
• ML Maintainability level: Measures coupling and cyclic dependencies. Verticalization minimize dependencies between vertical domains.
• Architecture metrics: Abstractness vs Instability metrics from R. C. Martin books
• Component Rank: Applying Google’s page rank to software components.
• Hard to extract automatically with tool when code is adhoc. Free form URL or non-statically typed languages.

That concludes my highlights for this software architecture conference 2020!

I hope you found this conference report useful. The next architecture conference is here: https://conferences.oreilly.com/software-architecture/sa-ca.

Until next time, don’t forget to be awesome!