What is implicit in the SA role is that the rest of the dev team is full of dummies that can't think strategically or architect big parts of the system.
This naturally leads to the SA producing ever higher and more complicated abstractions that the simian developer tries to implement, poorly, and the SA becomes an irreplaceable high priest -- inflating their salaries and prominence and depressing the salaries of the rest of the team.
Where I work, every developer is expected to be "architect-quality". Sure, more junior folks don't have the experience, but they're expected to have the capacity for strategic, high-level thinking. As they mature, they take on more and more architectural decisions. If they can't do that, then we've hired the wrong person.
Ultimately, that's the only way I know how to scale dev teams and produce amazing software. The SA/Dev stratification is an anti-pattern.
This may be terminology. Chris' blog post clearly was attacking that part of the problem.
The issue is that many people put 'architect' in a slot over 'developer' and that is wrong, it should be a slot beside 'developer.' I've interviewed lots of folks who said "I want to be an Architect!" and asked them what they thought that meant. Far too many of them it was some sort of 'decision maker without deliverables' kind of job (who wouldn't like that). But that isn't what architecture is about, it's about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'
When Sun was merging SunOS and System V we dealt with "Systems Engineers" from AT&T who were writing "Requirements Documents" but they had no clue how those requirements were affecting the underlying system. Most of the folks at Sun held them in great disdain, and their coders were not "allowed" to decide issues on the requirements. That was both sad and dysfunctional.
The trick is that some people are better at seeing the trees, and others are better at seeing the forest, and a few can both see the forest and point out which trees are out of place. Cultivating all of them for your team is a good idea, the product will be better for it.
While every member of the team may be capable of strategic thinking in general, not every member of the team actually has sufficient domain knowledge to chart everything out.
Building some data link avionics software that needs to be DO-178B Level C compliant and operate within the parameters specified by the EuroControl Link 2000+ initiative? Not every hacker off the street will be able to come up to speed on the implications of all of that in short order. Someone with fifteen years experience in the same or similar technologies will be able to plan the system and guide the more novice programmers.
But it likely depends on what software you're building. If you're building web applications that cull together lots of common-knowledge ideas, then having an experienced individual plan it out for you might not be as needful.
I don't dislike Software Architects (I've only worked with actually brilliant people with the SA title), but I think there's a strong truth to this:
"The SA/Dev stratification is an anti-pattern."
A good architecture is a good high level organization of the code. To be a good architect, you have to be a good developer. And you cannot be a good developer without being good at software architecture. So as far as I can tell, the only actual reason for the SA/Dev divide is to have titles to give to people. Titles are essentially something an organization gives to people in order to keep them happy. And to me, "architect" seems like a fancier title than "developer", if only to sound better to strangers at a party.
I'd like to hear people's opinion of this. In my organization, there are two career paths, one for "architects" and one for "system developers". They are presented as equally valuable roles. Are they actually distinct roles, or only a useful invention for the organization? Moreover, is this distinction actually valuable?
Although I agree with your strategy of hiring, it sounds like what you are saying is "hiring non architect-quality people is an antipattern". Okay, well obviously bad developers make a bad team.
Even on a good team, there are more and less experienced developers. I don't see what's wrong with calling the most experienced ones "architects" if that's what they want to be called, as long as it's clear that it isn't an excuse for the other developers to ignore higher level goals and design.
It's a role that any senior engineer should be able to take. And yes, every senior engineer should be architect-quality, but in some projects, it's useful to ensure that at least one person is tasked with the sole role of keeping an eye on the system as a whole, able to keep the entire platform in their head, and do the dirty work of documenting and cleaning up rough edges. In some cases, the architect can blaze the trail ahead a bit so that everyone else can focus on shipping code, rather than spinning wheels evaluating technical options.
If possible, it's a rotating role, with each senior engineering having to do duty as an architect just as he or she would do duty on devops.
Maybe you're working on a project that doesn't need that level of overhead. Maybe it's small enough and the system is simple enough. But at some level, the amount of architectural work becomes big enough that its worthwhile having someone on it fulltime.
"What is implicit in the SA role is that the rest of the dev team is full of dummies that can't think strategically or architect big parts of the system."
The IQ of a team is equal to the IQ of its dullest member divided by the number of members. Ergo the only way to have good systems architecture is for a handful of smart people to do it. These people are the architects.
The development of the IBM System/360 is a famous example of why this matters. They first tried to design the system by having a few hundred decent engineers do it in distributed fashion. The resulting design was so poor it had to be thrown away. The second try had a small team of architects plan the system while everybody else sat on their hands. It worked spectacularly well.
P.S. If you think this does not apply to you, there is a good chance you have delegated a lot of your system architecture to small outside teams. You do not need your own data access architect if you are using, say, PostgreSQL.
The "writes code" part is key to actually using software architects productively.
The times I have seen architects be productive additions it was essentially a job title for "a super-senior-developer who interacts with everyone." The times I have seen an architect be unproductive or a hinderance it was a job title for "someone who spends all their time telling other people how to code." I've even seen architects who were never coders: since I believe high-level design decisions are intimately linked to low-level design decisions the idea baffles me.
I agree. Reading through the comments I see that many people say that every develop should be an architect. Although I agree that developers should be able to think in terms of the larger picture, in my experience, certain developers either have more experience or are more capable of seeing how things fit together.
Some developers are better at the micro, others at the macro, and ideally you'll have one or two that can do both well. Personally I think it is good to have somebody who can work across teams and software areas to keep track of the bigger picture.
I'd much rather have a team full of A-type engineers that will stop at nothing to force their individual vision into a project.
We can trust that every top-notch developer has the whole project's welfare at heart, and not just the part that they own and whose success impacts their performance evaluation. Ergo, a totally flat team of aggressive rock-star engineers is destined to build their constituent parts in a homogeneous and consistent fashion.
A team of engineering ninjas are bound by a higher power to perfectly coordinate their coding style, core patterns, API design, conventions vs configuration trade offs, third-party dependencies, feature preference, etc., in a way that resonates precisely with the needs of the business and the risks of the industry.
In short, all world-class engineers are business-savvy, have no conflicting interests, never have unresolved disagreements, and are also telepathic. And since all the engineers I work with are obviously world-class engineers, having a single point of accountability and a single vision of quality around is an insulting slap in the face!
This is brilliant sarcasm! I have worked with several of these A-List teams / "democracies". They are a perfect storm of nothing ever getting done because agreements cannot be made on a single issue.
I've worked in places where "architect" was nothing more than a title given to senior developers to soothe their egos so they didn't notice they were underpaid. I've all seen architects who didn't code, preferring their ivory towers of UML diagrams. Neither of these types are effective.
A real software architect is a force multiplier: you help teams be more productive through your contributions, be it design, code, mentoring or leadership. Rather than being the team showboat, a good architect is the guy that helps everyone else be even better at their jobs.
I see lots of vitriol here. I think there are a lot of bad experiences, probably I imagine from the ivory tower architects that you get from big consultancies and the like.
I am a proper solution architect. I'm there to serve others with my extensive experience, nothing more. I am always there in the shadows to keep the cogs oiled, provide canned and well tested ideas, stop things that shouldn't happen, start things that should, make sure communication is made and most importantly spend time teaching and helping people. I'm also there to do the risky horrible jobs that no one else wants to be responsible for.
You're supposed to be more a spiritual guide than a facist dictator.
I will say that there is no place for me in an organisation with less than 10 hands on engineering staff.
Reading throught the comments, it's amazing to see how much damage the cowboy culture of our community has produced. "Every engineer should be an architect." Ha, ha, ha...
This also goes hand-in-hand with "Everyone can be a programmer" mantra that everyone likes to repeat. Go teach pointers to 20-year olds and you'll realize how most people can't be programmers.
I don't understand where this culture is coming from. I definitely can't fix my car; when I see my mechanic, he doesn't tell me how I should go learn how to fix my car. I'm confident he's much better at fixing my car than I am. The same is true with other professions -- lawyers don't tell clients to go interpret laws on their own and dentists don't tell people to go remove teeth on their own. What is it about our community that we ingrained into our youth that "writing code" is the thing that everybody must do?
I don't get the hate for software architects. Would you try to build a skyscraper without an architect? No? Then why is having one a problem for a large software system?
Sure, if you're building something small, one person can be architect and general contractor and electrician and painter, etc. But the idea of division of labor is usually seen as a good thing. Not sure why we hackers should see it any differently. If you're building enterprise software systems that span multiple divisions and locations of an enterprise with 30,000+ people in 100 countries, ya know... you probably do need somebody who's job is to look at the big picture, see that the pieces being assembled fit the needs of the firm, and that the pieces work together in a clean and elegant way.
Having an architect, where needed, doesn't denigrate or devalue the role of the developers at all. It really is a different role that needs to be filled.
Division of "labor" is counter productive in development, because in immortal words of Jack W. Reeves, "Code is Design." Say anything else (UML) and you're deluding yourself. So non-coding architects are effectively only HALF-designing the system.
The problem with non-coding architects is that they are isolatedfromlearning. They have an incomplete feedback loop, and are isolated from the repercussions of their decisions. This at first makes a non-coding architect useless and then makes him actively wrong. This is especially true in systems as complex as enterprise systems.
Because code is design and because building the design is free (in comparison to building a bridge), you need to actually translate your mental design into the real blueprint--the code. If you are isolated from that, then it's like sketching blueprints. You may be consistently wrong on some aspect of it, but you'll never know.
If skyscrapers could be built and torn down overnight, I bet you money architects would build the skyscrapers without the same rigor of blueprints, look at the result and say "Nah, move this a foot over!" and build again.
The correct equivalent for building construction workers is the compiler.
Probably because the number of people with "software architect" on their business cards greatly outnumber the number of "enterprise software systems that span multiple divisions and locations of an enterprise with 30,000+ people in 100 countries".
It's the 95% of useless bureaucrats that can't tell good working software from a print out of a diagram most developers have a problem with.
Anybody fairly handy can build a garden shed. If someone showed up calling themselves an "garden shed architect" and stood off to the side directing traffic I'm sure the "builders" would find it and them to be a complete waste of space. (wait cheesy pun alert?)
However, how many of us would like to get into an elevator ready to shot us to the 100th floor knowing that there was no architect on the project as all the builders decided that was an unnecessary title and those functions could easily be handled by the GC?
Amazon, Heroku etc has made it much easier to build garden sheds - there's a lot more garden sheds around per large building than there used to be. So I suspect if you believe the SA title to be completely unnecessary it's most likely because you're building sheds not buildings. Doesn't mean we still don't want and need them for those larger buildings.
But there is a difference between software construction and building construction.
The difference is that for software, anything that would normally be "construction work" in another field is or can be done in an automated fashion. Thus it can be argued that all programming is done at the "design" or the "architecture" level. That isn't to be say that the software architect position is alway illegitimate. But gives one an idea why, in contrast to sky-scraper construction, some people might legitimately want to dispense with architect as a distinct position.
AND the SA holds an overall vision of what that accounting entails. An "obvious" change in module A may have severe repercussions in module B, which neither developers for A nor B may see in a timely manner. Without "code accounting" with a vision - and an informed experienced one at that - 'tis too easy for over-confident short-sighted developers to go crashing through other sections of code, leaving something which may work but degrades performance & maintenance, and which is so pervasive and hard to fix the team must just live with it.
AND the holder of that vision must be able to articulate it, in documentation & code & conversation, in a manner which keeps the team cohesive, informed, and upbeat.
The definition of a software architect varies. In general, mainly refers to those that are responsible for the higher level design of systems.
In my opinion, a great system architect is a great developer, who also have an artistic flair. Those people that, when facing difficult design problems, can often come up with brilliant abstractions. That are so clever, that feel like art. Not only in development, but also in related aspects, like UI.
Those great abstractions will increase the productivity of everyone using the system, and in the end can accumulate to very high amounts of value.
It is the sole source I've ever encountered that had anything useful, actionable, insightful, informative, rigorous, etc.
Alas, I've never been able to synthesis Design Rules' methodology into any of my efforts.
Because what I do is software craftsmanship. I've designed some awesome stuff (and a lot of crap). But nothing rigorous, repeatable, explainable.
For a few years, I bought every software design book I could find. Some of them actually good. But the ones claiming to be about "software architecture" are really describing software craftsmanship. Describe as in descriptive, vs prescriptive.
From memory, Design Rules states that architecture is the set of visible design choices in a product. The entire thesis of the book, backed by oodles of case studies and data, is that deciding where the lines between subsystems, the interfaces, and the allowable parameters for those interfaces, is architecture.
PS- Just read the OP. Nothing actionable. Move along.
The name plate on my desk says "Software Architect", and honestly I feel kind of silly repeating that when people ask what I do. I usually just tell them 'I write software'. That said, I've worked in a bunch of different C#/.Net/SQL Server shops (IT depts, educational, shrink wrap apps, advertising), and I can see in some of these places why the role can be necessary. Not because .Net demands these over-architected enterprise uber-solutions, but because a large amount of developers in those places just don't seem to care about what technology choices and design methodologies are out there. And there's nothing wrong with that, so long as there are some there who are thinking beyond the next sprint, regardless of what their job title is officially.
I'm also pretty sure the role itself means different things depending on the scale of what the company is doing. At my current job (a recruitment advertising company w/ some very large clients), we have a lot of traffic and only moderate development resources in-house, so you really need to depend on proven technologies to prevent the whole thing from falling apart. So part of my job is making sure we are using the right technology where we need to and only rolling our own when it makes sense.
Agree with everything he says. Except for the part that I don't.
A software architect creates a vocabulary to enable efficient communication across an entire company.
That needs to be done with caution, because in a small team/organisation it's absolutely correct. In a large organisation it's just a non-confrontational way of saying "We need an enterprise architecture." That ends up becoming an IT dictionary whose value is to IT alone [1]. And IT serves the business. Not the other way 'round.
If you're doing this in a large organisation, do it for a project, and not for the organisation. It's right up there with the architect that sees an enterprise service bus as a silver bullet. Aka a unicorn.
Edit:
[1] Unless you're HP Services, IBM, ATOS, Cap Gemini or some similar systems integrator, because if you're one of them you're in the business of selling billable hours, and an enterprise architecture is an awesome way of billing to eternity without even having to deliver business value.
This is a nice ideal to have. Unfortunately I have never had the pleasure of working with the architect the OP described. I would say the ones I've dealt with have had some combination of: arrogance, stupidity, lack of technical knowledge, lack of creativity, and arrogance (did I say that already).
A software architect job is about interfaces between modules. An architect job is to design interfaces that are aligned with the product direction and technical capabilities (both of the product and the people developing it) and tell a consistent story, both syntactically as well as semantically.
Without such a person, each pair of developers, no matter how good an engineers they are, will have to develop their own language that is bound not to match those that are developed around it. This adds to the burden of each developer as he (or she) has to use APIs developed by different such teams. Consistency is key.
Because the architect has to see the big picture to do his job, it makes sense that he's also the look-ahead guy. Because he defines interfaces and modules, it makes sense that he gets to evaluate new technologies - so playing with rabbitMQ really is part of the job description.
This kind of job tend to require a working knowledge of the product internal, otherwise APIs can get completely incompatible with capabilities. As such, it attracts good developers that also think "strategically". Because many architect still love the code, you usually see such a person wearing two hats - the classic architect one but also the "lead developer" one - so code reviews, cleanup work and super important (but small) modules tend to be part the architect work, even if not in the job description.
Lastly, the architect must have soft skills. The job requires a lot of human interaction, considerably more than a developer job does. It also requires a much closer interaction with "management", the architect understands the aforementioned big picture.
Is the architect "better" than any developer? No. It's a complimentary role. Is this role always needed? No, but as a project gets bigger and start having more modules, interfaces tend to get hairy without a guiding hand. So why do architects make more? Supply and demand. Not everyone has the ability or the will to think "big picture" all the time. It's tiring, it's complex and you tend to think about balances (how will this affect the future? How much risk? How many man-hours? What's the alternative? How to phase development?) instead of "code purity".
Disclaimer: I'm an architect but I also do a lot of "lead developer" parts. And while the definition tends to get fuzzy around the edges (and some interfaces are made ad-hoc, without that guiding hand), I see the best results when I follow the above recipe (which, sadly, means a lot less coding than I actually like to do).
TL;DR: architecture is about interfaces between modules, not content of each module. Usually architects also wear "lead dev" hat because they like it.
A software architect I worked with before thought he was gods gift to programming, every time something worked out it was his work, when it failed he always blamed the 'process'.
You should change the title to 'Being a Good Software Architect'.
The same could be written of managers and leaders. They exist to serve those they work with, not the other way around. Our society just doesn't seem to understand this.
[+] [-] MattRogish|13 years ago|reply
What is implicit in the SA role is that the rest of the dev team is full of dummies that can't think strategically or architect big parts of the system.
This naturally leads to the SA producing ever higher and more complicated abstractions that the simian developer tries to implement, poorly, and the SA becomes an irreplaceable high priest -- inflating their salaries and prominence and depressing the salaries of the rest of the team.
Where I work, every developer is expected to be "architect-quality". Sure, more junior folks don't have the experience, but they're expected to have the capacity for strategic, high-level thinking. As they mature, they take on more and more architectural decisions. If they can't do that, then we've hired the wrong person.
Ultimately, that's the only way I know how to scale dev teams and produce amazing software. The SA/Dev stratification is an anti-pattern.
[+] [-] ChuckMcM|13 years ago|reply
The issue is that many people put 'architect' in a slot over 'developer' and that is wrong, it should be a slot beside 'developer.' I've interviewed lots of folks who said "I want to be an Architect!" and asked them what they thought that meant. Far too many of them it was some sort of 'decision maker without deliverables' kind of job (who wouldn't like that). But that isn't what architecture is about, it's about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'
When Sun was merging SunOS and System V we dealt with "Systems Engineers" from AT&T who were writing "Requirements Documents" but they had no clue how those requirements were affecting the underlying system. Most of the folks at Sun held them in great disdain, and their coders were not "allowed" to decide issues on the requirements. That was both sad and dysfunctional.
The trick is that some people are better at seeing the trees, and others are better at seeing the forest, and a few can both see the forest and point out which trees are out of place. Cultivating all of them for your team is a good idea, the product will be better for it.
[+] [-] tjr|13 years ago|reply
While every member of the team may be capable of strategic thinking in general, not every member of the team actually has sufficient domain knowledge to chart everything out.
Building some data link avionics software that needs to be DO-178B Level C compliant and operate within the parameters specified by the EuroControl Link 2000+ initiative? Not every hacker off the street will be able to come up to speed on the implications of all of that in short order. Someone with fifteen years experience in the same or similar technologies will be able to plan the system and guide the more novice programmers.
But it likely depends on what software you're building. If you're building web applications that cull together lots of common-knowledge ideas, then having an experienced individual plan it out for you might not be as needful.
[+] [-] lars|13 years ago|reply
"The SA/Dev stratification is an anti-pattern."
A good architecture is a good high level organization of the code. To be a good architect, you have to be a good developer. And you cannot be a good developer without being good at software architecture. So as far as I can tell, the only actual reason for the SA/Dev divide is to have titles to give to people. Titles are essentially something an organization gives to people in order to keep them happy. And to me, "architect" seems like a fancier title than "developer", if only to sound better to strangers at a party.
I'd like to hear people's opinion of this. In my organization, there are two career paths, one for "architects" and one for "system developers". They are presented as equally valuable roles. Are they actually distinct roles, or only a useful invention for the organization? Moreover, is this distinction actually valuable?
[+] [-] FourthProtocol|13 years ago|reply
What I'm talking about are the soft skills - stakeholder management, risk management, conflict management, politics, negotiation, and so on.
There's an overview here: http://wwww.wittenburg.co.uk/Presentations.aspx
You don't need to be "an architect" to be good at these things, but an architect should be good at these things.
Not having or even wanting these skills is not a bad thing, it's just that we're different, and good at different things.
[+] [-] dack|13 years ago|reply
Even on a good team, there are more and less experienced developers. I don't see what's wrong with calling the most experienced ones "architects" if that's what they want to be called, as long as it's clear that it isn't an excuse for the other developers to ignore higher level goals and design.
[+] [-] jaaron|13 years ago|reply
If possible, it's a rotating role, with each senior engineering having to do duty as an architect just as he or she would do duty on devops.
Maybe you're working on a project that doesn't need that level of overhead. Maybe it's small enough and the system is simple enough. But at some level, the amount of architectural work becomes big enough that its worthwhile having someone on it fulltime.
[+] [-] alttab|13 years ago|reply
In my mind, the role of a SA is to make the right decisions until everyone else can do it on their own, but enable and teach along the way.
* spelling
[+] [-] Ingaz|13 years ago|reply
Even more - I hate this title.
And I'm a SA at my current employer.
But Chris talk about right SAs - programmers with strategic thinking responsible for architectural decisions.
[+] [-] jwr|13 years ago|reply
[+] [-] chriseppstein|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] Daniel_Newby|13 years ago|reply
The IQ of a team is equal to the IQ of its dullest member divided by the number of members. Ergo the only way to have good systems architecture is for a handful of smart people to do it. These people are the architects.
The development of the IBM System/360 is a famous example of why this matters. They first tried to design the system by having a few hundred decent engineers do it in distributed fashion. The resulting design was so poor it had to be thrown away. The second try had a small team of architects plan the system while everybody else sat on their hands. It worked spectacularly well.
P.S. If you think this does not apply to you, there is a good chance you have delegated a lot of your system architecture to small outside teams. You do not need your own data access architect if you are using, say, PostgreSQL.
[+] [-] roguecoder|13 years ago|reply
The times I have seen architects be productive additions it was essentially a job title for "a super-senior-developer who interacts with everyone." The times I have seen an architect be unproductive or a hinderance it was a job title for "someone who spends all their time telling other people how to code." I've even seen architects who were never coders: since I believe high-level design decisions are intimately linked to low-level design decisions the idea baffles me.
[+] [-] jonstjohn|13 years ago|reply
Some developers are better at the micro, others at the macro, and ideally you'll have one or two that can do both well. Personally I think it is good to have somebody who can work across teams and software areas to keep track of the bigger picture.
[+] [-] mcgwiz|13 years ago|reply
I'd much rather have a team full of A-type engineers that will stop at nothing to force their individual vision into a project.
We can trust that every top-notch developer has the whole project's welfare at heart, and not just the part that they own and whose success impacts their performance evaluation. Ergo, a totally flat team of aggressive rock-star engineers is destined to build their constituent parts in a homogeneous and consistent fashion.
A team of engineering ninjas are bound by a higher power to perfectly coordinate their coding style, core patterns, API design, conventions vs configuration trade offs, third-party dependencies, feature preference, etc., in a way that resonates precisely with the needs of the business and the risks of the industry.
In short, all world-class engineers are business-savvy, have no conflicting interests, never have unresolved disagreements, and are also telepathic. And since all the engineers I work with are obviously world-class engineers, having a single point of accountability and a single vision of quality around is an insulting slap in the face!
[+] [-] imechura|13 years ago|reply
[+] [-] NiteCoder|13 years ago|reply
A real software architect is a force multiplier: you help teams be more productive through your contributions, be it design, code, mentoring or leadership. Rather than being the team showboat, a good architect is the guy that helps everyone else be even better at their jobs.
[+] [-] gouranga|13 years ago|reply
I am a proper solution architect. I'm there to serve others with my extensive experience, nothing more. I am always there in the shadows to keep the cogs oiled, provide canned and well tested ideas, stop things that shouldn't happen, start things that should, make sure communication is made and most importantly spend time teaching and helping people. I'm also there to do the risky horrible jobs that no one else wants to be responsible for.
You're supposed to be more a spiritual guide than a facist dictator.
I will say that there is no place for me in an organisation with less than 10 hands on engineering staff.
[+] [-] locacorten|13 years ago|reply
This also goes hand-in-hand with "Everyone can be a programmer" mantra that everyone likes to repeat. Go teach pointers to 20-year olds and you'll realize how most people can't be programmers.
I don't understand where this culture is coming from. I definitely can't fix my car; when I see my mechanic, he doesn't tell me how I should go learn how to fix my car. I'm confident he's much better at fixing my car than I am. The same is true with other professions -- lawyers don't tell clients to go interpret laws on their own and dentists don't tell people to go remove teeth on their own. What is it about our community that we ingrained into our youth that "writing code" is the thing that everybody must do?
[+] [-] mindcrime|13 years ago|reply
Sure, if you're building something small, one person can be architect and general contractor and electrician and painter, etc. But the idea of division of labor is usually seen as a good thing. Not sure why we hackers should see it any differently. If you're building enterprise software systems that span multiple divisions and locations of an enterprise with 30,000+ people in 100 countries, ya know... you probably do need somebody who's job is to look at the big picture, see that the pieces being assembled fit the needs of the firm, and that the pieces work together in a clean and elegant way.
Having an architect, where needed, doesn't denigrate or devalue the role of the developers at all. It really is a different role that needs to be filled.
[+] [-] astral303|13 years ago|reply
Read this article and weep, for it was written in 1992 and 20 years later, is still rings true, even though there was no UML at the time: http://www.developerdotstar.com/mag/articles/reeves_design.h...
The problem with non-coding architects is that they are isolated from learning. They have an incomplete feedback loop, and are isolated from the repercussions of their decisions. This at first makes a non-coding architect useless and then makes him actively wrong. This is especially true in systems as complex as enterprise systems.
Because code is design and because building the design is free (in comparison to building a bridge), you need to actually translate your mental design into the real blueprint--the code. If you are isolated from that, then it's like sketching blueprints. You may be consistently wrong on some aspect of it, but you'll never know.
If skyscrapers could be built and torn down overnight, I bet you money architects would build the skyscrapers without the same rigor of blueprints, look at the result and say "Nah, move this a foot over!" and build again.
The correct equivalent for building construction workers is the compiler.
[+] [-] rickmb|13 years ago|reply
It's the 95% of useless bureaucrats that can't tell good working software from a print out of a diagram most developers have a problem with.
[+] [-] jusben1369|13 years ago|reply
However, how many of us would like to get into an elevator ready to shot us to the 100th floor knowing that there was no architect on the project as all the builders decided that was an unnecessary title and those functions could easily be handled by the GC?
Amazon, Heroku etc has made it much easier to build garden sheds - there's a lot more garden sheds around per large building than there used to be. So I suspect if you believe the SA title to be completely unnecessary it's most likely because you're building sheds not buildings. Doesn't mean we still don't want and need them for those larger buildings.
[+] [-] joe_the_user|13 years ago|reply
But there is a difference between software construction and building construction.
The difference is that for software, anything that would normally be "construction work" in another field is or can be done in an automated fashion. Thus it can be argued that all programming is done at the "design" or the "architecture" level. That isn't to be say that the software architect position is alway illegitimate. But gives one an idea why, in contrast to sky-scraper construction, some people might legitimately want to dispense with architect as a distinct position.
[+] [-] swalsh|13 years ago|reply
[+] [-] ctdonath|13 years ago|reply
AND the SA holds an overall vision of what that accounting entails. An "obvious" change in module A may have severe repercussions in module B, which neither developers for A nor B may see in a timely manner. Without "code accounting" with a vision - and an informed experienced one at that - 'tis too easy for over-confident short-sighted developers to go crashing through other sections of code, leaving something which may work but degrades performance & maintenance, and which is so pervasive and hard to fix the team must just live with it.
AND the holder of that vision must be able to articulate it, in documentation & code & conversation, in a manner which keeps the team cohesive, informed, and upbeat.
[+] [-] chriseppstein|13 years ago|reply
[+] [-] wormphlegm|13 years ago|reply
[+] [-] Spearchucker|13 years ago|reply
[+] [-] nzonbi|13 years ago|reply
In my opinion, a great system architect is a great developer, who also have an artistic flair. Those people that, when facing difficult design problems, can often come up with brilliant abstractions. That are so clever, that feel like art. Not only in development, but also in related aspects, like UI.
Those great abstractions will increase the productivity of everyone using the system, and in the end can accumulate to very high amounts of value.
[+] [-] stephencanon|13 years ago|reply
[+] [-] alttab|13 years ago|reply
This folks!
[+] [-] specialist|13 years ago|reply
I asked Grady Booch "What is software architecture?"
He answered "Software architecture is what software architects 'do'."
At that point I stopped caring.
Until I found the book Design Rules: The Power of Modularity. http://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/0...
It is the sole source I've ever encountered that had anything useful, actionable, insightful, informative, rigorous, etc.
Alas, I've never been able to synthesis Design Rules' methodology into any of my efforts.
Because what I do is software craftsmanship. I've designed some awesome stuff (and a lot of crap). But nothing rigorous, repeatable, explainable.
For a few years, I bought every software design book I could find. Some of them actually good. But the ones claiming to be about "software architecture" are really describing software craftsmanship. Describe as in descriptive, vs prescriptive.
From memory, Design Rules states that architecture is the set of visible design choices in a product. The entire thesis of the book, backed by oodles of case studies and data, is that deciding where the lines between subsystems, the interfaces, and the allowable parameters for those interfaces, is architecture.
PS- Just read the OP. Nothing actionable. Move along.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] dbattaglia|13 years ago|reply
I'm also pretty sure the role itself means different things depending on the scale of what the company is doing. At my current job (a recruitment advertising company w/ some very large clients), we have a lot of traffic and only moderate development resources in-house, so you really need to depend on proven technologies to prevent the whole thing from falling apart. So part of my job is making sure we are using the right technology where we need to and only rolling our own when it makes sense.
[+] [-] Spearchucker|13 years ago|reply
A software architect creates a vocabulary to enable efficient communication across an entire company.
That needs to be done with caution, because in a small team/organisation it's absolutely correct. In a large organisation it's just a non-confrontational way of saying "We need an enterprise architecture." That ends up becoming an IT dictionary whose value is to IT alone [1]. And IT serves the business. Not the other way 'round.
If you're doing this in a large organisation, do it for a project, and not for the organisation. It's right up there with the architect that sees an enterprise service bus as a silver bullet. Aka a unicorn.
Edit: [1] Unless you're HP Services, IBM, ATOS, Cap Gemini or some similar systems integrator, because if you're one of them you're in the business of selling billable hours, and an enterprise architecture is an awesome way of billing to eternity without even having to deliver business value.
[+] [-] sbochins|13 years ago|reply
[+] [-] biroran|13 years ago|reply
Is the architect "better" than any developer? No. It's a complimentary role. Is this role always needed? No, but as a project gets bigger and start having more modules, interfaces tend to get hairy without a guiding hand. So why do architects make more? Supply and demand. Not everyone has the ability or the will to think "big picture" all the time. It's tiring, it's complex and you tend to think about balances (how will this affect the future? How much risk? How many man-hours? What's the alternative? How to phase development?) instead of "code purity".
Disclaimer: I'm an architect but I also do a lot of "lead developer" parts. And while the definition tends to get fuzzy around the edges (and some interfaces are made ad-hoc, without that guiding hand), I see the best results when I follow the above recipe (which, sadly, means a lot less coding than I actually like to do).
TL;DR: architecture is about interfaces between modules, not content of each module. Usually architects also wear "lead dev" hat because they like it.
[+] [-] thatusertwo|13 years ago|reply
You should change the title to 'Being a Good Software Architect'.
[+] [-] leothekim|13 years ago|reply
None of these characteristics should be stuffed in an architect role. Every engineer should possess them.
[+] [-] kylek|13 years ago|reply
[+] [-] cranklin|13 years ago|reply
[+] [-] Produce|13 years ago|reply