...Unless you are talking about the architect who designed the Java platform, like James Gosling, or the other six guys who designed the thing with him way back when.
An architect is an architect whatever the implementation platform. Anyone who claims to be an "Java Architect" is no architect at all.
An architect can specialize in Java based systems, just as an architect can specialize in Windows based systems or Unix based systems. But an architect who knows only Java run the risk of proposing inferior systems.
That's why the pragmatic programmers suggested to learn a new language every year.
But what language do you learn? And to what extent? I'm tired of people saying "Ruby is so OO," and following up with "Everything is an object, even blocks." I'm sorry, when "everything is" something, nothing is. And blocks are not objects no matter what the syntax.
Likewise for all the talks about closures, lambdas, and continuations. These are cool concepts but no OO. Just learn Lisp and be done with it already.
Another reason we learn new things is out of fear: the fear of obsolescence. New things come out every year. They all claim to be the ultimate solution to every problem. But you can't possibly learn all of them or you don't have time to work and live.
The trick is learn the essentials of the art and science of the programming trade, and distinguish the new new thing from the new old thing. The technical press is no help at all for their constant hypes of one thing after another. Big commercial vendors are even worse.
I did not witness this but Dale said yesterday that Cobol was to be the ultimate solution back when it was introduced. The press hyped it just like they are hyping SOA today and (the next big thing) tomorrow. The same thing happened for SQL—the SQL that we all want to wrap, hide, map, and otherwise remove from view today.
I salute the person who took one look at the SOAP spec, said "This will never work," and moved on to other things.
By and large, the problems we want to solve in our daily works are solvable and have been solved many times. Recognizing what the problem is and provide a road map to an efficient solution, both in terms of man-months and in terms of CPU-seconds, is the job of the architect.
If that road map says "Cobol!" so be it.
Truly revolutionary things have the habit of quietly sneak up on you. They are usually done by a teenager or a college kid. They never present themselves initially with a bang.
How do you find them out? I don't know.
Now back to work. Boring, tedious work where error handling cannot be omitted to "limit the length of this article" or "left as an exercise for the reader!"
Previous Topic
