#Architecture diagram of program software#

While most of the arrows are unidirectional (one-way), there's a bidirectional (two-way) arrow between the 'Risk System' and 'IAM' boxes. And 'input' (from 'RDS' to 'Risk System') is quite generic and ambiguous, especially if you don't know what 'RDS' means. I imagine that 'audit logs' are being sent to the 'Audit Log' box, but it would be nice to know what sort of things this might include. Only around half of the lines are labelled, and this is very common. Do you understand the meaning of all line styles used? (e.g.Do you understand the meaning of all arrow heads used?.protocols for inter-process communication) Where applicable, do you understand the technology choices associated with every relationship? (e.g.Does every line have a label describing the intent of that relationship?.the 'Audit Log') really just an implementation detail of the 'Risk System'?įinally, let's look at the relationships: 'software systems'), or are some of them (e.g. Moving away from the visual aspects, it's not actually clear what the elements represent, in terms of the level of abstraction. Why are some elements blue, while some are black? We have a collection of shapes being used here, and I'm not sure what the difference between the rectangles and the ellipses is. 'IAM' is quite a generic term too, so perhaps it would be better to add more detail. I know what 'RDS' means here, but you probably don't, so that should really be fixed. small vs large boxes)Įvery element has a name here, so that's good, but some of those names are acronyms/abbreviations. Do you understand the meaning of all element sizes used? (e.g.Do you understand the meaning of all border styles used? (e.g.Do you understand the meaning of all icons used?.Do you understand the meaning of all shapes used?.Do you understand the meaning of all colours used?.Do you understand the meaning of all acronyms and abbreviations used?.Where applicable, do you understand the technology choices associated with every element?.Do you understand what every element does?.Do you understand the type of every element? (i.e.

Again, here are some things to think about: Let's move on to look at the elements in more detail. I'd recommend adding a diagram key/legend for UML and ArchiMate diagrams too, since not everybody will know these visual languages. And while that's not necessarily a bad thing, a diagram key/legend would help readers to understand the notation being used. Well, this looks like an ad hoc collection of 'boxes and lines' rather than being UML or ArchiMate. My assumption is that the large box labelled 'Risk System' is the scope of the diagram, but a better title would clarify this.Īnd regarding notation. I'd estimate that upwards of 90% of the initial diagrams I see created during my workshops don't have a title! In this case, the diagram does have a title of 'Context', but it's not explicit about what it's showing the context of, and what the diagram scope is. Do you understand what the diagram scope is?.Do you understand what the diagram type is?.Here are a few initial things to think about: Let's start by looking at the diagram as a whole. It's high-level, clean, concise, colourful, and you might even be able to work out what's being described here. On the face of it, this diagram doesn't look too bad.

Let's start with a fairly typical example of a whiteboard diagram from one of my workshops. Some diagrams are better than others, but I've noticed that many people struggle to critique a diagram because they're not really sure what to look for.

#Architecture diagram of program software#

I see hundreds of software architecture diagrams every year, predominantly through my software architecture workshops.