Joshua Arnold

Buzzwords are alive and well in the software industry. From web 2.0, to service oriented architecture, to social media these phrases plague the lives of software developers. What’s interesting to me is that their very existence is beneficial to developers. It’s merely the lack of understanding of their purpose that ruins things for both the business and technical perspectives.

As a developer, these buzzwords cause havoc as management typically sees every single one as a silver bullet and an immediate and easy solution to any problem that they have. What’s more, these buzzwords are merely terms that have been coined to refer to an innovation of existing technologies that developers work with on a daily basis. The notion that implementing any one of these new terms could solve every problem is often viewed as insulting.

These terms exist to give meaning to those who do not understand the underlying technologies. They’re an attempt to bridge the ever-growing gap between the business and technical perspectives. No one can argue against the need for such a bridge in some capacity, but one can certainly agree on the misuse of this particular attempt. What is needed are individuals that are capable of seeing both perspectives and have the communication skills necessary to act as a facilitator. What we need are Architects.

“What I really do enjoy about being CSA [Chief Software Architect] is being at the juncture of business strategy, product and market strategy and technical strategy. I have the opportunity to work with not only the executive team on larger strategic issues, but also with the product teams at fairly detailed technical architectural levels. As an engineer, it is really fascinating …”

-    Ray Ozzie, Chief Software Architect, Microsoft

Among the many other responsibilities of an Architect, they fill this facilitating role quite often. Sitting through requirements sessions, mentoring other members of the team, managing the knowledge of the team, and ultimately leading the team are several of their other responsibilities.

If you do your homework on the term Architect, chances are you’re going to come up with too many definitions to keep track of. You’ll find terms like:

• Systems Architect
• IT Architect
• Information Architect
• Solution Architect
• Etc.

You’ll also most likely see the role of Architect as being comparable to that of an Architect in the construction industry. Martin Fowler points out the flaws in this metaphor in his Building Architect article. I’ve found the following quote as one of his most compelling statements:

“In particular an architect is not responsible for the structural integrity of the building. That’s the role of the structural engineer, such as my wife Cindy. An architect will call a structural engineer to make his building stand up – usually, by this time, it’s too late to make changes that would allow the structure to be efficient. A building will also require electrical and mechanical engineers too, with the same consequences from the architect’s initial role.

However despite the fact that the architect is one amongst several professionals on the team, he is the one that handles all the conversation with the client. An architect has overview training from college as well as his gleamed experiences in all disciplines that require a building to be designed, however, it is impossible that he can speak for all disciplines without their input.”

-    Martin Fowler, Chief Scientist, ThoughtWorks

Architects essentially act as a coordinator of all knowledge areas. They themselves have expertise in a wide variety of the areas but are typically capable of delegating particular assignments to members of the team that are qualified to complete them. Skilled Architects, like most good leaders, are capable of mentoring members of the team and training them to take the lead on particular areas of the project.

Tasked with knowledge management, always keeping the big picture in mind, and laying out the blueprints for systems, it’s not a role that is easily filled. The best systems are those that are designed to change. Structuring processes around change management will always give you a competitive advantage and as the leader of the team, Architects are responsible for doing so.
For more information, see Martin Fowler’s popular article: Who Needs an Architect?