Antwerp, Belgium
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
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
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
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
Cost reduction is one of the main focuses of so many companies out there today. The market is not great, and that is the moment companies take a deep look at the financials of it all.
One of the first things that is being asked is: What are we really spending?
Not just the big hard numbers like contracts and licences, but everything. The hidden costs and invisible hours.
Read More
It’s the start of a new fiscal year. Strategy season. That time when all the grand ideas come out and everyone is still hopefull.
Over the years, I’ve settled into a structure that helps me define projects that not only link to the strategy above but also looks at my own team’s enviroment, I thought I’d share it here.
Read More
Last week, while sitting in a bar, I had a chat with a good friend of mine about the role of software in an organization. I stated that the primary role software plays in an organization is to facilitate processes. My friend argued that this is a strict and overly theoretical view of software in the workplace. He might be right, but nevertheless, I think there is an article in this conversation.
Read More
In my last post1, I briefly talked about how I include information (PPTI) in my operating model (PPT), and I even promised to write a post about it. This is that post.
People, processes, and technology are very common ways to look at an organization from an architectural point of view. It is often argued that everything that happens (projects, implementations, strategy, etc.) is impacted and driven by these three pillars.
Read More
One of the most confusing things about architecture is the vagueness of the naming surrounding it. This is true not only for non-architects, who often don’t really know in detail what all the different disciplines do, but also for the architects themselves. A lot of the naming seems to be based on feelings without any clear definition.
Read More
Well, the real title was going to be “Business strategy is like a lizard: It leaves behind its tail while it grows a new one,” but that was just too long.
Strategy never exists in isolation: it’s always a response, a build-up, or a pullback. It also has to be passed down to all the layers of the organization to make these chances. It’s a very reactive business.
Read More