For many developers, a management role is not always the preferred career option, making a position as lead or system architect the better choice. Here is some advice on how to further your career by becoming an effective IT architect.
This is not a bad time to be a technologist. Management can be overrated (perhaps you have tasted the fruits of management and realised you prefer to be an "individual contributor"), and managers seem to be the most common layoff victims. Plus, many top technical positions yield paycheques rivaling those of senior management. Typically, these highly coveted jobs carry titles such as chief technology officer, software architect, or lead developer.
People in these positions are responsible for making informed decisions regarding the direction of an information system implementation. In fact, they must make decisions that significantly affect the company's competitive advantage. The term architect is typically used to describe such people, because they are building a foundation upon which the company will rely.
It is one thing to be known as an architect, but being an effective architect is another altogether. I have met many so-called architects who would be more accurately called senior developers. In this article, I will describe the requirements for becoming an effective architect.
Understand present and past technology
To be an effective, architects must understand not only the latest technologies in the pipeline but also the preceding technologies. This seems to be particularly difficult for newer developers who have only recently entered into professional software development. For example, new computer science graduates may know full well what a three-tier architecture looks like, but they may not understand its advantages over a client server architecture. It is not enough to know that the three tiers are Presentation, Business Rules, and Data; the architect must understand the progression of technologies to fully appreciate the inherent value in a particular architecture.
Be prepared to conduct and analyse validation
An architect must conduct technology validation and set corporate direction based on the findings. Many corporations are just beginning to understand the importance of this role. It is no longer acceptable to entrust all technology decisions to the most senior person. Many companies have lost millions of dollars because they failed to consider the overall architectures of their solutions. They now spend large sums integrating the disparate systems within their organisations.
Know your buzzwords
Below is a quick list of a few industry buzzwords that any self-respecting architect should readily understand and know when to use:
- Database independence
- Platform independence
- Scalability
- Performance
- Microsoft Transaction Server (MTS)
- Enterprise JavaBeans (EJB)
- Extensible Markup Language (XML)
- Load balancing
- Active Server Pages (ASP)
- Java Server Pages (JSP)
- Servlets
- Clustering
- Active/active failover
- Redundancy
- Design patterns
- Wireless Access Protocol (WAP)
- Application Service Provider (ASP)
As an architect, it will be your job to eat, drink, and smell these terms in your sleep. You must understand the different technologies residing in each tier in a 3-tier architecture. For example, what is HTML, where does it reside, and how does it relate to XHTML? And even more important, is a move toward XHTML warranted within your organisation? The answers to these questions would be: HTML is a presentation technology residing in the presentation tier. XHTML is a reformulation of the HTML specification made to conform to XML standards. It is not likely that your organisation should invest in XHTML, because the industry will not be recoding HTML pages. This would be too costly, especially since there is no compelling business value in doing so.
Architects must understand the relationship of Jscript, JavaScript, and VBScript and the differences between using Servlets, JSP, and ASP. Knowledge regarding the technologies residing in the business logic tier is critical, as well. For instance, do you know when you would use a messaging queue? What choices do you have for messaging servers?
Click here for section two of the interview.
