Webinar Recording: Software Architecture as Code

The recording of our webinar with Simon Brown,  Software Architecture as Code,
is now available on JetBrains YouTube Channel, as well as select Q&A below.

Here are the slides used in the webinar and the code.

We’re still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don’t reflect the implementation in code, and vice versa. This session with Simon Brown looks at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally-evident coding styles and the representation of software architecture models as code.

01:28 – How do we communicate software architecture?
07:00 – Abstraction is about reducing detail
07:50 – Does your code reflect the abstractions you think about?
11:18 – Why not auto-generate the diagrams?
13:42 – The intersection of software architecture and code
14:08 – The C4 model
19:40 – A C4 example – techtribes.je
23:10 – The static model is about code
23:56 – Why isn’t the architecture in the code?
29:10 – Questions
32:10 – Software architecture as code demo with Structurizr
52:45 – Summary
53:40 – Questions

Select webinar questions and answers with Simon.

Q: How can Structurizr be used in a build system, can I install a local copy or will it be a (paired) SaaS?
A: I’m still undecided whether structurizr.com will be a free or paid service or, more likely, a combination of the two. My hope is that other people will build diagramming tools that operate on the same intermediate JSON format produced by the open source library. These could include wiki integrations, IDE plugins, etc.

Q: Could Structurizr generate XMI so that UML tools could import.
A: Yes. On my todo list is also an export to something like DOT for subsequent import into graphing tools.

Q: Can the tool also be used as easy as shown with Java Enterprise?
A: Yes, and somebody is planning to contribute a Java EE component finder to make this easier.

Q: Do we need a JSR for Components, Layers etc. to be introduced to Java?
A: I’m not sure, possibly. Information about the “architecture” is absent from most codebases, so this could in theory provide a standard way to address this issue in Java. It will be interesting to see what modularity in Java 9 brings.

Q: Does a .NET port exist? Or do you plan to produce one?
A: A partial C# port exists at https://github.com/wolfbyte/ArchitectureScript

Q: Does the ComponentFinder work with frameworks other than Spring, e.g. Guice?
A: At the moment there are component finders for Spring and my custom Structurizr annotations, as well as some that identify components based upon naming conventions (e.g. classes named *Service). There are plans for a Java EE version and anybody is welcome to contribute an implementation at https://github.com/structurizr/java

Q: It seems like your reduced tweet component mirrors an OSGi module.  Is this on purpose?
A: You can think of my tweet component as a lightweight component, without any of the additional complexity, decoupling and other benefits that OSGi brings. But yes, structuring my code in this way allows me to explicitly consider and implement modularity at a level larger than a single Java class.

Q: Why don’t the diagrams use standard UML notation?
A: I personally don’t find that UML works well for describing software systems at the “architecture” level, plus UML doesn’t really support context diagrams that well. Also, based upon my experience, very few people seem to understand UML nowadays. SysML and ArchiMate are other possible notations. You *can* use UML to represent similar diagrams though, and if you’re interested in this I would recommend taking a look at this talk that Eoin Woods and I did at the “Software Architect 2014” conference in London.

Q: Each time you build does the diagrams loose their formatting of the box layout and arrangements?
A: No, you can copy layout information from the views in one workspace to those in another. Another possibility is automatic layout functionality, although I have no plans to build this myself.

Q: What about applying this approach to Desktop-class application? What components would you split it into besides the DB component?
A: The process is the same. A containers diagram would show your desktop application communicating with your database, and the components diagram for the desktop application would show how you’ve decomposed it into components, modules, services, layers, etc.

Q: What architect tools would you recommend along with an approach that you have just shared?
A: Some pens, paper and a whiteboard! In all seriousness, the lack of down-to-earth software architecture tooling is one of the reasons behind Structurizr.

Q: How do you keep diagrams up-to date?
A: This is one of the problems that I’m trying to solve, and it’s relatively straightforward if you integrate something like Structurizr with your automated build process.

Q: I see no reference to Domain-Driven Design in your approach. Why not?
A: In short, I don’t want to couple this way of thinking about a software system (my C4 model) to any particular design approach.

Simon BrownSimon Brown is an independent consultant and helps organisations to build better software by adopting a lightweight, pragmatic approach to software architecture. He is the creator of the C4 software architecture model and the author of “Software Architecture for Developers”, a developer-friendly guide to software architecture, technical leadership and the balance with agility.
This entry was posted in Webinars and tagged , , . Bookmark the permalink.

3 Responses to Webinar Recording: Software Architecture as Code

  1. Heimo Laukkanen says:

    Would have wanted to see Structurizr as a complete solution in the java code instead of calling a web service, so more like PlantUml that you can embed into your build process nicely. Though I understand Simon’s potential goals to create some income from the service to support develeopment.

  2. Simon Brown says:

    Hi Heimo, thanks for the comment. Income potential aside, there are two key reasons why I’ve created a web-based service. First of all, most of the existing architecture diagramming tools are desktop-based, and I wanted to build something different. My experience suggests that such tools aren’t installed across all developer environments and sharing architecture models isn’t easy when this is the case. Secondly, I wanted to create something that is agnostic to the programming language being used. A web-service is easier to integrate with many different programming language and automated build stacks.

    As I said during the webinar, the core library to create the software architecture model is open source, so you’re more than welcome to take the output and build a tool for local deployment. I’d personally love to see somebody build a plugin for IntelliJ, for example. :-)


  3. Ron says:

    Great talk. As someone who diagrams fairly frequently and an avid hater of UML, I’ve been wondering if there’s a better way to do things and this hits the spot. :)

    You mentioned something like “going right down to the Class diagram is less necessary because the upper diagrams are so clear”. As Classes will be the area of most churn, if any, doesn’t this lessen the value of a build system regenerating the diagrams every time?

    I guess the typical project I work on would require extremely infrequent changes to Context and Container diagrams. As these are usually preexisting projects, I see immediate opportunities to use the C4 model for diagrams and documentation, and I’m happy to stop there for now.

    My projects don’t tend to be done in C# or Java though, so it’ll be interesting to see how this approach can be applied to Node.js and front-end web projects.

Leave a Reply

Your email address will not be published. Required fields are marked *