Recording Venue:
Guest(s):
Host(s): Alexander Markus Michael
This is the first of a series of Episodes on Software Architecture. Alex, Michael and Markus talk about rather fundamental topics in this episode, we’ll go into much more detail in subsequent episodes in that series. Topics in this episode include:
- What is architecture, how is it different from design
- what different kinds of architecture are there in addition to software architecture
- the role of the architect, do we have one or more?
- architecture in agile software development
- tasks of the architect
- architect vs. the technical project lead
- architecture and project politics
- architecture requirements, estimating, team assembling
Show Notes
There aren’t too many good references for this general architecture discussion. You might want to take a look at Software Architecture in Practice by Len Bass, or, if you speak German, at the book Software-Architektur by Vogel, Arnold, Chugtai, Ihler, Mehlig, Neumann, Voelter and Zdun.
Links:
Transcript
Transcript brought to you by IEEE Software
Markus 00:00:22 Yeah. Welcome to this new episode of software engineering radio. This one is the first episode on software architecture and it’s a S uh, something we tried for the first time. This is basically a Skype teleconference with three people. Um, so this is me Markus. Then we have Alex. Hi Enrique. Hello there. Okay. So, um, yeah, software architecture. This is a very big topic and we’ll need several episodes to cover it. Um, in this first episode, we’ll talk about the fundamentals. Uh, this includes the role of the software architect and what software architecture is after all to get the discussion started. Let’s come up with a definition of what software architecture is, and then let’s see whether we, the three of us agree on that. So in the American heritage dictionary, I found the definition about what is architecture and it’s as the art and science of designing and erecting buildings, a style and method of designing construction and the orderly management of parts. So if we transfer that to software architecture, who would say that software architecture basically is the art and science of designing and building software style and method of design and construction, as well as the orderly management or arrangement of parts, anybody disagrees?
Michael 00:01:44 No, I think essentially it’s covers the core of it. When I get asked in my consulting activities to define what architecture is, then I, uh, mostly referred to first responsibilities, functionalities that a system has to fulfill secondly, uh, two interactions to dependencies between those responsibilities and thirdly, to interfaces between those responsibilities due to the dependencies due to the interactions. And that is basically all I need for, for doing architecture. And, um, well, the, the heart problem with, with doing architecture is to fulfill all the forces, all, basically the nonfunctional, uh, concerns, nonfunctional requirements, um, that are implied on my system. And that’s an architect. I try to balance those,
Markus 00:02:43 Right? So architecture is always a compromise. Um, Alex, I think you want to say something about, uh, software architecture versus the other kinds of architecture necessarily when building systems exactly right.
Michael 00:02:55 One point architect or software architect as a heavily used term
Alex 00:03:00 Right now. So almost everybody calls himself an architect, but what we really discuss your software architecture and software architects, and there are many other architects out there that are it, architects, business, architects, integration, enterprise architects, and every architect does another thing. He has another responsibility. And yeah, actually, can you give one example of, of such another responsibility let’s begin with an it architect, for example, um, the, it architect usually is responsible for infrastructure, for hardware, for network topologies, and, uh, therefore for the infrastructure stuff, the, an enterprise architecture is the overall architect who keeps all the things working together, the software architecture, the it architecture, business architecture, and so on an enterprise software architect on the other hand is a software architect that does huge software systems, enterprise ready software systems. So they, these architects have wary very different roles in an enterprise or in the company. And very often these get mixed up. So we have to create a discuss what a software architect is here in our podcasts, I guess. Right? So in this podcast we cover software architecture. We do not look at the other kinds of architectures. We might cover them in later episodes.
Alex 00:04:29 Um, before we go on, can I maybe, uh, offer another definition of what architecture is or what software architecture is? And that would be everything that I care about in a project that should be standardized or done in a similar fashion. Would you say that this is a sensible definition of architecture?
Michael 00:04:49 Yeah, definitely. I mean, that is a part of the, the result, the role of an architect that you have to ensure a consistency and, uh, with the software architecture at a high level, you ensured as a consistency.
Alex 00:05:08 What I like about this kind of definition is for me, architecture actually is a pretty fuzzy conceptual thing. I mean, we have code and architecture is within the code, but it’s not something experts. We don’t have an expert set or divided architecture thing. It’s just a, it’s like a structural thing or whatever. So maybe this also leads us to the distinction between design and architecture. Exactly. So if I say that architecture is everything that I care about that should be standardized and consistent, then design is maybe everything on a granularity level below that.
Michael 00:05:48 Right, exactly. That I totally agree with that design for me is one level below architecture. And wherever you start with your architecture design is below is so, so architecture is for me as, at the top level, guiding the project, guiding the system, guiding the software under development with, uh, um, rules with design guidelines, with design principles to adhere to with architectural styles and architectural patterns. Um, that guide that shape the, the overall software system at the lower layer, you would then have the, the design where you talk about individual classes, where you talk about objects, variables and all those things, but is there actually some kind of border where does design and an architecture begin or other way around,
Markus 00:06:43 That’s maybe the trick of this definition I offered, because if I say, I don’t care, whether somebody implements something using the observer pattern or in another way, then it’s designed because it’s, it’s on a level that’s not critical for, for example, the nonfunctional requirements for my system. It’s not important that it’s done in a standardized way. If I wanted to be done in a specific way to realize certain requirements, then I say it’s architecture. So it’s kind of a self fulfilling definition.
Michael 00:07:12 And this contradicts a bit the granularity thing. I mean, it’s, it’s more the importance you say. Um, well, in the indicator, if it’s design or architecture,
Markus 00:07:22 You say, in some cases you might have to make architectural decisions that are quite fine granular.
Michael 00:07:29 Exactly. Yeah, exactly.
Markus 00:07:33 So, um, let’s briefly touch upon some process issues. Um, in the agile world, the term architect and architecture is somewhat disliked. People say agile projects don’t need an architecture or don’t need an architect. Um, any opinions on that?
Michael 00:07:54 I don’t think they say an eight or in an HR project. You don’t have an architecture. All the systems I’ve seen that are done with extreme programming, for example, have an architectural and mostly very, very good architecture. So they have a structure, they have an architecture, they have important design decisions to stay with your definition. Um, what they not so often have as an expert said, architect as a role. So I guess there is the, the huge difference between the traditional software development pro checks or pro um, methods and HR projects. Yeah, I would put it that way that, uh, in HR road checks, uh, that the architecture is not explicitly blend, but much more created by having always a running system, starting with a small car, starting with the areas of highest risk, and then defining the architecture implicitly while developing the working system that the architecture grows as you complete your system. And, uh, still, I believe it’s, it’s important to pick the right architectural patterns for you for this car, for the initial working system to then be able to grow that system and not having to refactor, uh, your whole solution to match the later requirements. When you, when you increase, when you grow your system.
Alex 00:09:23 Exactly. That’s a very important point there. The timing is different from traditional software projects or methods. They usually do all the architectural stuff in front of the project from up. And, uh, our HR projects try to avoid design and architecture decisions as long as possible. They try to decide at the latest, responsible moment in the project. So it feels different, but there still is architectural and architectural work, of course. So there is maybe a difference between the architecture as an artifact that you might want to create at the beginning of a project, which consists of paper basically, and diagrams or whatever, and then the architecture as something that you can extract from an existing system. So something that grows over time and the agile folks say, we don’t want to do this upfront thing, but rather make sure the architecture evolves over time. Exactly. And this is one of the similarities between these different architect types, we, or type of architects.
Alex 00:10:28 We talked before. Usually if you have an architect, you have to distinguish between the actual architecture, the architecture of the software system and fuse, or the architecture, and maybe you, you do the fuse front up into the design and the architecture from the up and do UML diagrams or whatever, but you also can do it later on the project or after the, even after the project is a post-mortem. So the fuse of the architecture, and there are many, few, they are static shoes, dynamic shoes, whatever are not the architecture itself, but if I wanted to come up with a consistent system, and also if I say, I don’t want to preplan the architecture, rather I want to evolve it over time or over the course of the project, if I want it to be consistent, how do I, how do I make sure that in such an agile approach, a consistent system evolves, then
Michael 00:11:24 I think having, having guidelines and having as few as possible, a principals that are accepted by all developers involved, um, can help with that. So for example, um, only asynchronous communication is involved in the whole system and no synchronous communication because you need to be highly reactive and, and you’re in embedded real time environment. So if you’re just brought Hibbard, uh, the use of communication that already saves you a lot of trouble and many design decisions can be derived from that principle.
Alex 00:12:01 So you say that that, um, you also have a number of guiding principles, even in those agile projects, but you don’t spend, I don’t know, two months and, and write this big architecture document upfront. Yes. That’s the point. Okay. And another thing is you usually try to keep your code and therefore your architecture, but, but mostly your code in a state where you can change it easily. And the easier it is to change the code, or for example, the dry, the don’t repeat your self, uh, thing. If you have to just change little parts of the systems to do actor actual architectural changes, it’s easier for you to change the architecture. And to be honest, even if the, in the non HR projects I were in, um, we had to change some architectural stuff later on. So, um, architecture can’t be really static. It shouldn’t be in my opinion, actually.
Alex 00:12:59 So you should do everything to make it flexible and changeable and so on. So it’s basically not possible to come up with an architecture upfront. You might be able to start, you know, start with a good, a good starting point, but using architectural patterns or something, uh, which we’ll talk about in later episodes, but it always has to evolve. Yeah, it’s a bit different in, uh, well product lines or something like that, where you just can copy an architecture that already is proven in this area, but in normal non-complex systems, you can’t come up with an architecture front up that really hits the point and doesn’t have to be changed on the way. So Mika, do we need an architect?
Michael 00:13:45 Yes, I agree. I, well, I think, uh, the role of an architect as is often overvalued and maybe misunderstood. So it almost seems like it’s, uh, the, uh, the most honor of a developer to become an architect,
Alex 00:14:05 This set on my business card.
Michael 00:14:07 Right. And so I think, uh, every developer is as valuable as an architect. I actually kind of dislike, uh, does, uh, this ownership, uh, but still, I think, uh, somebody in the team must be responsible to ensure consistency, to facilitate communication, to ensure reuse, and to coach others, uh, in a project. And, uh, if I would have to give this person a name it’s of course, uh, the architect, yes,
Alex 00:14:43 There is always this discussion, whether there should be one architect or whether there should be a group of people who do the architecture and, and maybe somewhat
Markus 00:14:52 There’s maybe an analogy that people say that I that’s the saying that says nice systems or well-designed systems are the product of a simple, brilliant mind or something like that. You might’ve heard about this statement. So do we need to have one architect to make sure that everything is consistent in a way that he thinks are, or do we have a group of architects, or how does this work, or, or can this be done in different ways in different projects?
Michael 00:15:17 I think, uh, for, for small teams, one person, one architect is totally sufficient, but for big projects and projects distributed over several locations, which is the common case in my company that I’ve worked for. Um, you have typically a group of architects and, um, the important point here is to have only one lead architect. So, um, it’s kind of a hierarchical system that I such as. So for example, for every subsystem, have a, have an architect or, well, not for every subsystem, but try to minimize the number of architects, but when distributing the architects associated with, um, um, individual subsystems and then have one lead architect that has the final saying when there’s a dispute, when there’s disagreement on design the sessions.
Markus 00:16:18 And also it might probably make sense to in big systems to have architects that are experts in certain technologies. Like, for example, if you use carbo, then you might want to have somebody who you might want to call carbon architect or middleware architect or something who deals with the technology specifics.
Michael 00:16:35 Right. And also, uh, well, what I just said, uh, re splitting, uh, according to subsystems, splitting, according to layers is also something that is very common,
Markus 00:16:47 Right. Okay. To summarize what we discussed so far, why does the system need a software architecture? So first of all, it resolves conflicting forces in a specific way. The software architecture, as we said before, is almost always a compromise. It also serves as a guideline for more detailed design decisions. So the design decisions that developers or teams make on their own have to be compatible or in line with the architecture. So that helps to create a consistent the system. As a consequence, the architecture also leads to a well-defined programming model. A programming model is a term that we’ll discuss later, I guess. And it basically means that if you want to implement business logic based on a certain architectural style or a certain architecture, then the programming model defines how you implement that business logic. The architecture can also serve as a basis for a software system, family, which is also something we discuss later in the context of a product land engineering, a software architecture also helps to define the basic building blocks metaphors for the system, or even the vocabulary that can be used to discuss about the system in the team.
Markus 00:18:02 So before we go on to additional observations observations, I think it’s important that in a team, the architecture is something that everybody feels responsible for. It doesn’t make too much sense if you have this guru architect to, you know, always make sure that documents are nice, but nobody cares about that. And also usually an architecture, as we said, has to be built incrementally. It evolves over time, over time during a project, though, the number of changes and the severity of changes should become less frequent. Otherwise your initial software architecture was probably wrong. And the experience of a software architect shows, um, basically by, of experienced software architects more often get it right or relatively right in the beginning. So that’s basically a summary of what we discussed until now. Uh, we should probably now discuss, uh, in a bit more detail, the tasks that a software architect has to has to execute the things that he’s responsible for in a software project. So we go from software architecture as, uh, the thing we built to the tasks of architecting a system to the responsibility of a software architect.
Michael 00:19:23 So when I, as I just introduced, when I talk about software architects, I always think about bigger projects or projects that have a size of at least 15 to 20 developers. And so here is already a problem that I see that is the scalability of the role. I mean, kind of single person due to all the design decision, should a single person do all the design architecture decision or, um, should much more the team collaborate and define the architecture commonly and should, uh, basically, um, one person then ensure the consistency of it. So this has also to do with scalability, uh, getting, uh, having teams, uh, at, at a size of like 50 developers or even a hundred developers working on a software project, uh, you need to a way to scale the role of, of an architect. And so to achieve the scalability, um, I generally, uh, define the priorities of an architect like that.
Michael 00:20:33 So first he has to communicate, uh, with the stakeholders. So this is product management, general management, um, does this, what the requirements folks with the customers if necessary, and of course, between the teams with the teams, with the developers and, uh, what he should share are the requirements, the design guidelines, the principles, um, that the whole development team, uh, should adhere to. Secondly, for the second priority, he should ensure the consistency of the overall architecture by reviewing the design made by the individual developers. So this is for me, this is a key here because, well, when I’m in a team, I trust the developers that I do good design the sessions, uh, having the basic principles at hand, uh, and, uh, doing regular reviews ensures that, uh, all the design decisions go along and smooth and towards the same goal to achieve to the product success.
Alex 00:21:39 Right? So, so reviews is not a sign of mistrust. It’s rather just the way to make sure that people have compatible decisions, right?
Michael 00:21:48 Yes. Okay. And the third priority a is guiding the developers and doing good design. There might be some team members that are not so experienced and, and coaching them, doing design commonly with them being on the whiteboard and discussing things, uh, is very valuable for them. Uh, and you also then get a good feeling for how the developers think about the design, how the design decisions, uh, got defined, uh, how they got worked out and only at the, with the least priority, you would contribute your own design knowledge because you’re, you’re the, the main flow of your experience into the project should come through the reviews. And so what does, I had already a good success in the past and was able to lead even big projects, uh, as a technical lead, as an architect,
Alex 00:22:46 It’s probably a tough one for those guru architects who always want to show that they’re the best technical geeks and the best experts or something. If you say that they should contribute their knowledge only on priority four.
Michael 00:22:59 Yeah. It might be a kind of disappointing to them, but I believe the, the, the, the amount of developers, the, the amount of brain working there is it’s much larger this way than having only one guru architect
Alex 00:23:20 For me, the best way to scale architects and approach it. Uh we’re um, yeah, actually, if you have more than one architect, of course, you should have this lead architect you already thought about. Um, but then the, the single architects should concentrate on different architectural, uh, well components or layers or whatever. So you, you, you should give an architect or responsibility for an architectural thing, whatever this thing means, um, this is better for identification with the topic and, uh, I made the best, or the best results with this kind of scaling there.
Michael 00:24:01 So, um, one thing where it’s probably a good idea to have separate architects or people or technical leads as for certain technologies, I think we agree on that. Yeah.
Alex 00:24:11 Yeah. But in my opinion, you shouldn’t have a trust corporate architect that doesn’t know anything about the rest of the application. Um, so it, you should actually integrate the, the discussion or the, the people, um, along architectural things, whatever this means, asset components or whatever. Um, so yes, you need architects with different skill sets, but they, they shouldn’t be really separated along this technical topics. I would w yeah, I actually worked on projects where we just had this database architect and then this middleware architect, and this was actually their, their, the also the organizational thing that he, the one just cared for the database and the other didn’t know anything about the database. And that was a huge communication problem, and it never really fits together. So I’m not so sure if this is a good way to organize the architects, but of course you should have people with different, special skillsets.
Michael 00:25:16 Yeah. I, I also know a company, a consulting comedy in Germany, um, that splits the roles of architects along infrastructure, architects and application architects. So the infrastructure architects would care about all the middleware communication, uh, database persistency, um, et cetera. And, uh, that application architects would then actually deal with the customer, um, requirements with, uh, implementing the application logic on top of that. And I always ask myself whether that is a good split, whether they, uh, for example, the infrastructure architects have the right, uh, understanding of the problem, um, uh, to, to make the right design decisions to whether they know all the forces and posts on, on the software system as a whole.
Alex 00:26:12 That’s exactly the point if these Bose architects, um, don’t have to know or understand what the other task for the shop and the architectural things are that separated, that it works, it can work if the middleware architect actually doesn’t have to know anything about the, the other things in the system and the business logic or whatever, which is work. But this exactly, this is very, very unlikely. And then I have, I have had a lot of trouble with these kinds
Markus 00:26:44 Of a separation. So we have, so I think we agreed that it’s not a good idea to have the technical geeks, like, you know, do their own thing and don’t care about the rest. Um, and that’s probably true for most systems. I think there is an exception and, and that is something we’ll discuss in further episodes. And that is in the context of product lines or software system families, where you explicitly want to build and evolve a platform that can, uh, basically carry, uh, many different applications. They’re usually have a domain architect, uh, a person who takes care of the, of the fundamentals of the product line. And then you have for each project that you built on top of the product line, you have application architects, but actually even there, I would always try to get someone in to, to these, uh, well, however you call it infrastructure architectures, things who knows the domain stuff, you do need domain architects, but they are different from the specific application architect.
Michael 00:27:44 Yeah. And here, the difference is also domain architects doesn’t mean infrastructure, architects, infrastructure, right? It’s not only technical the domain, what the platform they use, but it’s a domain specific platform. So it is not only about, uh, communication and, and databases. It is also about, for example, the eCommerce domain about the automotive domain. There are specifics that are customer requirements that get down to the domain engineering to the platform, um, and have an impact.
Markus 00:28:21 Okay. But we’ll, we’ll discuss this topic in subsequent episodes. Right. Um, another thing that I want to distinguish is other roles of the architect versus the role of the technical project lead, uh, is this the same person, or do you see any difference there?
Michael 00:28:38 Yeah, sometimes it’s explicitly defined like that, at least in my environment. And in other cases, the lead architect of a project is then a de facto, basically the technical project lead being asked for all the tough technical questions and
Markus 00:28:58 In a project. So this is also a scalability thing. I mean, if you have a project with 10 developers, you don’t, at least in my opinion, you don’t need a technical project lead an architect, or more than one architects. And so of course the thing is completely different if you have a project with 200 developers. So, I mean, go ahead. Yup. Okay. Um, scaling and archive. I mean, I think it’s obvious that a three person project can’t be done the same way as a 200 person project, and we’ll probably discuss that in subsequent episodes. So, um, it’s, it’s the architect also has, does he have to deal with politics and all that, you know, for sure stuff,
Alex 00:29:43 For sure. I mean, I’m an architect has, or one of the major points an architect has to do is communicate with the developers, communicate with the project manager and, um, all or the cost, even the customer. If you have some, uh, functional stuff you, that affects the architecture, sometimes it’s better to change the requirements a bit, to get a much better architecture and therefore speed. And even the customer does want this change and requirements. So politics, uh, communication is maybe at least as important as, um, technical knowledge to me for an architect
Michael 00:30:21 For me, the technical project leader or software architect is the one who should be most concerned about the technical soundness and, uh, the proper technical goals. And he should, uh, preferably stay out of politics. And when he gets into politics, he should vote for the system, uh, care for, for the technology care for the, the sound architectural decisions and, and try to minimize all of course personal injury.
Markus 00:30:56 So, so you say that the technical architect, the architecture would say from a nonpolitical point of view, this is the way we should go. And if you managers want to override this decision, because you think there are some political stuff we have to do, then it’s your decision, it’s your responsibility. But I, as a technical person, I’ll say do it this way.
Michael 00:31:14 I would prefer that way. I know that it’s a tough way, but that is the way I went in the past. I had a lot of trouble with those a way, but at the end, uh, I had always a, uh, a clean mind at least, and right,
Markus 00:31:31 That’s the point. I always do it. This, I try to do it the same way. And if, if it, if I’m involved with too much politics, I’ll leave the project being a freelance consultant. I can do that.
Alex 00:31:40 Maybe not the best solution for the project.
Markus 00:31:43 It really depends. I mean, a frustrated Molokos on a project, also, not something you want to have,
Michael 00:31:52 Leaving a check that just makes the point. I mean, this tells the project don’t go on like that.
Alex 00:32:00 But, uh, you just mentioned the politics and while the two, the direction customer or management or whatever, um, I don’t think that is the only kind of politics you have to deal with an architect because you also have developers and UI designers and requirement, engineers, whatever you have to deal with. Uh, maybe a huge team and every, every yeah. Larger group of people has politics within. So I still think an architect should have the sense for politics and human interactions and communications. Is that, is that same? I mean, yeah. I agree that the architect should be able to work with people and coach people and communicate people and maybe also resolve, you know, if members of the team get on top of each other and fight some, some stuff out that the architect should be able to resolve that. But I mean, that’s not what I would call politics.
Alex 00:32:58 That’s depends on your definition of politics. Of course, for me, it is politics too, but that’s the definition of thing me that would be management of a team. Um, and politics is really, you know, the stuff that you go to the customer and basically tell him crap. So you get the most out of this, a definition thing. I mean, I think we agree on this, um, human interaction thing. We have to deal a lot with people as an architect, even more than the technology, in my opinion. And you have to have the skills. I mean, that’s one of the point why I think the best program or might be an not so good architect because you have to have more abilities than just architecture or technical stuff. It doesn’t work if you have the best architecture in mind and can’t communicate it to your team or get the team to implement, implement it too much to too big of an ego. And therefore always is. Right. Exactly. All these social skills set, things are very, very important for our hitches, in my opinion. Yeah. Okay. Uh, until now we’ve been talking about what the architect does once the project or the implementation has started. Um, is there, uh, stuff for the architect to do before the project really starts like in the areas of requirements or estimating the amount of money it costs or assembling the team, maybe hiring people. So any things the architect should do in this?
Michael 00:34:23 Yeah. In my believe, and in my understanding, the architect should be involved as early as possible. And the architect should question the requirements very much. So, uh, when the architect doesn’t understand or doesn’t, uh, have the feeling that there are sufficient requirements available, he won’t be able to communicate the design or design goals, um, or generally the requirements to the development team. Um, so in any case, uh, when for example, a system gets developed and, um, the project starts with no requirements, only weak requirements. I would actually expect the architect to do the requirements engineering, to talk to the customer, to talk to management, to all the stakeholders and, and get the requirements straight.
Alex 00:35:20 I agree, although that’s something that many architects, especially the more technical minds don’t really like to do. And that’s also where I might want to throw in a small anecdote about the role of the architect and politics. When I was working for a big consulting company a while ago, we had to do an estimation for, for a project. And we came up with, I dunno, 20 million or something. And so it was a rather big number. And then there was management insight, Oh, you know, that’s too expensive. We have to have all at most 12 million. So please reduce your estimations. So of course we didn’t. And then of course, that was where politics came in with. We offered the project with about 12 million and the customer accepted. And then of course we had roughly 8 million overrun.
Michael 00:36:06 Isn’t there a term for that, uh, designed to cost her, something like that.
Alex 00:36:11 Yes. But you didn’t decide to cross the, actually we just skipped anyway, just, just an anecdote. It’s the architect also responsible for building the team. What do you do as an architect? If you see the team isn’t appropriate or there are folks in the team who aren’t up to the, to the challenge.
Michael 00:36:31 No, don’t ask those tough questions.
Alex 00:36:34 It shouldn’t, but I think this is, this is really a tough one because if you, as the architect see that one of the problems in a project is that you have some people who aren’t up to the chop. What do you do? I mean, but that’s highly dependent on the project and the organization. You work the alternatives. Well, of course you could trust, um, talk to the guy, you have the problem with maybe you, you can coach him, whatever, um, otherwise, uh, and most probably you, you already did this at this point, so it didn’t work. Uh, you can talk to the project manager, uh, about the decision of staffing, if it’s possible to exchange him, whatever. I mean, uh, the, the organization, maybe even the project manager has not the right to exchange people there. So should this be possible for an architect to exchange people if necessary? No, no, no,
Michael 00:37:29 No. I, I agree with that. He shouldn’t be, shouldn’t have to right. To do it. So it should be the problem. It should be the responsibility after the project manager, the project lead. But I mean, the architect is the one who, who can best charge the technical abilities, the technical fitting, whether, whether a person is in the right position and in a project. And when he has a gut feeling that this doesn’t work should talk to the project manager and try to find a position within the project that this person does developer could fulfill Besser, his, his or her chop
Alex 00:38:10 That leads to this, this organization where you have two or three people who do the real work, then you have another two or three people who help to help those people to do the real work. And that you have this other set of people who do something so that they have something to do. Not, not, no, it doesn’t have to, obviously it’s a bit provoking and it doesn’t have to be that way. I mean, there are things that are important and, um, just different skill sets. I mean, talking to customers, doing maintenance, um, doing UI design for example, is very important thing. And I know a lot of developers, great technical guys who have a lot of trouble with doing good UI design. So, um, you’re very, at least in the larger projects or project teams, you really often have work to do that is important and you just have to find the right person for it. So I wouldn’t be so negative on this point. I mean, and I don’t fire people all the time. It’s just, I wanted to provoke the discussion now. Of course, sometimes I have, sometimes it has to, I mean, it’s, it’s Korean, not every body is okay for a software project and can do it. So sometimes you have to, of course,
Michael 00:39:24 Yeah. I mean, especially in highly critical and broad checks with a very tough, uh, timeline, um, you have very little time to argue whether this person is right, uh, in this position or not. And here it’s a really problematic and ethical question how, how to deal with that.
Alex 00:39:47 Yeah, but still, I think it’s not the question an architect should answer an architect should give an indication if somebody is not good in his shop and maybe, or he should also give a hint where he could do a good job, but he shouldn’t do all this decision stuff. I mean, an architect has to have some relationship with the developers and if he just throws out people out of the team, it’s much harder to work in the team.
Michael 00:40:16 Yeah. Yeah. I totally agree. I mean, you, you need to have trust as an architect, but developers need to trust you. You need to be able to trust the developers to be a good team else that doesn’t work. And you’re, you’re no longer an architect because the architect well defines itself by the team, by the developers. And when you’re not accepted, you’re just not the architect. Even though you might call you the, you might call yourself, uh, being the architect.
Markus 00:40:44 Okay. So I think this, uh, basically concludes the first episode on software architecture and our series, um, to give a small outlook, we’ll probably discuss some architectural patterns in subsequent episodes. We’ll look at the quality attributes architectures, realize we look at how to document architectures and also at how to scale the architectural process up to larger projects and bigger team sizes. And then of course we’ll have episodes on product lines and all that stuff, but that’s a separate topic. It’s not going to be under the name of software architecture. Anything else you want to say, Michelle or Alex?
Michael 00:41:22 Um, good luck with your next software design.
Alex 00:41:26 That’s a good one. Famous last word, cynical. Okay, then, uh, thanks
Markus 00:41:34 And see you next week or in 10 days, actually. Bye bye. Bye. Bye
[End of Audio]
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
