The Joel on Software Discussion Group (CLOSED)

I have seen several job advertisements seeking a software architect.

Sadly, even after 10 years of working in the IT field as a developer, I am yet to figure out what the role of an architect really is. I have worked on small to large scale software applications as a developer and have been involved with various aspects of software development including design, coding, build, testing and project management.

Can anyone please enlighten me about what constitutes the role of a technical architect in an organization? Is this just a euphemism for a very senior developer? What skills should I have in order to call myself an architect?

The architect is responsible for the high-level (top-level) design of the system.

IT architect is my official job title at the moment, so I probably should have an opinion on this.

For me, the IT architect role requires hardcore IT knowledge and skills, combined with good knowledge about the role of IT within a specific business domain and a specific organisation.

The ability to communicate well with anybody from the developer to the boardroom director is important. And the ability to draw pretty diagrams at the right level of detail for your audience is surprising useful.

Basically, I was useless at this role for my first year. But I'm working at it, and slowly getting better. It's lucrative and usually fun. But if you want to do this, I would recommend writing code for at least 1 day a week, as it's easy to lose touch with the coalface.

I've never used coalface.  Is that like ColdFusion?

I think Coalface is a music group out of the US.

An "architect" is someone who designs but does not build. A "developer" is someone who builds but does not design.

For example, you may ask an architect to design you a house, but all he does is draw up the plans. It is a different set of people, with different skills, who actually turn the plans into reality.

An architect who has never built anything in his life runs the risk of designing something which cannot be built, so IMHO a software architect who has no development experience is not to be trusted.

And rabbits like carrots.

I've had the term "architect" in my job title for about ten years and I'm convinced that the model where architects "do design" and then throw it to developers who do "coding" just doesn't work for software of any complexity.

I believe that the role of an architect is to make sure the right technical design decisions get made and to take high level responsibility for these designs. This can really only be done by facilitating an appropriate design process - not by dictating what the design has to be.

My first post defined typical requirements for a software architect. But I didn't address what the typical architect actually does.

I think this varies from company to company, and especially between industries. The role of a software architect in an investment bank will be very different to the same role at MS or Google. This entry is written from an investment bank point of view.

Typical business responsibilities include:
* Understanding the business domain.
* Understanding the business data flows.
* Looking at the whole picture, not just individual bits.

Typical design responsibilities include:
* IT infrastructure, especially system coordination.
* Connectivity and middleware.
* Production reliability and resilience.
* Software development process.

Typical communication responsibilities include:
* Talking to just about everybody.
* Writing documents that people will actually read.
* Drawing pretty diagrams aimed at the specific audience.
* Software development coaching and mentoring.

Typical execution responsibilities include:
* Project management.
* Project execution.
* Vendor management.

I even do some coding - look, I can still do FizzBuzz :-)
http://www.sleeksoft.co.uk/public/techblog/articles/20080313_1.html

"The architect is responsible for the high-level (top-level) design of the system."

That's part of it. The architect for a given system is the one who makes the really high-level decisions such as which development platform to use for that system (Java versus .NET, Hibernate versus JEE), which third-party libraries to choose, whether to have a two-tier or three-tier design between the GUI and the database layer, etc.

But even more importantly, in a large organization, an architect is someone who makes design decisions *across* systems. Architects decide on the coding conventions which should be followed for *all* coding which takes place in a particular company, they manage the development of reusable libraries for use across projects, they make decisions on how multiple systems will communicate with each other, etc. Basically, laying down guidelines to encourage consistency in design decisions across all the systems being developed within that company.

The Software industry via IT is so F%$#Yed up that those posting to this thread can't even agree on what constitutes a fundamental Software Architect....

This is not an indictment on anyone posting here, but is more so to that of the industry....

Is it any wonder that software is lacking so much in today's world?

Don't forget that there's more than one kind of architect as well. Under the general blanket term of 'technical architect' (or more often these days, just 'architect') you'll also find terms like 'enterprise architect', 'solution architect' and (per the OP) 'software architect'. They're supposedly all different jobs.

I used to be a Chief Solution Architect, and my job was much more about meeting with customers and working out what they really wanted and what sorts of technologies would make that happen than it was about doing software design. I'd generally stop at the highest level of design and let the development lead take over the rest of the design. That job could well be described as Technical Architect or Software Architect, but because the guy did that as well as coding and team leading, he would have the title of Lead Developer instead.

Titles are largely meaningless. About the only thing you can say about many full-time architects of whatever stripe is that they don't often do much if any coding. Other than that, it's all about the individual place, the individual role, and the person in it.

