Happy new year and I wish you all the best for 2016. My first trip of the year starts next week and I'll be doing some work in Shenzhen, China. As a result, I'll also be in Hong Kong on January 15th, presenting "The Art of Visualising Software Architecture" at a meetup organised by Agile Hong Kong. You can register on the Meetup page. See you there!
p.s. If anybody would like a private, in-house 1-day software architecture sketching workshop on the 15th, please drop me a note.
Last week I gave a presentation titled "2015 - A CyberSecurity Year" to the London Java Community's Open Conference. I like to present at the LJC's Open Conference on whatever topic has occupied the majority of my time in the previous year. This is partly because it's always advisable to "present on what you know" but also as a cathartic exercise to vent my frustrations! The slides can be found here but won't make much sense without the following context.
This year a huge amount of my time has been spent on Cybersecurity concerns as 2015 was the year these issues were forced into everyone's mind. The threats have been increasing for several years but many high profile (and often salacious) events mean that the press, and therefore the public, have realised this is a serious issue. The first part of my presentation described what had happened over the last few years to cause the current situation.
Once the press and the public have a concern, the politicians will pick up on it and this means... laws, regulation, 'guidelines' and consequences. The second part of the presentation discussed the large range of regulators and regulations that have been (and are still being) created. These can be complex, incomplete and sometimes contradictory. I only touched the surface of what is happening. Interestingly a few of the people watching had similar concerns and experiences but many seemed unaware of even the most basic provisions of the Data Protection Act - I suspect this could be a HUGE business risk in the next few years.
These concerns have led to an increase in actual and planned expenditure (including large announcements from governments) but many in the group expressed doubts on how effectively they would be spent.
Lots of money means... lots of companies offering products and services! We spent a while discussing some of these and again, there was concern about their maturity and effectiveness.
So to bring this back on topic! Security (whether at application, system or data level) is a highly complex quality attribute. It is also constantly changing. A good architecture will take the current security concerns into account and provide foundations for not only providing this now but also for solving future issues. You not only have to address the threat but also do this is a legally compliant way. It is possible to be secure but still in breach of the law.
It is also a concern throughout the system and cannot be considered in isolation. If you are writing an application you need to think about all the services you rely upon, the sources and destination of your data and most importantly the people using it. Your developers, system administrators, database administrators and operational teams need to communicate with each other on these issues.
Good luck, I'm sure it'll all be different by the end of 2016!
If you've ever worked on a codebase that's more than just a sample application, you'll know that understanding and navigating the code can be tricky, certainly until you familiarise yourself with the key structures within it. Once you have a shared vocabulary that you can use to describe those key structures, creating some diagrams to describe them is easy. And if those structures are hierarchical, your diagrams become maps that you can use to navigate the codebase.
If you open up something like Google Maps on your smartphone and do a search for Jersey, it will zoom into Jersey. This is great if you want to know what's inside Jersey and what the various place names are, but if you've never heard of Jersey it's completely useless. What you then need to do is pinch-to-zoom-out to get back to the map of Europe, which puts Jersey in context. Diagrams of our software should be the same. Sometimes, as developers, we want the zoomed-in view of the code and at other times, depending on who we are talking to for example, we need a zoomed-out view.
A feature that has been built into Structurizr is that you can link components on a component diagram to code-level elements, which provides that final level of navigation from diagrams to code. You can try this yourself on the software architecture diagrams for the Spring PetClinic application.
Whatever tooling you use to create software architecture diagrams though, make sure that your diagrams reflect real structures in the code and that the mapping between diagrams and code is simple. My FREE The Art of Visualising Software Architecture ebook has more information on this topic.
I presented a new version of my "Software architecture as code" talk at the Devoxx Belgium 2015 conference last week, and the video is already online. If you're interested in how to communicate software architecture without using tools like Microsoft Visio, you might find it interesting.
The slides are also available to view online and download. Enjoy!
As you may have seen on Twitter, I've been mulling over an idea for a new book, which I'm pleased to say is going to happen. It's currently titled "The Art of Visualising Software Architecture" and, as the title suggests, it will focus on the visual communication of software architecture through diagrams.
The core of the book is my C4 software architecture model and although this is covered in my existing Software Architecture for Developers book, I want to create a single resource related to this topic because I still see effective communication of software architecture as a huge gap across the software development industry. You'll notice that the title of this book includes the word "art". I've seen a number of debates over the years about whether software development is a craft or an engineering discipline. Although I think it *should* be an engineering discipline, I believe we're a number of years away from this being a reality. So while this book won't present a formalised, standardised method to communicate software architecture, it will provide a collection of ideas and techniques that thousands of people across the world have found useful.
I also want to include a number of other topics and answers to frequently asked questions that I get during my software architecture sketching workshops, including some of the blog posts I've written recently such as Help, my diagram doesn't fit on one page! and Diff'ing software architecture diagrams again, for example. I'm also going to include more discussion about notation, the various uses for diagrams, the value of creating a model and tooling. Structurizr will be in there too.
Thanks very much for all of the support so far on this; the tweets/e-mails I've had are telling me that this is the right decision. Since it's not going to be a long book and initial drafts may include some text copied verbatim from my "Software Architecture for Developers book", I'm going to make this available via Leanpub using their variable pricing model ... with a starting price of free, certainly for a while anyway. It's a work in progress, but please feel free to grab a copy from Leanpub if you're interested. Thanks very much!
This definitely goes into the category of a frequently asked question because it crops up time and time again, both during and after my software architecture sketching workshop.
I'm following your C4 approach but my software system is much bigger than the example you use in your workshop. How do you deal with the complexity of these larger systems? And what happens when my diagram doesn't fit on one page?
Even with a relatively small software system, it's tempting to try and include the entire story on a single diagram. For example, if you have a web application, it seems logical to create a single component diagram that shows all of the components that make up that web application. Unless your software system really is that small, you're likely to run out of room on the diagram canvas or find it difficult to discover a layout that isn't cluttered by a myriad of overlapping lines. Using a larger diagram canvas can sometimes help, but large diagrams are usually hard to interpret and comprehend because the cognitive load is too high. And if nobody understands the diagram, nobody is going to look at it.
Instead, don't be afraid to split that single complex diagram into a larger number of simpler diagrams, each with a specific focus around a business area, functional area, functional grouping, bounded context, use case, user interaction, feature set, etc. You can see an example of this in One view or many?, where I create one component diagram per web MVC controller rather than having a single diagram showing all components. You can see this in action in the software architecture diagrams for techtribes.je that are hosted on Structurizr. The key is to ensure that each of the separate diagrams tells a different part of the same overall story, at the same level of abstraction.
While at the Devoxx UK conference recently, I was interviewed by Lucy Carey from Voxxed about software architecture, diagrams, monoliths, microservices, design thinking and modularity. You can watch this short interview (~5 minutes) at Step Away from the Code! ... enjoy!
While at the YOW! conference in Australia during December 2014, I was interviewed by Craig Smith and Tony Ponton for The Agile Revolution podcast. It's a short episode (28 minutes) but we certainly packed a lot in, with the discussion covering software architecture, my C4 model, technical leadership, agility, lightweight documentation and even a little bit about enterprise architecture.
Thanks to Craig and Tony for taking the time to do this and I hope you enjoy The Agile Revolution - Episode 91: Coding The Architecture with Simon Brown.
A printed copy of Talking with Tech Leads, by Patrick Kua (a Tech Lead at Thoughtworks), arrived in the post this morning. We often discuss the technical side of software development and rarely the “softer” side. This book is a collection of short interviews with people new to or in technical leadership roles. They share their stories, tips and experiences of making that leap from developer to tech lead. To clarify, by "tech lead", Patrick is referring to somebody in a technical leadership role who still writes code. This is synonymous with what I call the software architecture role, with an expectation that part of the role includes coding.
I actually recommend this book during my software architecture workshops as there are some fascinating “eureka” moments presented in the book, especially related to leadership and dealing with people. One of the messages you'll see repeated again and again is that, as software developers, nobody really prepares you for how to deal with people when you make the jump into your first tech lead role. Looking back at my own career and of people I worked with at the time, I'd say the same was true. Hindsight is a wonderful thing, and I wish I had a book like this earlier in my career.
I'd certainly recommend taking a look if you're interested in the softer side of the technical leadership/software architecture role. The book is available on Leanpub and as a printed book via Amazon.com and Amazon.co.uk.
Disclaimer: I'm interviewed in the book, as is Robert Annett and a bunch of other people you may recognise ... I receive no royalties for recommending it though. :-)