Learning how to clearly define the role of an architect would benefit both IT companies and the Java workforce by establishing realistic expectations and job requirements.

Most architects hired by Java shops seem to be using the title of "architect" when "senior developer" is a more correct description, according to the article. Ruth Malan, of Bredemeyer Consulting, has suggested independently that "architect" is often used to give senior developers a more auspicious title, or to allow better pay based on title.

According to the article, "the difference between an architect and a developer is breadth of knowledge verses depth of knowledge."

Core points from the article can be found in two separate paragraphs:

Architects are often idealized as Java gurus. The reality is they are not gurus. Rather, they are the creative visionaries of an organization's Java future. Think of it like this: A publisher wouldn't hire writers expecting them to fill the role of editors simply because they can write. Construction companies wouldn't employ architects expecting them to lay cement simply because they know how to read blueprints. Well, why should Java architects be expected to traverse the role of a developer simply because they know how to write code?

Knowing how to solve a problem's context verses solving the problem itself distinguishes architects from developers. Thus an architect must be adept in object-oriented methodologies, design patterns, and UML, and, more importantly, have the discipline to enforce standardized guidelines while following best practices.

What do you think? Do you consider yourself an architect or a developer, and why?

Construction companies wouldn't employ architects expecting them to lay cement simply because they know how to read blueprints. Well, why should Java architects be expected to traverse the role of a developer simply because they know how to write code?

This is quite heavily implying that making software and building houses is analogous, which it absolutely is not. It also implies that you can pre-define and pre-plan software development in excrutiating detail with "blue-prints" that will then be followed, which is also a load of bollocks.I tend to agree with Martin Fowlers assertion (http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf) that "architecture" is a word we use when we want to blow up the importance of design decisions.

Knowing how to solve a problem's context verses solving the problem itself distinguishes architects from developers.

I would agree with this if anything despite my criticism.My definition of an "architect" is someone who can:- tie business outcomes to technical solutions.- Solves problem contexts rather than problems (good addition from the article!)- Knows how to define appropriate levels of abstraction for different solutions that are well decoupled.

In my book, very senior developers and architects tend to be one and the same.However the real crunch point for me is "abstractionists" vs. "implementationists". People that are "abstractionists" and are able to define appropriate levels of abstraction for problem contexts and spaces are extremely rare, but worth their weight in gold.

I would agree with this if anything despite my criticism.My definition of an "architect" is someone who can:- tie business outcomes to technical solutions.- Solves problem contexts rather than problems (good addition from the article!)- Knows how to define appropriate levels of abstraction for different solutions that are well decoupled.In my book, very senior developers and architects tend to be one and the same.However the real crunch point for me is "abstractionists" vs. "implementationists". People that are "abstractionists" and are able to define appropriate levels of abstraction for problem contexts and spaces are extremely rare, but worth their weight in gold.

I disagree. For me, senior developers are...senior developers. An architect is the one who knows how to translate the business requirements from the sales/business staff into a high level technical design that can be perfected by a senior developer.

As such, I believe the role has changed a bit. It's not blue prints in that we lay down the law as to how something should be done. It's blue prints in that...here's a way we could do this, now let's go and figure out the best solution that meets these business requirements. It's about being close to the business.

Perhaps this was the role of a business analyst in the past, but riddle me this...what does a CTO do, and what is that role closer to, architect or developer?

Perhaps this was the role of a business analyst in the past, but riddle me this...what does a CTO do, and what is that role closer to, architect or developer?

IMHO the CTO (or CIO, or whatever...) is the top program manager for a company's IT organization. His job is to sell the company's IT organization to the business in general (or sell it out and outsource or offshore).

The last thing you want is a program manager making engineering decisions.

Perhaps this was the role of a business analyst in the past, but riddle me this...what does a CTO do, and what is that role closer to, architect or developer?

IMHO the CTO (or CIO, or whatever...) is the top program manager for a company's IT organization. His job is to sell the company's IT organization to the business in general (or sell it out and outsource or offshore).The last thing you want is a program manager making engineering decisions.

I have that being two different roles (and your milage will vary depending upon whom you work for).

While the CIO is involved in financing the IT department, the CTO is involved in determining what the overall picture of the technologies to be used are.

Should we continue using a mainframe, should we move towards .NET, is Microsoft offering a better deal than IBM. Should we use open source in our core product set. What kind of price can we negotiate for service on our RedHat contract?

Those types of questions are left to a CTO, whilst the CIO is more involved with the finance arm, determining what can be done this year, and what must wait until next.

In some organizations these roles are combined under a single person. Some organizations require more or less out of these roles. If you're providing a technology service, or packaging software for sale, these roles may be much more highlighted than if you're running a IT in a manufacturing company where the roles may require more of selling the IT organization to the company as a whole.

To me the architect is on the career path towards a CTO type of roles. Some companies have chief architects who report directly to a CTO or CIO and are responsible for the overall infrastructure. Some do not...milage always varies.

That's where I see a difference. The programmer wants to program. He's really not interested in getting that involved with the buesiness. The architect, will have to get close to the business to be highly effective.

I disagree. For me, senior developers are...senior developers. An architect is the one who knows how to translate the business requirements from the sales/business staff into a high level technical design

The rest of your post seems to into detail of having missed exactly this point alltogether.. :)

And yes, you are correct in that an architect may have a more business- and even strategic-focus to his work than a senior developer, but my point is that the difference between an architect and "very" senior developer tends to be miniscule:As Vic mentioned, any senior developer worth their salt will also have basic understanding of the business and be able to make good design (architecture?) decisions based on that understanding. A Senior developer that is unable to have that level of expertise is not a senior developer, he is merely a junior developer with lots of years working behind him.

Of course there are organization where you have PowerPoint-architects who hide their ignorance and lack of actual knowledge behind stack loads of nice-looking high-level block-diagrams that do absolutely nothing and will never be looked upon a second time after they have been presented to the project board or whoever. Certainly no developer will take much notice of such things at least, because its of no use to them ("..and here we have the oompa-loompa layer which requires no coding and eats small children").

I guess I disagree on the depth required of business knowledge for a senior developer. They don't need to understand what is happening in other areas of the enterprise to be successful. An archtect should.

If a decision is made to build web services for internal comms, a senior developer can code to the specs and work with the business analsysts and code a wonderful system.

It's all for naught if you find out that the other systems in the enterprise are not ready to support services.

One would hope that the architect would plan for these sorts of things. I certainly don't expect a project manager to handle that sort of thing.

I guess I disagree on the depth required of business knowledge for a senior developer. They don't need to understand what is happening in other areas of the enterprise to be successful.

I think we both agree and disagree:I believe senior developers should have good business knowledge, or at least strive for it, there is no substitute for domain knowledge when solving problems in a particular domain.