A few years ago, I wrote the article "Why I am not an architect" - http://www.ddj.com/architect/184407745 - but I have moderated by opinions a bit over the years.

Basically, it really depends who you are talking to.  To a consulting firm, an architect is someone just technical enough to collaborate with the engineers and with enough sales skills to talk to the customer.  In other words, it is a technical liason role.  This is really not all that different than a sales-engineer, but the role is post-sale.  It's also not much different than a requirements analyst, but the architect is expected to have the technical chops to say "It doesn't work that way". 

This is actually pretty close to what a real building architect does.  He talks to the customer, asks a bunch of questions, proposes a blueprint that is very high-level, and asks the customer "is this what you want?" The the architect works with the customer to refine the idea, finally coordinating with the engineers to actually build the thing.  (Yes, the architect should keep the builders in the loop throughout the process.  Some of them do.)

In a large organization (microsoft, sun, state farm insurance, etc) the term can mean something different. In a big software firm, you have to have a career ladder for technical folks, and it often involves the term "architect", which is a position with little responsibility for implementation.  Likewise a big IT shop.  Often these people go to meetings all day and are very concerned with things like scalability, performance, reliability, failover, and other enterprise-scale concerns.  They may review the plans of the actual do-ers and suggest (mandate?) additional work.

Overall, I don't see a ton of value in that kind of role at most shops.  Exceptions, of course, do exist, and I'm open to changing my mind if presented with strong evidence.

Regards,

I completely disagree with the comments that Architects don't write code...

Where I consult, fortune-5, I'm an architect for a very large project (you see TV commercials for this company's product).

We do quite a bit of code development.  It's true there are developers we work with that write a majority of the code however, Architects, at least from my experience, do a fair amount of code development:

  -  Proof of Concepts code development.  Much of this code becomes the start code the developers use to implement with.

  -  Protocol specification (sequence diagrams) and then developed the code.  Common theme when dealing with hardware devices and often the case for Architects who are not has highly focused as a developer role in same project tends to be.

  -  Developers tend to be very focused.  For example, the .NET guys don't do J2EE and vise-versa.  As an architect, I  have to know both.  Consequently, again in my experience, architects develop code in more languages than highly focused developers.  This has been the case on the 30 or so  enterprisey projects I've been on.

  -  Architects are the go-to folks when problems come up during development.  If a developer finds they are having performance issues, then architects step in to review code to refactor, etc..  Mostly finding junk code being developed. 

  - Architects have more responsibilities and this comes with more $$.  If you fuck up the design, then it's on you to fix or get fired.  Architects have to know more about the external systems, if any, that all must be integrated with.  If it's a web application then chances are that you may be dealing with web service calls to other systems and if it's external vendors, then maybe you trying to develop a single sign on system between the two entities.  In these cases I see architects also being product knowledgeable as well...  Knowing what, for example, IBM's DataPower can and can not do, what MS-Exchange can and can not do, what Windows Communication Services is capable of and what Java timer beans can and can not handle on a WAS vs JBOSS platform.

I'm a little cynical about this.  I think Architect is a title that is used so that programmers/developers can feel like they've gotten a promotion.  It's also used because people are becoming uneasy about having a title of "programmer" as they get older, because it sounds like something that could be easily done by a younger or offshore worker.

