Full-text dispatch from Frederick Vanbrabant's Delirious Rantings
There is this line of thought that has been bugging me for a while now: “With the coming of LLMs we don’t need juniors anymore”. The idea is that all the boring work (boilerplate, etc.) can be handled by LLMs, and we can now just focus on the real work. As you’ve probably heard a million times by now, the counterargument to not hiring juniors is the question of succession. Who will be…
The market is in a weird place right now, a lot of companies are making record profits, but at the same time every other company seems to think bankruptcy is around the corner. Both of these camps seem to use the same general strategy: cut costs and maximize profits. What mainly comes down to: getting more money.
I have the feeling that every organization out there is, at least partially, focusing on process optimization, something that often happens when the market is down. These days there is also the AI angle to the entire thing, and the unrealistic expectations that follow it. To come fully prepared for this, I’ve decided to re-read two absolute classics in this space: The Toyota way & The Goal 1…
Last post I wrote about how you can approach buy in for your architecture . I’ve been thinking a lot more about the topic, and would like to delve a bit deeper into it. I still stand fully behind the post I wrote two weeks ago, but the more I think (and research) about it, the ideal situation is that you don’t have to seek buy in for your architecture at all.
I recently read the quote, ‘The best architecture that isn’t implemented is just an expensive drawing,’ and I couldn’t agree more. I wish I came up with it. When organisations hire for architecture roles they always look for extremely technical and knowledgeable people. While it is true that you need deep technical knowledge to set up large-scale architecture outlines, it’s all…
Two weeks ago I wrote an article about governance and documentation on an organisational scale. This is the follow-up post that focuses on the project scale. You could just read this post, but it’s probably better that you start with the previous one first The biggest problem with documentation is that nobody just sits down to write it all out. And I also think that’s the wrong way to…
If you’ve known me for long enough, there will be a point where I’m going to pitch you the concept of Obsidian . I adore that program 1 , I basically live my life in it. Everything is connected, and ideas just bubble up on their own. That love for Obsidian is always amplified when I have to look up something on an organisational documentation platform. I can never find anything, it’s…
I first learned of systems thinking in the domain of city planning, and that is apparently also where the idea comes from. It was described to me in the context of building new residential buildings and effects on local bird populations. Birds don’t always perceive glass clearly, especially when it’s a tall apartment building and on their flight path. So there are birds that think they can…
Some years ago I worked with a scale-up that was really focused on the way they handled data in their product. They extensively argued over data language, had value objects everywhere, explicit models and, even hexagonal architecture. It was a cool place to work, with a lot of smart people. At some point they started to talk about standardizing their data transfer objects, the data that flows over…
Every six months or so I read a post on sites like Hackernews that the enterprise service bus concept is dead and that it was a horrible concept to begin with. Yet I personally have great experiences with them, even in large, messy enterprise landscapes. I would go even further and say that I see a resurgence in their usage in big enterprises. Even companies that moved away from them seem to have…
Before my end-of-year holiday break, I received an email 1 from someone who read my post about “ Choosing your starting line in enterprise architecture ”. Mark asked me what I meant by the line: So yes, you can map the AS-IS. You can design the TO-BE. You can even claim you’re doing both, which is the classic architect escape hatch.
Organizations often use “value stream” and “value chain” as interchangeable labels. It’s not the biggest architectural drama in the world, but it’s still something that always annoys me a little. We as architects might actually be to blame for this. We keep on coming up with related concepts that are very close to each other and then naming them ever so slightly differently.
I’ve been part of the creation of five enterprise architecture offices in my life. Some I’ve led, others I’ve simply been part of. If you start up an enterprise architecture office, you have two types of strategies people use. Some people start by mapping everything that exists, in whatever state it happens to be. They then assess what they have and start building a gap analysis towards a…
Every company that I’ve helped start their enterprise architecture practice so far, always tell me that they might not have architecture setup yet, but they do have a ton of information in the CMDB that we can use to kickstart the exercise. The CMDB is our source of truth of all the applications, servers, and it’s all linked to service lines and capabilities. Furthermore, it’s…
When I was a developer, half of our frustrations were about technical debt (the other were about estimates that are seen as deadlines). We always made a distinction between code debt and architecture debt: code debt being the temporary hacks you put in place to reach a deadline and never remove, and architectural debt being the structural decisions that come back to bite you six months later.
A few weeks ago I walked into a meeting room to discuss my solution to a fork in the road problem. We’ve been roadblocked for two weeks with two clear paths forward. One of them I preferred; a bit more work, but it would bring dividends in the future and not burden us with a less than ideal solution. The other way forward was what a different group wanted: to push the project through so they…
Architects always get a bad rap when it comes to design documents. We get blamed for delivering these massive solution design documents that take weeks to produce, eat into the time for development and in the end result into an encyclopedia that nobody reads. The architectural drive to document and cover as much as possible naturally evolves into templates that are in the 40–50 pages (template…
Every time I go to teams and start talking about process mapping and standard operating procedures (SOP) I notice an undeniable amount of unease like it just got a few degrees colder. What people hear isn’t “we’re here to understand your work and make it smoother.” What they really hear is: “We’re here to judge, strip the creativity, maybe even replace you with a machine.”
In my startup days, we often had these dead marches where we had to implement a massive new feature in time before some kind of trade show happened. We worked long hours and even weekends to make it happen so the boss and a project manager could go to Vegas for the trade show. When they came back on Monday, they told us what the competition was doing, and laid out a brand-new strategy they’d…
I’ve been working a lot with service line architecture recently. If you’re not familiar with that; it’s how business units such as IT, HR, or Sales bring services to clients, both internal and external. These structures often mirror team organization. Think of it as a hierarchy: IT at level one, Software Development and Ops at level two, and then individual teams, like: Software…