An architect who specializes in a single language or technology is like Batman with a single pouch on his utility belt, or a painter with only a single color in their palette. In order to be most effective, an architect must strive to be continually adding to their palette. They must continuously diversify their knowledge with new technologies, new ideas, and new methodologies.
Calling me a Java architect implies that I am only capable of solving problems with Java solutions. It either means that there are certain problems which I just can't solve, or simply utilize the wrong tool to solve them (Java). Architects must be problem solvers and solution providers first, and any specialization in a single technology diminishes them.
During my career I've designed and developed professionally in variety of languages: C/C++, Oracle Forms, Visual Basic, Clipper, Progress 4GL, PERL, and yes… Java. I've self taught and dabbled in many others. So why am I labeled as a Java architect?
In my early days as a consultant in the early 90's, it was fashionable to provide a laundry list of languages on your resume. More tools meant a wider breadth of experience, which bagged you more gigs. That is, until Java entered the scene. Java took the industry by storm, and as a 'general purpose cross platform language' it played a part in polarizing the industry. Those companies which embraced Java did so fervently. With the zeal of a fanatic, enterprises created two categories of applications: Java and legacy.
Soon everyone had Java on their resume, and I began to notice interview candidates becoming more two dimensional as their non Java skills began to dry up. Java's growth in popularity was directly proportional to the expansion of the language itself. When I first laid hands on Java in the mid 90's, I wasn't impressed. The language felt slow and sloppy; a toy addition to Netscape (as XUL feels to Firefox today) rather than a full-fledged language to build applications with. Now Java has a robust set of language features coupled with a seemingly infinite supply libraries and frameworks. Like the great Roman Empire, Java's size is also one of its downfalls. It has become increasingly difficult for developers to comprehend the whole product suite. Resumes began appearing with claims of sub specialization within Java itself: J2EE, JMS, Swing, Struts, Hibernate, and Spring; expertise became focused on components of the language.
And so began the dark ages of software development. It was a time of great despair and sorrow, in which the narrowness and specialization of the resume pool equated to a biased technology strategy at the enterprise level. Many skills were restricted to narrow specializations (e.g. the average Java developer had horrible data modeling skills). This propagated to the enterprise level, causing specialized technicians ("architects") to prescribe one size fits all Java architectures across the company. Java became the de facto standard for everything from enterprise class web applications to back office infrastructure projects.
Over the past decade, there has been a shining light at the end of the tunnel. The dark ages have given birth to a renaissance of new thoughts and ideas. A revitalization in language development brought newfound attention to languages such as Ruby, F#, Groovy, and Scala. As developers once again added new languages to their repertoire, they found it increased their overall aptitude for software development. The experience they gained from learning new languages and techniques actually made them better Java programmers.
For an architect, knowledge in more than a single discrete technology is an advantage. A single technology focus is an indicator of a bias or limited view of the methods for creating business solutions. An architect must be able to express their solutions in multiple technologies. To go one step further, the architect should be required to express their solutions without the use of technology at all. I am reminded of my days as a consultant when one of my team's clients wished to build an inventory control system; our final recommendation was a more efficient use of inexpensive index cards.
For an architect, it is an imperative that we not allow our technology to define who we are. So please, stop calling me a Java architect.
written by Brian Disbrow
Brian Disbrow is a pragmatic software architect for over 5 years and slinging code for over 15. His software background spans the financial, insurance and inventory domains. Current passions are web development and corporate strategy.
Subscribe (RSS)
