#81 - Architecture Is Context—Making the Right Architecture Decisions - Eltjo Poort

[00:01:18] Episode Introduction

Henry Suryawirawan: Hello, my friends and all my listeners out there. I’m very happy to be back here again with a new episode of the Tech Lead Journal podcast. I am your host Henry Suryawirawan. Thank you for tuning in listening to this episode. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your favorite podcast app and social media on LinkedIn, Twitter and Instagram. And if you are a regular listener and enjoy listening to the episodes, will you subscribe as a patron at techleadjournal.dev/patron, and support my journey to continue producing great Tech Lead Journal episodes every week.

Making architecture decisions is hard, especially if we focus too much on coming up with a perfect architecture. There are so many aspects that we need to consider both from the functional requirements and also the non-functional requirements, which are also sometimes called quality attributes. Not only making the architecture decisions itself is hard, communicating and documenting them are also equally challenging. And how about managing and dealing with technical debts? How can we think about prioritizing fixing technical debts versus all the other things that we need to do?

My guest for today’s episode is Eltjo Poort. Eltjo is the architecture practice lead at CGI Netherlands with over 30 years of experience in the software industry. He was involved in the implementation of the first SMS text messaging systems in the 1990s and received the Linda Northrop Software Architecture Award in 2016 for his work on Risk- and Cost-Driven Architecture.

In this episode, Eltjo started by explaining the importance of architecture context and business drivers that can help an architect understand the different trade-offs and options in order to make the right architecture decisions. Eltjo shared the architect’s main responsibilities and how architects should avoid writing big and long architecture documents by understanding the different goals of an architecture document. Eltjo also shared his great insights on how we should deal with technical debt, “move slow and fix things”, and put a more balanced efforts towards working on enablers in order to maintain sustainable pace in delivering great software. Towards the end, Eltjo shared a few anti-patterns that architects should avoid based on his article “Waterfall Wasteland and Agile Outback”.

I really enjoyed my conversation with Eltjo and learning about architecture has always been one of my favorite topics. If you also enjoy and find this episode useful, please share it with someone you know, either your friends or colleagues who would also benefit from listening to this episode. Also leave a rating and review on your podcast app or share about this episode on your social media. It is my ultimate mission to make this podcast and the knowledge available to more people, and you can play a part towards fulfilling my mission. Before we continue to the episode, let’s hear some words from our sponsor.

[00:05:14] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I have a guest with me. He’s an experienced digital software architect with over 30 years of experience. He currently leads the architecture practice at CGI in Netherlands. So as you can tell, today we are going to talk a lot about architecture which is one of my favorite topic in this podcast. Really looking forward to have this conversation with you. Thank you so much for being here.

Eltjo Poort: My pleasure.

[00:05:40] Career Journey

Henry Suryawirawan: I always like to start my conversation by asking about my guests to share their journey or their career experience. Maybe you can also tell us your highlights or turning points in your career.

Eltjo Poort: Yeah. So I started getting interested in programming basically in high school when I discovered the existence of calculators that you could do small programs in. TI- 57, I think was one of the main treasures. When I started going to university, I started studying theoretical physics because we yet to have a computer science curriculum. This was in 1980. So quite a while ago. But I soon discovered that I’m actually much better at software than I am at physics.

In the end, I ended up working for a small software house for seven years. We basically made you would know call them ERP systems, but they were very small for small businesses. After seven years, I decided to move onto my next job, which is actually my current job. I joined a company that was called CMG in 1993. That company, through several mergers and acquisitions, became CGI, which is where I’m working for now. I started there as a developer or a software engineer. I still don’t know exactly what the difference is. That’s a topic for a different conversation, I think. But after a few assignments, I got some more responsibilities. I became a team lead. We were actually working on a software for telecommunication providers, specifically for mobile telephony.

We were working for several mobile telephony networks and they required something which we considered to be quite strange. Mobile phones had these letters on their keys. You could use those to actually send very short text messages, maximum of 140 characters. Nobody thought anybody was ever going to really use that because it was so awkward. The telecom operators they wanted it anyway because it was part of the standards. So they asked us to build it. As soon as we had finished that, we discovered that actually young people found these short text messages extremely attractive, and they were using them all the time. That led to a huge demand for SMS technology, which we would then basically (take) the lead in. There was a time in the late nineties when I think over 90% of all the text messages of the worlds were passing through our systems.

I got involved in that, first as a team leader and then quite quickly, they needed somebody to talk to the clients because we were getting more and more clients very quickly. So I became what they called customer accounts supervisor. My job was to oversee the deployment of new systems and new clients, but also then to do basically account management for these clients in the first years of their using our systems. Some of my clients were in the United States, which was not a strategic choice, but the demand was such there. Well, we didn’t want to go there, but we want to sell our systems there. But the demand there became so big that we decided to start an office there, a very small office for local support and local sales. So I spent from 1996 to 98, in our small office in New Hampshire, in the United States.

