Frederick Vanbrabant's
delirious rantings

Antwerp, Belgium

The CMDB as an architecture source
7 min read

The CMDB as an architecture source

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 maintained by a team and it’s fully ITIL aligned. It’s a treasure trove!

Read More

Architectural debt is not just technical debt
6 min read

Architectural debt is not just technical debt

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.

Read More

Nemawashi and the Meta of Meetings
5 min read

Nemawashi and the Meta of Meetings

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 could reach the deadline.

Read More

Solution designs should only be a few pages
6 min read

Solution designs should only be a few pages

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 alone).

Read More

Following processes won't make you a robot
5 min read

Following processes won't make you a robot

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.”

Read More

Teams Outlast Projects
4 min read

Teams Outlast Projects

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 dreamed up between hotel bars and expo booths.

Read More

How teams grow organically
5 min read

How teams grow organically

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 Team X or Ops Team Y, at level three.1

Read More

Pace layering an application portfolio
8 min read

Pace layering an application portfolio

In every organization I’ve worked with, there’s always been a handful of core applications, central, timeworn systems that quietly hold the business together.

Knowledge of these systems often lives in the heads of a few long-tenured experts and is usually passed on through informal, almost ritualistic projects where newer employees are slowly initiated into their mysteries.

Read More

The real ask
5 min read

The real ask

One of my mentors, Steven Caus, always taught me the concept of “the question behind the question”: The question we receive is not always the problem we need to solve.

The concept is very easy. When someone comes to you with a question to do something, instead of blindly doing the ask, take a step back and try to understand what they actually want to achieve. Often this task might actually not be the best way to achieve the goal they are set out to do.

Read More
Chesterton’s Fence and paralysing your organization
4 min read

Chesterton’s Fence and paralysing your organization

Some years ago I worked at a place that had, buried deep in the codebase, a service running that combed through the central data warehouse and flagged certain users. One through seven, except four.

A left over from an old proof-of-concept application that had something to do with GDPR. This field went out over the API as part of the “employee data” resource.

Read More