However I DO agree with you on the fact that the person called "an architect" should probably excel in his business knowledge beyond what developers know or perhaps most of all: they should recognize a problem context, rather than a problem when trying to solve something.This again is going back to my point of "abstractionist" vs "implementationist".Perhaps being a bit vague in saying "there is no distinction between developers and architect": perhaps what I should have said is that an architect DOES distinguish himself from developers in his involvement in tying business outcomes to technical solutions.

A developer is someone who works hard to keep up with the constantly shifting rules of implementing software changes. A sharp developer can morph into a good architect at will.

An architect is someone who does not try to keep up with the detail required to implement software changes. A sharp architect can resume development activities at some point, but may have missed some big shifts in the programming landscape that will require serious study to try to catch up.

Supporting anecdotal evidence: Good OO programmers could have become architects prior to J2EE, but would not have been good J2EE architects without paying their dues as coders.

The next big shift may well be AOP. Today's good J2EE/.Net architects will probably lose ground when/if AOP reaches critical mass.

I agree. I think a java architect (j2se platform) would have to pay some coding dues to become a j2ee architect. As for AOP, I think a j2ee architect could utilize AOP without too much trouble. I.M.H.O. there should be a distinction between a standard java architect and a j2ee architect. The J2ee architect has to insure that patterns, framework strategy (blueprints to purchased) and re-use strategy of the j2ee nature are adhered to, along with integration strategies. Of course web service integration is another one.On another note, this is quite an old debate. Grady Booch said in a book in 1995 that he would never let anyone design a system (OO design) who had not previously taken part in successfully implementing one. He went a step further in saying that the designer should be condemned to live with the design.

Grady Booch said in a book in 1995 that he would never let anyone design a system (OO design) who had not previously taken part in successfully implementing one. He went a step further in saying that the designer should be condemned to live with the design.

Well said. All "effective architects" code very well. If you can't roll out the framework code and refractor those after testing against few in-house applications, for sure it is piece of crap. An enterprise level component based on any JSR spec, is bound to take few years ( Projects ).

I guess I disagree on the depth required of business knowledge for a senior developer. They don't need to understand what is happening in other areas of the enterprise to be successful.

In the good ol' days, for those of us that experienced it. Developers would acquire a deep understanding of the business if they worked for that type of a company. These days with Java and the Internet, business knowledge is rarely on the "required" list on the job description.

Of course there are organization where you have PowerPoint-architects who hide their ignorance and lack of actual knowledge behind stack loads of nice-looking high-level block-diagrams that do absolutely nothing and will never be looked upon a second time after they have been presented to the project board or whoever.

Of course there are organization where you have PowerPoint-architects who hide their ignorance and lack of actual knowledge behind stack loads of nice-looking high-level block-diagrams that do absolutely nothing and will never be looked upon a second time after they have been presented to the project board or whoever.

Disagree! PowerPoint is actually the most effective architecturing tool around. At least, our developers need not to falling sleep reading hundred of pages of word documents or messy over-loaded UML diagrams!Besides, if you cannot explain your design in a few PowerPoint slide, it is not going to be implemented correctly either, nor the design document will be updated to reflect the reality!The more documents are there, the less likely they are relevant.

Well, I wouldn't disagree with you in part there: hundreds of pages of word documents is NEVER going to be read. :)

What I am turning against is the obvious cases where people create nice diagrams that have nothing to do with what eventually happen and everyone knows it."The emperor has no clothes" comes to mind..

I agree with you that presentations with little touches to the real problems on hand are useless.

However, using Powerpoint as a medium for design documentation is not bad.

For a project, I created a dozen of PowerPoint each covering one architectural aspect of the problem like security, O/R modeling, etc. Each presentation ranges from 10 to 40 slides but they are very much self explanatory and yet concise. Since each slide has a title and simple sentences. They are easier to follow.

But I will not put in any full UML class diagram or API, in any document format. I believe diagram should only be high-level, showing only the major classes and relations. All the class details and API should be written in plaint Java code! Then you don't have to have the headache of making sure the diagrams look nice and not got out of sync or messed up.

I found it more demanding to write good presentation because it must be very clear, very concise and, not the least, very pretty. But just because of that, I make sure I'm really thinking about the design and the resulting document is much more readable than those in Word or other traditional full text format.

I agree with you that presentations with little touches to the real problems on hand are useless.However, using Powerpoint as a medium for design documentation is not bad.

An architect can design, code and test the reference framework in the same time some other architect make power point presentations. They never try to use MS Office as JVM. 99% of time the design shown is ppt falls apart in hours.

- Knows how to define appropriate levels of abstraction for different solutions that are well decoupled.

Couldn't agree with more. I find that a lot of very bright senior developers seem not be able to think of the big picture or isolate themselves from the problem and think in terms of the "Whole Tree" as the article put it.