After two years, my family situation was such that we wanted to come back to the Netherlands. And then I was in a situation in my career where I had basically done just about everything related to software. I had done sales. I had done project management. I had done development and etc. I had an opportunity to look back and see what I liked. And I decided that I liked leadership. But I didn’t look like management. So what I liked was basically content management. Management based on technical decisions and content and expertise, or leadership based on. And now we would call those roles tech leaders or architects. But, at that time, that was a time in the late nineties when the whole architecture movement in the software world was coming into being. It became basically the thing that I focused on and I haven’t looked back ever since.

I started to become the lead architect on ever bigger projects. After a while, about 10 years ago, I became the leader of the architecture practice, which is the architecture community that we have in CGI in the Netherlands. And also outside of the Netherlands. I took part in the leadership as well, which is quite informal but still it’s a big community over a thousand architects. So now I spent about a third of my time on those responsibilities of leading that community. The other two-thirds, I worked with government organizations and also financial institutions, high-tech companies, because architecture is such a broad topic and it’s needed everywhere. Of that time, I spent about one-third helping organizations modernize the way they do architecting. Moving away from the big upfront design type of traditional architecture function and going towards a more agile way of working. The rest of the time I do second opinions, assessments, evaluations of other people’s architectures. For various reasons either because they have a project that’s in trouble or product that they’re not sure about, or they want somebody to look into it, or they just want to make sure when they’re about to commit to a design, they want to make sure that the design is okay, and they want to have somebody from outside the team to give a second opinion about that.

Henry Suryawirawan: Thanks so much for sharing your story. The moment when you shared about inventing or maybe working on the SMS technology, I was probably one of those young teenagers during that time, like trying SMS, and it’s so cool. Thanks for bringing that to the world and so that we all used it. Although now it’s probably a little bit obsolete, getting replaced by all these chat apps.

Eltjo Poort: You still see the remnants of some design decisions of those times. You still see it in today’s social media platforms like Twitter, the length of the message is 280 characters, which is twice the 140 that was the limit for the GSM standard for text messages. So yeah, you see that in a strange way, some architectural design decisions that seem rather random can live on and have an impact decades later.

[00:11:10] Architecture Is Context

Henry Suryawirawan: Speaking about design decisions that seem to be random, right? I think one of your key message, when I look at the articles that you wrote, it’s about getting to understand the context. Architecture is about context, right? So all these seemingly random decisions, probably at that time, it’s not so random. Maybe can you elaborate more what you mean by architecture is actually context?

Eltjo Poort: Yeah. So when you learn software design, you learn a lot of good design principles. Depending on the sort of school of thought, you know, you either learn how to decompose the responsibilities of a new system into several components, or you learn how to basically look at common responsibilities and design classes and objects and relationships between those. And there’re a lot of good design principles, such as information hiding. If you hide the information that’s inside an object from the outside world, then that means that you have a lot of freedom in rearranging that information as long as your interface to the outside world stays the same. So that’s one example. Another example is low coupling and high cohesion, and those are all good design principles that, of course, every software developer in architecture knows.

However, to me, it becomes architecture if you do not just look at these generic, good design principles, but you actually look at the business context in which you apply them. So, justifying a particular choice in your design by saying, yeah, this choice leads to high cohesion and low coupling, right? For an architect, I don’t think that’s good enough. I think you actually need to show how in this particular system, in this particular business context with these drivers, that is actually a better choice than doing it the other way around, because every design choice that you make has alternatives. And you can only make the right trade-offs between these alternatives if you know the context drivers. These can be commercial drivers. It can be time pressure. They can be technical drivers. If you look at, for example, design principles such as information hiding, that’s a very good design principle. If your goal is to be able to modify the software easily later on, and to have few dependencies between what’s going on inside such a module and what’s going on outside it. But sometimes that is not so important and something else maybe much more important such as delivering something on time.

Those are the trade-offs that you have to make as an architect, and this is why I keep saying architecture is context. And that leads to all kinds of other good practices, or things to avoid. So it means that as an architect, you should not hide in your ivory tower and just make great designs because you can’t. You cannot make the right trade-offs if you don’t talk to the business people or the business stakeholders, as well as the technical stakeholders that can tell you what are the important drivers in this particular situation.

[00:13:51] Understanding Architectural Trade-offs

Henry Suryawirawan: So I think it’s very important that you mentioned the key word trade off, right? Because at the end of the day, it’s about multiple different factors. You mentioned about commercial aspect, maybe time, maybe technologies that are available at that point in time. And you mentioned sometimes all these requirements actually can seemingly be in conflict with each other, which makes it sometimes difficult as an architect or technical leader to make decisions. Maybe, can you tell us more about how can an architect actually be able to make good decisions, out of this sometimes seemingly, you know, in conflict requirements?

Eltjo Poort: So that requires a number of steps. Of course, first you need to understand these requirements and how they can be conflicting? Some requirements never conflict, like functional requirements, what we want the system to do. It’s either they have to do this or they have to do that. They cannot be conflicting, right? It’s either it leads you to that restaurant or it leads you to that restaurant if you’re looking for a restaurant. But the conflicts arise actually in the other requirements. The ones that are not just about plain functionality, which we often call non-functional requirements, but actually a better name is quality attribute requirements. And these are things like performance or modifiability or usability, etc. This is where the architectural trade-offs really come into place. And there’s another category of non-functional requirements, or some people call it constraints, which have to do with delivering on time or creating the software with a certain group of people. Some people call those extra functional requirements or I like to call them delivery requirements. And those are the things that really drive the architectural decisions. It’s very rare that just the plain functionality, the functional requirements drive the architecture. So you have to understand this and you have to understand what are these non-functional drivers.

