Forwarded this email? Subscribe here for more

Architecture Weekly #153 - 13th November 2023

Oskar Dudycz

Nov 13

READ IN APP

Welcome to the new week!

Are you scared about GDPR? Or maybe annoyed? Do you think that's about user data removal? I have something for you. In the latest article, I went through the common challenges and those that may surprise you and as always provided some guidance on what to do with them. I think that’s a decent guide explaining how to deal with common mishaps.

Oskar Dudycz - GDPR for busy developers

My take on GDPR and related regulations is that they're needed. In IT, we didn't care much about what data we store, how long and what we're doing with them. As we didn't care about the proper Data Governance practices, someone had to force them on us.

Just check those links:

You also had numerous examples in the previous editions.

Regulations don't need to be scary as long as we’re not building our financial model based on our users’ privacy. I think that if we're applying sane data management practices and do it as the default choice, then as a result, we'll get a system that's more maintainable and manageable. And removing user data won't be a big issue.

Speaking about regulations, read a decent explanation from Mark Nottingham of the web regulators’ responsibilities (like W3C) and how we should think about them as architects and technical leads:

Mark Nottingham - Technical Standards Bodies are Regulators

I’m a big fan of the Architecture Decision Record. It increases the transparency of decision-making and makes our documentation easy to maintain, as we don’t maintain it; we just log a new decision (I wrote about it in How to successfully do documentation without a maintenance burden?).

Yet, as with any tool, it’s never just. No, “just use ADRs” is not an answer. Providing a good process around that is challenging (I showed my story here). That’s why I’m happy that we’re also getting lessons-learned articles like:

Pierre Pureur - Has Your Architectural Decision Record Lost Its Purpose?

Pierre Pureur goes into detail on the common challenges around it. He lists three major points where ADRs should not be used for:

Promoting reuse. Some people, managers especially, see the ADRs as a means to enforce reusability. They want to see common components and subsystems reused because they think this will lower cost and simplify development. (…) Promoting reusability is one aspect of knowledge sharing across a development organization, but there are better ways to promote this knowledge sharing than gumming up the ADRs with lots of information about the potential reuse of designs and code.
Responsibility deflection (CYA). Some teams believe that by putting a decision in an ADR they can absolve themselves from the consequences of that decision should it prove wrong. The more people who see and explicitly or tacitly approve an ADR, the more the responsibility for making a poor decision is diluted. There is, they think, safety in numbers. (…) If teams don’t have to fear being blamed for their decisions, they can focus on building better solutions by experimenting instead of using an ADR to inoculate themselves from blame.
Recording non-architectural product decisions. This often happens because teams make important decisions all the time, but if they lack a place to record them they are going to put them in an ADR. Misusing the ADRs in this way makes the architecture harder to perceive: if every decision is architectural, no decision is architectural. Put another way, an ADR that turns into the "Any Decision Record" has lost its purpose.

Great points; I fully agree; I saw that happening. I love the “Any Decision Record” term. Read the whole article; it’s worth it.

Adrian Cockroft is one of the most battle-tested Engineering Managers, a person worth following. He was VP of Cloud Architecture Strategy and was one of the leading people in Netflix’s migration to a large-scale, highly available public-cloud architecture and the open-sourcing of the cloud-native NetflixOSS platform.

In his InfoQ talk, he shared his retrospective on Netflix's impact on spreading the microservices and industry.

Adrian Cockcroft - Microservices Retrospective – What We Learned (and Didn’t Learn) from Netflix

It’s an intriguing talk showing various aspects like product engineering and technical and cultural bits.

He concluded it with:

I started off with the retrospectives book by Aino. One of the antipatterns that she highlights in that book is the prime directive ignorance. You ignore the prime directive, because you didn't protect unprepared organizations from the dangers of introducing advanced technology, knowledge, and values before they were ready. Maybe at Netflix, we came up with stuff and we shared it with people and a few people took it home and tried to implement it before their organizations were really ready for it. I think we had a bit of that happening, as well as all the cool companies that actually did pick it up and take it to new heights, and we all learn from each other. Just a little worry about the dangers of coming home from a conference and saying, I saw a new thing and let's go do it.

Speaking about transformations, GitHub proclaimed that Copilot transforms GitHub into the AI-powered developer platform.

GitHub - Universe 2023: Copilot transforms GitHub into the AI-powered developer platform

Funnily, Git was initially made as a decentralised code repository. Now, the trend is the other way round. With trunk-based development GitHub's popularity, we’re getting a fragile system that depends on a single vendor and a single pipeline. Now, this vendor will help us to write the code (also with the announced enterprise mode).

I’m not against AI; I’m also using it to get a boost in coding and tedious tasks. I may sound grumpy and like a boomer, but for me, the yellow light is already blinking as it looks like a classical “first dose is for free”. We should do our due diligence and think how that will impact our development process in the long term and if this code-generation vendor locking won’t be more dangerous than cloud vendor locking. We’ll see.

On a positive note, they also shared their brief description of LLM Architecture:

GitHub - The architecture of today’s LLM applications

It’s a nice and intriguing article and a must-read if you want to build your own tools around it.

Getting back to the vendor lock-in AI. Of course, the companies will try to unite, as Docker, Neo4J, LangChain, and Ollama did:

Docker - Docker with Neo4j, LangChain, and Ollama Launches New GenAI Stack for Developers

We'll also have some regulations like the mentioned earlier White House recommendations:

The White House - FACT SHEET: President Biden Issues Executive Order on Safe, Secure, and Trustworthy Artificial Intelligence

But it’ll be hard to beat a big conglomerate that owns most of our common tooling.

Staying in the complaining mode: what really grinds my gears is when someone blindly copies and pastes patterns and techniques from one dev environment to the other. Of course, there’s nothing wrong in adopting good patterns to the local conventions. I’m all for collaboration and learning from others. What I don’t like is when people (e.g. object-oriented developers from Java or C#) blindly bring their conventions to lightweight environments like Node.js, Go, etc. Those environments are by their nature and may not need the heavyweight ceremony. If we make them heavier, then we’re losing their competitive advantage and making the lowest common denominator. That’s why I agree with take about tooling like Nest.js:

Ethan Glover - I Hate NestJS

I even came up recently with a meme:

No alternative text description for this image

Recently, in the full stack Javascript frameworks, there was also discussion about a similarly looking but much different framework: Next.js. It’s a different story, but if you’re thinking about using it (like I do), then it’s worth checking the pros and cons. Yes, frontend architecture is also architecture.

Check also other links!
Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.