The secret to a good software architecture

Transcription. 

Björn Schmitz: Hello Michael, Happy New Year!

Michael Kabdebo: Happy New Year, Björn! Hello!

Björn Schmitz: You might remember the interesting podcast about Domain-Driven Design by our colleagues at consistec. It was also software architecture as well and we thought that it would be an interesting topic to explore further.

Michael Kabdebo: Exactly, right! Domain-Driven Design was already quite specific and we then thought that we would have to add the topic of software architecture in general and shed a little more light on what it actually is. I would say, let's introduce ourselves first, maybe you want to start, Björn?

Björn Schmitz: My name is Björn Schmitz, I'm a software developer and sub-project manager at consistec. I've been working in the field of software development for about 15 years now, and have also been involved with software architecture from time to time in the past. And that is actually quite an interesting topic. What about you Michael?

Michael Kabdebo: My name is Michael Kabdebo, I've been at consistec for about seven years, I've been a software developer for 13 years, mainly in the Java environment. And as a software developer you're always affected by software architectures and that's what we're talking about today.

Björn Schmitz: I've been told in the past that software architecture is a bit unnecessary and that the whole field is too expensive and that you don't really need it or that it's just not clear why you need it. What is software architecture in your eyes, Michael?

Michael Kabdebo: There can't be software without software architecture. Everything has an architecture somehow, take a building for example. Of course I can build a building without an architect, that's possible, a certain kind of architecture results from that. But whether this architecture is good and whether it fulfils the original purpose of the building is very questionable.

Björn Schmitz: Or perhaps, to put it in a nutshell, if you don't look at any software architecture at all, the project is actually already doomed.

Michael Kabdebo: Yes, it could be that I'd be missing the mark pretty blatantly.

Björn Schmitz: Because you have to consider that software architecture is the basis of a new software solution. And if this is not done, the end result is a very strange solution that is perhaps not in line with the market.

Michael Kabdebo: The software architecture is practically the foundation of the software. And if the foundation is not in order, as we know from building, then maybe the whole building will collapse or only half of it will be supported. So it doesn't work the way I needs to. It works somehow, but either not efficiently or - I'll repeat myself again - it misses the target.

Björn Schmitz: Or the building simply collapses in the end.

Michael Kabdebo: Exactly, right! Because it doesn't carry what it should have carried. Because I didn't think about it beforehand.

Björn Schmitz: Maybe first of all for the listeners: Let's just find a vivid example. How about an internet webshop for New Year's Eve supplies?

Michael Kabdebo: Yes, it's a good current example, we just had New Year's Eve. A web shop that sells fireworks and firecrackers.

Björn Schmitz: Maybe also streamers.

Michael Kabdebo: Streamers, champagne, everything you need for the New Year.

Björn Schmitz: If we look at the example of the shop, of course it has various professional requirements, but also perhaps non-professional requirements as to how the shop has to function in the end. And from this, quality characteristics can be derived as to what this shop must have in the end in order to function properly.

Michael Kabdebo: You can also differentiate between the functional requirements, which ultimately mean that I am able to buy fireworks, pay for them and have them sent to me. And then the non-functional requirements would be that the shop runs relatively efficiently, that I don't have to wait ten seconds for every click, but that I keep to certain response times and perhaps take into account certain ergonomics. Now without anticipating much, the quality features, Björn, you just started with that.

Björn Schmitz: First of all, maybe the availability, so how available is the shop at all times? Or also the security of the shop? That is, how protected is it against hacker attacks, for example? With the web shop, of course, how easy is it to use, but also how ergonomic is the whole thing? So ...

Michael Kabdebo: ... that the customer has a good experience.

Björn Schmitz: Exactly!

Michael Kabdebo: Another thing that comes to mind is performance and scalability. It's no use if the shop needs 20 seconds after every click to react in some way. I can also imagine scalability for the webshop. We only have a certain time window where we sell things, so we have a lot of access, so I can just add a few more servers who process the order, process high order volumes.

Björn Schmitz: What might be an issue as well is testability, i.e. how well is the software testable? Or perhaps also the integrability, i.e. how well can the software be integrated into existing system landscapes? Or even if I look at it, when the software is already finished, how good is the expandability of the software, i.e. how well can it be changed at the end?

Michael Kabdebo: So in the end, maintenance.

Björn Schmitz: Exactly! We have now gone through various quality attributes. Now the question arises: If I want to fulfil all quality attributes, it will be really expensive in the end. Is it even possible to fulfil all these quality attributes ?

Michael Kabdebo: It is definitely possible, but as you say, it can be very costly. Software architecture is not a means to an end, it is actually meant to serve. That I write good, efficient, high quality software. So as with everything in life, I can overdo it here too. I have to set my priorities as a software architect or perhaps as a customer as well. So what of it is really important to me now? I don't have to consider all of it now necessarily. You don't have to drive it to absolute perfectiont. But I should keep an eye on it. Because even then I have a certain control over my software as a whole. I then know about my weaknesses. Which is okay, software can have its weaknesses. It's good to know where. The best way to find that out is to keep an eye on my software architecture. In other words, these individual points that we have just discussed.

Björn Schmitz: Interesting point, Michael. I disagree a little bit. I think you simply can't fulfil all the quality attributes. There are too many of them and some of them are mutually exclusive. For example, if I look at maintainability and performance, it could be that if I have a webshop that has to run particularly well, it could mean that the software is no longer that easily maintainable. Simply because I have geared the shop so strongly towards performance. That's why I think you always have to weigh up which goals are particularly important to you and then always align yourself according to these points. The best thing is to have a top 3 or maybe even a top 5 of quality attributes and to base all decisions you make on these quality attributes. Perhaps you have to consider a little bit that software architecture always means that you have a compromise between quality attributes, costs and functionality. It's a bit like project management in general, where you have this magic triangle of cost, time and scope or quality, and you always have to decide a bit what is really important to you in the end.

Michael Kabdebo: That is definitely true. You have various limits within which you operate. Money is one. Of course, I can't make a software project infinitely expensive. So software has to be automated at some point; it's no use building a web shop that eats away at your turnover for the next ten years. No one really benefits from that. That's the balancing act of defining these characteristics, what is important. We can use our case study again. With a web shop, for example, availability would be very, very important. It's no use if my webshop is unavailable half the time. Or, to a certain extent, the usability of the software. It's also no use if I make a webshop available that no one can use. Nobody wold order from me, they go to the competition, I'm not the only webshop. Those are two points that come to my mind. Also that I comply with the legal regulations. Of course, I can now start selling firecrackers earlier because I don't have a date check in them, or I can also sell sparkling wine to minors, i.e. to under-16s, because I haven't built in a check, because the check was simply too expensive for me.

Björn Schmitz: Mhm (affirmative). Just one of those safety tests. After that I get God knows how many charges, indictments, which then swallow up God knows how much money for fines and lawyers' fees etc.

Michael Kabdebo: Good! We have already found a lot of characteristics, quality characteristics. I would say that some of them can be discussed now, how important they are or how unimportant they are. What would you say, Björn, are the most important quality features of a software architecture from your point of view?

Björn Schmitz: It always depends. So every solution is always a bit different or it also depends on how the market is. So you can't generalise about which quality features are the most important. But if we look at the example of our web shop, perhaps usability and ergonomics would be at the forefront. So it's important that the customer finds his way around the webshop and gets to his result quickly. Because if he doesn't manage that, he's more likely to jump off and maybe look at the competition. And of course we don't want that. Maybe availability would also be important, because the shop should of course always be available before New Year's Eve, because that's when most sales are generated. What do you think Michael, what would be your top three?

Michael Kabdebo: I definitely see the topic of security at the top. In the past, we've seen data leaks or people taking personal data, whether it's payment data or master data, in order to do some kind of mischief with it. So a lot of bad things have happened there, so for me that would be at the top of the list. Availability  of course. It doesn't make sense to run a webshop that is offline most of the time. Performance always plays a very important role for me. As users, we all expect software to react quickly and orders to be processed quickly.

For example, when I order from a webshop, I don't always want to wait 20 seconds for a click. When that happens, I tend to look around at the competition. But I also don't want to wait three days for my order confirmation to arrive by e-mail. All that should be taken into account.

Björn Schmitz: Of course, it always depends on what you want to value in the end. That can vary from solution to solution.

Michael Kabdebo: Absolutely, exactly!

Björn Schmitz: Now we have used the example of the shop to name various features and we agree that it is very important to define these at the beginning and that they can differ from software to software. I think we agree that you always have to name them before you even start with a solution.

Michael Kabdebo: Absolutely! Because otherwise you have no chance of achieving a good software architecture.

Björn Schmitz: Or even generally getting a solution up and running in the end.

Michael Kabdebo: It's important to think about it before you start implementing it.

Björn Schmitz: Michael, you were talking about the software architect, the person who takes care of the whole thing, the software architecture. What do you think a software architect has to be able to do, or what are his tasks?

Michael Kabdebo: He must have a certain foresight with regard to technologies, both old and above all new ones, in order to be able to use them appropriately, to be able to discuss what makes sense and what doesn't. Are we doing this with some hyped technology or does it simply not make sense for us? Or which pattern do I use, which pattern do I perhaps even have to develop as a software architect? These are just a few keywords that I can give you on the subject of what a software architect has to be able to do. But I assume you have a few more additions, Björn.

Björn Schmitz: No, these are the main points. But I have a slightly different opinion. I think that if there is a software architect as such a role, then perhaps he should also support the team more, i.e. also develop the solution. So that the software architect doesn't model something on his own and the developers only have to program it at the end. It should be a joint task, where the architect can simply add his knowledge.

Michael Kabdebo: I definitely agree with you. Above all, the software architect must know what his team can do. As you already mentioned, there is no point in setting up a software model, that the team that is supposed to implement it, cannot implement. I may have a Java development team, but it would be a good idea to do everything in Python. If I don't have anyone who knows Python, then I have to find a compromise and somehow try to do the whole thing with Java. I agree with that in any case. So the software architect can't sit alone in his little room and make models and then present them to everyone at the end of the day. They have to take the team into account, not just the customer's wishes and the non-functional requirements.

Björn Schmitz: Of course, we also get feedback from the team. In general, there is always a loop in software architecture, so you define and check it again and again. That's why the whole process is relatively lively, because it's constantly changing. It can happen that the model you defined beforehand turns out not to work properly. Then you simply have to redo it or tweak it a bit so that it works in the end.

Michael Kabdebo: Errors can creep in, actually, ...

Björn Schmitz: Of course!

Michael Kabdebo: ... when I notice that as a developer and then I have to talk to my software architect or the software architects, make them aware: Watch out! That doesn't work for such and such reasons.

Björn Schmitz: Michael, there are various voices that say that perhaps you simply don't need a software architect in a software development team. What do you think about that?

Michael Kabdebo: I have already said that software without software architecture does not exist, cannot exist. And that's actually how I see it with software architects. Maybe the software architect doesn't necessarily have to be a permanent person, it can also be a team. One can also imagine that the software developer or the software developers define software architecture as a team. The important thing is to be aware of it, that the architecture is on your radar. So it's not that software architecture simply emerges uncontrollably during development, but that you talk about it beforehand and define beforehand what the software architecture has to be, what it has to look like.

Björn Schmitz: What is perhaps also important is that it depends a little on the size of the team or how the organisation is structured. If I have many different projects working together at the same time, then it can of course make sense to employ different architects who can coordinate with each other and thus create an overall picture of the solution. 

Michael Kabdebo: Yes, I definitely agree with you. So the more complex, the larger software becomes and the more software perhaps comes together, even different systems, if you say you have to link something, then software architects have to talk to each other. In any case, you have to have it on your radar. It can make sense to introduce the role of the architect at some point. I also think that this is often missed. Software is constantly growing, and at some point software becomes more complex and more complex and more complex, and at some point you miss the point where you might have to say that now you need the role of the architect from a single person or a team who takes charge of it in order to create a certain accountability, that someone is responsible for architecture, is aware of it and acts accordingly.

Björn Schmitz: It doesn't have to be a single person, it can be the team, but the team simply has to be aware that it has that responsibility.

Michael Kabdebo: Well, if you imagine the software architect as a single person, what does he have to bring to the table? Can every software developer be an architect at the same time or ...?

Björn Schmitz: It depends a bit. A software architect should have a lot of experience and should perhaps have seen various things and also know how an overall system works in the end, and know which patterns, which tools must be brought together so that functioning software can be created in the end.

Michael Kabdebo: The software architect has to be very forward-looking. They have to be up to date with the latest technology and know what new technologies are on the market that can possibly be used, because we are developing new software. He has to be quite an all-rounder.

Björn Schmitz: Above all, he has to know how to proceed if something doesn't work as originally imagined. And then maybe have a plan B up your sleeve. Michael, what have we learned about software architecture today?

Michael Kabdebo: In any case, I hope we have learned that software architecture is a very, very important aspect of software production. Something you have to keep in mind at all times while you are developing the software.

Björn Schmitz: And that it always exists.

Michael Kabdebo: That it always exists and that software architecture can be a significant cost factor, especially if you have a bad architecture.

Björn Schmitz: And if you don't think about it in time.

Michael Kabdebo: Yes. Software architecture mainly helps me to implement and achieve my goals. Actually, we are already at the end. I hope we were able to summarise what software architecture means, what all is involved. The topic is often simply underestimated. I hope that came across as well. It was fun talking to you about it, Björn.

Björn Schmitz: Yes, I enjoyed it too.

Michael Kabdebo: Stay tuned and see you next time. Bye!

Björn Schmitz: See you next time! Take care!

That's it for today. We hope you enjoyed the topic and that we were able to answer some questions about architecture in software development. You can find further links to the current episode in the show notes. And if you are interested in the wonderful world of software development, we would of course be happy if you subscribe to us. Our next "Developed Talk" will be out on the 3rd of February. We would be happy to welcome you back. See you next time! Bye!