That’s step one. Because that will lead to the criteria that you will use to make your decisions. Then, of course, you have to also be aware of what are the various choices that you have. If you had to make a decision to go for something that you think has only one alternative, or it’s the only one choice, that’s not a decision. Decision is if you have several choices. So in order to make the right decision, you also need to make sure that you are aware what are the choices that you have? What are choice A, B, C, and D that I have to choose between? For example, what is a good development language for this particular system? Should we go with Java or should we use Python? Or actually, should we not use a development language at all, but go for some low-code or no-code option, and just configure some existing thing? Those are alternatives that you have to choose between as an architect. If you are lazy in the sense of, okay, Java worked the last time on my last project, so I’ll just use Java again, and then use some generic design principle that says that Java would work here for this, you actually have a risk of missing the best choice there. So a good architectural decision also mentions or takes into account the choices that you did not make.

And then once you have the criteria, based on your architectural drivers, usually non-functional requirements, and you have the choices that you have to pick between, then you have to make the trade-off. This again is something that is very hard to do on your own. Actually, it’s probably impossible to do on your own. Because now you have to see what are the impact of every choice on the various criteria that you’re using to make that decision. That’s not something I think that a technical person should do unless, of course, it’s just the technical criteria. Like, does the platform support this kind of messaging protocol which is required? Yeah. Okay. That’s a very technical criteria. But if it’s about more business-like architectural drivers, such as affordability or maintainability, then you need stakeholders to make the decision with you.

So most architectural decisions actually are made not just by one person or one architect. Also not just by the team, the technical team, the agile team that is creating the software. They are mostly made together with other people. And this, I think, is the core of the work of what we call the Tech Lead function in a team. I don’t think the Tech Lead or the architect should necessarily have the mandate to make all architectural decisions because sometimes they have a big impact on money, for example, and on risks. But they certainly should, are responsible for making sure that architectural decision is made, and that the right people are involved, and aware of the trade-offs that they have made.

[00:17:59] Understanding the Business Drivers

Henry Suryawirawan: So speaking about asking other people, I think sometimes, maybe it’s anecdote, right? So when you ask business people, what do they want? They want everything right. I want speed. I want fast. I want a good UI/UX, I want, slick, whatever that is. So, and you mentioned one key point that, which I think is really important, a good architect needs to always keep asking the business why? Maybe I don’t know, using five why’s or whatever number of why’s. But why do you think this technique actually matters for an architect as well?

Eltjo Poort: Well, I think just knowing what the business needs is not enough to make the right trade-offs. You need to know the reason why they need it because that’s where the real architectural drivers usually are. They can tell you, okay, I need Microsoft Teams in my landscape now. And that may be the right choice, but we don’t know unless we also know why they think they need Microsoft Teams rather than Google Meetup or WebEx. So we cannot help them with that decision unless we know why. Yes, of course they say we want everything. But they only say that they want everything because they are unaware of the trade-offs. Every choice that they make has drawbacks, and I think it’s our job to point out those drawbacks to them. Specifically, to point out those drawbacks and those trade-offs in their language.

If we say you have a preference for this particular way of doing it, but it leads to a more complex system. You’re not going to convince them. They’re not worried about the system being more complex. They say, that’s your job. You’re the architects, right? You’re the technical person. So you deal with the complexity. Why are you bothering me with that? But you need to translate that complexity into what it means for the business. A more complex system means that it’s going to probably take more people to keep the complexity under control, so it’s going to be more expensive. But maybe even more interesting for the business people is actually it increases the risk of bugs. Because in a more complex system, we can not always oversee the whole impact of a particular change. A seemingly simple change may actually impact a lot of other components, which means more work. So once again, more expensive. But also, more risks because there are extra dependencies and we may miss a dependency or an interface may change that we are not aware of, etc. So if we translate those tradeoffs into business terms, then we help them be involved in the decision of making the right architectural choice, the right design choice, instead of just being annoyed that they want everything and don’t understand everything.

I once was at a certain conference, and there was a presentation by a guy called Jochem Schulenklopper. The name of the presentation was “Why they just don’t get it?” It was a great presentation about how architects sometimes seem to think that the business people are stupid because they don’t understand. It’s the other way around. It’s our responsibility to make them understand the impact of what they want, and so we need to talk their language rather than just be annoyed that they don’t speak our language.

[00:20:41] Incorrect Architecture Decisions

Henry Suryawirawan: So which brings us to actually a very important point, right? No matter, maybe you have done your analysis, the NFR, all the choices. You inform the stakeholders or whoever people that need to make the decision together and you make the decision, right? But at the end of the day, I think there’s no such the best, a hundred percent correct architectural decisions. And especially as time goes by, your architecture also might need to change. So maybe if you can touch on a little bit on here, like sometimes I see people also like going into a project or just join a new company, they see, oh, this is not so good architecture. That’s why it’s very important to actually understand the context. How can you actually explain this to those new people, or probably stakeholders or leads who just knew about legacy? They don’t actually be part of the decision-making.

