Contribution 23

From WikiContent

Revision as of 16:23, 14 July 2008 by Rmonson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Architects must be hands on

A good architect should lead by example, he/she should be able to fulfil any of the positions within his/her team from wiring the network, and configuring the build process to writing the unit tests. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology. As has been said elsewhere the architect is the interface between the business and the technology team, the architect must understand every aspect to be able to serve the business without having to refer others. Similarly the architect must understand the business in order to drive the team toward their goal of serving the business.

An architect is like an airline pilot, they might not look busy all of the time but they use their decades of experience constantly monitor the situation, taking immediate action if they see or hear something out of the ordinary. The project manager (co-pilot) performs the day to day management tasks leaving the architect to free from the hassles of mundane tasks and people management. Ultimately the architect should have responsibility for the delivery and quality of the project(s) to the business, this is difficult to achieve without authority and this is critical their success.

People learn best by watching others, it's how we learn as children. An architect who can demonstrate by example in front of others is vital, a good architect should be able to spot a problem, call the team together and without picking out a victim explain what the problem is or might be and provide an elegant work-around or solution. It is perfectly respectable for an architect to ask for help from the team, they should feel part of the solution but the architect should chair from discussion and identify the right solution(s).

Architects should be bought into the team at the earliest part of the project, they should not sit in an ivory tower dictating the way forward but should on the ground working with the team. Questions about direction or choices of technology should not be spun off into separate investigations or new projects but be made pragmatically using advice from architect peers (architects are well connected) or through hands-on investigation.

An good architect should be an expert in at least one tool of his/her trade, e.g. an IDE, remember they are hands-on. It stands to reason that a software architect should know the IDE, a database architect should know the ER tool and an information architect an XML modelling tool but a technical or enterprise architect should be at least effective with all levels of tooling from being able to monitor network traffic with Wireshark to modelling a complex financial message in XMLSpy.

An architect usually comes with a good resume and impressive past, they can usually impress the business and technologists but unless he/she can demonstrate their ability to perform most tasks hands-on it's difficult gain the respect of the team, difficult for the team to learn and almost impossible to deliver what they were originally employed to do.

By John Davies

(Edited RMH 7/14/2008)

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools