Architects as Gatekeepers
I had experiences where every single service had to be a ticket with an architect document in order to be able to start using every new technology or service. So every engineer hates to work like that. I personally dont think thats the why to roll because thats means that process wins. Netflix is famous to have a culture where they threaten people like grown-ups. So if you have grown-ups why do you need to review every single thing people do all the time? For sure reviews are a good thing but architects as Gate Keepers are not a good thing. In general Gate Keepers(DevOps Engineers) as well is as bad as Arch as Gate Keepers. I have mixed feelings but personally, I dont think there is value in having Gate Keepers which is a very poor solution and IMHO a poor usage of people’s times. So Why gate Keepers exist?
We are not a technology company (Are you sure?)
Famous last words. Lots of companies dont consider themselves as technology companies. This is a serious mistake. The technology was key for the Allies to win World War II. Technology is key for innovation. Most companies nowadays are technology companies even when they are on aviation, auto, health care, hr, finance, media, retail, or several other industry categories. Technology is the business. When you dont see technology strong in your CORE what happens is:
* You have the mindset of BUILD IT and Dont Break it, Dont touch it
* Pile Up technical Debt like there is no tomorrow
* Let great engineer go
* Focus on politics rather than on innovation and outcomes
* Outsource all your business to offshore because tech is an expense so the cheap the better
Look at companies like Pixar, Tesla, and Amazon and how they disrupt their segments with the right vision about technology. So most companies see tech as an expense and therefore want to reduce cost — and how do you reduce cost?
* Higher the cheaper contractors
* Build as many shared libs as you can — Do not trust people doing services
* Have Gate Keepers for everything (Architects, QA, and DevOps)
It must have a different and better way. Thank God there is and some successful SV companies like Google, Netflix and Amazon found it.
A different approach to Guidance
Basically, a new approach would be composed with the following items:
* 1 Talent Density over Gate Keepers and Process
* 2 Way doors over one-way door
* 3 SOA Service contract and Isolation over extensive review
* 4 Quadrants over binary stacks
Let’s talk a look at each one of those in more detail.
1 Talent Density over Gate Keepers and Process
Netflix has this awesome concept about treating people as grownups. Meaning the bigger is your talent density is the less process you need. Because good people make an awesome judgment. The less talent density you have the more process you need.
The issue with the process is that often people have poor discipline(also the reason why most digital transformations fail). Therefore process solutions often work for a while but stop working in the long run. Or the process works and literally is a huge bottleneck and source of frustration.
2 Way doors over one-way door
Amazon has this concept of avoiding 1-way doors. Which are doors or things you do that are hard to recover. e.g fire someone. Amazon both in leadership and engineering whats to leverage 2-way doors. Meaning you can recover or you can rollback if you realize was a bad decision. That’s the right way to leverage innovation and if you have proper isolation you can o that safely.
3 SOA Service contract and Isolation over extensive review
Isolation is everything. Isolation allows us to test safely in production. Honoring SOA Contracts allow us to make changes on services under the hood without breaking consumers. This great SOC(Separation of Concerns) is the foundation for to teams get really independent and faster innovation. Isolation also means reducing or even avoiding shared libs as much as you can.
4 Quadrants over binary stacks
Finally, you can have a simple comunication via quadrants as Google does.
Google classifies technology with quadrants so you have a self-service comunication mechanism where you dont need to ask for a blessing from anyone and no meetings are required. e.g:
Try: Rust, Micro-frontends, Data Meshes
Use: Java, MySQL, Redis, S3, React
Avoid Angular, .NET, Oracle DB
Forbidden: Ruby, C++, MongoDB
You dont need a shared library for everything. The main benefit of microservices is to have things happening in parallel and in isolation so typing will not be the bottlenecks I can assure 100% however migrations and binary coupling will be a bottleneck and bigger chunk of your initiatives.
The way forward
In order to things improve you need to have some critical mass. Thats why the Netflix talent density principle is so important. In general, you want to make things as self-service and self-running as much as you can. Meetings are smells of poor or lack of automation. Sometimes review from architects is a good idea but not all the time. So save that for Big, complex, important projects which likely will not be the majority of your projects.
Sometimes engineers need guidance and attention so practices like 101s, retrospectives, Lunch, and Learns, Dojos, Hackathons, Guilds, and Chapter can help you to make ideas flow and also grow people in they careers. Instead of a focus on Ket Keepers focus on education, training, and self-service information and solutions so not only you can scale but also you save time for the good stuff.
Cheers,
Diego Pacheco
Originally published at http://diego-pacheco.blogspot.com on February 25, 2021.
