Today I’ve been working exactly minus 23 days at JDriven. So as you might expect, officially I’ll be starting there at the first of July. For my new employer, this is no reason at all not to invite you on the seminars they provide for their people, so yes this proved as well there is a reason to make this next step into choosing for JDriven. So last Thursday there I headed to headquarters at Nieuwegein for a full day workshop about Microservices, given by nobody else than Sam Newman!
"We’re agile! Just build it!" Or on the other hand; "agile does not support Software Architecture so we should stop doing agile". Two very different opinions that you can sometimes hear within the same company. Which one is right? Or are they both wrong? Should we stop doing architecture to be more agile? Why do we even need architecture? In this post I’ll give my view on the matter and hope to inspire you to combine Agile and Architecture in your organisation.
While many of the architectural challenges we have to deal with are big hard choices, there are also many smaller simpler ones.
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:
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?
A low code approach to composing microservice architecture diagrams from per service context diagrams.
Congratulations! Someone has made the wise decision to hire you as the new technical lead. It is an exciting time. You start in a new environment, will be working with a new team and maybe even have to learn new technologies along the way. This can be quite challenging. In this two-part article I want to share my personal views regarding Introducing change and shaping teams as a technical lead.
In a previous post we learned how to use a
together block to keep elements together.
We can also layout elements in a different way: using hidden lines.
We define our elements and by using the keyword
[hidden] in our line definition the elements are layout as if there was a line, but we don’t see it.
This gives us great flexibility on how we layout our elements.
Inspired by Neal Ford’s presentation at our Change is the Only constant event I started experimenting with architectural fitness functions. An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s). If you want to take a deeper dive into evolutionary architectures including fitness functions take look at Neals book: Building Evolutionary Architectures: Support Constant Change. Neal’s slides contained an example of verifying package dependencies from a Unit Test using JDepend.