views:

1625

answers:

17

I've seen a few posts that briefly touch on the subject but don't address the question directly. So please don't label this as a dup.

Having been independant/freelance for 5 years or so, and having also had plenty of exposure to perm positions, I've been exposed to many views on what an "Architect" really is.

As a result, I've coined the term, "One man's architect is another man's n00b", as it seems to be perpetually relative.

I've interviewed at mom-&-pop shops that didn't think I was worth a hill of beans. I've also interviewed at world-class consulting firms who thought I was incredible. Again, it all seems relative.

But what specifically makes a software architect a true "Architect"?

+28  A: 

Personally I've always viewed a software architect as the designer of an overall (usually large) system, in terms of what components are present and how they fit together.

The term seems to be much derided these days, but I can see it being a valuable role, particularly for large projects. It can avoid everyone doing their own thing in isolation with little idea of how they fit into the big picture.

Jon Skeet
+1  A: 

The way I see it, a software architect spends his time designing, creating and assembling the code that other developers use to implement the actual application. His job is to provide tools and practices that makes those other developers' lives easier, short and long term.

chaos
definitely not. that maybe a tool wizard, but not the architect. I think other responses are much closer to how I perceive the architect position.
MaxVT
Fair enough. I do seem to have a minority interpretation. Let me specify, though, that I mean "tools" in a much more general sense than it means in context of the "tool guy" who says "oh hey, here's your lua scripting engine, enjoy".
chaos
+42  A: 

In my view an Architect must be capable of making decisions that go far beyond programming, such as scale, performance, fault tolerance and deployment strategy (i.e., single or multi tier), interface standards (APIs), testing strategies (specially integration testing). An architect has to have at the same time a deep understanding of programming and development as well as product and system vision.

Otávio Décio
Surely most programmers (or at least senior ones) will know about all of the above? And an architect is just one herding the cats
Chris S
+7  A: 

Dilbert's beat me to all the useful definitions:

http://www.dilbert.com/strips/comic/2008-03-04/

http://blog.miragestudio7.com/2006/04/dilbert-the-architect/

rball
+1 Really funny. Dilbert is the best!
victor hugo
Clearly and without a doubt the most accurate answer here so far...
Jon
+2  A: 

An Architect translates a business requirement into a logical solution. They design the blue-print of the solution, describing what needs to be done and how.

Bhaskar
+1  A: 

Typically the architect is the more experienced person that's able to lead the others to a successful project. They are also should have a closer understanding of the business rules and work with the major stakeholders to flesh out ideas. Those rules and ideas then are then built around the knowledge of the architect to create the software involved.

rball
+2  A: 

An architect is the guy who says:

  1. Curly braces must be on the same line as the method.
  2. No Hungarian notation even if it makes sense, like when using web controls (txtName, lblName etc..)
  3. Has meetings with people and pretends to know everything.
  4. Defers to senior developers when asked tough questions.
Jack Marchetti
LOL! I think you're thinking of "Egotects", not "Architects". {-o)
Boydski
Those are the only ones I've worked with :)
Jack Marchetti
+20  A: 

I've been the chief software architect of my current company for the past 8 years (since day 1 of the company). This has been my first gig as an architect, and I've kind of learned on the job what an architect is.

At my company, we hire very strong, very senior developers. Nobody here wants an architect that tells them what to do or what to write. My job is to know the product inside and out, and to be involved in the design of all major features. Sometimes I bring ideas to the design meetings. Sometimes my ideas are no good, and they get shot down by the other developers. Frequently, the other developers drive the design, and my job is to make sure their designs will work well. For example, maybe their designs won't perform well, or maybe they will be incompatible with another part of the product, or maybe there is a cheaper-to-implement alternative.

But, frankly, all developers at our company play this same role of bringing ideas to the table and finding flaws in approaches under consideration. The main difference between me and the other developers is that I know the full product better since I've been here from the beginning. In this sense, the Architect title isn't really important. It's all just about experience.

Another key role I have is dealing with customers. When a major customer runs into a technical hurdle with the product, I usually end up on the phone with the customer. This is where the Architect title is really important because the customer gets a sense that we really care about them and are really trying to address their problem when they get to talk directly with the Architect. In this role, communication and people skills are key to being a good Architect. Having a deep understanding of the product is also key here too.

