Discover more from Architecture Weekly
Architecture Weekly #153 - 13th November 2023
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.
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:
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 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.
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.
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:
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:
We'll also have some regulations like the mentioned earlier White House recommendations:
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:
I even came up recently with a meme:
Check also other links!
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.