I believe that an architect is like a good chess player; he can see the board 5 to 10 moves from now and hence adjust accordingly. Senior Developers (who don't have the architect’s gene :-)) tend to at max anticipate 1 or 2 moves ahead.

This means that both can play chess but they both play at different levels.

Hello,This is a very worthwhile discussion for managers, hiring authorities and for java world. I want to add few more things, although it should not be a part of job responsibilites but an Architect is supposed to be smart enough to delve into coding level details to mentor the development teams and other stake holders of the project. I think this role varies from company to company, some companies are happy with 50-50, and some don't want there architects to write refactoring code where bad smells comes from the code and to let the architects write POJOs. Although Archtect should be able to smell the code 10 times more then a developer. May be it would be required sometimes from an architect to teach developing team to refacor the code by implementing few coding examples in the current component. And Java Architect requires good communication skills, information sharing/non-egoistic and quick learning abilities. Java is the name of a diverse set of concepts,tools and technologies and end-to-end solutions keeping in view this diverse nature of this technology. The role "Java Architect" or "J2EE Architect" is correct. Just like a .Net Expert or Architect. Technology selection is a major concern of most of the big IT organizations. Unlike other industries, software industry is very dynamic and bussiness strategies depends on technology selection.

The big problem with the article is it assumes that you can understand how to use technologies just by reading about them. No hands-on experience required.

But that's just wrong. If you stop being a developer - if you stop reading code, if you stop writing code, if you get too distant from issues involved in supporting code - then you lose touch.

That's why I've become very suspicious of 'architecture' roles. Usually the only possible person who could fulfil the role is a superman, since usually it required in-depth knowledge of a broad range of technologies. Since that can't work, instead you've got to trust your head developers to do design, and head developers (obviously) need to look at more than just their own system.

Architects who see their role as that of co-ordinating the work of the lead developers, and who have the skills to do it, are worth their weight in gold. But still they need to get their hands dirty sometimes, or they'll lose their touch.

is this what an architect is? Developers can do a better job designing applications and how they communicate together. You need one or two developers who knows UML very well and knows well about all the systems around. And based on that knowledge make recomendations how they should communicate. We all talk about design patterns and better architecture of systems and such and we all knows solutions to that yet when it comes to bundle software for deployment, lot of places will create individual jar files that is common to all these different systems which would require of jar file release for all the systems. Is this what a system architect should allow? my ass! this is not a freking opensource project that we are working on, these are your business domain objects. and your enterprise should have to be restarted because you released few changes to few files. How many architects are not afraid to put in dependencies? standard answer "oh! we will be creating dependency and we defenately don't want to do that?" screw it! do they even realize before saying so that it is how distributed computing works?

A better title is a hands-on-tech-lead-and-pm. If you can code and have a track record of delivery, you get respect from developers and clients, no one cares about the title.

IMO, Likely that if you have an architect in you shop, you should get rid of them, most can't code and most are not respected by developers and their designs exude lack of experience. When somone calls you an J2EE architect, they are insutling you, imo.

When you need one: If you have a PM that has not risen trought the ranks, they pick somone to tell them if their ideas are techincal. Since the PM is not techical, they can't pick a technical "Architect". Then they draw things on the board, and I can't allways tell if the plans and designs would work untill well into the project I find that these 2 have never put anything in production ever. I just let them fail and *don't help them*, makeing sure my projects are fine. Then you get respect and be over those 2; neutralize them by resumes that show the coder has a track record of delivery. B-bye. That ends meetings and increases keyboard time.

Just don't have titles. "People that carry-and somehow don't take the credit" and "people that get carried-but take the credit".

When you go in a shop and they have an architect, it's very telling. Back in the days of "Data processing", when it was a boring job, there was no such thing.

most can't code and most are not respected by developers and their designs exude lack of experience.

It sounds like you've seen your share of crappy architects.

I think there is a distinct lack of architecture out there and it shows. Project teams that are lead by a lead developer are better than ones run by PMs. but not much better.

Good architects not only create an overall design of the components of a system. They also are able to see the reusable parts and make a much better object orientated design. Much like brick-and-mortar architects, they create prototype models/blueprints that the programming team can expand upon.

Bad architects make Visio diagrams that look curiously like the ones you see in trade magazines. They don't know how to tell the programming team how to implement their design and can't tell you the possible pitfalls and traps that can arise. They are full of buzzwords and are useless if the programming team runs into issues during implementation. They don't know why their design is good. They don't know

The trouble with hiring architects it's very rare that the people hiring know how to qualify the candidates. That's why they're hiring them. Java Architects need to know a wide variety of J2EE technologies. They need to know what to use and when to use it. They need to know design patterns. When and why to use them.

When you're looking to hire an architect, you need to look at their track record of projects. Ask them how they made their decisions. Ask them why them made them. Ask them what other designs they had thought of and why they chose them.

"Java Architects need to know a wide variety of J2EE technologies. They need to know what to use and when to use it. They need to know design patterns. When and why to use them"

I agree with John, I have seen so many self-claimed Java Architects who do not know much Java. They are simply not even able to validate that does developer implement the code like the way they designed. Those Architects are just useless craps.

The author of this artitle need to be educated more on what is software architect. Maybe this is a better start point for this topic: Institute of Software Architects

According to Sun's definition of J2EE architect role (as it follows from objectives for SCEA examen) is that it is someone understanding not only Java but as well basics of systems' perspective: networks, firewalls, protocols etc., and non-functional requirements like security and performance, and their implications to the system as a whole.

An architect is supposed to define an overview of the system and provide developers with a 'architectural template', layers of the system, underlying technologies and the ways of integration.

As opposed to the architecture, the design of the system is applying architectural template to solve particular business problem.

E.g. an architect would define that the system has presentation layer using Struts, and below it will be layer of "business applications", and below it will be "business service" layer which will use Hibernate for persistence and SOAP client. A designer will then deliver design with concrete classes, filling the template. A developer will then write code according for each designed class. Oh yes, and unit tests indeed.

That's all theory. Practically, I've never ever seen an architect of a designer that deserve their title without being able to code themselves. Note that "being able" doesn't mean they do code, it's just that they must read and understand code. In a sense, all good IT project managers, architects and designers I've ever met were all with a decent _current_ development background. They have just decided at some point to sacrifice the fun of development for job titles and respectively higher salaries :)

Author - I wanna get paid the big bucks but I dont want to be responsible for the code. Therefore I will try to publicise the definition that suits me.Why in the world should an expert developer heed the architect who just reads whitepapers all day? You have to know a component before you can use it. Unless of course the architect is a consultant! Then the bucks are even bigger, and the expert developer has no choice because the VPoE has been snookered.B

he he, exactly what I was thinking. I want to get paid $20-$30k more than the developer, cause I can go on javaworld and read about all technologies while the developer is actually doing work :)

In our shop, chief programmers are people who have a proven track record in formulating problems and solving them efficiently and elegantly. They are also good at communicating formulations and solutions.

Java architects - software architects specializing in JavaDifference between architect and senior programmer (a-sp):a) technical skills and experience to be able to gather, analyse, and translate technical and application requirements into design, code, and automated unit tests, and,b) self motivated to improve the technical and application requirements and delivery process - adept in more than one method (DFDs, CRCs, UML, etc) they know where to apply changes in process, and changes in tooling to effect significant savings in effort, maintenance, tunability, etcc) ability to design with performance in mind, and to design and execute performance tests and prepare reports on resultsd) ability to quickly analyse complex, multi-system problems to determine fault(s) present, and to communicate the remedy options with a recommendation to stakeholderse) ability to teach others these skillsf) putting together a architecture roadmap with supporting architecture blueprints, and detailed plans is another skill of many that really support (a) above so I'll stop -Matthew

The problem is terms like "software architect" or "system architect" are tossed around for the sole purpose of making individual's roles sound impressive - both for the customer and the individuals themselves.

The bottom line is every project needs someone who understands the big picture, including:- the general business and it's priorities- the specific details of the business problem being solved- all of the technical components of the solution- all of the external systems and tools used in the enterprise- the operations and maintenance side of the application lifecycle- the relationship between additional features and increased lifecycle costs- disaster recovery- scalability- security

This person's official role in the project may very. Often time it is probably the PM, lead developer, or system analyst. On sufficiently large projects it could be a dedicated role.

A good architect is a generalist. He may have a specialty (such as Java development), but ultimately he must be a generalist. On sufficiently large projects, one person can't possibly understand all the details of what everyone does and how every component works. But one person must understand how everything fits together.

