This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
Welcome to this Agile Meets Architecture pre-event.
We’re really glad you’re here.
If you haven’t heard of Agile Meets Architecture yet, it’s the conference that brings together agile software development and software architecture with thought leaders from both worlds.
We hope today gives you a taste of the talks, speakers, and vibes.
The full schedule is out for a while and early bird tickets end tomorrow.
Welcome to this event with Eberhard.
Eberhard, over to you.
Yeah, thanks a lot.
And thanks a lot for having me.
So, my name is Eberhard.
I’m with SWAGLab.
We are a consultancy and we have people who actually make the impact in projects.
And I’m concerned with software architecture primarily, and I will talk about architecture and organization.
So, to start off, like a fundamental problem of architecture, my opinion is to come up with modules.
And if you think about that, modules is actually a term and a concept that is slightly older than I am.
So, it’s from the beginning of the 70s.
And there is the famous paper by Parnas that talks about information distribution aspect of design mythologies.
And the point here is that already that paper, which is like 50 years ago, says that software architecture is about controlling the flow of information, which is a social problem, right?
The flow of information is a social problem.
There’s a strong relation between those two.
And the information distribution aspects basically say modules can be changed freely if they still meet the expectations from other modules, or I should probably rather say from other developers.
And also other modules will use all the information about a module.
And therefore, the concept of information hiding is invented in that paper, which says, well, you will hide as much information as possible because if less information leaks to other modules, then the result is that modules are easier to change because there is less information that other modules rely on.
And there is more stuff that you can change because there is just less that leaks out.
This is a fundamental concept, and it’s applicable on different levels in software architecture.
So if you look at a class, it has instance variables on the inside that’s hidden information, like the balance of an account.
And then there is the public methods, like tell me the amount that is on that bank account.
And if you apply this principle of information hiding, then the data can be changed.
So the bank account can either store the balance as a money amount, or it can calculate the balance from all the transfers on the fly.
So it means that you can actually change the implementation quite freely because it is hidden from the outside world and access is only allowed by public methods.
This also applies to cost stream modules or microservices.
Then the data would be in the database.
There would be an interface, and you can actually use the same example.
So if there is a microservice that deals with bank accounts, you can have an interface that allows you to tell the balance of an account.
And you can either calculate that on the fly with all the transfers stored in the database, or the alternative would be that you just store the balance in the database, so either the transfers or the balance.
And others won’t notice if you change that.
So modules have a data model inside and an interface.
And I did an episode about that in software architecture in stream.
I’m afraid it’s a German one.
You can look it up and take a look at it.
It’s actually an old episode because it’s a very fundamental concept, and I explained it in more detail there.
Which leads to the question, so what is software development all about?
Well, software development is about developing software in iterations, and that’s sort of obviously true.
But there are other things that are also concerned with software development.
So there is the development organization.
There are the teams, the people who actually develop the software, and there is the domain and the user, and all of them change.
So the development organization changes, people join the projects, people leave the projects.
The same is true for the users and the domain.
They have new different ideas what should be implemented, and of course the software also changes in iterations.
So it means there is an influence between the development organization, the domain, the software, and also the software and the development organization.
And there is one thing, one let’s say case study that I would like to join, to share with you.
It’s something that occurred in a consulting project, and in that consulting project we were asked to do a review.
And one of the questions that we were supposed to answer was the question, is it a good idea if a project manager decides that three teams should work on one module?
And I would think if you look at it, it seems like a bad idea.
As I mentioned, modules are meant to limit knowledge.
So if multiple teams work on one module, they all need to understand that module.
Changes will influence the other teams, and it’s sort of not what information hiding is about, right?
We are in a way violating what this is about.
We should have one module for each team, because then those teams are largely independent, because they don’t need to understand the implementation, they just need to understand the interface of whatever the other teams do.
But if we share one module, we actually share a lot of information.
Information hiding doesn’t really apply, and we have a problem.
Now it turns out that there is Conway’s law, and Conway’s law says that the architecture copies the communication structures of the organization.
And the idea is basically if you have some people in an organization, then those people will probably, well, stick together, talk to one another.
And if I have something to do, if I have a task that is assigned to me, I will probably write some code, and I will probably talk to other people that have tasks that are somehow related to my task.
And then we will probably build one piece, I will build one piece of the software, one module, the other person that I talk to will also build one module of the system, and therefore we will have interface negotiations, and we will have an interface.
So if I talk to another person, this will be reflected in the code.
Now, if we apply that rule to the example that I just gave, then we have a problem, because the problem, what this actually means is that we have three different teams.
So here’s one, here’s one, and here’s one, and we have one module.
And that is something that Conway’s law says is not really possible.
So what comes out of this naturally is either that we have three teams and they each work on one module.
So we tell them, well, you know, build that system that deals with bank accounts and tells us something about the amount that is on the bank account.
We have a large complex system that does all the transactions and so on.
And maybe we figure out a way to split that.
Maybe we have one team that deals with the UI, we have another team that deals with logic, then we have two modules here.
We have one for the UI and we have one for the logic.
Maybe we have a split where we say, well, these work on the transactions and these here work on the balance, whatever.
We might be able to come up with something to split it apart.
Or the other solution is that we are unable, or what happens is that we are unable to split that module.
And it’s just one module, one large thing, but then all of the teams work on it together.
And this is probably what we are afraid of, because then we will have a lot of communication overhead and we will therefore have some problems.
What I’m basically saying here is Conway’s law is like gravity.
It’s not, if you don’t believe in Conway’s law, it doesn’t happen.
It is a natural process.
And if you have three teams that are supposed to work on one module, that’s not going to happen.
Either they become one team and you will have a lot of communication between them, or somehow they figure out a way to split that module apart into three different modules.
So is it really a bad idea to have three teams working on one module?
I would argue that project managers should probably have a say in who does what.
So there is a good explanation why some project manager might come up with that idea.
Maybe there is a deadline.
Maybe it helps to have more people working on that.
And now to come up as an architect and say, well, we are not going to do this because that’s a bad idea from an architectural vision.
I don’t see how that’s a good thing, because at the end of the day, it means that the project won’t be successful and we have a problem.
So maybe adding people to the system and have more people work on the system is a good idea.
And I use this as an exercise, and usually people can easily think about reasons why we would like to have more people working on a specific thing.
And if we don’t allow the project manager to set a priority on one thing and to have more people work on one thing, what are they even good for?
Because setting a priority, putting a priority on something, that is something that I think project managers should be allowed to do.
And it’s even their, I think, core domain.
It’s what they really care about.
So Conway’s law, as I said, says that the architecture copies the communication structures of the organization.
Now there is the idea of the inverse Conway law, where we basically say, okay, we set up some team, we assign them some task like order processing, and then automatically we will get a part of the code that implements that part of the domain.
So we have a decision about modules in a way.
So what this basically means is, instead of doing traditional architecture and saying, okay, we will have one part of the code that does the order processing, instead we say we have a team that is assigned order processing, and then natural, because of the Conway’s law, this will also result in a module.
This is something that is related to microservices and modern architecture approaches.
I would argue that architects shouldn’t decide that by themselves, because this is about which team does what.
And as I mentioned before, this is something where we have other things that we should take into consideration, like priorities, where the focus should be, maybe things that require more people to work on, and so on, and so on.
And we don’t have the full control over the organization.
So therefore, we as architects cannot really apply this inverse Conway maneuver.
The other thing that I wanted to talk about and that also spreads a different light on the Inverse Combat Maneuver is team topologies.
So team topologies is an approach where we define how teams should collaborate.
It’s not really that complex, there are just a few patterns that you need to understand.
And it’s sort of intuitive, I would argue, at least to me, but you might be different.
And it also gives more fracture planes than just domains.
So what the Inverse Combat Maneuver in a way says is that we assign a domain to some team.
In real life, we do have teams that are responsible for some technical stuff, not for some business domain.
For example, building an iOS application that uses all the APIs that other teams provide.
And team topologies also covers more than just development teams, which is also a difference to the Inverse Combat Maneuver and a lot of traditional thinking, because obviously there are teams that do architecture or some kind of infrastructure.
So in team topologies, there are streamlined teams that are aligned to a stream of changes where we have some ideas, some business requirement, and we implement that business requirement and put it in production.
And that stream of change, that’s something that one team is responsible for.
Now if we do that, that’s actually a very complex task, and therefore we need to support those teams, and therefore we have enabling teams.
So enabling teams are specialized in some technical stuff, like technical consultants.
So maybe an architecture team would be an enabling team that provides some guidance on architectural problems and how to implement them.
Then there are platform teams that might provide something like Kubernetes or CI server, CICD server.
And finally, there are complicated subsystem teams which are responsible for complex algorithms like, I don’t know, customer scoring or whatever you have.
The interactions between those teams come in different forms.
So there is access to service.
From the cloud’s perspective, there are different cloud services, and they all are provided as a service, which means they are either provided through a web interface where you can just click and get a Kubernetes cluster, or they might also be provided with an interface.
And for the complicated subsystem team, we will probably provide some kind of programming interface where we provide some methods that could be called that provide some results.
And this is access service.
There’s probably not a lot of communication.
This might also be what the platform team provides.
Maybe then it’s a website where we say, okay, we want to have a Kubernetes cluster that we can then use.
Enabling teams, well, they do facilitation.
So they provide some knowledge support with, I don’t know, domain-driven design if they are an architect team with specific architectural problems.
And if that takes more time and is more complex, then they might even join one of the StreamAlign teams for some time to work with them on the problem.
So we could have a setting where we have some business domains like invoicing, order processing, or delivery.
And then we have, and those are StreamAlign teams which are responsible for providing that stuff in production.
Then we have delivery optimization, an algorithm where we put in all the orders and it spits out some optimized itinerary to deliver all those deliveries with an interface.
Then we have a Kubernetes or CI team that provides some kind of website or a different interface for all the StreamAlign teams.
We have the architecture team which supports the teams or maybe even provides some further support.
Again, I did an episode about this.
There’s also a lot of material at teamtopologies.com.
And I think the interesting or an important part here is that team topologies define magnets.
So it’s the goal that teams should work towards and which sort of raises the questions how many organizations actually implement team topologies fully and by the book.
And I’m not sure because it’s a magnet.
So quite a few teams are probably on the travel towards this goal.
But whether they make it or whether they have already made it, that’s a different question.
And I’m not sure whether that matters because at the end of the day, we have some state that our development organizations are in.
We are just looking for improvement.
So it’s not being perfect and implementing everything.
It’s just some like we are traveling towards that goal and we are trying to become better.
It’s not that we just say, okay, we are going to do this and then we are done.
Team topologies acknowledges that informal communications exist besides organograms.
And I think this is important because this is usually where most of the problems actually occur.
I did talk about these more soft aspects of software development in this episode.
And the problem or one of the things why I think team topologies is actually a good idea is because it talks about different fracture planes.
So what we could come up with is a UI team in India and we have two streamlined teams for auto processing and delivery, one in Kaiserslautern and the other one in Hamburg here in Germany.
And the reason why we split it this way is probably because if we have people from India joining the teams from Germany, it’s hard to do the stand up because there are different time zones.
You will force the Germans to speak English, which might be a problem and so on and so on.
So compared to the inverse convey maneuver, which basically says, okay, we are going to assign some domain, part of the domain to some team, I think that’s pretty unrealistic because in real life, I do see other factors taken into account, like the location of people or even their technical skills.
Another reason why I would probably have a UI team or might have a UI team is because there is an iOS UI and that team would then have all the technical means to build that system.
They are still streamlined.
So this team would be able to, well, implement something in the UI and put it into production.
This team would be able to do something in auto processing and put it into production.
So there is one part of the system that each of these teams are responsible for.
So these fracture plans are interesting because always splitting teams by domain is impossible.
So it is always, and that means that also splitting modules by domain always is impossible.
You will have some technical modules and therefore the inverse convey maneuver, in my opinion, is something that sometimes just doesn’t work.
And therefore some team that works on a UI module might make a lot of sense.
Architecture also splits into layers and there is hexagonal architecture, which is a means how you can separate your systems from a technical perspective, which is something that you usually don’t do on the team level, but still it means that there is more than just domains that influence what an architecture should look like.
So what shall we do differently?
In my opinion, the main point is that software development is a social technical activity.
The teams are the social side.
The modules are the technical side.
And you must consider both.
And one of the things that I notice where I seem to think different about things is interfaces.
An interface to me is not just something that we have in the code, but it’s also about communication.
It means that people actually talk to one another.
And if we look at information hiding, this is about one way to reduce cognitive load.
It’s about trying to hide the implementation details and therefore to make it possible to build systems that are too large for one person to understand.
So if you look at the fundamental parts of architecture like interfaces and information hiding, those are things that are motivated because of social problems.
This is why we organize our system in a specific way.
That’s pretty much what I wanted to say.
There are a few things that I still want to add.
So one thing is if you thought this was interesting, feel free to drink a cup of coffee with me so you can set up a meeting.
And in the meeting, I’m happy to discuss whatever problems you might have in your project or otherwise.
And you can just book an appointment here.
And the other thing, if you like the presentation, feel free to download the slides.
So one way of doing that is to send an email to armadingd in 2026 at evolve.com and you get a link to the OneDrive.
The other possibility would be to scan the QR code, which takes you directly to the OneDrive where you can download the slides.
The email is just used for sending out the download link and I will lock it for 14 days.
If you mistyped something in the address, then I would handle that manually.
And therefore, we can take the questions, right?
You’re muted or at least I don’t hear you.
Yes, I was saying thank you so much, Eberhard, for the presentation.
We already have one question from Lucian.
Do you see it or should I read it out loud?
Let me see.
I think we can get rid of the slides for now, right?
Yeah.
Oops.
Like this.
And expand.
And nope.
So Lucian is saying that you wrote about the hidden influence of developers and architects and the fact that managers usually decide team composition.
What concrete tactics can architects use to shape team structures without formal authority?
Yeah, I think that’s a great question.
And first of all, let me say that architects can probably not even decide by themselves what the code should look like.
I mean, if you think about it, I can come up with some diagram and some idea what the code looks like or should look like.
But really, I need to talk to the developers, I need to get some feedback from them, I need to incorporate that feedback, I need to convince them and so on and so on.
So what I’m trying to say is, even if I have formal authority as an architect over something like the code and what it looks like, and maybe even if I’m officially responsible for the project from that side, it’s still that things are not happening until I actually convince people.
And I think this also applies to managers, which basically means if I have a good reason why the teams should be set up in a specific way, like it obviously makes sense to have one team deal with one module.
I’m not arguing that, I’m just saying that there are other things that you also need to take into account.
And the way to do this is to talk to managers and tell them, well, you know what?
If you do this, if you have three teams working on one module, I expect a lot of communication over it, and I’m not sure whether it’s worth it.
And then we have some discussion, and then we have to figure out what the right path is.
And as I mentioned, there might be reasons that why the manager would convince me to actually have those three teams working on one module, like a deadline, for example, and maybe there is not too much communication over it at all.
But this also works the other way, so maybe I’m able to convince that person.
And quite frankly, so I use this as an exercise, as I said, and usually I ask people whether they want to have the formal authority over the teams, what the teams should look like.
And usually the answer from the architects is, yeah, I want to have that formal authority.
And like by a large margin, it’s usually the majority.
And the reason why I find this interesting is because that means that you’re basically the only person that is responsible for the project, not just the architecture, but also like all the other stuff, like setting up the teams and so on.
And that’s something that I don’t want to do because it’s too much responsibility.
And this is something that I sort of don’t really understand.
What I want to do is I want to talk to project managers and tell them or managers and tell them this is what I think should be done.
And then I want to have a conversation and I want to come to some conclusion.
And I feel quite comfortable if what I advise is not implemented because otherwise I would have total authority over the project and total responsibility.
And that’s a role that I don’t want to play.
And I might add that I do own a share in Swag Lab, but I’m not one of the CEOs, so we actually have three CEOs.
And I think it’s a quite comfortable situation to be in because the other ones are the ones who are officially responsible, the other shareholders, and I’m just a shareholder.
And that’s sort of by intention.
And obviously, we have open discussions where we convince one another and have a common plan, but I don’t see what would be different if I would also become one of the official CEOs of the company.
And that’s, I think, the same thing.
I hope that helped.
Thank you.
I hope that answered your question, Lucien.
And if you have follow-up questions or if we have any other questions, let us know.
Oh.
I might add, because that’s also something that is somewhat dear to me, so if you download the slides, you will find a link to an episode that I did for Software-Architektur im Stream, where we discussed fearless change.
And fearless change and fearless journey are, fearless change is actually a game.
And fearless journey is a set of patterns to influence an organization, even if you don’t have the formal authority.
And that is another answer to the question that you just raised.
So how shall I put it?
If you look at it, that’s also what the team technologies book says, there is so much informal stuff going on in an organization, probably that even dominates the formal stuff.
So the question, which tactics you can implement, I think fearless change and fearless journey are some of those.
The main point that I’m trying to make is, I’m not sure if you have the formal authority, how powerful that actually is, because you can just be ignored and people might just do whatever they like, even though you are the one who is officially in charge.
And I think we all know how we can avoid doing something that we don’t want to do, even though some managers said we are supposed to do it.
And that’s sort of natural.
So in my opinion, I would argue the only way to get something done is to convince people or to do these informal things and convince them.
And I don’t think that convincing just includes rational things, it’s also clearly an emotional thing and how people interact with one another.
Thank you.
We actually got a message on DM on LinkedIn, and this is the question.
One second.
Let me show it on the screen.
What are some steps to actually improve architecture projects using what you have described in the heart?
So to me, it’s about some techniques that you can follow, and some of the things are maybe even trivial.
I mean, if you have some meeting, naturally what happens is that someone is, I mean, if it’s a meeting in real life, some person will stand at the whiteboard and will take the pen and draw stuff.
So sort of by definition, you have one person that sort of drives the meeting, and that person is very likely to sort of dominate that meeting.
And obviously, there are introverts and other people, and that leads to some challenges because obviously those introverts won’t stand up and say, OK, I have a question, by the way, and this is something that we should do different.
So in my opinion, one thing that you should do as an architect is to be aware of these facts and to use, and there are simple solutions to that.
So one of the simple solutions is to use Post-it and say, OK, write down on a Post-it the answer to, I don’t know, how we are going to solve that architecture problem.
So there is some architecture problem, and you want to have a discussion about that, so have the people write Post-its.
Why?
Because that’s in parallel, and it also means that you get the information from the introverts.
And this is about the informal things that I mentioned, and it’s not a tactic, so it’s not on the level of fearless change or fearless journey.
It’s just some technique that you can use.
And I think that’s one of the ways to have better results, to have a better conversation and to improve the situation there.
And that is something that I would encourage people to do and to be aware of these facts that are so very important.
And there is also all the stuff around collaborative modeling, like event-storming or domain storytelling, which also by definition are things where you, well, collaborate, which means that you, well, collaborate, which means that other people are involved and they use these techniques, right?
I mean, event-storming basically means that there are people who have these, everyone has some Post-its, and you write down the business events on a Post-it and stick it to a wall, which by definition means it’s parallel and introverts get a way to express their knowledge.
And it involves everyone, and it also involves people or can involve people who are not technical, so domain experts.
So again, it’s about a technique that is inclusive and leads to a better shared model.
And I think that’s one of the things that you can do in that regard.
Because at the end of the day, and that’s what I tried to say in this talk, it’s a social activity.
The main problem that we have is that we have a team and the team wants to collaborate and wants to build some piece of software.
That’s the main problem.
And this means it’s all about communication and working together.
And I think that’s also why this idea to have agile and architecture as a common theme in a conference makes sense, because it’s both about, I would say, people.
It’s just that that’s not so obvious to everyone.
It’s rarely a software problem, right?
It’s always a people problem.
Exactly.
And that is why it just seems like a technical thing, but really it’s about people and how they collaborate.
What would be some stats, if you can share that from your experience, how often was it a people problem and how often was it a software problem?
There is one thing that I still want to do an episode about, that’s the laws of consulting by, I can’t remember the name from the top of my head, so that’s a very old book, Weinberg from 1985 or something.
And he says, so the first law that he introduces is there is always a problem.
And I can relate to that because I have been to kickoffs for reviews where I was like, well, you know, is it fine if we just write down that you don’t have any problems at all and it all works out?
And, you know, after we did the review, it turned out that they really had severe problems.
And the second point is, no matter what it looks like at first sight, it’s always a people problem.
And I would totally agree and I would encourage you to look up the third rule.
And that’s from, as I said, it’s from 1985 and that’s from, I mean, I have to say that I wasn’t around in the consulting business at that time, obviously, but I believe that this was probably the start of what we are doing nowadays with consulting, because I believe that beforehand developers and development organizations were basically pretty much in-house and there wasn’t probably too many people that would run around and do consulting.
So in a way, from the very start, since we have that as a profession, it was clear that it’s about people and that’s still what it is.
And that’s also why we at Swag Lab believe that the people are the main thing that we need to care about.
And that’s also why we have this different role, because if you just take the problem from a technical perspective, which I can do with my software architecture background, it’s quite likely that you do have some influence, but you’re much better off if you have some other people that can deal with problems from other perspectives, because usually it’s not like one thing that doesn’t really work.
And in particular, it’s most of the time people.
I think that would be actually a great way to wrap this up if we don’t have any other questions, because that’s the essence of agile means architecture, right?
Look at the people and the software in the same time and see how the two can work together.
Yeah, and I think, as usual, you have a great lineup of speakers, so I’m really looking forward to the conference and I’m really happy and honored to be part of the lineup.
Happy to hear that.
If you do have other questions that we haven’t addressed during this event, please let them in the comments on LinkedIn and we will pass them over to Eberhard.
Thank you all for attending.
Don’t forget that the schedule is out at the birth and tomorrow and have a great rest of the day.
Thank you, Eberhard.
Oh, wait, we have one final question.
Yeah, let me see.
How would you run a six to 12 month experiment with inverse Conway in a big political enterprise?
What would you measure and what are the warning signals would tell you to stop or pivot?
So, I mean, I mentioned that I do have these virtual coffee, so maybe that’s a good point to discuss in one of those one hour calls, because, I mean, obviously it’s a complex thing.
I have to admit that if someone says, I want to do this and that in a project, the first question that I tend to ask is, what is the problem that you’re trying to solve?
So with inverse Conway, I would argue, and that’s actually already why the question is great, because I didn’t really mention that.
I think the idea concerning inverse Conway is that it improves productivity and that it allows us to have, well, more outcome with less communication.
However, that’s sort of from an abstract point of view what this should be about, right?
I mean, basically the idea is you have one team and that one team deals with one part of the software and is able to implement something that makes business sense without talking to other teams.
That’s sort of the idea.
And also the idea is to not steer or not define the architecture, but rather take it from an organizational standpoint, because that might be more effective and leads to more self-organization, which again leads to more productivity.
So I would try to understand what the goal is.
Maybe that’s the goal.
But then the problem is that the architecture might not allow you to do that.
If you have a large, well, badly structured legacy system and you assign some domain to some team, they are probably not going to be able to work independently because the software is just so badly structured.
And then the experiment doesn’t really make a lot of sense because the goal that you want to achieve, more independence, more productivity, it’s quite likely that you won’t achieve that.
So that is why I think it’s important to figure out the reason, the goal, to figure out whether this is an approach that allows you to reach the goal, whether there are any problems on the way, and to take care of those problems.
So maybe one of the alternatives would be to, well, take the legacy system, maybe to have just one team that deals with some domain that you can split apart from the other teams and that can actually work independently and so on and so on.
And political enterprise means that you have to deal with, well, people.
As I mentioned, I would try to convince them.
And this is actually helpful because if you can spell out why you want to do that, that helps you to, well, think for yourself why you want to do that.
So I think convincing other people is a helpful filter to separate ideas that really don’t really make a lot of sense from ideas that actually do make sense.
So therefore, talking to those people and trying to convince them is something that I think is actually helpful.
And I would therefore try to figure that out.
What I would measure, well, depends on your goals.
So I would try, if you want to improve productivity, you have to have some means to measure productivity.
I did actually an episode about that.
And that’s also a talk that you can find on my YouTube channel somewhere.
So in English, there’s an English recording there.
So maybe that is something that you would work with.
Warning signals.
I have to admit that when I’m deeply involved in a project, I run around and talk to people.
So the early warning signs that I would see is people who actually say, well, that wasn’t a good idea after all.
And then I would try to talk to them and try to understand where they see the problems and try to figure that out.
I hope that that helps.
Thank you.
Thank you.
As I said, have a great rest of the day.
Thank you, Eberhard, once again.
See you all at the Chalmers Architecture.
And thanks for the questions and I hope to see you at the conference.