Mark Richards runs the Developer to Architect website, and puts out a video every Monday. He has helpfully categorized them. I watched all the videos in the “Soft Skills” category and took notes.

Gaining Technical Breadth⌗

Everything in the world can be divided into three categories:

  • What you know
  • What you know you don’t know
  • What you don’t know you don’t know

Technical depth is “what you know”.

Technical breadth is “what you know” + “what you know you don’t know”. (Sidenote: I’ve always thought technical breadth as stuff you know at a high level, but never used in production.)

To increase technical breadth is to get stuff from “what you don’t know you don’t know”, into stuff “you know you don’t know”. You can do that by looking at these three websites, and spending just 20 minutes a day on them.

Challenges of Architecture Teams⌗

Beware the Witches Brew Antipattern, which is when a team doesn’t have a clear direction, just a bunch of ideas.

(Sidenote: It’s always rough seeing building architecture used as a metaphor for computer architecture. Mark Richards using a piece of real life architecture that does have a clear direction and concept as a metaphor for bad planning; just because it’s ultra-contemporary doesn’t mean it’s a mess.)

  • So select a mediator. Could be anyone. Could rotate every week.
  • All achitecture opinions need to be backed up with a reasonable justification.
  • When two decisions conflict, mediator decides.

(Sidenote: I don’t like this process. I’m not saying I like a mojority vote more, but I’m a much bigger fan of building consensus, like I see in small town government.)

Presenting Architecture to a Stakeholder⌗

5 tips for conveying architecture.

  • Expansion Joints - In real life, roads have joints that expand and contract in different temperatures. Create a full presentation, then only show a subset of the presentation for different stakeholders.
  • Accordian Slide - Avoid bullet points on the slide. That way you don’t have to read them, and can can summarize. (And you really shouldn’t have bullet points anyways, this is a Tufte idea.)
  • Animation - To show a complex process happening over time, and in parallel, animate it.
  • Dimension and Focus - After the intial oerview of the slide, fade out the parts of the diagram you’re not talking about.
  • Buildouts - As you talk about the different parts of the architecture, build out the picture piece by piece.

(Sidenote: Or, don’t use slides. Use Tufte’s idea of a simple 3 page piece of paper. Let them read it, then discuss. The Expansion Joints is still applicable here.)

Mark is recommending fancy wipes.

Book Recomendation: Presentation Patterns

Diagramming Architecture⌗

Beware the Irrational Artifact Attachment, which is an inverse relationship to an artifact and the amount of time it took to produce it. Don’t get attached, especially to an incorrect diagram.

Tips:

  • Have a title that is short and meaningful.
  • Favor unidirectional arrows. (If information can go back and forth, use two unidirectional arrows instead of one bidirectional arrow.)
    • Don’t need to show arrows for acknowledgement. Only show major directions of information moving.
  • Don’t mislead people with different sized shapes, unless they’re meaningful.
  • Avoid acronyms.
  • If you need to use a color beyond gray, use blue. People with color blindess can unually see blue, and it prints well in B&W.
  • Make sure the most important part has a big and juicy part of the page.
  • Use a key for colors, shapes, arrows, whatever.

Simon Brown created the C4 model, which stands for context, containers, components, and code. You start by showing the system at its highest and most abstract level (how it fits into the IT world), and dive deeper. Eavc lower part is an expansion of the part above it. It’s a good way to start thinking about diagramming. See it at https://c4model.com

Translating Quality Attributes to Business Concerns⌗

Architects often think in terms of non-functional attributes (e.g. interopability, scalability, agility, testability), but business stakeholders think in tersm of business outcomes (e.g. time to market, user satisfaction).

We want a terminology map. When the CEO wants “time to market”, we can map that to “deployability, testability, agility”. Likewise, “user satisfaction” maps to “availability, fault tolerance, performance.” And “Merges and acquisitions” maps to “extensibility, interopability, learnability.” A final example, “competative advantage” maps to “scalability, availability, agility.”

These are bidirectional mappings, you can go backwards as well.

Interesting note: very few of these -ilities can individually achieve the business concern, they only work as part of a group.

The Software Architect’s Bookshelf⌗

The books that were most influential to Mark Richards’ career.

And his number one Linked In group: Enterprise Architecture Forum

Architecture Certification⌗

The Open Group Architecture Certification - There no test, just fill out a nomination packet. It requires you to demonstrate experience, and then write short essays on mentoring, community involvement, business expertise, etc. Then there’s an oral defense.

Is it worth it? Eh. Maybe it’ll get you past an HR filter.

It’s better used as a tool to find your own deficiencies. Fill out the nomination packet, and see what you should be doing.