5 ms·

Why I don't believe in software architects

47 points by smikhanov 17y ago

modoc 17y ago
As a software architect for the last ~10 years I have to disagree. His point seems to be that if you get a job as a software architect you'll end doing nothing but meetings and creating UML diagrams. I'm sure there are places like that, I've worked at one (Rational Process - shudder), but there are many places where they need someone who can provide architect level application design, who can see the forest through the trees, who can balance the needs of the business, the 3rd party integrations, and the technology. My current contract role has me providing architecture (usually just a 1-2 page design doc, not often UML), mentorship, and coding some of the trickier stuff. I still code a lot, but I also have responsibility over the whole software ecosystem and hence some power to decide how things go. I mentor developers, perform code reviews, and work on process improvement too. It's a great role.
- smikhanov 17y ago
  I'm sure there are places like that, I've worked at one (Rational Process - shudder) Thank you for your honesty :) The bottom line of my post was "beware of the advertise SA positions, they tend not to offer what is usually expected from an advanced position like that". I also think that a key to being a good SA is to keep writing code, no matter what happens. Looks like this is exactly the case for you.
  - modoc 17y ago
    I absolutely agree that if you like coding, don't ever stop. It will also make you a better architect. In my experience, large companies who use Rational will have their architects buried in Rose building UML and writing 150+ page docs all day. Smaller and/or agile/XP companies will be looking for a super experienced coder, who can mentor, and look at the big picture, see the business drivers, etc... Ideally this sort of thing can be figured out early on in the interview process. "How do your other architects spend their time?" etc...
    - hga 17y ago
      Hmmm ... I think you can do both. I used OOSE (from the book, the cut down version of Objectory (prior to it becoming the Rational Process)) in a project ... but it was just me and a bright newbie almost right out of college, with someone added for a last feature. It worked fantastically well, e.g. I had to stop working on the project for a few weeks to attend to the prototype (that I'd hacked up in in a 6 week burnout), and when I came back the newbie had neatly iterated the design and was able to slip right back into coding with no fuss. By the end of the project my estimates for how long to finish a unit of work were accurate to 30 minutes (by then I'd been programming for two decades, so it wasn't all the process!). On the other hand, I wonder if Objectory/OOSE/Rational Process solves the wrong problem. If you're going to use imperative OO to build a big complex system, yea ... but maybe you should try e.g. functional programming. I.e. the other relevant development that came out of Ericsson was Erlang and was for the same problem space (e.g. telephone switches). Still, I feel that if you use parts of it correctly for the right sorts of problems (especially ones that are pretty well understood, e.g. I'd been figuring out for 5 years how to do my project correctly before I had a chance to do it as detailed above) it can be very useful.
      - hga 17y ago
        CORRECTION: the newbie had neatly iterated the design and I was able to slip right back into coding with no fuss
- hello_moto 17y ago
  There should be more people like you. The biggest problem in our industry is that there isn't enough mentors to tell the young people that they were wrong all this time.
  - modoc 17y ago
    :) I think the biggest problem in the industry is that many of the "young people" (I'm still young, dammit!) don't really want to learn or be mentored. Seems like there's a slew of folks in the junior to mid-level developer arena who got into CS because it was going to make them a lot of money, not because they love to code. I love it when I'm working with people who love to tinker with new libraries and APIs, who are working on something neat in their spare time, etc... They make much better developers than folks with a CS degree who do what's assigned to them from 9-5 and that's it. I'm not saying you have to work a ton, but just be interested in the whole tech universe:)
    - meta 17y ago
      As best as possible, I think a company should screen for that in the Interviews. (given that Interviews are sometimes a effectiveness gamble, I realize that it can be difficult to screen for that). I usually watch to see if they light up and get into conversations when I ask questions in the Interview related to our tech. If they don't get that expression and interest (hard to qualify but I think most people know what I am talking about) than that is a lot of hire points lost. If you spend an hour talking computers and they never 'light up', I feel, they are probably not the right fit.
    - jerf 17y ago
      I blame the myth that young hackers are somehow strangely more knowledgeable than their elders because of the putatively ever-changing nature of technology. I've always been suspicious of this self-serving narrative (in what other engineering field is this true?), but as I approach what passes for Old Fartness in this industry (30) now I know it's bullshit. All the twenty-year-old whizzes I know are experts at taking something like Ruby on Rails, trading in the quality of the underlying framework to put together a hack-job very quickly, and then promptly getting themselves stuck in a morass that they can't get out of because they don't even understand why they are in a morass. Hand these people something with a lot of technical assets they can borrow against and yeah, they can toss something together fast, but that's hardly "better" then what I can do now, which is actually produce technical value. (Mind you, I'm not saying that's necessarily a bad thing. There's a time and a place for that. What is a bad thing is that the developer won't understand the tradeoffs they just made, and probably didn't make the tradeoff after a sober and careful balancing of the costs and benefits, but did it because it's all they know.) Anyhow, my point is that thanks to that mythology, a lot of younger people don't think they can be mentored by the old farts they think know nothing in this rapidly changing technical environments. The old farts (at least the ones who have ten years of experience and not one year of experience ten times) have learned that frankly, the tech world isn't changing that fast (different languages, different APIs, pretty much the same messes). There's plenty of mentoring to be done, but you gotta accept that the mentors are going to tell you some things that may shattered your treasured conceptions of the programming world....
- bmelton 17y ago
  I'm in almost the exact same boat, though I find that much of my job is in just predicting pitfalls, and in anticipating when things won't work. As a federal contractor for an agency that prefers to use COTS/GOTS software, there is a surprisingly great need for having a developer that can look at a given piece of software, intuit how it works, probe its sales and development teams to say "Well, this claims to do Kerberos authentication, but it really does GSSAPI, and hence, won't work with your existing OpenSSO implementation." I also code a lot, mentor other developers, etc., and yes, it IS a great role.
- japherwocky 17y ago
  This is much closer to the role a real architect plays in a real architecture firm. Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.
gaius 17y ago
Good systems architecture is crucially important - which is why it should only be done by people who know they can get called at 3AM when it all goes hatstand. Not the sorts who wave their hands and draw nonsense diagrams on a whiteboard and chuck something that cannot work, ever over the fence to the implementation team and blame their skills when the project fails.
lucifer 17y ago
The practice of architecture is inevitably entangled with one or more notational and representational systems. This is true if you are architecting ships, infrastructure, buildings, or software. Complaining about UML is like complaining about drafting, drafting notation standards, and CAD software.
- blasdel 17y ago
  It's more like there's only one drafting standard, and it was built by and for the Soviets in the 70s.
delano 17y ago
Programmers often neglect the fact that not all problems need to be solved with more code. More specifically, there are problems that are better solved at the architecture level. For example, rather than queue jobs in a wonky static variable, use RabbitMQ or Redis. And instead of implementing search functionality through Hibernate, consider a separate stack which you can grow independently of your core application. While you're at it, consider using Solr instead. I'm not justifying the term software architect (I don't like it for other reasons), I'm simply suggesting that if your infrastructure consists of a single, monolithic application, you need to consider solving some of those problems outside of your code.
- smikhanov 17y ago
  I'm not justifying the term software architect (I don't like it for other reasons) What are your reasons, BTW?
  - arethuza 17y ago
    One reason might be that "real" architects get a bit upset at the use of it in the software world.
    - modoc 17y ago
      Haha yeah everyone thinks I build houses because I'm an "architect" and a "contractor".
  - japherwocky 17y ago
    As someone who went through Real Architecture school, I find most software architects don't deserve the title. Architecture school is very hard, mentally and physically. The perk is the weird mystique that society gives us.
    - hga 17y ago
      Hmmm, ignoring the school part, have you found some "software architects" worthy of the title? I know you say that implicitly, but I wanted to make sure and perhaps have you elaborate a bit on what distinguishes them.
arethuza 17y ago
I tend to believe that the job of an architect is not to make the important decisions but to make sure the important decisions get made correctly and to take responsibility for that process and its results.
- smikhanov 17y ago
  This blurs into my vision of top-notch software engineer without the fancy title, which was the reason I wrote that post in the first place.
  - arethuza 17y ago
    In my experience the title is really there to identify who will get shot if the damned thing doesn't work for fundamental technical reasons.
    - Luyt 17y ago
      The developers, who failed to glue the mandated technology together, probably will be blamed ;-)
- Maro 17y ago
  Isn't that the job of a manager: delegate the technical decisions to the best and brightest teammates? I would think the software architect is the "default" choice.
drtse4 17y ago
Fancy job titles and funny job descriptions aside, i always thought that the ability to perform critical architecture related decisions is something that every developer should some day achieve, making this "software architect" as a natural step of the evolution of every developer. And regarding UML, having seen it misused and misunderstood a lot of times, it's just a tool, the same ideas can be expressed with other means, what counts is that the content is clearly explained and correctly understood.
- smikhanov 17y ago
  As I'm saying in the neighbour thread, this was the reason why I wrote this post in the first place. Something like "hackers, don't be lured by fancy architect job, just master your own craft, this is more valuable".
Silhouette 17y ago
It seems to me that the biggest problem is not software architecture per se, it's when you have a software architect who thinks they are automatically senior to other members of the team. Software architects are (or at least, IMHO, should be) co-ordinators, not directors/dictators. Of course architects need to be technically strong, because they need to be working with the team leads responsible for each part of the software project. That means they need to be able to communicate effectively with those leads and understand the technical implications of what is being said. But it's a two-way street, and both the team leads and the architects have their own role to play. The team lead needs to be more aware of the finer details going on in their area of the project. The architect doesn't need to know those things, but does need to be aware of how everything fits together. That includes knowing enough about what each individual team is doing to identify areas where something new would be useful, or where multiple teams are doing the same thing and there is redundancy that could be eliminated. Ultimately, it's all about collaboration. A software architect who only draws diagrams and produces hundred-page design documents probably isn't very useful. A software architect who talks to business leaders to clarify the requirements, liaises between the various development teams to make sure that they collectively meet those requirements, keeps an eye on testing and on bug reports coming in from the field, and so on, is pretty much essential to building large software systems successfully IME. (Edit: I realise that my final description there was rather broad, and has some overlap with management responsibilities. Realistically, I think a software architect is going to have an element of that as part of their role, just as team leads do within their particular areas. But both are primarily technical roles.)
- j_baker 17y ago
  Agree. Nothing is worse than an architect who's a closet manager.
  - joezydeco 17y ago
    I'll tell you what's worse: an architect that has no experience in your product field. I'm currently in an embedded systems company where the chief architect came from a server-design group. So now everything we do looks like a server. It's awful on multiple levels.
hga 17y ago
One detail from the Antipatterns book: They claim that only about 1 out of 5 programmers "get" abstraction. To the extent this is true (and it agrees with my experience in the field starting in 1977 including a dozen years in and around MIT) you can't have "democratic" design processes, for the "software architects" who do get abstraction will be voted down and you'll end up with the usual mess of spaghetti (or whatever they're calling it nowadays). Hmmm ... another problem I ran into was understanding scaling, O(whatever) issues. At least one project I declined to join died horribly because the people in it couldn't grok that their design wouldn't scale to the level needed for basic customers, let alone big ones (in this case the lead had only done CD-ROM based applications, so his library code for the DB didn't even work when they tested 2 clients, but the bottom line was equivalent to trying to use e.g. the biggest baddest version of Oracle to implement a Google scale internet search engine).
coffeemug 17y ago
I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship After some years of this mindset I finally realized that the proportion of excellent people to mediocre ones is roughly the same in every profession. I no longer draw the lines between "hackers" and "suits" (a kindergarden attitude, really), but between excellent people and mediocre people. It's liberating. You can go into any profession with this mindset and it will be your own personal playground.
deleted 17y ago
[deleted]
j_baker 17y ago
I think that we need to consider the scale of the organization you're going to work for. Are you going to find a "software architect" in a five-person startup? If you do, you should run far, far away. On the other hand, a larger organization with lots of different teams probably has a valid need for someone to bring in cohesion.
blasdel 17y ago
I have only found one Software Architect truly worthy of the title: Roy Fielding (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) If you're doing anything Prescriptive, you're really doing design, for better or worse. Software Architecture is properly Descriptive -- it's an explanation of how a system works, and how to make your work fit its structure. It's not something you should ever be doing up front. The GoF had a good idea to describe software in Alexanderian patterns, but they didn't really understand why and for whom his pattern system was designed, and then they fucked up the implementation in the extreme.

47 points by smikhanov 17y ago

modoc 17y ago

As a software architect for the last ~10 years I have to disagree. His point seems to be that if you get a job as a software architect you'll end doing nothing but meetings and creating UML diagrams. I'm sure there are places like that, I've worked at one (Rational Process - shudder), but there are many places where they need someone who can provide architect level application design, who can see the forest through the trees, who can balance the needs of the business, the 3rd party integrations, and the technology. My current contract role has me providing architecture (usually just a 1-2 page design doc, not often UML), mentorship, and coding some of the trickier stuff. I still code a lot, but I also have responsibility over the whole software ecosystem and hence some power to decide how things go. I mentor developers, perform code reviews, and work on process improvement too. It's a great role.

smikhanov 17y ago
I'm sure there are places like that, I've worked at one (Rational Process - shudder) Thank you for your honesty :) The bottom line of my post was "beware of the advertise SA positions, they tend not to offer what is usually expected from an advanced position like that". I also think that a key to being a good SA is to keep writing code, no matter what happens. Looks like this is exactly the case for you.
- modoc 17y ago
  I absolutely agree that if you like coding, don't ever stop. It will also make you a better architect. In my experience, large companies who use Rational will have their architects buried in Rose building UML and writing 150+ page docs all day. Smaller and/or agile/XP companies will be looking for a super experienced coder, who can mentor, and look at the big picture, see the business drivers, etc... Ideally this sort of thing can be figured out early on in the interview process. "How do your other architects spend their time?" etc...
  - hga 17y ago
    Hmmm ... I think you can do both. I used OOSE (from the book, the cut down version of Objectory (prior to it becoming the Rational Process)) in a project ... but it was just me and a bright newbie almost right out of college, with someone added for a last feature. It worked fantastically well, e.g. I had to stop working on the project for a few weeks to attend to the prototype (that I'd hacked up in in a 6 week burnout), and when I came back the newbie had neatly iterated the design and was able to slip right back into coding with no fuss. By the end of the project my estimates for how long to finish a unit of work were accurate to 30 minutes (by then I'd been programming for two decades, so it wasn't all the process!). On the other hand, I wonder if Objectory/OOSE/Rational Process solves the wrong problem. If you're going to use imperative OO to build a big complex system, yea ... but maybe you should try e.g. functional programming. I.e. the other relevant development that came out of Ericsson was Erlang and was for the same problem space (e.g. telephone switches). Still, I feel that if you use parts of it correctly for the right sorts of problems (especially ones that are pretty well understood, e.g. I'd been figuring out for 5 years how to do my project correctly before I had a chance to do it as detailed above) it can be very useful.
    - hga 17y ago
      CORRECTION: the newbie had neatly iterated the design and I was able to slip right back into coding with no fuss
hello_moto 17y ago
There should be more people like you. The biggest problem in our industry is that there isn't enough mentors to tell the young people that they were wrong all this time.
- modoc 17y ago
  :) I think the biggest problem in the industry is that many of the "young people" (I'm still young, dammit!) don't really want to learn or be mentored. Seems like there's a slew of folks in the junior to mid-level developer arena who got into CS because it was going to make them a lot of money, not because they love to code. I love it when I'm working with people who love to tinker with new libraries and APIs, who are working on something neat in their spare time, etc... They make much better developers than folks with a CS degree who do what's assigned to them from 9-5 and that's it. I'm not saying you have to work a ton, but just be interested in the whole tech universe:)
  - meta 17y ago
    As best as possible, I think a company should screen for that in the Interviews. (given that Interviews are sometimes a effectiveness gamble, I realize that it can be difficult to screen for that). I usually watch to see if they light up and get into conversations when I ask questions in the Interview related to our tech. If they don't get that expression and interest (hard to qualify but I think most people know what I am talking about) than that is a lot of hire points lost. If you spend an hour talking computers and they never 'light up', I feel, they are probably not the right fit.
  - jerf 17y ago
    I blame the myth that young hackers are somehow strangely more knowledgeable than their elders because of the putatively ever-changing nature of technology. I've always been suspicious of this self-serving narrative (in what other engineering field is this true?), but as I approach what passes for Old Fartness in this industry (30) now I know it's bullshit. All the twenty-year-old whizzes I know are experts at taking something like Ruby on Rails, trading in the quality of the underlying framework to put together a hack-job very quickly, and then promptly getting themselves stuck in a morass that they can't get out of because they don't even understand why they are in a morass. Hand these people something with a lot of technical assets they can borrow against and yeah, they can toss something together fast, but that's hardly "better" then what I can do now, which is actually produce technical value. (Mind you, I'm not saying that's necessarily a bad thing. There's a time and a place for that. What is a bad thing is that the developer won't understand the tradeoffs they just made, and probably didn't make the tradeoff after a sober and careful balancing of the costs and benefits, but did it because it's all they know.) Anyhow, my point is that thanks to that mythology, a lot of younger people don't think they can be mentored by the old farts they think know nothing in this rapidly changing technical environments. The old farts (at least the ones who have ten years of experience and not one year of experience ten times) have learned that frankly, the tech world isn't changing that fast (different languages, different APIs, pretty much the same messes). There's plenty of mentoring to be done, but you gotta accept that the mentors are going to tell you some things that may shattered your treasured conceptions of the programming world....
bmelton 17y ago
I'm in almost the exact same boat, though I find that much of my job is in just predicting pitfalls, and in anticipating when things won't work. As a federal contractor for an agency that prefers to use COTS/GOTS software, there is a surprisingly great need for having a developer that can look at a given piece of software, intuit how it works, probe its sales and development teams to say "Well, this claims to do Kerberos authentication, but it really does GSSAPI, and hence, won't work with your existing OpenSSO implementation." I also code a lot, mentor other developers, etc., and yes, it IS a great role.
japherwocky 17y ago
This is much closer to the role a real architect plays in a real architecture firm. Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.

gaius 17y ago

Good systems architecture is crucially important - which is why it should only be done by people who know they can get called at 3AM when it all goes hatstand. Not the sorts who wave their hands and draw nonsense diagrams on a whiteboard and chuck something that cannot work, ever over the fence to the implementation team and blame their skills when the project fails.

lucifer 17y ago

The practice of architecture is inevitably entangled with one or more notational and representational systems. This is true if you are architecting ships, infrastructure, buildings, or software. Complaining about UML is like complaining about drafting, drafting notation standards, and CAD software.

blasdel 17y ago
It's more like there's only one drafting standard, and it was built by and for the Soviets in the 70s.

delano 17y ago

Programmers often neglect the fact that not all problems need to be solved with more code. More specifically, there are problems that are better solved at the architecture level. For example, rather than queue jobs in a wonky static variable, use RabbitMQ or Redis. And instead of implementing search functionality through Hibernate, consider a separate stack which you can grow independently of your core application. While you're at it, consider using Solr instead. I'm not justifying the term software architect (I don't like it for other reasons), I'm simply suggesting that if your infrastructure consists of a single, monolithic application, you need to consider solving some of those problems outside of your code.

smikhanov 17y ago
I'm not justifying the term software architect (I don't like it for other reasons) What are your reasons, BTW?
- arethuza 17y ago
  One reason might be that "real" architects get a bit upset at the use of it in the software world.
  - modoc 17y ago
    Haha yeah everyone thinks I build houses because I'm an "architect" and a "contractor".
- japherwocky 17y ago
  As someone who went through Real Architecture school, I find most software architects don't deserve the title. Architecture school is very hard, mentally and physically. The perk is the weird mystique that society gives us.
  - hga 17y ago
    Hmmm, ignoring the school part, have you found some "software architects" worthy of the title? I know you say that implicitly, but I wanted to make sure and perhaps have you elaborate a bit on what distinguishes them.

arethuza 17y ago

I tend to believe that the job of an architect is not to make the important decisions but to make sure the important decisions get made correctly and to take responsibility for that process and its results.

smikhanov 17y ago
This blurs into my vision of top-notch software engineer without the fancy title, which was the reason I wrote that post in the first place.
- arethuza 17y ago
  In my experience the title is really there to identify who will get shot if the damned thing doesn't work for fundamental technical reasons.
  - Luyt 17y ago
    The developers, who failed to glue the mandated technology together, probably will be blamed ;-)
Maro 17y ago
Isn't that the job of a manager: delegate the technical decisions to the best and brightest teammates? I would think the software architect is the "default" choice.

drtse4 17y ago

Fancy job titles and funny job descriptions aside, i always thought that the ability to perform critical architecture related decisions is something that every developer should some day achieve, making this "software architect" as a natural step of the evolution of every developer. And regarding UML, having seen it misused and misunderstood a lot of times, it's just a tool, the same ideas can be expressed with other means, what counts is that the content is clearly explained and correctly understood.

smikhanov 17y ago
As I'm saying in the neighbour thread, this was the reason why I wrote this post in the first place. Something like "hackers, don't be lured by fancy architect job, just master your own craft, this is more valuable".

Silhouette 17y ago

It seems to me that the biggest problem is not software architecture per se, it's when you have a software architect who thinks they are automatically senior to other members of the team. Software architects are (or at least, IMHO, should be) co-ordinators, not directors/dictators. Of course architects need to be technically strong, because they need to be working with the team leads responsible for each part of the software project. That means they need to be able to communicate effectively with those leads and understand the technical implications of what is being said. But it's a two-way street, and both the team leads and the architects have their own role to play. The team lead needs to be more aware of the finer details going on in their area of the project. The architect doesn't need to know those things, but does need to be aware of how everything fits together. That includes knowing enough about what each individual team is doing to identify areas where something new would be useful, or where multiple teams are doing the same thing and there is redundancy that could be eliminated. Ultimately, it's all about collaboration. A software architect who only draws diagrams and produces hundred-page design documents probably isn't very useful. A software architect who talks to business leaders to clarify the requirements, liaises between the various development teams to make sure that they collectively meet those requirements, keeps an eye on testing and on bug reports coming in from the field, and so on, is pretty much essential to building large software systems successfully IME. (Edit: I realise that my final description there was rather broad, and has some overlap with management responsibilities. Realistically, I think a software architect is going to have an element of that as part of their role, just as team leads do within their particular areas. But both are primarily technical roles.)

j_baker 17y ago
Agree. Nothing is worse than an architect who's a closet manager.
- joezydeco 17y ago
  I'll tell you what's worse: an architect that has no experience in your product field. I'm currently in an embedded systems company where the chief architect came from a server-design group. So now everything we do looks like a server. It's awful on multiple levels.

hga 17y ago

One detail from the Antipatterns book: They claim that only about 1 out of 5 programmers "get" abstraction. To the extent this is true (and it agrees with my experience in the field starting in 1977 including a dozen years in and around MIT) you can't have "democratic" design processes, for the "software architects" who do get abstraction will be voted down and you'll end up with the usual mess of spaghetti (or whatever they're calling it nowadays). Hmmm ... another problem I ran into was understanding scaling, O(whatever) issues. At least one project I declined to join died horribly because the people in it couldn't grok that their design wouldn't scale to the level needed for basic customers, let alone big ones (in this case the lead had only done CD-ROM based applications, so his library code for the DB didn't even work when they tested 2 clients, but the bottom line was equivalent to trying to use e.g. the biggest baddest version of Oracle to implement a Google scale internet search engine).

coffeemug 17y ago

I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship After some years of this mindset I finally realized that the proportion of excellent people to mediocre ones is roughly the same in every profession. I no longer draw the lines between "hackers" and "suits" (a kindergarden attitude, really), but between excellent people and mediocre people. It's liberating. You can go into any profession with this mindset and it will be your own personal playground.

deleted 17y ago

[deleted]

j_baker 17y ago

I think that we need to consider the scale of the organization you're going to work for. Are you going to find a "software architect" in a five-person startup? If you do, you should run far, far away. On the other hand, a larger organization with lots of different teams probably has a valid need for someone to bring in cohesion.

blasdel 17y ago

I have only found one Software Architect truly worthy of the title: Roy Fielding (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) If you're doing anything Prescriptive, you're really doing design, for better or worse. Software Architecture is properly Descriptive -- it's an explanation of how a system works, and how to make your work fit its structure. It's not something you should ever be doing up front. The GoF had a good idea to describe software in Alexanderian patterns, but they didn't really understand why and for whom his pattern system was designed, and then they fucked up the implementation in the extreme.