I think Erik Engbrecht's definition is probably the best one I've read. The key word he uses is "generalist". I'd extend his definition to be "generalist with full life-cycle experience". Too many times I've heard references to "data architect", "application architect", "infrastructure architect", etc. There's even a "project architect" from what I understand. For Christ's sake, gimme a #$!*&% break. What's next - "Secretarial Architect"!? IMO, you're either an enterprise architect, or not an architect at all. In the physical world (ie, the Construction business), there's is only architect. Not electrical architect, not HVAC architect...you get the point. Also, "generalist" does not imply "abstractionist" (as someone else pointed out), but rather their knowledge breadth is wide AND deep. In this day and age with overriding business/technical alignment initiatives driving very aggressive delivery dates, as well as the push towards outsourcing & offshoring, you'd better have some prior hands-on experience, and knowledge that what you hand off to the development team is actually implementable. In other words, if the design isn't proofed out early in the project life cycle (eg, ala Agile methodology), you probably should go back to developing component applications.

Too many times I've heard references to "data architect", "application architect", "infrastructure architect", etc. There's even a "project architect" from what I understand. For Christ's sake, gimme a #$!*&amp;% break. What's next - "Secretarial Architect"!? IMO, you're either an enterprise architect, or not an architect at all. In the physical world (ie, the Construction business), there's is only architect. Not electrical architect, not HVAC architect...you get the point.

I think there are at least two types of architect's role. One is 'external', more of a consultant type, which concentrates on the technologies and their applicability in general. Another is 'internal' who works for a company big enough to care about its IT infrastructure as a whole. 'Internal' architect may not know a lot about technologies in general, but must know everything about particular subset of technologies used in the company. For a successful implementation of a new/updated system into existing company's IT framework combination of both skill sets is required.

The problem is terms like "software architect" or "system architect" are tossed around for the sole purpose of making individual's roles sound impressive - both for the customer and the individuals themselves.The bottom line is every project needs someone who understands the big picture, including:- the general business and it's priorities- the specific details of the business problem being solved- all of the technical components of the solution- all of the external systems and tools used in the enterprise- the operations and maintenance side of the application lifecycle- the relationship between additional features and increased lifecycle costs- disaster recovery- scalability- securityThis person's official role in the project may very. Often time it is probably the PM, lead developer, or system analyst. On sufficiently large projects it could be a dedicated role.A good architect is a generalist. He may have a specialty (such as Java development), but ultimately he must be a generalist. On sufficiently large projects, one person can't possibly understand all the details of what everyone does and how every component works. But one person must understand how everything fits together.

+1

In addition to this, I believe that "Architects" are the people who are not confined to a single programming language like Java. IMO, being an architect is having the knowledge on ALL possible technologies that can solve the problem at hand (including those requirements for scalability, performance, security...). A senior developer may only confine to his own mastered technology, but sometimes it is not enough to implement a large-scale project. Architects are the people who sees through these technologies and select the best possible solution. The organization might be like this:

A senior developer may only confine to his own mastered technology, but sometimes it is not enough to implement a large-scale project. Architects are the people who sees through these technologies and select the best possible solution. The organization might be like this:PM&nbsp;- Software Architect&nbsp;&nbsp;&nbsp;&nbsp;- Senior Developer -- J2EE&nbsp;&nbsp;&nbsp;&nbsp;- Senior Developer -- .Net&nbsp;&nbsp;&nbsp;&nbsp;- Senior Developer -- Legacy Systems&nbsp;&nbsp;&nbsp;&nbsp;- Senior Developer -- ERP / CRMJust my opinion,Noel Branzuela

So what does the PM do? Having been in the architecture you've describe and in a "self-directed team" I would say that a flatter organization is better. As I said before, you have to hire the right people.

Architects are often idealized as Java gurus. The reality is they are not gurus.

True. An architect isn't necessarily a black belt at Java-syntax-jutsu. There could be senior developers working under an architect who are better at Java syntax than the architect.

Thus an architect must be adept in object-oriented methodologies, design patterns, and UML, and, more importantly, have the discipline to enforce standardized guidelines while following best practices.

This is only half the picture. Or, ahem, let's make that a tenth of the picture.

What defines a good architect, is knowing all common problems/needs of an enterprise system, and tailoring common technologies of the day to answer those problems. Optimistic/pessimistic locking for example, is a common issue, we used to solve it with plain SQL, now we solve it through Hibernate. Issues are the same, technology changes (oh and we like the Hibernate way).

Everything that falls outside the programmers development box (their little cacoon) is the architects' job.

Deployment (whoever still uses ftp, logging with user/pass manually to deploy code at year 2005 gets an F. An architect must be adept at Unix-jutsu, or cygwin on Windows).

An architect must know his favorite technologies' shortcomings, and work around them if necessary.

Architect must have an healty respect for scripting, must be able to script any development/deployment related task without much delay. Must know regular expressions!

Must know database modeling.

Must understand performance tuning.

Must understand project management issues, must know what the necessary processes are for bug tracking, version control, etc..etc.., and how to set them up, how to enforce them.

The architect basically should do all things that will allow a developer just *code*.

I have been an architect for a number of years now and my definition of it is:

"One who takes a big system, breaks it up into smaller systems and then defines how those systems will work together"

This is probably too close to the technical coding side of things and tends to ignore the business side but persoanlly I do not think architect are part of the business process. You are there for the technical side of things. You job is to break down a system into the manageable pieces and let the developers do their jobs. But when they are done it all has to work together which is your job.

Any of the following is much better definition of a (Java) architecture:

1. One who does not know how to start a java JVM.2/ One talks about UML all the times and present you a class diagram by copying from Gang of Four pattern book as his design.3. One who has never managed to write more than 100 lines of codes successfully.4. One who is the buddy of the VP of Engineering or CTO.

OK, if you have enountered an architect whom cannot be described by any of the above. Those are actually geeks forced into being the architect as the company has no budget for a real one.

IMO, we should stop hijacking job descriptions. An architect is someone who designs real buildings - someone who "designs" software is a software engineer, period.

And there is no difference between "coders" and "designers" either, because the whole software engineering process is about designing, albeit at progressiely detailed levels. As soon as the process can be executed blindly without creative decisions, it is time to crank up the compiler - which is our equivalent of the "bricklayer".

IMO, we should stop hijacking job descriptions. An architect is someone who designs real buildings - someone who "designs" software is a software engineer

That's splitting hairs. Both the arthitect and the software engineer do essentially the same thing: provide both a physical and artistic solution to a problem. it does lead to confusion, however.

And there is no difference between "coders" and "designers" either, because the whole software engineering process is about designing, albeit at progressiely detailed levels. As soon as the process can be executed blindly without creative decisions, it is time to crank up the compiler - which is our equivalent of the "bricklayer"

That is an interesting comparison. I don't know if I agree with it or not, to tell you the truth. You can carve the context in many ways. Truth be told, I think there is a big difference between a "coder" and a "designer". A good designer is a good coder (not necessarily great). A great coder can be a horrible designer because they don't see the big picture.

