Diagrams in IT

From Federal Burro of Information
Revision as of 17:43, 23 August 2022 by David (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Introduction

You are a system person†; You work in technology. You should be drawing diagrams of systems as part of your everyday activities.

This does not mean you are drawing diagrams _everyday_. But any given day you should be prepared to draw a diagram. Any day you may also come across a change, or learn something and _UPDATE_ an existing diagram. Diagrams must be living doucmenty to be valuable.

Diagrams are documentation as much as _documents_ are documentations.

They should be part of run books, they should be part of planning, they should be part of implementation, they should be part of operations.

Why?

So that you more sure that you understand what's going on and how the system works.

So that you can explain how the systems works:

  • to Developers
  • to Management
  • to New staff

† - be that SRE, Sysadmin, Devops, Architect.

Don'ts

reference: https://www.youtube.com/watch?v=x2-rSnhpw0g ( in C4 diagrams )

  • have boxes and no lines
  • different shapes we don't know why
  • different colours we don't know why
  • different sizes of boxes and we don't know why
  • we have layers both horizontally and vertically
  • Acronyms are used
  • no titles
  • Font too small
  • too much going on.
  • mixing logical , physical, network , and data flows.
  • put too miuch intformation in one view.

Do

  • Use layers.
  • Break up complicated systems in to parts.
  • use colours, symbols , size and shape to convey meaning but