Eltjo Poort: Yeah. So, talking about bad decisions or legacy decisions from the past, it’s actually unavoidable to make decisions that, after the fact, may turn out not to have been optimal. One of my favorite sayings is from Phillipe Kruchten, who some of you may know from the 4+1 views architecture framework. He says that the life of a software architect is a long and sometimes painful succession of sub optimal decisions made partly in the dark, which is frustrating. And why is that? Why do architects, from time to time, make decisions that after the fact turn out to be wrong? It has to do with the order in which you have to make decisions as an architect.

Basically, what it comes down to is you have to make the most important decisions at the time when you have the least factual knowledge. And of course you do everything to try to avoid that. You try to keep your options open. You try to delay your decisions until the point in time where actually delaying it further would break things, or which would make people not being able to work anymore. Of course, you try everything to delay the decision until you have more knowledge. However, you have to make the most important or the most impactful decisions first. Because every decision that you make constraints all of the other decisions that you have to make in the same design space later on. So your architectural decisions, they reduce your design space. They reduce your options for later on. And what you do not want is that a low-impact decision and unimportant decision constraint your choices for much more high-impact decisions that you have to make later on. That is actually doing it the wrong way around. Basically, what you’re doing then is painting yourself in a corner. So you have to make the most important decisions first, because you want to make the high-impact decisions constrain the low-impact decision and not the other way around.

So that means that no matter what you do to keep your options open, in the end, you end up making decisions that actually if you would have known two months later on, you would have done them differently. So this is why it’s unavoidable to get into that kind of situation. What can you do about it? Of course, you have to try once again to get your options open. If there is this particular high level of uncertainty still around, you try to find ways to make it easier to refactor if it turns out that it was the wrong decision. But in the end, it’s unavoidable. You sometimes make a wrong decision. You have to live with that.

[00:23:45] Architect’s Responsibility

Henry Suryawirawan: Speaking about decisions, right? You mentioned a couple of times architecture making decisions and all that. This is, I think, probably also counter intuitive for me because all along that I know is that architect provides a blueprint or high-level architecture diagram or just roadmap of what the system should be. But you actually mentioned that an architect’s deliverable is actually making architectural decisions. And these are plenty, right? Decisions, not just one. So tell us more about this responsibility of an architect?

Eltjo Poort: Yeah. And it doesn’t even have to be the responsibility of the architect. It is an architectural responsibility that a team or a department or a piece of an organization has to fulfill. These high impact technical decisions have to be made. Whether or not you have a role called architect, or a person called the architect, it’s not really that relevant anymore. These high-impact design decisions have to be made. You can have some made by the teams, by the agile teams. Sometimes, of course, the individual decisions actually have much more impact than the local team, and then you have to find some way to combine that, to scale the decision-making. It’s quite easy to avoid having architects if you don’t like that word. But you cannot avoid having to make these decisions. So every organization has to do architecture, even if they don’t have an architect.

And then the question becomes, what is the most important responsibility in the field of architecture? Is it making these architectural description documents or is it making decisions? And I think that in an agile organization, or let me say an organization that was dealing with change upfront, probably the decision-making is the more important deliverable. The decisions rather than the models. The models are still needed from time to time to support the decision making, and also to support the communication of the impact of the decision. Sometimes you have to create the big picture that sort of shows how all the decisions hang together, and what the collective effect is on the structure of your solution. So modeling is still needed. But it’s needed as a way to preserve knowledge, as a way to validate things, and as a way to communicate the architecture. But it’s no longer, in an agile world, your primary deliverable. The decisions are what it’s all about.

That also has a second reason, which is that we want to learn quickly. In the traditional architecture, a few architects or teams would create an architecture document, usually at the beginning of a project, or try to do it at the beginning of the project. That could grow quite big, right? I’ve seen two or even 500 page architecture documents. That takes a long time to create, and that means that your feedback loop on the content of the document is probably quite slow. You want the document, of course, to be almost perfect before you show it to stakeholders. And that also means that actually takes a long time before you ask the stakeholders to tell you what they think about it. Asking for feedback on an individual decision is much quicker and more low threshold activity than asking for feedback on a big document. So this is another reason why, if you want to move quickly, individual architectural decisions are a better entity to focus on.

[00:26:43] Architecture Documentation Goals

Henry Suryawirawan: So I think you brought up a very good point here because from my past experience as well, I dealt with some architecture team, they tend to produce a very thick documents, just like what you mentioned. I haven’t seen 200, 500 pages, but it’s thick enough for me to read in one go. But you mentioned about when dealing with a fast, rapid change of business context in these days, right? Especially like in agile world, you want to make shorter faster architectural decisions, right? You point out the good point where you can actually ask feedback for individual decisions rather than one giant doc. Tell us more how we can do it in practice? Because all I know is that yeah, you have a architecture template, probably. One template where we just fill in the blanks. But how can we translate that into more architectural decisions based documents or models?

