BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Simon Brown on the Role of the Software Architect in a Continuous Delivery Environment

Simon Brown on the Role of the Software Architect in a Continuous Delivery Environment

This week's podcast features Simon Brown well known for his work training software architects. Topics include the differences between a tech lead and an architect, how much documentation is enough and what that looks like in a continuous delivery environment.
 

Key Takeaways

  • As an industry we seem to have lost our knowledge of how to do architecture well in the context of modern agile software teams.
  • Architecture is about the expensive decisions; things that are costly to change later.
  • Ideally architects should code in the production code base. If you are not able to do this at least be involved in quality reviews and peer reviews in the production code so you can get feedback on your designs.
  • It is often said the the code is the only documentation you need but the code can’t tell you everything. You do need to document the things you can’t get from the code such as the architectural drivers, they key quality attributes and so on along with some high level diagrams and how you operate the system.
  • As you step into the role of architect go and find a mentor or a local meet-up. The major change is that you have to influence and lead people.

Sponsored by

AppDynamics: Software architects play a critical role in designi­­­ng, executing, and migrating large infrastructures to the cloud. Download AppDynamic’s FREE eBook "10 Tips for Enterprise Cloud Migration" and launch your migration project with a proven plan.

Show notes

Why is architecture important?

  • 01:55 We seem to have lost track of how to do architecture well, especially with agile teams.
  • 02:00 If you go back to 2001 when agile came about, a lot of the teams threw away a lot of ceremony in the process - including the architecture stuff.
  • 02:10 The software toolkit focuses around lightweight tools for architecture; the tooling and techniques, but also on the role of architecture.

Is everyone an architect in an agile team?

  • 02:55 Before agile, we had a very hierarchical approach to architecture, where there was typically one person on the team dictating what to do.
  • 03:05 Agile came along with self-organising teams and trust.
  • 03:15 A lot of teams have come to me doing “agile” and saying that they don’t need architect, because they all are.
  • 03:20 I’ve seen good examples where they have a small team with no dedicated architect, but between the team members they have the collected knowledge and skills to do it.
  • 03:35 On the other hand, I’ve seen a lot of teams where you have a more typical mix of experience and knowledge and different personalities on the team.
  • 03:45 On those sort of teams you need someone to take on the architecture role; and in those teams, it is typically the team lead.

Is it a function of culture or technical aptitude?

  • 04:00 Both - I’ve travelled to about 30 countries in the past few years, and some of the teams in those countries have a different culture to others.
  • 04:15 If you go into North Europe - Scandinavia, Norway, Denmark - those teams tend to have much more of a self-organising team culture.
  • 04:25 If you go further West - especially the UK, for example - sometimes you don’t get the same feel; sometimes the teams are more hierarchical.
  • 04:30 But of course technical experience does matter.

How do you define architecture and architects?

  • 04:45 Architecture is about two things - structure and vision.
  • 04:50 If you’re building a piece of software, you need to understand how to visualise and structure your software.
  • 05:00 For example, there’s a structural element - modules, relationships between them - that’s a static view of the system.
  • 05:50 So need to take a set of business requirements, and translate that into some notion of an architecture or software design.
  • 05:15 There’s a whole notion of process, and one of the things that Grady Brooch says a lot is “Architecture represents the set of significant decisions”, where significant is related to the cost of change.

What do you use for describing your software?

  • 07:30 I only use UML for describing when I want some detail - so if I want to document something at the class level, UML suits that beautifully.
  • 07:40 But you do have to be careful because that does come out of date - you’re mirroring code in documentation form.

What do you use at a higher level?

  • 08:00 I use something I created which I call the C4 model. It’s a hierarchical way of thinking about the structures making up your system.
  • 08:10 A software system (the Context) is made up of Containers (an app or database; not the runtime docker concept), which contain Components (a group of related functionality) and Classes.
  • 08:45 So a higher level from Classes is Components.

What’s the focus of the Context?

  • 09:00 I draw a set of diagrams - I start with a simple box to represent the system, and around the edges of the box there will be the other systems and people that it interacts with.
  • 09:20 It’s a high-level map of users and systems.

What does the Container include?

  • 09:50 The easiest way to think of it is as a set of things that can be deployed separately.
  • 10:00 Examples of containers include Java application, a J2EE application, a database schema, a folder on a file system - an app or datastore.

How does that look with horizontal scaling?

  • 10:35 The diagram represents the static structure of the system, separate from the deployment view.
  • 10:45 You might have different deployment environments with different deployment views, for example.
  • 10:50 The static view will just show a single instance, talking to other single instances.
  • 10:55 You then have a separate deployment view showing how those containers are mapped onto infrastructure.
  • 11:15 Most of the time I will just use supplementary documentation - which sounds very boring but is the easiest way to do it.
  • 11:25 For risks, I have something called risk storming, which I teach people.
  • 11:30 You draw some pictures of the thing you have built or are about to build, get as many people who may have knowledge of the system, and give them sticky notes.
  • 11:50 Then in a time-box exercise of 10 minutes, look at the diagram and identify what you personally perceive to be the risks of that architecture - data breaches, servers falling over, and so on.
  • 12:05 When you’ve identified the risk, you have a priority scale; likelihood versus consequences, and then you rank the risks.
  • 12:20 You use the coloured sticky notes to correspond with the risk, writing them on notes and keep them to yourselves.
  • 12:25 At the end of the time-box, you put the sticky notes on the diagrams.
  • 12:30 It’s like an innovation style game thing. It’s a great way of getting the risks associated with the system.

