Software architecture vs code

The video from GOTO Chicago 2014

My Software architecture vs code talk has evolved considerably over the past year and I've presented a number of iterations at events in Europe and the US. If you're interested, thanks to the nice people behind the GOTO conferences, you can now watch the video of the version that I presented at GOTO Chicago 2014.

During September I'll be presenting a new version of this session at Foo Café in Malmö, Software Architecture Summit in Berlin and DevDay in Krakow. See you there!

About the author

Simon is an independent consultant specializing 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’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Structure101 and architecture modelling

Hi Simon,

Interesting talk! I just need to correct a small lie ;) at 22 mins, where you say that Structure101 only shows you your package structure.

I totally agree that tools have traditionally only shown package structures, and that these do not generally reflect what is considered to be an "architecture", and that alternative abstractions are often desired for the latter.

This is the whole point of the recently released Structure101 Studio! It allows you to manually/automatically organise an existing code-base into a well-structured containment model. This new containment model can be entirely different from the current package structure, although structure101 maps it to the current structure so that the dependencies between the new containers are always accurate. You can ask Structure101 to initialise the model to reflect the current package (and/or jar/maven/etc) structures, or you can start from scratch, or get Structure101 to suggest an organisation based on class-class dependencies.

Once you have constructed your architectural containment model, you can either proceed to communicate/enforce the model without modifying the package structure, or you can choose to align the package structure with the architecture - s101 will export an action list to your IDE for this.

Interestingly, we find the separate/parallel abstraction approach a hard sell much of the time - people tend to want to align the package structure with the architecture sooner or later, it just reduces confusion, makes it more "real" for the developers.

Check out the 2nd to 5th videos here for an overview of the s101 approach (jump to the last one to see it in action).

Structure101 and architecture modelling

Thanks Chris, I just watched those videos (plus your talk from Oredev). I think I can see what you're trying to do here, but much of what you said (with the examples) still comes back to diagrams showing packages/namespaces. I do agree with what you say in your talk about modularity and how packages/namespaces don't have a defined interface, which is why I like thinking in terms of components/services. Of course, it depends what you're building (e.g. frameworks and libraries vs applications). BTW, I've done a bunch of work since that talk ... have you seen my Structurizr stuff that models a software architecture *as* code?

Re: Software architecture vs code

Ah, yes I can see why you might think that ;). Mostly when I demo I use the "show containers as implementations" option, which causes the package/jar/maven icons to be displayed for containers. There is an alternative "show containers as logical modules" option, which uses a generic "module" icon. In a sense which you use is just cosmetic, but actually it is very important to use the right one when you share models with the development team as it clearly indicates whether you are intending the containers as purely abstract architectural components, or a target package structure that mirrors your architecture. I sometimes think I should just always use a bucket icon, and explain that you can think of the buckets as packages or abstract containers, whichever suits your world...

The Structurizr concept is interesting. If I understand it right, it is somewhat top-down in focus, where I would say Structure101 is more bottom up. I think this makes them quite complementary. E.g. for large existing codebases you could use something like Structure101 to organize the (possibly 10's of thousands of) classes into what you call "containers" and "components". Structure101 will spit out a hierarchical "class map" once you have done this, which could be munged into your json format easy enough. At which point you could add the relationship descriptions etc. for Structurizr. In fact, you could close the loop and create Structure101 architecture diagrams from the Structurizr relationships so that the architecture dependency rules could be checked at edit/build time - cool! :)


Add a comment Send a TrackBack