That's splitting hairs. Both the arthitect and the software engineer do essentially the same thing: provide both a physical and artistic solution to a problem. it does lead to confusion, however.

my point is that the term "architect" is/was already in use for another trade, which is sufficiently different from ours to warrant its own name. Anyway, my real point is probably the one already made elsewhere: "architect(ure)" is a word we use when we want to blow up the importance ...

A great coder can be a horrible designer because they don't see the big picture.

Aha. So where exactly does the picture start being big enough so you can call yourself an "architect", and your occupation "design"?

IMO, we should stop hijacking job descriptions. An architect is someone who designs real buildings - someone who "designs" software is a software engineer, period.

There are no software engineers. It is the big term programmers invented themselves. Anyone can be a programmer: a student, a Ph.D or a former truck driver. Unless he got an engineering degree in some other field, he is technically not an engineer.

On the other hand, both terms make sense in in software development. According to dictionary.com, engineer is a person who uses scientific knowledge to solve practical problems. Right on, that is what a good developer does when he decides on sorting or compression algorithm or on how bitplanes should be organized. The architect must be an engineer and more. Architect cannot produce good results without knowing how his designs will be implemented. Architect is an engineer with the vision.

By complex system I mean a system so complex that you can't expect a single developer to see the whole picture. Designing and understanding the whole picture becomes a job in itself.

my point (apart from the fact that I dont like hijacking names that are already in use for a different thing) was that designing and understanding is happening at all levels, and in essentially the same way. Even the people that are commonly called "coders" (I take pride in being one, but for the sake of money, and to prevent others from getting into my way, I'll rather be an architect) are taking a spec and refining it to make it understandable for the next level (in their case, the compiler). Thats the essence of the whole business - taking higher level (and incomplete and ambiguous) specs, and refining them so they can be handed on to the next level. It starts with the business analyst, goes on to what you may call the software "architect", and lands in the hand of the "coder". On all these levels a certain degree of complexity gets handled. Unfortunately, due to the undefined and ambiguous nature of the artifacts (human prose or UML) delivered by the first two levels I have seen projects where the real complexity had to be handled by the programmers.

my point (apart from the fact that I dont like hijacking names that are already in use for a different thing) was that designing and understanding is happening at all levels, .Of course it is. That's because coding software is also a design activity.

Designs are always evolving. The architects designs merely represent the best efforts at the level of abstraction.

Excuse me! The analogy goes a long way, a class is blueprint for the objects, we build software one they are created in code and so on.

The term is around the market and people advertise and stake their experience for it. If the role does not exist in the stream you are going that is fine. But where it exists what does it mean. Is the question. It may be handy when going to places where some architect exists. Then you know what to expect.

Perhaps the definition is a high level conceptualizer. Familier with put the whole technical shebang in perspective of the business needs. Perhaps the role is just a tie for marketing and technical managers.

Software Architecture is very well described in Herzum & Sims book "business component factory" (isbn = 0-471-32760-3).

Architecture is a viewpoint, not a title. Maybe we can say that while development and project management are focused on project's targets and deadlines, the architecture is focused on the organization's infrastructure consistency and efficiency. It is a needed balance, introducing a long term attention to the ROI of the company. Cost efficiency is leading to industrialization of software production, which relies on software architecture.

I agree. The main difference between a senior developer and an architect is what that person focuses on. Most people find it very difficult to manage simultaneously the gory details and the big picture, thus the "architect."

It's really funny to see that everybody has another understanding of what an architect is as I recently had a discussion with one of my colleagues who teaches architecture (what ever this means).

I think a good architect is someone who is responsible for his decisions. If someone is responsible for his decisions he won't let anything slip through which might cause risks. Some so called architects that I know simply say "this is a technical detail" or "we don't talk about performance here, we talk about abstractions" blabla.

For me these people have no practical knowledge about how a technical detail can influence or even break a sophisticated architecture. They haven't experienced the pain when you realize a bad architectural decision. And when they realize it they tell everyone that the architecture has passed any review so the problems are caused by the developers who don't understand the architecture.

As someone who is looking to switch jobs I have been struggling with how to define myself in terms of Resume title.

I have taken a number of pretty big J2EE systems from pre-requirements all the way to production and then provided technical support. I also like to and believe it essential that I should keep coding and my core skills fresh. Therefore on the projects I have worked on I try to spend 20-50% of my time doing pure development.

Therefore in my Resume title I wanted to put forward three things. My hands on nature, the fact I prefer using Agile processes, and finally express my experience in delivering systems and hence my $$ requirements. Current my resume title is "Hands On Agile Architect".

After putting my resume out there I have gotten calls for three different types of positions.

(i) Large companies that consider architects to be modellers who never code and just do UML all day. To be honest I'd rather die but this does pay the best money though and that is a factor since I live in the SF Bay Area with my family.(ii) People looking for senior developers to do 100% coding with some team leading. I would do this as a contract if the technology and domain was good but generally the rates are too low.(iii) A company that is looking for someone who can do (i) and (ii) can't find any talent but has no money.

In conclusion I think we should scrap the term architect. Use the term modeller/analyst for people who don't want to code anymore, senior developer for experienced people who want to mostly code but have some technical responsibility and say Application Leader for the person who likes to build systems but also loves the hands on stuff.

In my book, a programmer knows how to write software. An engineer is someone who knows how to write software, AND understands why things are/should be done in a certain way. An architect IS an engineer that is responsible who's primary responsibility is determining and organising a project's structure. As we use the term separation of concerns in our systems, our project organisation might benefit as well if we're talking about large teams, as an architect's time might be better spent on doing other stuff than programming.

I've always been a software engineer. In a few cases, I've also been architecting the systems, thus also I've been an architect. I've always prefered the term software engineer.

svp.s. I'm not sure if I like the Java prefix before architect, as at that level it's often (should be) platform independant. An architect will discuss platform issues with platform experts like a provisioning, security expert ( or architect;) ), and act as a mediator.

After certain years of development and design experience, you will gain the software architect skills that is platform independent. but when you are architecting a software project, it is not, you have to pick a platform/technology to resolve the business problem. without knowing how to implement it and without knoweledge of architecting constructs, just like a building architect does not know the building material. Those designs may not be implementable at all, or does not work at all. Are those designs useful? Unless you are teaching architect class, non-hands-on architect is useless for a business.

I totally agree with the author on the need for an architect and the inherent differences in job functionality. Each team in a company would have multiple senior developers - each one of these developers would be defining their own standards and their own interfaces . Who is the atrbitrator ?

Companies need either a person or a group that performs this role. Define what technologies would be used and how best to use them. Define what communication models will be used. On a smaller scale, for individual projects, you need some one who decides what your application layers will be and how these layers will communicate. What kind of data passes between these layers. In a recent project we had over 7 teams each implementing different modules. If we had let each team define their own strategies, come integration time, life would not have been pleasant.

