Hardware architect

(In the automation and engineering environments, the hardware engineer or architect encompasses the electronic engineering and electrical engineering fields, with subspecialities in analog, digital, or electromechanical systems.)

The hardware systems architect or hardware architect is responsible for:

Large systems architecture was developed as a way to handle systems too large for one person to conceive of, let alone design. Systems of this size are rapidly becoming the norm, so architectural approaches and architects are increasingly needed to solve the problems of large systems.

Engineers as a group do not have a reputation for understanding and responding to human needs comfortably or for developing humanly functional and aesthetically pleasing products. Architects are expected to understand human needs and develop humanly functional and aesthetically pleasing products. A good architect is a translator between the user/sponsor and the engineers—and even among just engineers of different specialties. A good architect is also the principal keeper of the user's vision of the end product—and of the process of deriving requirements from and implementing that vision.

Determining what the users/sponsors actually want, rather than what they say they want, is not engineering—it is an art. An architect does not follow an exact procedure. S/he communicates with users/sponsors in a highly interactive way—together they extract the true requirements necessary for the engineered system. The hardware architect must remain constantly in communication with the end users (or a systems architect). Therefore, the architect must be familiar with the user's environment and problem. The engineer need only be very knowledgeable of the potential engineering solution space.

The user/sponsor should view the architect as the user's representative and provide all input through the architect. Direct interaction with project engineers is generally discouraged as the chance of mutual misunderstanding is very high. The user requirements' specification should be a joint product of the user and hardware architect (or, the systems and hardware architects): the user brings his needs and wish list, the architect brings knowledge of what is likely to prove doable within cost and time constraints. When the user needs are translated into a set of high level requirements is also the best time to write the first version of the acceptance test, which should, thereafter, be religiously kept up to date with the requirements. That way, the user will be absolutely clear about what s/he is getting. It is also a safeguard against untestable requirements, misunderstandings, and requirements creep.

...
Wikipedia