Eltjo Poort: Yeah. That’s a very good question. If we don’t focus on the big architecture documents anymore, what should we do? And I think the answer to that question starts with an analysis of what we’re trying to achieve with architecture. And what we’re trying to achieve specifically with architecture documentation. The analysis that we did actually led to three main goals for architecture documentation.

The first goal was, of course, to collaborate on decision making, to be able to take along the stakeholders in the decision making process, to ask them to validate the trade-offs, etc, and to give you the criteria. So that’s collaboration on decision-making. That’s the first reason that we do architecture documentation. Because if we don’t document those decisions, it becomes harder to collaborate without them.

Second reason that we create architecture documents is to preserve knowledge for later. So an architecture document is often presented as guidance to the team that has to implement the solution. Everything that we sort of thought about and modeled as architects when we created that architecture has to be somehow preserved for the team. But not just for the team that is building the solution, but also later on for teams that have to troubleshoot things that goes wrong, or that have to modify the solution.

So that’s basically a knowledge repository. And if you compare these two goals for architecture documentation, the collaboration during the decision-making and the knowledge preservation for later, you’ll see that these two goals have a completely different timeline. You want a quick back and forth for the decision making, but you want something stable and something longer term to store that knowledge. Trying to put that in one architecture document doesn’t really make any sense because they not only have a different life cycle, they also have a different language required. The language that you use to preserve your models and your designs for the team is different than the language you use when you’re talking to business stakeholders.

And then there’s a third goal that we see for architecture documentation, which has to do with what we call architecture governance or project governance. This is actually something that is a remnant from the waterfall world, but many organizations still need it because they need to be compliant with auditors and stuff. So they need to show that they are in control of their IT delivery and their landscape. They do that by showing that the things that they do have come through a proper approval process. And that’s the third goal of architecture documents is to have something, an artifact that is approved before we actually commit to that architecture.

That third goal also has a completely different life cycle. It’s only needed at these approval moments, depending on your governance cycle. It also needs a completely different language. Actually, for the approval, we should create an architecture document that only contains the bare minimum that’s needed to convince these approving stakeholders that their concerns are being addressed, that we are in control of the risk and cost of the solution, for example. Nothing more than that. If you actually put all of your architecture, all the knowledge that’s needed for later, and also all the decisions in that same document, no wonder it becomes very big. And that actually doesn’t help you get the approval. It’s completely in the way of getting the approval, because you’re using that same big architecture document for the same thing. That doesn’t make any sense at all.

This is why we try to split this up, actually, in three different documentation types. First of all, we have a decision register which we put in a place that is accessible to anyone who needs to be involved in that decision-making. It’s going to be quite lightweight. We have found ways to actually make these very easily accessible, and to make it easy for people to find the decisions. And then there’s the repository of the design, which can be as big as you need it to be. You can use a model repository, a tool for that, or you can just use a Wiki depending on your style. But that should be kind of separate from the decision register. The two should, of course, point to each other. They should be linked to each other because every decision has impacts on the models and vice versa. But because they have such different life cycles, you can use different platforms for them. And then finally, there is this governance document. The baselines that are approved by management. And those should be as small as possible. They can be PowerPoint or Word documents or whatever. I think that’s sort of what we evolve into for doing architecture documentation in the agile context.

Henry Suryawirawan: So thanks for sharing the different types of doc that you can use decision register, or maybe some people also call it ADR (Architectural Decision Records), repository for design, maybe it’s your code, maybe it’s your models. And also like governance docs, right? The docs that actually get approved.

Eltjo Poort: I think they were invented by Michael Nygard. It’s a very nice way to put your architectural decisions in with the software, in with the code, in your code repository, in your version control system, etc, which is, of course, a platform that is very accessible to your developers. So if your developers are your main stakeholders for your decisions, that’s the best place to put it. However, you know, I often run into situations where actually the decisions have more impact on the business, and maybe a little bit more detached from the technical software content. And then maybe putting them in a version control system that no business stakeholder ever has access to and that they don’t know how to use might be not such a good idea. Maybe you want to move to something more like a content management system or a Wiki or whatever.

[00:32:30] Dealing with Technical Debt

Henry Suryawirawan: So speaking about the other perspective of architecture. So far, I think we have covered the initial phase where you make decisions, you analyze trade-offs, and all that. But there’s another part that we touched on a little bit about legacy, which is about technical debt. I think this is also a large topic for architects out there. I think you have one interesting quote that I also want to read here. You said that the world is drowning in a pool of technical debt. There’s so much technical debt. I, myself probably is a culprit for few of the code that I wrote. Tell us more about this situation. So what can we do about this insurmountable of technical debt out there?

Eltjo Poort: Yeah. Well, let’s first talk a little bit about the cause of the world that is drowning in a pool of technical debt. I think there has been a time in the past decade where the culture of the software development world was very much determined by a few big players. We had the Spotify model. We had the two pizza rule. We had all of these success stories of the big internet players, like Facebook, like Google, like Netflix. Of course, everybody wanted to be like them. And we based part of the culture on their way of working. Which of course, if you look at it from a distance, not everybody works for a company that is a big internet player, and maybe there are different business drivers for them. Then there are for your typical government or high-tech organization. But, let’s not discuss that too much.

One of the slogans that really caught on was “move fast and break things”, was one of Facebook’s slogans. That was actually an extreme version of the rule that it’s much more important to quickly create business value than to keep things whole. That attitude has led to a lot of shortcuts being made in software design. I think that is one of the underlying causes for technical debt. I wrote in the original blog post, I think that was titled “Move slow and fix things”, instead of “move fast and break things”, and maybe it’s now time to actually take a step back and see what we have broken and whether we want to fix some of those things.

By the way, there are other things like time pressure, KPIs in organizations. It’s not just the culture and the attitudes of the developers. There’s also a lot of business drivers that have led to all of that technical debts. Short-term focus, especially from publicly traded companies that have a three month cycle. And usually delivering something in that three-months is much more important than making sure that the platform is still healthy a year later. So that also leads to more technical debt come into play. But once you know where it came from, what do you do to get rid of it, to control it and to remediate it? And here, we are also hindered by the fact that technical debt is considered to be a technical problem. Of course, it’s in the name, right? Technical debt. However, to remediate technical debt requires a lot of resources and has a big impact on the business. Actually, not to remediate the technical debt also has a big impact on the business because it leads to risks. Technical debt can be, for example, something running on a really old platform that has vulnerabilities that are no longer being patched. Those vulnerabilities are a business risk. They’re not a technical risk. If they lead to ransomware being installed, that can be very expensive. So it’s actually a business risk.

So I think the name technical debt in this sense is quite misleading, and it leads to misunderstandings. It leads to business stakeholders. If you ask them, we need a month to remediate this technical debt, to clean up the mess, basically that we had to make last year because you want it to start so quickly. So, we are not going to be able to give you any more business features for about a month. Is that okay? The answer will always be no. Because they say, “Oh, what are you telling me? You didn’t do your job well. What is the problem? Technical debt? Why didn’t you manage your technical debt?” No, it’s not technical, it’s business debts. So, I think maybe we should call it that. We should call it business debt rather than technical debt to make sure that the business understands it’s actually their pain that we are trying to manage here. And that we didn’t fail. No, it’s the organization as a whole. We techies didn’t fail. It’s the organization as a whole that’s failed and didn’t apparently understand the tradeoffs that they were making when they were demanding for something to be made in a quick and dirty way. Or to delay the upgrading of some platform that is now suddenly very dangerous. So we should enroll the business in the discussion about getting rid of technical debt. That’s the only way to make it happen. The cost of not fixing it, but also the cost of fixing it.

[00:36:38] Enablers

Henry Suryawirawan: It’s like either you do, you don’t, you also get an impact out of this technical debt. And you mentioned another important point, not just in terms of risks or the business impact, but actually the sustainable pace of the maybe software development team itself, or maybe the business itself to keep on churning out features over features and improvements for the users. And you coined this term enablers. So tell us about the association between this technical debt and enablers and sustainable pace.

Eltjo Poort: Phillipe Kruchten has a nice model for the business value of the stuff that’s in your backlog, which on a just an audio podcast is very hard to explain. You need to visualize it. He uses colors for that. But in that model, he makes a distinction between the things that are in your backlog that lead to direct business value such as new business features, and things that are invisible to the end user that have only indirect business value. Basically, there are two types of this indirect business value. By the way, all the things that have indirect business value, some people call enablers because they have no business value from themselves, but they enable the real business value to be created on top of them.

There are things like platform improvements, like architectural components. They are, of course, visible to the architects and to the developers. They’re just not visible to the end users. For example, a caching mechanism. You’re using a cache in your software, and you temporarily store data from the database in that cache in order to make sure that you have quick access to them the second time that you need the same data. So that is actually good for your response time. But the cache is absolutely invisible. At least you hope it is to your end users. Usually if a cache becomes visible, it’s because it contains the wrong data and there are some bugs in it.

In some framework, we’re talking about the architectural runway. So that’s the platform. The architecture that you build your business features on. That is one type of enabler and technical debt is the other type of enabler. The main difference between the two is that architecture runaway is something that you extend with new stuff, new architectural components, and technical debt is something you need to remove. It is a negative value that you need to remove. As long as you haven’t removed it, you’re paying interest. That is the metaphor that’s in the work “debt”. As long as you are borrowing the money, pay an interest. And the interest can be in speed and velocity of your team. As long as the technical debt is there, the team is slower or it can be in risks that you run like vulnerabilities.

How does it relate to the sustainable pace? Well, if you realize that every sprint you make a choice. What type of stories you are implementing? Are we going for the direct business value stories, or are we going for the enablers? All the time you spend on enablers, you cannot spend on things with direct business value. So all the time you will spend on enablers lowers the speed of the creation of the business value. So you can actually increase your speed of delivering business value by not doing any enablers at all. And that creates a very steep curve. Business value curve going upwards very quickly. However, that is not sustainable, and that’s the relationship with sustainability.

At a certain point in time, you’ll have to pay attention or spend capacity on these enablers. You are bound to make that slope of the business value increase less steep. That is what I call a sustainable pace. Sustainable pace is where you spend a balanced amount of attention. The enablers compare to the capacity that you spent the business features. And if you do that, you can keep that up forever. Of course, there are framework like SAFe has a rule for that, it’s called capacity allocation, right? They say, you know you spend a certain percentage of your time every sprint on enablers, and that’s how you can create a sustainable pace. And of course, from time to time, you have a deadline and it suddenly becomes a very important to deliver your business features on time. And then it’s okay for one or two sprints to not do the enablers and build up a little bit of technical debt that can actually be a very good business decision. As long as you then later on manage that by sort of restoring the balance.