One other responsibility I would hand over to the "Architect" would be technology identification and prototyping. He could do this with inputs from developers, but he does have to ensure that a particular technology stack is worth the time and effort required to maintain it. This is especially true in today's open source world. There are many implementations for any particular functional stack and some one needs to decide which is best.

Nomenclature is usually not important, but I believe in this case, it does matter - Like a building's architect who decides what the building will look like, what exits and entrances will be available, what road the building will face - so does a software architect decide what a project will look like in its completed state, what systems will it integrate with and how.

In most projects that I have "Architected", it was seldom the case that I worked on a single project - As my job was only to read "white papers", as someone so kindly posited, I was able to handle multiple ongoing projects at a point in time. Most architects do this, do be cost-effective and because they have a need to understand how systems are being built and designed.

An architect must have designed and built comprehensive software systems. In my book, the architect should be an absolutely rabid coder. If the architect is not having fun, on his own time, designing software, moonlighting, debugging, writing systems, etc., then he is probably a kook. Drawing pictures does not make you a good architect. Thousands of hours of debugging, and loving the systems you build, and loving good designs...that makes you an architect. Point to something you built. An architect should be able to do that proudly.

An architect is whatever the organisation paying the salaries wants it to be, and in the end what they end up getting. Sure, the definition is a bit blurred, but since when has anything been clear cut in this industry? In my book, if you know you're stuff as a programmer, have a solid track record of delivering quality systems, and have a passion for analysing, designing, implementing, and enhancing enterprise software, whilst keeping in mind best practices, security, performance, scalablity, etc etc etc, within the confines and expectations of the requisite system (eg web services are not always a good solution) and communicating why your decisions were made, then you are an architect. If you have the time or responsibility to code then fine, if not and if you have good developers in support, thats also great, but as architect you are responsible for seeing your technical vision through to the end. You are the one the system ultimatley depends on. The key is communication, if you're not a good communicator it can be more difficult, especially with CEO's or PM's who have little or no clue technically.

Who cares about actual titles, and yes some shonks will get away with being miscast, but there is obviously a need out there to distinguish between an "architect" and otherwise.

Architect and senior developers or something like these are just roles. A person can have multi roles like a class can implement multi interfaces. So it is not surprise that a person seems like an architect but does coding, vice versa.

Knowing how to solve a problem's context vs. solving the problem itself distinguishes architects from developers.

I'd submit that implementation technology is part of the problem's context. Therefore any good architect must have a good understanding of programming, and the best way to have gotten that is a stint in development.

However there are some people who have more to add than just lots of years crunching code. They understand the relationship between the business, the vision, and the technology tradeoffs needed to get there.

Of course there are bad/pretend/idiot architects, and there are plenty of projects that can be done without too much care and planning because every developer has been there before.

But sometimes there isn't a substitute. Thinking that a truly unique/groundbreaking project can succeed without a good architect is as naive as listening to the guy with the fancy schmancy title that reads whitepapers/trades stocks all day and contibutes a few brain farts every month.

It should be obvious that an architect role and a developerrole is about different things.

An architect is supposed to work with architecture - thebig picture. How is business requirements going to betransformed into a system design consisting of a numberof components in a way that meets performance and scalability requirements.

A developer is supposed to work with code - the details. Howis a component with some specific tasks going to betransformed into a component design consisting of classes,methods etc. in a way that performs well and is easy tomaintain.

Or to give an example. If an architect sees a piece of badcode he will think "this is bad because this will not scalehorizontally by using multiple hardware boxes" or "this isbad because end to end response time will be too high usinga database here". If a developer sees a piece of bad codehe will think "those classses are unnecesarry becausejavax.foobar.Something has this functionality" or "thecode in method XYZ should be modified to algorithm A insteadof algorithm B because it is O(nlog(n)) instead og O(n^2)".

But working with a different view does not mean thatan architect should not be a good developer. To understandthe behaviour of components the architect needs to beable to code on himself and to have actually tried it - boththe good way and the bad way (seeing the results from doingit the bad way si probably what you learn most from !).

The typical problem with the useless architects referred tomany times in this thread is that their system design andreality do not have much in common. I belive that themain cause of that is that the architect is not capableof writing the components in their design. He does notreally understand the problems. Then the design just becomesa picture with two boxes A and B connected with a line andsome standard buzzwords (enterprise this and that etc.).

So why do software architects needs to be able tobuild the components when real architects do not need tobe able to build a house ?

Some of the main reasons must be that:* software development is a very inmature discipline compared with building houses.* the difference between software projects are much bigger than the difference between houses* software development is chaning much faster than house building

The result is that if a real architect draws a wall witha door then everybody (other architects, constructionworkers, customer) knows exactly what it is, but whena software architect draws a box labelled "Data AccessLayer" then 10 people reading it will have 11 opinionsabout what it really is.

Architect: Understands Businees needs, Know how to achieve them through use of Techonologies,Tools available to him. (By the above definition -- he must be called Software Engineer, but this designation is already taken).He has to see the solution/product where it is going to be depolyed, how it is going to be interacted with other system,how the usage will be. He should be able evaluate techonologies/tools impartially, have the capabilty to choose which one is better for his needs.

I doubt a senior developer can scale to this level, where he can understand those differeneces/needs for a solution.

I think Architect plays a key role in whole spectrum of Software engineering. Yes, if he doesn't know how to code, he is worthless. A real architect should be able to do the above and should know how to code/read code.

Disclaimer: I haven't read all the posts on this thread so what I have to say may already have been said.

At my workplace we didn't have the budget for a full-time architect. So we outsourced the 'Design' phase to an outside firm who did a really good job of, firstly, coming up with the overall solution and then refined that big picture to the extent that we had individual classes and methods in a UML diagram.

That's where our software developers (or engineers/coders/etc.) came in and completed the job by coding the actual functionality. This worked pretty well for us.

I can conclude from this experience, IMHO, there is a huge difference between an Architect and a Developer. An architect should be able to analyze the problem domain and *come up* with the proper solution framework whereas a competent Engineer is only required to *implement* the framework and all it's details. They are not expected to come up with those solutions themselves. As far as their regular day-to-day tasks goes, I don't expect an Architect to be able to do an Engineer's job or vice-versa. Couldn't you theoretically have an Architect who is really good at OOA/OOD deployed on a Smalltalk project where he/she doesn't know the specifics of the language too well? In that case they'll be great Architects but make lousy Developers.

That said, i have seen cases where the Software Engineer is so good (mainly through years of experience and interaction with other Architects) that they themselves are qualified to be Architects. (I would like to think of them as "Architects in denial" :)

