A loosely coupled software architecture and an organizational structure to match is one of the biggest predictors of continuous delivery performance. To optimize end-to-end value creation and delivery, technical leaders must adopt a sociotechnical mindset.
When teams are designed without consideration of the software architecture, dependencies will arise in code that inhibit teams from delivering high value at speed. Organizational dysfunctions will multiply as productivity and motivation drop dramatically across the entire company. But by adopting a sociotechnical mindset, teams and software systems can be aligned to minimize dependencies and maximize product innovation speed.
The sociotechnical mindset is the synthesis of multiple perspectives, including social dynamics, domain-driven design, business models, and software architecture. Nick Tunee teaches you how to apply these principles and patterns through real examples based on years of practical experience across a wide range of organizations, including the UK government, Salesforce, and more.
Many applications that start with a good design are slowly degrading in maintainability, to a point where they are becoming hard to maintain without notice.
Currently there are tools that can analyze the code statically and give you feedback, but if they are not used from the beginning of the project, it can be overwhelming for team to keep up with all the issues.
During the presentation we will discuss what are the most impactful metrics that can significantly improve the maintainability of the code and how to setup an automatic governance on code and application at architecture levels.
“Ninety-five percent of the words are spent extolling the benefits of ‘modularity’ and that little, if anything, is said about how to achieve it”—Glenford J. Myers, 1978.
The above quote is 40 years old. Today, four decades later, nothing has changed except terminology. Time to fix this.
Vladik Khononov explains how to decompose a system into loosely coupled components: how to draw boundaries between services, how to decide whether some logic belongs to one service or another, and how domain-driven design can help us make those decisions. Finally, he takes a stab at answering the age-old question of what part of a microservice should be “micro” and how it can be measured.
You’ll hear about neither Docker nor Kubernetes. Actually, nothing related to infrastructure. Instead, you’ll dive into the difference between microservices and bounded contexts, discover when each pattern should be used, and get takeaways from Vladik’s experience optimizing microservices-quotebased architectures at Naxex.
SOA has been around for decades, and its latest iteration - microservices - for a while now. Just five years ago microservices were hip, dominating the agenda at conferences; now we almost take them for granted. With microservice-focused conference talks losing steam, the time is ripe to consider what we, as an industry, can learn from the microservice disruption; more importantly, we have a golden opportunity to consider what we have yet to learn!
In this talk I'll analyse the lessons hammered into us as we've adopted microservices, and take a hard look at the challenges I believe we still struggle with as an industry. If you're not doing microservices you'll leave the room knowing where the pains will come from; if you are, you will leave with ideas and leads on mitigating these pains.