[00:40:26] Waterfall Wasteland and Agile Outback

Henry Suryawirawan: Speaking about all these dynamics, sustainable pace, maybe day-to-day development operations where architects could actually play a role. You wrote a very interesting article, which I read recently. It’s titled “Waterfall Wasteland and Agile Outback”. I mean, it ties back to the responsibilities of architect, and maybe in the day-to-day operations of software development life cycle as well. Can you tell us more what are these two extremes, waterfall wasteland and agile outback are?

Eltjo Poort: Yeah. So, as I told you all the way at the beginning of this podcast. One of the things I do is I help organizations improve and modernize their architecture way of working. The last few years we have done that based on a model of responsibilities. In that model of responsibilities, we also have a maturity model, which we used to measure the agile architecture maturity level of teams or departments or whole organizations. This model has five responsibilities. Understanding context is the first of them. We have already discussed that. The second is decision-making. The third is modeling. The fourth is validation, and the fifth is delivery support. So those are five responsibilities of an architecture function in an organization.

Organizations ask us to help them modernize, and what we do is we start by assessing how good are you currently at fulfilling these five responsibilities. And when we started doing that a few years back, quite quickly, we started to notice some patterns. There are some teams that were focusing very much on the modeling and the validation. These teams did not focus at all on decision-making and on delivery support. They considered that to be somebody else’s job. We called that pattern the waterfall wasteland, because these were usually architecture teams that were used to creating an upfront design and then handing that over to a team for realization. And while the team was doing that, they were already on another design. They were not that much in touch with the teams that were creating them. So we call that the waterfall wasteland.

And another pattern that we started to see was the opposite of this. These were teams that were focusing on the decision making. They were making quick technical decisions, and then immediately they would implement them. These teams would actually not do any modeling at all. They would also not validate. They considered modeling to be a suspect activity that was actually against agile working, which I don’t know where they got that idea. Maybe from the Agile Manifesto, where it says that the best architectures emerge from self-organizing teams. That doesn’t say that they shouldn’t model, they should organize it themselves, the modeling. But okay, some people would interpret that as saying, no, we don’t do modeling anymore. And they would also won’t do validation of the designs. Their reasoning for that was fail early and fail often. Because if you fail, you’ll learn quicker from making mistakes than from sitting behind the desk and just thinking about the design for weeks. Of course, there’s a truth in that. However, in some situations, a little bit of validation up front can save you a lot of pain later on. Specifically, in very business critical or even safety-critical applications, you can’t afford to make a lot of mistakes. You actually do need to make sure and validate that what you’re doing is going to result in something that works. So we call that second pattern where the team only focuses on decision-making and realization delivery the agile outback.

We use those as two extremes on a spectrum. They are more like caricatures than real. We have not seen any teams that were so extreme that they would only do one or the other. But what we’re looking for is actually the middle road between agile outback and waterfall wasteland. I say middle road, maybe it’s a better way to say best of both worlds. Of course, not every situation is the same. Architecture is context. So maybe in some teams, yes, you should focus a little bit more on delivery, and in other contexts, you should focus more on validation. Like I said, safety critical things, of course, you will focus more on validation there. But you should always look at that balance in the business context and not from a dogmatic point of view. Don’t say, “The Agile Manifesto says this, so we don’t model.” That is foolish.

Henry Suryawirawan: And I like when people say, yeah, we value working software more than documentation. I think that’s also what leads to all this confusion and misunderstandings about, yeah, we don’t need to model or think upfront and validate the design. And I think you brought up a good point about balance. I think, let me just repeat again the five responsibilities of an architect that you mentioned. The first is understanding context, making decisions, modeling, validations and, at the end, is the fulfillment or delivery of that architecture itself.

[00:44:46] 3 Tech Lead Wisdom

Henry Suryawirawan: So Eltjo, it’s been a really pleasant conversation. I learned a lot. Talking about architecture, we can spend hours just talking about different options. But unfortunately, due to time, I think we have to end this conversation. But before I let you go, normally I would ask this one last question to all my guests, which I call three tech lead wisdom. Would you be able to share some leadership wisdom that you want to advise all the listeners here?

Eltjo Poort: Sure, Henry. So I think the most important, call it wisdom, the most important thing to keep in mind as a Tech Lead or as an architect, is that you should be aware of silver bullets. The solution that solves all problems. I’ve been working in this industry for quite a while now, and I’ve seen them come and go. Object orientation was one of them, and we’ve seen quite a number of them. Agile working was one of them. I think the current generation, we see some architectural styles that are sort of worshipped beyond reason, like the microservices architecture. If you’re not doing microservices, you really have to explain why that wouldn’t be a good idea for you. You know, even though there’s a clear trade-off also in choosing a microservice architecture. Of course, having the responsibilities divided into business services and making these business services small and independent of each other, that is, in general, a good idea. However, this independence comes at a price, and this price, for example, is that they cannot access the same data because that would make them dependent on each other. That price can become very high very quickly because it can lead to quite a high level of complexity, and then suddenly the complexity instead of being in the individual components moves to the interaction between. So that’s an example of the silver bullet.

