Direct interaction with project engineers is generally discouraged as the chance of mutual misunderstanding is very high.
If any compromises are to be made—to meet constraints like cost, schedule, power, or space, the architect must ensure that the final product and overall look and feel do not stray very far from the user's intent.
The engineer should focus on developing a design that optimizes the constraints but ensures a workable and reliable product.
In the absence of an architect, there is an unfortunate tendency to confuse the two architectures, since the engineer thinks in terms of hardware, but the user may be thinking in terms of solving a problem of getting people from point A to point B in a reasonable amount of time and with a reasonable expenditure of energy, or of getting needed information to customers and staff.
They know the applications of hardware design and development intimately, apply their knowledge to practical situations—that is, solve real world problems, evaluate the cost–benefits of various solutions within their hardware specialty, and ensure the correct operation of whatever they design.
Many commercial-off-the-shelf or already developed hardware components may be selected independently according to constraints such as cost, response, throughput, etc.
Or, s/he may still need the help of a hardware engineer to select components and to design and build any special purpose function.
The architects (or engineers) may also enlist the aid of specialists—in safety, security, communications, special purpose hardware, graphics, human factors, test and evaluation, quality control, RMA, interface management, etc.
An effective hardware architectural team must have immediate access to specialists in critical specialties.
Ideally, each such hardware component/subsystem is a sufficiently stand-alone object that it can be tested as a complete component, separate from the whole, using only a simple testbed to supply simulated inputs and record outputs.
That is, it is not necessary to know how an air traffic control system works in order to design and build a data management subsystem for it.
The architect will use a minimum of rules to ensure that each partition is well-defined and clean of kludges, work-arounds, short-cuts, or confusing detail and exceptions.
And they act as the principal goal towards which all subordinate personnel must design, build and test for.
A well written set of requirements, or specification, is intelligible only to the engineering fraternity, much as a legal contract is for lawyers.