I also do write some code (though not as much as I'd like), and I occasionally get to work on some cool research projects.

Clint Miller
This doesn't sound like a software archetect. This sounds like something else. A valuable position, don't get me wrong, but this sounds like you're designing user features...not how the software will be built.
Beska
Very senior developers should listen to an architect IMHO
victor hugo
Victor, you're hired! :-) Seriously, though, I don't mean to imply the senior developers don't listen to me and that they do whatever they want. Rather, I've got a lot of good ideas and a few lousy ones, and the other developers at my company have a lot of good ideas and a few lousy ones. We all work together to make sure the lousy ideas get weeded out and that the best ideas are implemented. A key job of the architect is to facilitate this communication, and to make sure it happens productively and with mutual respect.
Clint Miller
+8  A: 

G'day,

Software Architects are advocates for the design and the customer. They are the bridge between the builders (developers) and the customer.

I'd highly recommend Marc and Laura Sewell's excellent book "The Software Architect's Profession: An Introduction" (sanitised Amazon link) which is a great overview and discussion of Software Architecure.

One chapter in the book relates software architecture back to Vitruvius's original architectural creed of:

  • utilitas: the function of the structure,
  • venustas: the design of the structure, and
  • firmitas: the means, materials and logistics of construction.

Lots of interesting ideas here and highly recomended.

HTH

cheers,

Rob Wells
+2  A: 

I would expect architects to be at a level where they

  • define the vision of the product suite
  • Design according to principles
  • know the product suite thoroughly
  • are responsible for Scalability of the application
  • Integration of multiple systems
  • determine the best way for Data to flow
  • design Decision Support System
  • define fault tolerance levels and self-healing strategies
Raj More
+1  A: 

A software architect is someone who says either "J2EE" or ".Net" depending on a weighted evaluation of his/her résumé and managerial prejudices. People that respond differently are automatically disqualified as software architects and strategists, though they might have some credibility at the tactical (stovepipe) level.

If this is rejected as unsatisfactory, I'd suggest that a software architect is someone who does software architecture. Unfortunately, this means that everybody who makes ad hoc decisions that constrain software architecture is a de facto software architect.

If neither of the above definitions please, I'd define "software architect" as the thin (and often absent) layer of wisdom between business requirements and major IT initiatives.

There, are you happy?

+1  A: 

A software architect is a still-evolving definition designed to bin a growing category of Software Professionals. We can't have all these people running around influencing people and potentially directing how a company spends money without putting a nice label on them.

So someone decided Architect was a nice analogy so they hijack that term and slapped it on us.

But essentially we ensure the business' needs are met by the software that is built.

I:

  • talk to Clients and Developers using their own terms and language
  • look at the "stuff" that crosses solution boundaries, but could affect a solution
  • prototype new technology to see if it is appropriate for a given solution
  • do a lot of stuff that a senior level developer in a smaller shop would do for him/herself

But to be clear, I do NOT tell the developers what to do (unless I'm playing both roles). I sit with the developer and describe clearly what the answer needs to look like. Sometimes I'm responsible for the interfaces. But you don't tell a professional how to do his job, you just define what the expectations are and he will fill in the details.

Ernie

EStormann
+2  A: 

A good architect should create software with the below attributes:

  • Durability - it should stand up robustly and remain in good condition.
  • Utility - it should be useful and function well for the people using it.
  • Beauty - it should delight people and raise their spirits.

Source (it's about building architecture, but I believe you agree)

Nick D
+1 For Beaut and delight!
sixtyfootersdude
+4  A: 

Certification

Certification may make you an architect

... but certification won't make you a good architect. Some architects are home-grown, and are just placed in that role.

What's the Technical Architect's role?

(I have also seen successful Enterprise Architects and Functional Architects)

  • Primarily technical leadership. Keeping abreast of industry trends and the effect on the software products under the architect's care.
  • They design the application architecture, specifically responsible for process-level, component-level, deployment-level items.
  • They solve the *ity problems of the system (Reliability, Scalability, etc).
  • They often handle the cross-cutting concerns of the app (Security, framework adoption, tool choice, etc).
  • Most often called on for POC or Prototyping (third party integration, platform upgrades, etc).
  • Handle SDLC issues like choosing the process for dealing with the version control system, process for the build, process for performance testing, and process for development testing.
  • Sometimes the archs that get stuck in process definition can get myopic about the software they're trying to create (IMO).
  • They can be called on to do PM, develop features, BA, Dev Mgmt, but that should be to pick up slack or ease project tightness.

The lines blur

Most shops used to get away with putting this role on a good Sr. Developer/Team Lead. When that team lead is only doing the Arch Role, then it's probably time to be fair to him/her and change labels.

johnwalker00
+1  A: 

A true Architect draws up a building, landscape plan, drainage plan, reforestation plan (etc., etc.) according to nationally accepted building code, fire code, electrical code, plus unique state, local and neighborhood codes and ordinances, that (hopefully) meets the requirements of the customer.

The Architect's drawing specifies materials to be used, which implies construction techniques but does not necessarily dictate them, except in cases of structural or code requirements.

Aesthetics, both internal and external, are a consideration.

So, in my opinion, an Architect (of any type) melds all the requirements together and dictates the final form and functionality of the product. Getting there is up to the workers.

kmarsh
+1  A: 

A software architect can draw a complicated IT system in Visio with 3 square boxes, 3 labels and 2 connectors, then talk about it for an hour or so.

Paul Rowland
+1  A: 

Architect , the way I see it means... one who knows HOW the system /software will be built to satisfy the customer needs . He will know how the pieces will fit together and work in conjunction to make the WHOLE work . So, by extension a software architect should absolutely know the domain in which he works and should be expert in the technologies which are typically used for building applications in the domain .
He is the one who prepares the design which other people implement to get the software up and running .