Yeah, there's a difference between what a typical "Architect" and a typical "Programmer" does, but there's also a difference between what a Junior Lawyer (going through 20 boxes of printed records with a yellow highlighter for "discovery" vs what a Sr Partner does (organize and structure litigation strategies on a high level).  But nobody seems to think we need different terms for the profession, probably because Lawyers don't feel like they need to drop the Lawyer title to indicate that they've advanced in their profession. 

Truth is, we drop "programmer" quickly in our field because it's still not pecieved as a high value job.  That's nuts, in my opinion - programmers can be exceptionally valuable.

Where I've worked in the past, the architect(s) designed the interfaces, coded the base framework and system-wide libraries and did all the documentation for that. Developers then did the individual modules. Project management and IT stuff were done by PM's and IT department, not the architects.

(I'm sure it varies by company though)

Geebee:

>> I'm a little cynical about this.  I think Architect is a title that is used so that programmers/developers can feel like they've gotten a promotion.  It's also used because people are becoming uneasy about having a title of "programmer" as they get older, because it sounds like something that could be easily done by a younger or offshore worker.

>> Truth is, we drop "programmer" quickly in our field because it's still not pecieved as a high value job. 

Completely agreed.  "Architect" is one of those supposed "high value" jobs that stupid overspecialized code monkey programmers who were offshored are supposed to gravitate to.

My observations:

Job titles in all industries have been co-opted and degraded for commercial purposes in the recent past.

For example, decades ago, "consultant" used to have a meaning similar to "architect" - someone who advises but who does not implement. There are precious few "real" consultants, by this definition, around, and "real consultant" (adviser) roles are not advertised or made public.

"Architect" has a very similar patina of intellectualism and high level perspective.

The reality is that precious few businesses are willing to divide the the development roles in this way in order to enable architect roles.

The way it's been for 20+ years is - if you understand code, you code. If you can *plan* code, you are still expected to code, you just have more architect like duties. But your role is not really architect.

Agreed, "architect" is used as a cheap "promotion."

"The Software industry via IT is so F%$#Yed up that those posting to this thread can't even agree on what constitutes a fundamental Software Architect...."

Brice,

You have the same thing in many engineering fields.  Depending on what company you go to or even which department your work in certain titles will have different meanings.

So drink some warm milk and take your meds on a regular schedule.

Architect is responsible for
- the business requirements
- translating the requirements to technical design
- the implementation approach and solutions.
- technology evaluation (DB to use, language, framework, tools, etc).
- design guideline and styles
- the development process
- the overall architecture
- layering, components, and interface
- foresee installation and deployment
- foresee testing architecture and qa process.
- versioning, upgrade, migration.
- data modal, object modal, process flow, data flow, transaction.
- reliability, scalability, (high)-availability, recovery.
- security - data security, authentication/authorization
- and many other things.

A good architect worths his weight in gold.

"Been There", if all that you listed constitutes an "archtect", then Ive been one the past 8 years and didnt even know it! Ive done all that but recovery, in most projects I code. That's why these titles really only apply to larger corporate environment, where you really need to break duties down.

Its kinda like some backstreet cop being promoted to lead detective or homocide squad after 30+ years of hard service. He's really there because he earned his stripes...not because he knows any more or has any more talent than the next guy. In just a few years, I doubt the guy could still do what his fellow cops do everyday. Programmers and architects follow the same rule, I think.

I go back to what makes a good "coder". If you know your code, and are a darn good programmer, then you can do all the other stuff....eventually. Thats why this whole offshoring model has messed up our priorities in technology around the world, as we commoditize and devalue very good coders with years of experience in many areas of their career and think we can replace that with some 14 year old Romanian kid who hacks .NET apps for IBM in his underwear for $5 an hour. There sint any comparison with a seasoned coder who has ten years experience across multiple practices..."architect" or not.

Strangely enough, what I think every poster has missed in this thread (unless i missed it myself) is the blatant fact that a real "architect" must first and foremost be a real technologist but most importantly, also a politician.

My take: a software architect is someone who directs a software implementation effort and ensures that the software gets built to specifications. SAs provide the software development effort a solid vision - both technically and function-wise, though not necessarily unilaterally.

SAs should have immense breadth and depth in technologies and domains involved. You don't "learn on the job" as an SA. You are expected to know your stuff, and must have gone through similar SDLCs a few times at least. SAs have impeccable hands-on credentials. To me, the line between lead programmers and architects is very blur.

Examples: Anders Hejlsberg, James Gosling, David Cutler, Linus Torvalds, John Carmack.

>> If you know your code, and are a darn good programmer, then you can do all the other stuff....eventually. <<

This is just wrong, sorry. Not matter how well somebody codes, simple experience isn't also going to make him/her:

* knowledgeable about the business domain
* an effective communicator
* a good system and infrastructure designer
* a reasonable politician.

This set of skills in one person is quite rare.

And another thought:

Capitalism tends to reward being in the top 10% in 3 useful skills higher than being in the top 1% in a single useful skill.

If you're in the top 0.0001% in a single skill, then you're probably going to make it rich anyway. But only 1 in a million can reach this level. The rest of us are never going to be in that position.

So once you've reached the top 10% in a skill, it makes more sense from a financial point of view to focus on a different skill. Combine 3 or 4 top-10% skills, and you too can be an architect :-)

I used to be confused about the difference. Here is what I think:

A software architect decides on the layout of the overall system: 2-tier fat client vs. 3-tier thin client, black-board, layered, etc. The architect also makes system- or component-wide technology choices, like choice of middleware, choice of OS, choice of DBMS, choice of language, etc.

All of these decisions are driven by the customer requirements and the constraints of the problem.

To contrast, the software designer lays out the software itself with what the architect lays out: if the architect chose layers, then what the modules will be within each layer, the responsibilities of each class, domain objects, aggregate roots, factories, etc.