What’s enough documentation for a system?

  • 13:05 Teams often say that the code is the only documentation you need - and that’s flat-out untrue.
  • 13:15 The code can’t tell you everything - there’s much more that happens besides the code; it can’t tell you the why or the key important reasons behind the decisions made.
  • 13:25 In terms of how much documentation is needed - I would typically have an architecture document (whether you call it that is up to you).
  • 13:40 I would document the things you can’t get from the code - the context, architectural drivers, the key attributes and constraints.
  • 14:00 I want some high-level maps of the architecture (like the C4 model above)
  • 14:05 There should also be information about how you support and maintain this thing.

In an environment with multiple teams, how do you build a process for continuous updates?

  • 15:25 If we have a bunch of teams working on the same codebase, with multiple versions deployed every day, then have one document describing the architecture checked in.
  • 15:55 At the end of the deployment process, have a gate which asks whether you’ve updated the diagrams and documentation?
  • 16:05 You then have a series of small changes which can be applied as it grows.
  • 16:10 In a micro-services world, each team would have a set of documentation for each micro-services - but that would lack the higher level of how they all fit together.
  • 16:25 There’s a lot about enforcing good process.

You have a tool called structureizer that helps with the C4 model?

  • 16:45 I teach people the C4 model, but we use paper - they’re drawing a lot of boxes and lines and text.
  • 17:00 A lot of architecture diagrams are just named boxes - so I get them to write more text in the boxes.
  • 17:10 People love the C4 approach, but hate using paper.
  • 17:20 Until a few years ago, I was recommending Visio - they are just boxes and lines, after all.
  • 17:30 Over the past few years I have been creating my own tools (called structurizer).
  • 17:35 There are two parts; there are a set of open-source libraries for Java and C#.
  • 17:45 The libraries allow you to describe architecture using code, in a similar way to PlantUML.
  • 18:15 There are exporters that can convert to other formats.
  • 18:30 There’s no forward engineering or model-driven architecture.
  • 18:40 If you’re creating an architecture diagram with code, then it can be executed - and you can use reflection to go and find things in code.
  • 19:00 (On a tangent: one of the things Jigsaw should give us is better modularity in apps, which should simplify the modules and thus diagrams of our apps.)
  • 19:30 The other half is a web-based front end (both open-source and commercial are planned) that will render the diagrams and create documentation in markdown or asciidoc.
  • 19:45 It’s like a publishing platform for your architecture.
  • 19:50 This can be integrated with the automatic deployment process and build pipeline; the documentation can then be updated automatically.

What is the difference between a team lead and architect role?

  • 20:45 It depends on the audience - for some customers, a tech lead is an architect, for others the difference is that a team lead is a lower version of an architect in an organisation.
  • 20:55 From my perspective I treat them as synonymous.
  • 21:05 Patrick Kua wrote a book “Talking with Tech Leads” that is talking about a software architecture role.
  • 21:20 His definition is that a team lead is someone who is a project lead but who also codes at least 30% of the time.
  • 21:25 So it’s a hands-on role - there’s a lot of benefit to have architects who are hands on, because they get to know the work, get to know the pain, see whether others are following the architectural principles and the quality.
  • 21:45 IF you have a big system with lots of team members, the amount of time to code diminishes quite quickly.
  • 22:00 So ideally, the architect should have a hands-on role.

What are some of the things that change from a tech lead to an architect?

  • 22:55 One of my simplest advice is to find a mentor - ideally in the same organisation, but perhaps through a meet-up.
  • 23:15 A big part is actually dealing with people - although it’s a technical role, you do have to influence and lead people.
  • 23:45 Day-to-day dealing with people is a different skill set to working with technology.

How do you refine those soft skills?

  • 24:25 Mainly with practice - just doing it; winning some battles and losing others.
  • 24:30 There are some books you can read - Gamestorming: a playbook for innovators and Innovation Games which we discussed earlier.
  • 24:45 Having some visual collaborative techniques can go some way towards reducing a number of barriers about conflict resolution.

Do you have any recommendations?

  • 25:10 The Gamestorming and Innovation Games books should be on your list, but Switch by Chip Heath and Dan Heath - books like that.

What are the architectural patterns you’re seeing today?

  • 25:30 I’m seeing things like the distributed monolith.
  • 25:40 I’ve been to some customers recently who have told me they are adopting micro-services, but are running into issues, because they are taking their monolith and breaking it apart with network calls and REST interfaces.
  • 25:55 That doesn’t scale, of course.
  • 26:00 It’s worrying that we’re seeing this happening more frequently.

What is a distributed monolith?

  • 26:30 With a monolith, you put all of your components into a single container and deploy it in one go.
  • 26:45 If you want to modify one component, you have do redeploy one thing. With a distributed monolith, it’s essentially the same thing - they are “micro-services” with a synchronous network call and you probably have to redeploy them all together.
  • 26:50 You have coupling and lock-step in terms of integration and deployment.

You’ve said you’ll give copies of your book to people who are doing an architecture meet-up. Why is that?

  • 27:05 First, I don’t understand why architecture isn’t talked about more widely - even at architecture conferences, there aren’t many talks about the practice and processes, they’re more about the latest micro-service and react frameworks.
  • 27:25 It irritates me because software architecture is one of the fundamental things that all software developers should know about, and it bugs me that we don’t talk about it enough.
  • 27:35 So as a way to encourage meet-ups, and groups of people to talk to architecture, I thought I can give some books away. Just e-mail me with the details about the meetup and I’ll organise a few copies of my book.

Resources

Book recommendations

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and YouTube. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT