There seem to be two camps of thought on whether such a person exists. Some folks view the SystemArchitect or SystemDeveloper as the person with the leading vision, the overall comprehension of how the hardware, software, and network fit together. In past times, this person may have had performed SystemsAnalysis. Nowadays (and on this Wiki especially) though, most folks view software development as a team effort rather than a hierarchical dictatorial process. Everyone becomes JustaProgrammer.

''Or does ''everyone'' become a SystemArchitect?''.

There may also be a difference between the SystemArchitect and a SoftwareArchitect. The latter is responsible for how the objects are developed, the framework for interaction between objects, and the levels of separation and modularity between in-house and vendor-supplied objects. The SystemArchitect, on the other hand, looks at the long term flow of physical architecture and the direction of the industry (databases, networks, processors, frameworks), and attempts to establish guidelines that will enable the developers to create a business solution that will last into the future. -- JeffChapman

''I completely agree with that observation Jeff, at least that's what my job description and title says I'm doing. -- NiclasOlofsson''

Not ok so fast :) What role has the SystemArchitect has in StrategicAlignmentOfItProductsAndServices, and in particular, alignment with Business mission and objectives? I think one needs to know the "real business" of the organization well (e.g. those working for cosmetic company are working in an industry of "hope") to have good contributions in the subject area just mentioned. -- dl

----

What about a ProductArchitect? Someone ultimately responsible for determining the requirements of a product? This is not to say that they should go away, examine their navels; and return with requirements engraved in stone tablets. However, some subset of a design team must be assigned the task of gathering requirements (whether by customer research, NavelExamination, or ConsultingTheWell), and said team probably should have a leader. That person, in my mind, is the ProductArchitect.

The alternative, unless consensus can be reached (and the chances of that are k^n, where 0<k<1 is how agreeable the team members are, and n is the number of members on the team), is to have the project lead become ultimately responsible for the requirements. MythicalManMonth advises against this.

engineer_scotty (ScottJohnson)

----

Okay, here's my two cents. I've been hired as a Unix System Architect, and also a System Architect. Simply put, the architect becomes one with the current system - physical layout, hardware, OS, and software. From that point they then have the ability to integrate new components into the system as needed. Depending on the size of the company, this can be from simply writing a document up (god forbid if that's all you are doing), to buying the hardware, OS, and software needed, "racking and stacking", installing os, software, and tweaking the system. Usually it's somewhere in between with the SA designing the concept, throwing in a wrench as needed, and also a fair amount of work being the conduit that system admins, network admins, programmers and managers communicate through. <-
* I call you an I''''''nfrastructureArchitect, or N''''''etworkArchitect instead of of SystemArchitect :)

Final note, a Software Architect is radically different. This is the person that reads all those painful programming "concept" books, delves into patterns and other "useful" topics and basically tries to maintain the cohesiveness of large programming projects. I usually have the most problems with these types, especially the zealots that treat programming like a religion, and release dictums instead of guiding a team of programmers. I'll qualify that saying I have almost exclusively worked on Internet-based projects and not "MS Word"-like mega-projects. I find in the Internet world, a good quality Team Lead to be much more useful than a Software Architect, and allowing the group of programmers to "evolve" the software...

-- Steven S. Boger
sboger@hotmail.com
----

It seems to me that the non-programmer has a perspective on software as a user that the programmer does not seem to have. 

''This is precisely the argument that Machiavelli used to explain to the Prince how he, Machiavelli, had anything of interest to tell the Prince (in the book of that same title). Since you're taking a Machiavellian stand, you really need to address the many critiques that have been made of Machiavelli, no?''

----
''The main distinction is simply that most programmers don't give a damn about what the public wants, so they don't even try to guess. But you can't generalize from that, because there are '''some''' programmers who do care, and who do hazard guesses, and their track record is probably at least as good as e.g. the average MBA marketing guy who thinks he knows everything but doesn't.''

'''It's the combination of perspectives that makes a project rich and reach success''' (pun intended). 

The Shick metaphor. Remember? The guy who said: "I thought the blades were so good I bought the company". This is truly how things work. I have been trying zillions of tools since 8 months to write a book. I have disliked them all except one. I am damn certain everyone in the world will agree with my choice. That is the software I am trying to build. 

''If you have a good aesthetic then you may be right. The proof of the pudding is in the tasting; we shall see once you're done.''

Programmers rarely put themselves in the skin of users as non-programmers do. Why do you think beta-testers are needed so much? 

''False generalization. Most programmers do not, but also most non-programmers do not. Beta-testers are needed to get a fresh outside perspective; note that it does not suffice for the non-programmers in a company to do beta-testing. This has been tried endlessly, and it does '''not''' constitute beta-testing. It really is important to go outside the company, or at least as far outside the original department as possible, for fresh perspectives.''

''On the other hand, sorry to say, it sometimes fails miserably to have a non-engineer try to direct engineers, because often they literally cannot understand what the issues are. It depends on how technical the task is. Try to have a non-engineer direct the programmers who are working on the software that runs Cisco routers, or that does floorplan layout of the next Intel Pentium, or that computes the flight of the next Mars orbiter: disaster, it's too technical, the non-engineer wouldn't understand a single word of the meetings.''

''It's well known that many composers do not know formal musical notation, and when they want to they can learn it as a separate skill than composing. There is no immediately obvious parallel with programming: if someone knows how to design algorithms, then they always know at least one programming language, even if only an abstract mathematical notation, because otherwise there is no way to express an algorithm. Any way of expressing a programming language could be either called a programming language or actually become a programming language (this is where APL came from; originally it was a purely mathematical notation Iverson invented; something similar has been claimed for Lisp, for that matter).''

----

The ''System Architect'' is the head ''System Engineer'' in the DoD or former CMM sense of ''System Engineer''. He tracks requirements, allocates them to subsystems in hardware, COTS software, new code, and unifies the view of several disciplines. In FEA those include the business view, the project performance view, the data view, the software view and the component service view. In a commercial perspective, it is the network, hardware, product and new code views as well as the business view. The ''System Architect'' thinks about ''alignment'', supporting business goals, BPR, etc. as much or more than software, code or object hierarchies.

I envision my job as freeing you software guys to work.

-- Matt Kern

----

''A big HR realignment later - and I'm now called a Senior Technical Architect.  Interestingly - most of the architects I run into have little practical experience in designing and developing software systems (obvious from some of the designs I see).  My advice to anyone who is in this arena: KeepItSimple.  Concerning the SoftwareArchitect - I've never seen one of those in job title or focus.  By and large, all architects in my company concern themselves with all aspects of a design - from the physical (power/cooling, machine capabilities and other physical plant), network (expected traffic loads and the implications to the network design/modifications), software (functional specification, protocols, expected performance parameters, and tool selection), and operations/maintenance considerations (aspects of the design to make refactoring possible/easy, configurability, human factors considerations etc).  Some do it better than others - and many miss things that should be codified, but aren't.''  -- MalcolmCampbell