I think the author of this article makes one big mistake. He tries to define roles by what they do rather than by what they have to achieve. As an architect I have to make sure that the resulting system has the level of modularity, scalability, security, robustness, extensibility, etc, that is required for that particular project.

Here's the important thing: What the architect actually does to achieve all this, depends entirely on the kind of project and above all on the number and experience of the people who work on it. If a project is staffed with 3 gurus, who take interest and pride in what they do, who are experts in all the technologies used and have a clear understanding of all the functional requirements, my role as an architect will be very different than on a team combining two business analysts and 10 junior programmers who are tasked with implementing something a customer hasn't even quite worked out for himself in terms of requirements.

In the first case, my role may be that of a visionary who leads the design debate on a very high level and who makes sure that people actually get things done instead of reimplementing the whole system once a month just to asymptotically approach the ultimate level elegance and beauty.

In the second case, I absolutely have to review critical parts of the code and write them myself if necessary. If I can't be sure that people understand threading, locking, isolation levels and other such things that absolutely have to be done right, it is my responsibility as an architect to get my hands dirty and make things work. Not because somebody wrote exactly this task into my job description, but because it follows from the responsibility I have for the robustness of the "finished" system.

In my view, managing risk is one of the most important tasks of an architect and it is really a meta task that can mean anything from selecting third party components to understanding the intricacies of one particular central algorithm or understanding where requirements are underspecified and go back to the customer or business analyst to sort it out.

To be an architect is about responsibilities and results, not about tasks.

If we would draw a use case to model a developement teamwe would have 2 actors, one who does the functions of systems architecture and another who is responsible of the code that implement the model.

Excellent point Ali. People are trying to make this too cut and dried mostly base on people they know and/or themselves.

There are those who make good developers but not good architects. They just can't see the bigger picture. But some can.

One thing I do believe is true - unless you are involved in development/use of the tools it is VERY difficult to understand the bigger picture (CTO/CIO/Architect/PM).Another thing - having a hierchal developement team is bad too. The ...

PMArchitect(s)Lead Developer(s)Developer(s)

... structure is not good. This goes back to roles, responsibilities and abilities. Of course, this means you have to actually pick good people.

Thus an architect must be adept in object-oriented methodologies, design patterns, and UML, and, more importantly, have the discipline to enforce standardized guidelines while following best practices.

Architects are all the great innovators in open source that wrote the first line of code. Senior developers are all the guys who mastered using them. Staff developers are all the guys that post more questions than solutions on forums. Angels are the guys that write documentation for us all.

Enterprise Architects should not even care about business. Their job is to provide, iterate and enhance a framework (set of components) that can fulfill all framework and plumbing requirements of all projects across enterprise.

“Enterprise Quality” Products architects and Open Source architects are visionaries and they are true “gurus”. For example, I would say that WebSphere / WebLogic / AXIS architects are far more competent then bunch of project specific architects.

Then we have a set of architects extending the enterprise components to provide project specific frameworks.

Hiring folks should know that what kind of work these architects will be doing. I am sure that a chief architect of Wall Street firm can’t even talk to WebSphere chief architect.

WebSphere architect would end up listing to some financial requirements. The Wall Street architect has no idea what happens in SCM industry. There is vast difference between designing a software platform vs. designing a computing platform.

There is vast difference between designing a software platform vs. designing a computing platform.

...and the purpose of a software architect is to transcend those boundaries, otherwise how could the financial institution develop an application that meets its needs and uses WebSphere as a component...

I want to clarify that I don't envision enterprise architects understanding project specific business requirements. I envision that an enterprise components ( lets say a communication component on top of JMS interfaces ) should meet ALL communication requirements of ALL projects across ALL functional units located at various pockets of world.

Project architects ( ? ) just need to extend and customize those to suit project requirements. Project specific architecture requirement can be promoted and encapsulated in enterprise components. Enterprise architecture component should be designed and tested with great care with 100% backward compatibility in mind, as 100s of in-house application depend on those components.

I would also say that project level architect does not make lot of sense. They are senior software engineers / developers. Pardon politics.

If the architect's job is to have supreme technical knowledge of the application being implemented, who's job is it to understand the application and business process as a whole? Who's job is it to understand how the application and business process fits in with other applications and business processes across the enterprise (or across customers)?

An individual needs to have this knowledge and vision, and this person must be recognized and respected by not only every person on every projects he works on, but by people on all related projects as well. This is the person who should be able to have three different customer stakeholders, a project manager, a project sponsor (the one with the $$$), a DBA, a developer, a system administrator, and an application administrator all sitting in a room disaggreeing on how some set of requirements should be met (or if they should be met at all), and be able to take from the disaggreement to aggreement. Every one of those people will try to justify his stance by diving so deep into the details of his respected discipline that no one else in the room will understand him. The architect (or whatever you want to call him) needs to be able to dive in with him, understand it, and communicate the relevant information to the rest of the group. The architect must be able to do this because the architect is responsible for ensuring the entire team has a clear and consistent vision. This is a HUGE task that requires an individual with an incredibly broad range and depth of talents.

Perhaps we should throw out the term architect because it has been abused so much that it no longer has any meaning within the software industry.

Perhaps we should throw out the term architect because it has been abused so much that it no longer has any meaning within the software industry.

The term still fits; how many software engineers have you worked with that should not have that title? If you create another role name it still will be bastardized.

Good definition of architect though.

I just wanted an excuse to use the following quote :-D, “Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity.” [The Mythical Man Month after 20 Years] Frederick Brooks Jr.

I disagree with this statement.You have to be care about the business in order to design a solution for a particular problem. As an architect you have to be able to articulate business requirement and translate them into architectural artifacts.

You would not hire an Arch. to build your house if he did no care about your needs.

Enterprise Architects should not even care about business. Their job is to provide, iterate and enhance a framework (set of components) that can fulfill all framework and plumbing requirements of all projects across enterprise.“Enterprise Quality” Products architects and Open Source architects are visionaries and they are true “gurus”. For example, I would say that WebSphere / WebLogic / AXIS architects are far more competent then bunch of project specific architects.&nbsp;Then we have a set of architects extending the enterprise components to provide project specific frameworks.Hiring folks should know that what kind of work these architects will be doing. I am sure that a chief architect of Wall Street firm can’t even talk to WebSphere chief architect.

