I'm an independent consultant specialising in software architecture and the author of Software Architecture for Developers; a developer-friendly guide to software architecture, technical leadership and the balance with agility. I'm also the creator of the C4 software architecture model and the founder of Structurizr, a collection of tooling to help software teams visualise, document and explore their software architecture.
I speak at software development conferences, meetups and organisations around the world; delivering keynotes, presentations, training courses and workshops. In 2013, I won the IEEE Software sponsored SATURN 2013 "Architecture in Practice" Presentation Award for my presentation about the conflict between agile and architecture. Some of the slides from past talks are available to view online/download, and there are many videos of my talks available online, most of which can be found on YouTube.
I've spoken at events and/or have clients in over 30 countries.
Here is my recent and future public speaking schedule.
Here's some information about my speaking fee, along with my current bio and talk abstracts. I've done many different talks related to software architecture in recent years, so please get in touch if you'd like something slightly different from what you see here.
My speaking fee is dependent upon a number of factors such as the event type (open, closed, commercial, community, not-for-profit, etc), location (Europe vs further afield), date and proposed participation (keynote, talk, workshop, etc). Please contact me for further details.
Simon is an independent consultant specialising in software architecture, and the author of "Software Architecture for Developers" (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He is also the creator of the C4 software architecture model, which is a simple approach for creating maps of your code. Simon is a regular speaker at international software development conferences, travelling the world to help organisations visualise and document their software architecture.
The software development industry has made huge leaps in recent years; with agile, lean, software craftsmanship, evolutionary design and microservices being just a few of the buzzwords we throw around. Despite this, software development teams are often more chaotic than they are self-organising, with the resulting code being more of a mess than was perhaps anticipated. Successful software projects aren't just about good code though, and sometimes you need to step away from the IDE for a few moments to see the bigger picture. This session is about that bigger picture and is aimed at software developers who want to learn more about software architecture, technical leadership and the balance with agility. This talk will debunk some of the common myths as we look at five things every developer should know about software architecture; a guide to software architecture on modern software projects that's pragmatic rather than academic and lightweight rather than "enterprisey".
It's very likely that the majority of the software architecture diagrams you've seen are a confused mess of boxes and lines. Following the publication of the Manifesto for Agile Software Development in 2001, teams have abandoned UML, discarded the concept of modelling and instead place a heavy reliance on conversations centered around incoherent whiteboard diagrams or shallow "Marketecture" diagrams created with Visio. Moving fast and being agile requires good communication, yet software development teams struggle with this fundamental skill. A good set of software architecture diagrams are priceless for aligning a team around a shared vision and for getting new-joiners productive fast.
This session explores the visual communication of software architecture and is based upon a decade of my experiences working with software development teams large and small across the globe. We'll look at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, and the value of creating a lightweight model to describe your software system using the "C4 model", which I created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.
"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, up front 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 assessed or reviewed. If you're willing to consider that up front 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 of the lost art of software design, and how we can reintroduce it.
If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices. It's everywhere! For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago "done right". Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you can’t build a well-structured monolith, what makes you think microservices is the answer?
I run software architecture training courses at organisations across the globe, the content of which is based upon my Software Architecture for Developers books. These courses, which are aimed at software developers and architects, are a guide to software architecture on modern software projects that's pragmatic rather than academic and lightweight rather than "enterprisey". See the following links or e-mail me for more details and pricing: