Meanwhile, there is a debate for a long time whether architecture and design are the same thing or not. The advocates of the “both are the same” thesis say that architecture is basically the first stage of design, while the opponents of this thesis claim that architecture and design are completely different tasks that just share some more or less fuzzy line of contact. So, who the heck is right?
I think it is really hard to find out who is right or wrong … actually I think it is sort of impossible. Even within our small company we are not able to get a common agreement about what exactly architecture is and what design is. And if it is not possible to get to an agreement within a few people (even if some of them are strong characters … 🙂 ), how should we come to an agreement within the whole IT community? It is probably impossible.
Thus, I will not try to find a precise answer for that question. Instead I will try to approach the topic from a different angle. First, why is it so hard to answer the question? I think a big part of the problem is that there is no satisfying definition for both terms available, neither for architecture nor for design. So, whenever you talk with another person about architecture or design you can almost be sure that he or she will talk about something different than you do.
I mean there are *lots* of definitions available but most of them are so specific that they do not capture the topic sufficiently or they are so vague that they do not help at all. Just for instance, Robert Martin (who said and wrote a lot of very smart things, btw) once stated “Architecture is about the important stuff. Whatever that is.”. Now, this means everything and nothing. Does it mean that design is about the unimpotant stuff? Probably not. And, if coffee is really important for the developers (which it usually is), does it mean, that architecture is about coffee? Probably not. As you can see this definition does not really help.
I will not go into detail for other definitions because I think it will not lead anywhere. It won’t be possible to find a definition for architecture and design that everybody will agree upon *and* that will help us to figure out the difference between architecture and design. Especially I think it won’t be possible to find a clear separating line between architecture and design, where the one thing ends and the other thing starts. Everybody draws his line somewhere else and many people probably rather have some kind of fuzzy cloud in mind instead of a sharp line. “Somewhere within that cloud architecture stops and design starts” they will say.
Okay, but there must be something that might help us. At least there should be something …
Maybe it does help to step away from that question for a moment. From my experience I figured out that there are two basic tasks that make up that whole architecture and design thing (without trying to find the separating line). The whole thing is about transforming all the requirements that are around into a result. (Btw: If you would ask where the coding is in there, I think I would leave it up to you to find the separating line between design and coding; I think it is a similar question … 😉 )
The first part of that transformation task is to understand all the requirements (not just the business and user requirements, but also the requirements of the mangement, the project management, the development team, operations, system planning, the security department, the testers, and so on), really understand them, to balance them (there are always conflicting and inconsistent requirements across the different domains and stakeholders to deal with) and to find an appropriate solution idea for all those balanced requirements. I usually call this part of the work “alignment”.
The second part of the transformation into a working solution consists of turning the solution idea into an appropriate structure that supports maintainability and changeability, and refine the structure over and over again until you are down at the code level without losing the properties described before. I usually call this part of the work “structuring”.
Now, is it important to distinguish those two tasks? I think, yes! The reason for this is that I figured out that those two tasks require very different skills. While alignment has much to do with communication and conflict management skills, structuring requires more formal strengths. Also alignment requires kind of a broad knowledge about all the different requirement domains while structuring requires more of a deep knowledge about the solution domain. As a consequence, you will find quite few persons who are capable (or willing) of doing both tasks with the same strength, and if you neglect one of the two tasks you will most likely get an unsatisfying result.
Okay, getting back to the initial question. Will alignment and structuring help us to find a separating line. I think, sort of …
From my perspective, alignment is definitely part of any good architecture while structuring is definitely part of any good design. You cannot be a good architect without doing a lot of alignment and you also cannot be a good designer without doing a lot of structuring. How much of structuring is required in architecture and how much of alignment is required in design, I think that is mostly a matter of taste and there won’t be a definite answer to this.
So, I also cannot provide you with “the” answer to the initial question. But I know, if somebody talks about architecture without talking about alignment he does something wrong and if somebody talks about design without talking about structuring he also does something wrong. And that is the most important thing from my point of view …
PS: My apologies to Robert Martin for picking on his definition of architecture. As I wrote before he said and wrote a lot of really smart things, even though I do not agree with all of them. So, if you have the opportunity to read some of his stuff or listen to a presentation of him, just do it! Now, that should be enough of indemnification … 😉
Was this post helpful?
More articles
fromUwe Friedrichsen
16.10.2018 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Uwe Friedrichsen
CTO
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.