Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Naming (Or How Names Can Be Ambiguous)

DZone's Guide to

Naming (Or How Names Can Be Ambiguous)

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

I've done a bunch of software architecture sketching sessions with teams over the past few months and, although we cover a lot of ground, here's a tip to improve your diagrams. If naming is one of the hardest things in software development, resist the temptation to have a diagram full of boxes that only contain names.

A really simple way to add an additional layer of information to an architecture diagram (and to remove any ambiguity) is to annotate boxes with a very short statement of what their responsibilities are. A bulleted list (7 ± 2 items) or a short sentence work well. Provided it's kept short (and using a smaller font for this information can help too), adding responsibilities onto diagrams can help provide a really useful "at a glance" view of what the software system does and how it's been structured. Here's an example ... which diagram do you prefer?

Naming

If you're interested in how to sketch software architectures, you can...

Happy sketching!

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}