Pave’s Post

𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐬 𝐁𝐞𝐰𝐚𝐫𝐞: 𝐓𝐡𝐞 𝐎𝐧𝐞 𝐃𝐞𝐜𝐢𝐬𝐢𝐨𝐧 𝐓𝐡𝐚𝐭 𝐂𝐨𝐮𝐥𝐝 𝐌𝐚𝐤𝐞 𝐨𝐫 𝐁𝐫𝐞𝐚𝐤 𝐘𝐨𝐮𝐫 𝐍𝐞𝐱𝐭 𝐏𝐫𝐨𝐣𝐞𝐜𝐭! In the realm of software architecture, the 𝐝𝐮𝐚𝐥𝐢𝐭𝐲 𝐨𝐟 𝐝𝐞𝐜𝐢𝐬𝐢𝐨𝐧-𝐦𝐚𝐤𝐢𝐧𝐠 is a path walked on the edge of a sword. As architects, we constantly balance on the tightrope of trade-offs, where every choice comes with its own set of sacrifices and gains. But what if I told you there's a way to navigate these waters with confidence? Drawing from the deep well of wisdom in "Developers Road Ahead," it's clear that the cornerstone of impactful architectural decisions lies in a principle-based approach. By grounding our choices in solid, time-tested principles, we can see beyond the immediate crossroads, foreseeing the long-term implications of our decisions. This principle-based mindset doesn't just shield us from the myopic pitfalls of quick fixes; it empowers us to build architectures that are not only resilient but also adaptable to the ever-evolving landscape of technology. The true duality lies not in the decisions themselves but in our approach: Do we seek 𝐬𝐡𝐨𝐫𝐭-𝐭𝐞𝐫𝐦 𝐠𝐫𝐚𝐭𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐨𝐫 𝐥𝐨𝐧𝐠-𝐭𝐞𝐫𝐦 𝐯𝐚𝐥𝐮𝐞? As we embark on our next projects, let's choose to anchor our decisions in principles that have stood the test of time. Let the wisdom from "Developers Road Ahead" guide us in making choices that not only meet the immediate needs but also pave the way for sustainable growth and innovation. For more insights on navigating the architectural landscape with a principle-based approach, check out "Developers Road Ahead" at https://lnkd.in/dmJw9ekT. Your next decision could be the one that defines your legacy as an architect. #Architecture #SoftwareDesign #PrincipleBasedArchitecture #DecisionMaking #Tradeoffs #LongTermValue #Innovation #DevelopersRoadAhead #SoftwareArchitecture #TechnologyLeadership #SustainableGrowth

Scaling your product for rapid growth? Keep it simple: - modular design - flexible architecture - always listen to your users Stay agile, scale smart! --- P.S. If you liked this post, you'll enjoy The Product++ :) 1. Follow me 2. Hit the bell 3. Join my weekly newsletter

@Gert Marx @SSW Solution Architect, interviews @Chris Simon Startup CTO Coach, about his open-source project, Contextive. Learn how Contextive, inspired by Domain-Driven Design (DDD), addresses miscommunication in software projects by documenting domain terminology. Watch now to see how Contextive can improve your projects! https://buff.ly/3X0rNUJ #OpenSource #Contextive #DomainDrivenDesign #SoftwareDevelopment #Documentation #CodeQuality #DomainModeling #CollaborativeWorkshop #TechnicalDebt #CloudService