The role of the enterprise architect is entirely about the business. Their role is to ensure that the enterprise IT matches and supports what the business wants to do. If you take a look at the zachman enterprise architecture framework (http://www.zifa.com) you will see that the top two layers (scope & business model) are all about the business and absolutely nothing to do with technology.

Enterprise Architects should not even care about business. Their job is to provide, iterate and enhance a framework (set of components) that can fulfill all framework and plumbing requirements of all projects across enterprise.“Enterprise Quality” Products architects and Open Source architects are visionaries and they are true “gurus”. For example, I would say that WebSphere / WebLogic / AXIS architects are far more competent then bunch of project specific architects.&amp;nbsp;Then we have a set of architects extending the enterprise components to provide project specific frameworks.Hiring folks should know that what kind of work these architects will be doing. I am sure that a chief architect of Wall Street firm can’t even talk to WebSphere chief architect.

The role of the enterprise architect is entirely about the business. Their role is to ensure that the enterprise IT matches and supports what the business wants to do. If you take a look at the zachman enterprise architecture framework (http://www.zifa.com) you will see that the top two layers (scope &amp; business model) are all about the business and absolutely nothing to do with technology.

I agree that Business process folks (Enterprise Architects?)will make business models, and possibly refactor them to reduce redundancy.Here's where I get lost. Do they throw that model over the fence to a java/j2ee architect, who will then convert them to Use Cases, thus begining the design/construction of a software system?

Well, why should Java architects be expected to traverse the role of a developer

Because you cant actually force people to do anything - especially not developers.

If you try and force them, they will just resent you for it, and make sure they do a crap job. And then blame you because it doesnt work.

You have to convince the developers that they want to do it your way.

To that extent, any "architect" that cant turn their "vision" into good working code will be ignored. Their "vision" will be seen as "theoretical" - and you will be dismissed as being clueless as to the problem (often, rightly so :-).

Ultimately, an architect's job is to get a team of developers to follow some direction, and have the developers think it was their own idea all along :-)

While I agree that architects may be overkill for a single project, they are absolutely essential for an environment in which there exists a suite of applications built to support evolutionary business processes that manipulate some aspect(s) of the same universe of data.

There needs to be an encompassing solution developed by a person or team who understands the business area, the technology(ies) chosen to implement the solutions, the data universe, and the supporting infrastructure. Especially if the application suite is to be supported by a small team. Having an architect can greatly reduce the amount of refactoring that typically goes on. A team that is constantly refactoring cannot have the time to develop something new...

Today, when people refer to a Java architect, most probably it's about a J2EE architect. Based on my "class hierarchy" of Architects, an J2EE architect should understand both the business and the J2EE very well, guru level preferred. An Enterprise architect might know little or just in high level about J2EE.

From the article and from the discussion, it is clear that the role of the software architect is not well defined. But there are organizations working on that. One of them is the already mentioned WWISA, another is the International Association of Software Architects and the other is the Software Engineering Institute (SEI).At http://www.sei.cmu.edu/architecture/ you’ll find definitions and descriptions of “architecture” and “architect,” as well as concrete techniques and resources that can help in the task of architecting software successfully.

A distinguishable ability an architect should have is to know ways to achieve quality attributes (or “non-functional rqmts” if you will) such as performance, availability, security, modifiability. These qualities are highly impacted by the architecture and cannot be dealt with only in the implementation phase.

At this point, I there isn't much more to add. Every time I got ready to write a reply someone would take the words out of my mouth (and I'm not one to blog a dead horse). What I will do, however, is add a little more context to the article. First off I was [am] a developer. Which is why I stated, "...in order to be a good architect, one must also be a skilled developer." Prior to that I was an implementation consultant. While in that role I had no development experience and simply taught people how to use applications. Upon recognizing there was an 'information gap' between users and developers, I began to traverse the role of a developer, in hopes of being able to provide information straight from the horse's mouth. However, after spending several years as a developer I realized there was also a gap between developers and business analysts (you know developers won't talk to people unless it's in an IM). In the end I realized what I enjoyed most about IT wasn't in writing the code, it was in solving problems. Hence, I worked my way into the role of an architect. The point is I've spent over 10 years traversing IT roles.

Like everyone else I have met good architects and bad architects. I've also met good developers and bad developers. Because of that, I'd never say an architect is more valuable than a developer because they can see the big picture. Nor would I say a developer is more important than an architect because they're better at coding. What I do believe is that regardless of our job titles we all have a passion or, a gift for doing something. Whether you're a project manager, architect, developer, business analyst, etc. And when you're able to fully express this passion it shows in your work. Personally, what gets me out of bed in the morning is the challenge of being able to sit down at the computer, wrack my brain until I'm sweating blood, in order to find the most efficient way to migrate a legacy EAS into the best darn 'loosely coupled' application I can. Nerdy, yes, but that's what sends chills of excitement up my spine. However, because there isn't a clear delineation between the role of an architect and developer, like many of you have mentioned, we're often prodded into roles that aren't in alignment with what we do BEST.

Now, from within that context the article could just as easily been titled, "Hiring the phantom project manager" or "Hiring the phantom business analyst." The difference, however, is that their roles and responsibilities have been defined in such a way that if they were asked to write code but replied, "It's not my responsibility" no one would think anything of it. Whereas if an architect were to say the same thing, he/she would be viewed as incompetent, lazy or not a team player. For example, when projects fall behind the tendency is to through more bodies [developers] at the problem instead of stepping back and fixing the problem that caused the slippage. That, IMO, is when it requires the discipline and leadership of an architect to say, "Developing is not my job," as a means to encourage the team [organization] to focus on fixing what 'caused' the project to slip. In this situation, an architects responsibility should be to determine things like 1) did he/she contribute to the slippage by over complicated the architecture 2) are there any existing components that can be re-used or created to reduce development time 3) what time constraints may have been overlooked during the inception and elaboration phase, etc. If these boundaries aren't set, yes, architects will inevitably end up writing poor code because that isn't they're specialty; and they'll produce less quality design because they're only doing it at a 50% capacity. Ironically, as OO programmers this type of efficiency is exactly what we try to avoid when designing applications (GRASP Patterns). Administering this disciplined approach to separation of responsibility within a team, and organization, is difficult. But if it isn't done we'll forever be stuck working in the chaotic firefighter mode.

The point of the article was to encourage the IT community to clearly defines roles so that as technologist we can fully utilize our skill set by bringing our passion and domain knowledge to our work. A four person team that consists of a project manager that enjoys meeting deadlines; an analyst that loves gathering requirements; an architect that loves OOA/OOD and a developer that loves to code will be one hundred time more productive than a 40 member team of people simply trying to get product out the door.

------------------------------Al Smith, Jr."I can make your Java Shake, Dance, Sing and even Swing!"

A four person team that consists of a project manager that enjoys meeting deadlines; an analyst that loves gathering requirements; an architect that loves OOA/OOD and a developer that loves to code will be one hundred time more productive than a 40 member team of people simply trying to get product out the door.

Very well put!

We need more of the passionate craftsman's pride of the old times instead of the fast-and-cheap-plastic-crap attitude of today.

To get the best outcome from a Java project, is it more recommended to hire both a Java architect and a developer? This might be a problem for smaller companies who have smaller budgets dedicated for the Java programming. Isn't the best case scenario someone who can do both well?

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.