Computers have been part of my life for as long as I can remember, and I've been at it professionally for almost twenty years now. But I came from music, and the longer I do this, the more I think the two are the same thing in disguise: taking chaotic, formless ideas and giving them structure and meaning. Software architecture is where I keep chasing it, designing systems that hold up and grow gracefully.
As part of the research for my book, I came across an algorithm called Redlock on the Redis website. The algorithm claims to implement fault-tolerant distributed locks (or rather, leases [1]) on top of Redis, and the page asks for feedback from people who are into distributed systems. The algorithm instinctively set off some alarm bells in the back of my mind, so I spent a bit of time thinking about it and writing up these notes.
“Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from “big design up front” in the 20th century, to “emergent design” and “evolutionary architecture” in the 21st. In their desire to become “agile”, many teams seem to have abandoned architectural thinking, upfront design, documentation, diagramming, and modelling. In many cases, this is a knee-jerk reaction to the heavy bloated processes of times past, and in others, it’s a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be communicated, assessed, or reviewed. If you’re willing to consider that upfront design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and “refactoring” seen on many software development teams can be avoided. Join me for a discussion about the lost art of software design, and how we can reintroduce it to help teams scale and move faster.
Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues - an alternative to component and process modeling that uses applied complexity science to make managing uncertainty a fundamental part of the design process.
When EventStorming is applied effectively, we’ve seen plenty of successful sessions, many of which teams have used EventStorming as the basis for the design of their microservices.\r\n\r\nIn this article, we’ll share a few easy-to-learn techniques that will help you to get the most out of EventStorming so you can design more domain-aligned software systems.
Typically, microservice-based applications distribute data widely, especially in cloud-based applications, resulting in distributed applications. This impacts the transactions within these applications. This white paper refreshes the concepts of classical and distributed transactions. Next, we explain how cloud-based applications are affected by distribution. Finally, we present compensation-based transactions as a reliable method for microservice-based application transactions, even in the cloud.
When I think about design, I more naturally think about it the other way around: how to decompose the whole into a set of parts that will work together to accomplish the system goals. But of course Conway is right that those parts do have to fit together to produce the intended whole again.
You wouldn’t want to jump into a project without a solid plan, and software architecture design is no different. By making this process more effective, you can account for all of your requirements properly and give stakeholders the opportunity to provide their input.\n\nUsing technical visuals and a careful planning process, you can outline your software architecture and design before you get started on a prototype.
As software developers, we might think that our main job is to write code and create solutions. But really, our most important job is to understand the problems we're trying to solve. In this article, we'll talk about why it's important to understand the problem domain, why this helps us build better software, and how developers can get better at it.
Integrating systems provides many benefits, from seamless user experiences, consolidated data for better insights, or interacting with partner ecosystems. And the modern cloud applications that we are building are fine-grained and thus inherently interconnected. Despite having connected systems for decades, some of the fundamental concepts of partial failure, eventual consistency, or idempotency still challenge many developers.\n\nThis session tackles the nuances of integrated systems, such as messages vs. events, thinking in integration patterns, whether loose coupling is always better, and how cloud automation can change the way you think about integration.
Where do architecture styles come from? Do architects retreat to an ivory tower to decide what the Next Big Thing will be? No–new capabilities constantly appear in the software development ecosystem, and clever architects figure out new ways to leverage the new building blocks, leading to new named architecture styles which are only named after they have existed for a while. This is similar to art and cultural movements, how Victorianism became Modernism. In this keynote, Neal traces the similarities between architecture styles and cultural movements, how each affect the other, and points towards how Metamodernism will inform architecture, corporations, and individual workers in a fundamental way.\n\nNote to organizers: This keynote covers technical details from both my books _Fundamentals of Software Architecture and Software Architecture: The Hard Parts to illustrate the larger observations about both software architecture and the profession of software engineer. This keynote is more philoshopical than the Software Architecture: The Hard Parts keynote, ending with a call to action that architects and developers must become aware of the impact of ethics in seemingly technical decisions and act accordingly to improve rather than degrade the world.\n\nNeal Ford\nNeal is Director, Software Architect, and Meme Wrangler at ThoughtWorks, a software company and a community of passionate, purpose-led individuals, delivering technology to address the toughest challenges, all while seeking to revolutionize the IT industry and create positive social change. He speaks at many conferences.