Team Topologies is going to be the most important re-read this year. While I read it, I think of a few ”reorgs” I happened to see. Mostly driven by the idea of moving people around like they were just pawns on the board, constrained by static thinking about ensuring sufficient headcount to deliver output-based goals, ignoring inevitable Conway’s law - which usually led from a lack of any improvement at best, to a disaster at worst. Regarding the quote above - there’s one recurring pattern, or rather anti-pattern, I’ve seen in several companies. Imagine a monolithic architecture. Let’s make it a modular monolith so different teams can independently contribute to their piece of the system without interrupting others. Seems like a nice way to ensure that teams are independent, without investing further into removal of architecture and organizational coupling, right? Wrong. Your teams are still constrained: by the ”shared” or ”core” modules in your monolith, these few legacy modules that you pretend don’t exist, shared CI/CD pipeline. or infrastructure that has to address the needs of everything (read: can’t be optimized in terms of efficiency and costs). Add ”guilds” to the equation, entities that own the ”backend” or the ”frontend” in your company. Done wrong and unmanaged, these entities tend to control technology choices that teams would otherwise make on their own, coding standards or ways of working to the extend that they become a constraining entities, instead of enabling. Architecture and organization design are two sides of the same coin. Print it, memorize it. Ignore it and pay the price. I wonder if my Saturday’s thoughts are resonating with anyone else. #teamtopologies #architecture #orgdesign #conwayslaw

What do you think makes burnout in Architecture so prevalent? I have my own ideas, but I want to hear yours! Post below or send me a DM. Also, what do you think needs to change in order to reduce burnout in the profession?

My LeadDev talk from the Berlin conference has just been published on YouTube: https://lnkd.in/eCtuf8_S I talk about two different approaches of managing software architecture that I've experienced (a more self-organized "guild" approach, and an "enabling team" as in Team Topologies), and some observations I've made. Let me know what you think in the comments. #softwarearchitecture #architecturemanagement #engineeringmanagement #flow #teamtopologies

Agility and Architecture by Randy Shoup. So many great ideas are beautifully weaved together. Simple and impactful presentation backed by his extensive experience. Take a listen. ✅ Build Right Things: What problem we are trying to solve? - Only 1/3 of all the features delivered have positive impact to customers, remaining 2/3 either have no or negative impact - Building the wrong things is the biggest waste in software development 💡 Reduce waste by continuously delivering value in short iterations and using feedback. Also allows for change in priorities, direction. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” - Principles behind the Agile Manifesto https://lnkd.in/eNFWXFHc ✅ Building things Right: Fast sustainable flow of change - Independent Stream Aligned teams own software from cradle to grave  - Own 80% work not requiring fine grained coordination with other teams  - Enabled by Modular Architecture, vertical slicing per domains that are decoupled in time, event driven and async - Common Developer Platform - Enable DevEx, reduce cognitive load, impose enabling constraints and sensible defaults  - Work in small steps that are easy to understand, code review, test and rollback. With larger steps, the rise in risk is exponential  - Tests are enablers to move fast, produce better design and code  ✅ Long term evolution What evolves in long term is constraints, capabilities, problem space, markets. - Big upfront design doesn’t work, but No upfront design also doesn’t work  - Follow 80/20 rule - get started with good enough design and evolve  - Evolve architecture in small steps  - “If you do a big-bang rewrite, the only thing you're guaranteed of is a big bang” - Martin Fowler 💡 Agile approach enables solid architecture with iterative changes and feedback. At the same time making progress in small steps is enabled by architecture. References 👉 Team Topologies by Matthew Skelton and Manuel Pais (Team Topologies) 🇺🇦 🇵🇸 👉 Continuous Delivery by Dave Farley and Jez Humble 👉 Trustworthy Online Controlled Experiments - Ron Kohavi 👉 Lean Software Development - Tom & Mary Poppedieck #softwareengineering #continuousdelivery #agile #evolutionaryarchitecture https://lnkd.in/eW4PE2vd

"This conversation provided more educational value for architects than most books / trainings about architectural decision making. " -- Michael Franz Heiß I chatted to Andy Butcher about trade-offs and architectural decisions using a Team Topologies 'lens' and we captured the conversation in a doc. #FastFlow #TeamTopologies #OrgDesign

Gert Marx SSW Solution Architect, interviews Chris Simon Startup CTO Coach, about his open-source project, Contextive. Learn how Contextive, inspired by Domain-Driven Design (DDD), addresses miscommunication in software projects by documenting domain terminology. Watch now to see how Contextive can improve your projects! https://lnkd.in/epA4VMFj #OpenSource #Contextive #DomainDrivenDesign #SoftwareDevelopment #Documentation #CodeQuality #DomainModeling #CollaborativeWorkshop #TechnicalDebt #CloudService