work-arounds, short-cuts, or confusing detail and exceptions. As users needs evolve, (once the system is fielded and in use), it is a lot easier subsequently to evolve a simple concept than one laden with exceptions, special cases, and much "fine print." Layering the architecture is important for keeping the architecture sufficiently simple at each layer so that it remains comprehensible to a single mind. As layers are ascended, whole systems at lower layers become simple components at the higher layers, and may disappear altogether at the highest layers. Acceptance test The acceptance test is a principal responsibility of the systems architect. 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. Communications with users and engineers A building architect uses sketches, models, and drawings. An automation systems (or software or hardware) architect should use sketches, models, and prototypes to discuss different solutions and results with users, engineers, and other architects. An early, draft version of the users' manual is invaluable, especially in conjunction with a prototype. Nevertheless, it is important that a workable, well written set of requirements, or specification, be created which is reasonably understandable to the customer (so that they can properly sign off on it, but the principal users' requirements should be captured in a preliminary users' manual for intelligibility). But it must use precise and unambiguous language so that designers and other implementers are left in no doubt as to meanings or intentions. In particular, all requirements must be testable, and the initial draft of the test plan should be developed contemporaneously with the requirements. 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. Architect metaphor The use of any form of the word "architect" is regulated by "title acts" in many states in the US, and a person must be licensed as a building architect to use it. In the UK the architects registration board excludes the usage of architect (when used in the context of software and IT) from its restricted usage. See also Enterprise architecture Enterprise architect Hardware architecture Requirements analysis Software architecture Software engineering Systems architecture Systems modeling Systems engineering Systems design Business analyst Service-oriented modeling framework (SOMF) References Further