There’s a very nice article written by Fred Brooks which was added to his famous book, “The Mythical Man-Month” already 20 years back, I think. It’s called “No Silver Bullet”, and it explains why silver bullet in software development can never lead to more than, say, a 50% improvement in productivity or in other success factors. And I think that’s very true. As architects, we should always keep in mind that architecture is context. All the things that are presented as silver bullets, they always relate to quite a particular specific context, and we should always be aware of it. So if somebody comes to you and tells you, “Oh, I found this thing and it’s going to solve all our problems.” The first question you should ask them is, “Can you please explain to me when it does not work? When is this not a good solution?” And if they can explain it great, that means that they are aware of it, and they were aware of the trade-offs. If they cannot explain it, you can be sure that this is not a mature technology. Because they have not yet run into its limitations. So that would be my first wisdom.

Very similar, the second reason is beware of the best practice dogmas. It’s very similar to this “no silver bullet” thing, but we’re not talking about practices, about ways of working. In the agile community, for example, there are a number of dogmas. Let me just give you one example, it’s YAGNI, you ain’t gonna need it. So whenever you propose to build a piece of architecture runway, just in case it might be necessary for a particular event that might occur in the future, the standard reaction from the agile community will be, “Oh, you’re not sure that this is a good idea. Well, in that case, don’t build it.” And of course, it is wise to consider the trade-offs of a piece of architecture runway. You should always do that. But you should not just discard it just out of hand because of acronym that somebody in the agile community has made up. That should not be the reason to discard that plan.

Of course, dogma is a term that comes from religion. The church has dogmas. The definition of a dogma is something like, okay, it’s something that is considered to be true irrespective of whatever happens or whatever. There’s no justification for this to be true. It’s just believed to be true. Phillipe Kruchten, and I’ve already mentioned his name twice, I think now. He wrote a very amusing paper called “The Voyage Through the Agile Memeplex”, where he compares the agile movements to a religious sect. If you want to understand what I mean, beware of best practice dogmas, then read that paper. I also don’t like the word best practice. I always say best fit practice. Because architecture is context and it’s not always best. It’s whatever is best in fitting into the context that you’re talking about.

The third wisdom, because you asked for three, is let me try to formulate this way. Vulnerability is the road to understanding. That’s a deep one. What I mean is sometimes people ask, should I be an architect? And what should I do to become an architect? What are the skills required for an architect? Then people tell them, well, you need to be able to sell your design to the stakeholders. You need to be able to convince people of the design, that this is a good design. I think that is a little bit suspect. It depends, of course, on the situation that you’re in. But I think it’s much more important that you are able to be vulnerable towards your design, meaning that you are always open for the possibility that your design is wrong, and that you’re always looking for reasons why it may be wrong. And if people are attacking your design, your first reaction should not be, oh, I’m going to use my convincing people skill. No, your first reaction should be, oh, they may have a point. And I’m going to ask them why do you think this is wrong? That’s what I call vulnerability.

So have a vulnerable attitude when you’re presenting your design or also on the level of individual design decision, when you’re presenting that decision. You’re presenting this beautiful trade-off matrix that has all the criteria and all the options are scored against these criteria. And in the end, it’s very clear. This option is 10 times better than the other two. You present this to stakeholders and one of them says, I don’t think that can be the right option. This is the most interesting moment in that meeting. Because they may be wrong, but they may be right. And they may have a reason that this can never be the right option. If they tell you that reason, probably because you missed some criteria, people didn’t tell you that this was an important driver because they thought it was so obvious that they didn’t need to tell it, or they thought you already knew because everybody else is talking about it. So I think this is important. Vulnerability is the road to understanding.

Henry Suryawirawan: Wow. Yeah, that’s really deep, actually. But I can also see the interrelation with the first two. Because if you say your design is the best, you also like, build your dogma yourself, right? You want people to also know what context you make the decision based on, and maybe also hear from other people if they have good feedbacks and maybe change your decisions afterwards.

Thanks Eltjo for sharing those wisdoms. Really lovely. For people who want to know more about you or follow your work or read your articles, where can they find you online?

Eltjo Poort: Well, there’s only two people in the world that have my name. EltjoPoort.nl, the NL for the Netherlands. That’s my website, and it points also to other repositories. Just connect to me or follow me on LinkedIn or on Twitter. By the way, the other person that has the name Eltjo Poort is my uncle. Don’t send emails to him. It’s EltjoPoort at Gmail.com Those will end up with my uncle, and he has gotten tired of forwarding them to me. So don’t send him email. Use my website or my LinkedIn to connect.

Henry Suryawirawan: Wow. A little bit of fun fact there. So it’s really interesting to hear about that. So yeah, thanks so much for your time here. Really pleasant to hear all this architecture wisdom from you. Good luck with transforming all the traditional best practices into more modernised architecture decisions.

Eltjo Poort: Thank you.

– End –