Documenting

Easily build your own tech radar

Posted on by  
Sander Smeman

The Thoughtworks Technology Radar is well known for showing technology trends and choices. For my project I wanted to have the same thing, not use the hosted public version from Thoughtworks, but a selfhosted option. Therefore I choose to base it on the Zalando opensource tech radar, and create a way to use a CSV file as input so updating would be an easy thing to do. To accomplish that I took the following steps:

  1. Create a folder to put the tech radar into: ${project-folder}.

  2. Start with the HTML5 Boilerplate index.html file and put it into the ${project-folder} file.

  3. Insert the snippets as documented at Zalando Tech Radar, with one adjustment. I don’t fill the entries array with entries, but will do that later on, from the input in the CSV file. Note the names of the rings and quadrants, as they will be used in the next step, the CSV.

  4. Create a CSV file (${project-folder}/data.csv) as input for the tech radar. It has columns for the ring and quadrant where a technology should be put, and an indicator for movement. The names of the rings and quadrant should equal those in the configuration copied from the Zalando example. If you changed them, use those names instead. The movement indicator is (up, none, down) and in the next step translated in to value understood by the radar. The CSV will be translated into entries for the radar.

  5. Add the following D3.js library to parse CSV:

    This library provides functions to parse CSV file(s) into a map structure per row in the file.

  6. Create a function to transform a row in the CSV into an entry for the tech radar:

  7. This is the diversion from the steps in the Zalando tech radar description. Wrap the radar_visualization() function a custom one, that takes an array of entry, to render the transformed rows, e.g. draw_radar(entries).

  8. Finally glue everything together to fetch the CSV, parse and transform it, and draw the entries. The code below uses the functions I defined in the previous steps

    When you have followed the above steps, the result should look like this:

Continue reading →

Lightweight Architecture Decision Records

Posted on by  
Niels Dommerholt

As a software engineer you make architectural decisions all the time. Neal Ford calls these software engineers 'accidental architects'. I personally prefer the term implicit architects because I don’t think software engineers doing architecture is in any way an accident or even something you would not want. You’re the expert after all. Decision making is one thing though, how do you document these decisions?

In my current project my function title is Software Architect. I have mixed feelings about this. While it definitely looks good on a resume I actually don’t feel software architect is a function title. Software architect is in my opinion a role, and one that can’t be handled by someone that doesn’t have his or her’s boots on the ground where the software development happens.

This is reflected in many teams where there is an 'architect' that, every now and then, comes down from his golden throne in his lofty ivory tower to enlighten the code monkeys software engineers with his architecture. After enlightening the engineers he again ascends the thousand stairs to his throne to work on his next perfect work.

Another word for this is a seagull architecture; architects that, like seagulls, fly down cover everything with shit and then fly off again. Leaving the software engineers wondering what they did wrong in a previous life to deserve all this. And if you’re lucky you don’t have a single seagull to deal with, but a whole team of them with conflicting ideas on the direction your teams should take.

Continue reading →

Microservice architecture diagram composition

Posted on by  
Tim te Beek

A low code approach to composing microservice architecture diagrams from per service context diagrams.

On a recent assignment I was one of multiple new engineers joining a start-up transitioning into a scale-up. The past two years had been spent rapidly developing to prove the concept, and while at the outset some diagrams were drawn up, at the time I joined these were outdated, lacking or even misleading. To help get ourselves and other new developers up to speed, Andrew Morgan and I set out to create architecture diagrams for the system as a whole.

Continue reading →

shadow-left