The systems architect's work should seek to avoid implementation issues and readily permit unanticipated extensions/modifications in future stages.
Systems architects interface with multiple stakeholders in an organization in order to understand the various levels of requirements, the domain, the viable technologies, and anticipated development process.
Their work includes determining multiple design and implementation alternatives, assessing such alternatives based on all identified constraints (such as cost, schedule, space, power, safety, usability, reliability, maintainability, availability, and other "ilities"), and selecting the most suitable options for further design.
They communicate with users/sponsors in a highly interactive, relatively informal way— together they extract the true requirements necessary for the designed (end) system.
If any compromises are to be made— to meet constraints- the architect must ensure that the final product and overall look and feel do not stray very far from the users' intent.
The engineer should focus on developing a design that optimizes the constraints but ensures a workable, reliable, extensible and robust product.
Architecture may also be seen as a simplified model of the finished end product— its primary function is to define the parts and their relationships to each other so that the whole can be seen to be a consistent, complete, and correct representation of what the users' had in mind— especially for the computer-human-interface.
But— the engineer thinks in terms of hardware and software and the technical solution space, whereas the users 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.
Many commercial-off-the-shelf or already developed hardware and software 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 or software engineer to select components and to design and build any special purpose function.
The architects (or engineers) may also enlist the aid of other specialists— in safety, security, communications, special purpose hardware, graphics, human factors, test and evaluation, quality control, reliability, maintainability, availability, interface management, etc.
Ideally, each such 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 heuristics to ensure that each partition is well defined and clean of kludges, work-arounds, short-cuts, or confusing detail and exceptions.
It is the chief means by which the program lead will prove to the users that the system is as originally planned and that all involved architects and engineers have met their objectives.
All stakeholders should sign off on the acceptance test descriptions, or equivalent, as the sole determinant of the satisfaction of the requirements, at the outset of the program.