Thread by @skmruiz

I've been thinking for several years how software architecture affects the culture in a company and how business capabilities gravitate around architectural decisions. I want to share some of my findings (long thread). Hope it's interesting and I'll be happy to discuss any topic.

1/ Let's start talking at a technical level. I want to share my thoughts about cloud services, platforms, serverless, microservices, microfrontends and all around.

1.1/ First, we need to rethink how we design software boundaries and data ownership. We've been designing for a long time software boundaries as deployment units that hardly match business concepts.

1.1/ Service boundaries are artificial and hard to develop, and teams sometimes hardly understand them, building coupled systems around. We see a lot of a architectural patterns that emerged and are based in P2P communication, breaking encapsulation and blurring data ownership.

1.1/ My bet is that this will eventually change and we will work around domain boundaries. How those domain objects are implemented can vary depending on the framework, we already have function systems (fn) and actor systems (vlingo, akka...).

1.1/ I don't foresee a clear winner in the short term, but I think the actor model will eventually become a standard in the long term. The main reason is that data locality is really important in distributed architectures, and the actor model explicitly protect it.

1.2/ Microservices and microfrontends are mostly an anti-pattern if you use the concept alone. They don't define boundaries but slices: you want a slice of your favourite cheese but you want to specify also how big it is. That's why we still try to fix them with DDD.

1.2/ IMHO, both concepts will eventually be dropped to more organic boundaries. I'm still thinking which one would work better:

- Data consistency boundaries (like aggregate roots)
- Use case boundaries (with a CQRS model)

Or maybe both at the same time.

1.3/ Now let's talk about serverless and cloud services. I'm personally happy that we have services like Azure and Google Cloud (explicitly removed AWS from the list) that allow teams to be more autonomous and enable them for a better Continuous Delivery of business value.

1.3/ However I missed most of the times a technical vision on how to use those services. Consequences: overused budget, underused resources, broken security policies... Lots of teams aren't ready to take advantage of clouds. Upskilling first is more important than enabling first.

1.4/ Platforms, in sense of business platforms are great. They are even part of the #seismicShifts from @thoughtworks and we promote them. However I've seen lots of companies building technical platforms, like abstractions over their cloud providers.

@thoughtworks 1.4/ Even if those abstractions can be useful in some cases, companies should promote the mindset of business-enabled platforms as a competitive advantage in their market. A good business platform can enable teams and unleash their true potential.

@thoughtworks 2/ Now let's talk about team culture, building high performant teams, and chaos engineering.

@thoughtworks 2.1/ First I think it's important to talk about team performance. Most of the practices I've seen in teams require a conservative approach: the team should be stable and this will improve their performance. Even if that's true it's not pragmatic in the long term.

@thoughtworks 2.1/ Teams change, people leave, business change. Stability is a mirage: it exists if you want to see it. Even if we can guarantee avoiding changes in a short term, considering a couple of months, things happen and teams need to adapt, harming performance.

@thoughtworks 2.1/ Chaos engineering says that on any system change is inevitable. Because teams are systems with capabilities, inputs, outputs and requirements, they effectively change. We need to rethink on team building on how to make them prepared for change in the team, not only business.

@thoughtworks 2.1/ Some ideas:

- Give a free day to do whatever they want to a developer, or a pair, every week / two weeks.
- Rotate people routinely, optimize offboarding/onboarding on teams.
- Promote a culture around empathy, fight the fear of failures and celebrate learnings.

@thoughtworks 2.1/ Teams that I've seen work better in a controlled amount of chaos. Overengineered processes are overwhelming, difficult to adapt to new people, and some of the rules are usually broken under unexpected circumstances (there are always fires to fix in production)

@thoughtworks 2.1/ Funny enough, this also works for software design. A controlled amount of technical debt means that some decisions have been not taken in purpouse to be more adaptable to business changes. Controlling uncertainty and chaos is far more effective than avoiding it.

@thoughtworks 2.2/ High performant teams can hardly be measured on the number of tasks they can move to DONE in a board. Even if looks convincing because you can go to any company and sell easily the concept, making progress on a choosen scope does not mean we are delivering value.

@thoughtworks 2.2/ We've been struggling to understand how tasks are affecting business outcomes, they are usually too small/big and unrelated to business opportunities. Moving tasks can mean working on business outcomes or not doing anything at all! It's just like measuring lines of code.

@thoughtworks 2.2/ That's why high performant teams...
- understand the value they generate and enable opportunities.
- are scalable and ready to change.
- are happy and accountant of their learnings and failures.
- own and measure business outcomes and metric trends.

@thoughtworks 2.2/ How teams track progress internally IS NOT a metric of value delivery, but how fast we make progress on the scope that we decided. Please, stop using it as a metric for your stakeholders. It's not useful and builds unclear and some of the times even false expectations.

@thoughtworks 3/ Finally, I want to talk about how architecture affects the culture of a complete organization.

@thoughtworks 3.1/Bad architectures disallow companies to take advantage of business opportunities and build an effective culture of learning, innovation and cultivation. Sometimes they promote toxic environments, where domains are abandoned and teams are splitted just to deliver tasks faster

@thoughtworks 3.1/ Architectures are an essential way of understanding how a company works. Even if your company doesn't sell software, you are building software that build an experience for your users. If your company runs on software, you are also software company. Simple as that.

@thoughtworks 3.1/ If all your systems are automatised, using different vendors, your bit of salt of custom code, you have a webpage, and your revenue depends on how this software works, you are also a software company. Avoiding this change of mindset will eventually harm your business goals.

@thoughtworks 3.1/ Use the architecture, enable a better culture of teams, to be more efficient, more ready to changes and innovate on your business. Amazon is a shopping platform. Spotify is streaming music. Netflix is producing shows and films. But all of them are also software companies.

@thoughtworks 3.2/ Avoid silos, you don't want them. Build teams with UX, Devs, PO, QA, BA, whatever they need to be effective and autonomous.

@thoughtworks 3.3/ As a company, promote a culture of learning and change. Provide teams with a vision, with goals, make them enjoy the business. Most developers prefer to work on technical aspects because they are completely annoyed of boring, coupled, and unchallenging business initiatives.

@thoughtworks And I think that's it for now, I've spent 1h and a half sorting and prioritising my own thinking. I have lots of other things but I would say this is the most interesting part of it. Looking for feedback, opinions, and other experiences.

Thanks for reading this long thread!