Yesterday, I read Fowler’s “Who Needs an Architect” , which is an odd piece that never really answer the question to my liking, but it did get me thinking.

For me, being an IT architect is a full time job that has many facets. One facet is designing systems and applications; this facet is primarily controlled by experience. This facet incorporates requirements gathering, joint application design (JAD) and planning. The more hands-on experience that an architect has, the greater the likelihood that the design of the system will meet the requirements while requiring few modifications to support growth and longevity. This does not mean that we cannot build extensible systems in a generic manner, but ultimately, being able to balance generality with domain-specific knowledge, which requires seeing ten steps ahead, will deliver a system that is most capable for the domain that it is being deployed. This is where I spend the bulk of my time, 65%-80%.

Another facet of being an architect is staying abreast of changes in the field. One day you’re arguing the best CORBA persistence mechanism with Chris Stone of the OMG and before you know it you’re faced with the need to understand the implications of using Struts, Spring & Hibernate. In this field, things change at an incredible pace. I try to spend 15%-20% of my time keeping abreast of emerging technologies and it’s difficult at that pace. Why is this important for an architect? Because there’s a lot of ideology around these tools and they have the capability to speed development, but they also have the equal capability to cripple performance and testing. It’s important for the architect to understand how technology choices will impact delivery, deployment and maintenance.

The final facet of being an architect is relating design decisions to a diverse population of stakeholders, which includes business representatives, peer architects, management, quality control and users. It’s known that people hear subjectively based on their own experiences, so when you’re presenting a vision of the future state of an existing system, or the more difficult, the design of a new system, where there is no experience to pull upon, one wrong word and the sand trap opens swallowing you up. You’ll spend so long explaining your way out of the trap that the entire vision and all the value it brings will be lost. I spend 5%-8% of my time reading articles and books that help with leadership and influence issues to assist with this responsibility. For me, I also do a lot of education as a way of sharing, which includes blogging, writing books and speaking, so I include that in this facet as well, but I don’t believe it’s necessary for all architects to be educators as well.

What’s most important is that I have found that these three facets feed each other. Many architects I know do one, maybe two of these, but I have found that the trinity is what creates a well-rounded architect capable of bringing value to IT processes.

So, to answer Mr. Fowler, architects are critical members of the IT team that lead the efforts to deliver systems and applications for the business that meet their needs in the shortest time frame without sacrificing growth and performance. The business needs them!