Systems architect

Systems Designer
Systems designers divide large and complex systems into manageable subsystems that can be handled by individual engineers.
Occupation
Names Systems designer
Occupation type
 Profession
Activity sectors
 Systems Engineering
Systems
Design
Engineering
Description
Competencies user domain knowledge, scientific knowledge, engineering, planning and management skills
Education required
 see professional requirements

The systems designer is a professional figure in information and communications technology. Systems designers define the Systems design of a computerized system (i.e., a system composed of software and hardware) in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces (including with the environment, especially the user), and the technologies and resources to be used in the design.

The Systems designer's work must avoid implementation issues and readily permit unanticipated extensions/modifications in future stages. Because of the extensive experience required for this, the Systems designer is typically a very senior technician with substantial, but general, knowledge of hardware, software, and similar systems. But above all, the systems designer must be reasonably familiar with the users' domain of experience (that is, the designer of an air traffic system needs to be more than superficially familiar with all of the tasks of an air traffic system, including those of all levels of users).

Overview

Systems designers interface with multiple stakeholders in an organization in order to understand the various levels of requirements, the domain, the viable technologies, and anticipated development. Their work includes determining multiple design alternatives, assessing such alternatives based on all identified constraints (such as cost, schedule, space, power, safety, usability, reliability, maintainability, availability, and so on), and selecting the most suitable options for further design. The output of such work sets the core properties of the system, and those that are hardest to change later.

In small systems the design is typically defined directly by developers. In larger systems, a Systems designer may be appointed to outline the overall system and interface with the users and stakeholders. Very large, highly complex systems may include multiple designers, in which case the designers work together to integrate their subsystems or aspects, and may respond to a Chief designer responsible for the entire system.

In systems design, the designers and engineers are responsible for:

  • Interfacing with the user(s) and sponsor(s) and all other stakeholders in order to determine their (evolving) needs.
  • Generating the highest level of system requirements, based on the user's needs and other constraints.
  • Ensuring that this set of high level requirements is consistent, complete, correct, and operationally defined.
  • Performing cost–benefit analyses to determine whether requirements are best met by manual, software, or hardware functions; making maximum use of commercial off-the-shelf or already developed components.
  • Developing partitioning algorithms (and other processes) to allocate all present and foreseeable requirements into discrete partitions such that a minimum of communications is needed among partitions, and between the user and the system.
  • Partitioning large systems into (successive layers of) subsystems and components each of which can be handled by a single engineer or team of engineers or subordinate designer.
  • Interfacing with the design and implementation engineers and designers, so that any problems arising during design or implementation can be resolved in accordance with the fundamental design concepts, and user needs and constraints.
  • Ensuring that a maximally robust design is developed.
  • Generating a set of acceptance test requirements, together with the designers, test engineers, and the user, which determine that all of the high level requirements have been met, especially for the computer-human-interface.
  • Generating products such as sketches, models, an early user guide, and prototypes to keep the user and the engineers constantly up to date and in agreement on the system to be provided as it is evolving.

Systems designer: topics

Large systems design 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 design approaches and designers are increasingly needed to solve the problems of large systems. In general, increasingly large systems are reduced to 'human' proportions by a layering approach, where each layer is composed of a number of individually comprehensible sub-layers-- each having its own principal engineer and/or designer. A complete layer at one level will be shown as a functional 'component' of a higher layer.

Users and sponsors

designers are expected to understand human needs and develop humanly functional and aesthetically pleasing products. A good designer 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.

designers do not follow exact procedures. They communicate with users/sponsors in a highly interactive way— together they extract the true requirements necessary for the designed system. The designer must remain constantly in communication with the end users and with the (principal) systems engineers. Therefore, the designer must be intimately familiar with the user's environment and problem, and with the engineering environment(s) of likely solution spaces.

High level requirements

The user requirements' specification should be a joint product of the user and designer: the user brings his needs and wish list, the designer brings knowledge of what is likely to prove doable within cost, time and other 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.

The development of the first level of engineering requirements is not a purely analytical exercise and should also involve both the designer and engineer. If any compromises are to be made— to meet constraints- the designer 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. The provision of needed services to the user is the true function of an engineered system. However, as systems become ever larger and more complex, and as their emphases move away from simple hardware and software components, the narrow application of traditional systems development principles has been found to be insufficient— the application of more general principles of systems, hardware, and software design to the design of (sub)systems is seen to be needed. A design 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 user had in mind— especially for the computer-human-interface. It is also used to ensure that the parts fit together and relate in the desired way.

It is necessary to distinguish between the design of the user's world and the engineered systems design. The former represents and addresses problems and solutions in the user's world. It is principally captured in the computer-human-interfaces (CHI) of the engineered system. The engineered system represents the engineering solutions— how the engineer proposes to develop and/or select and combine the components of the technical infrastructure to support the CHI. In the absence of an experienced designer, there is an unfortunate tendency to confuse the two designs. But— the engineer thinks in terms of hardware and software and the technical solution space, whereas 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. A systems designer is expected to combine knowledge of both the design of the user's world and of (all potentially useful) engineering systems designs. The former is a joint activity with the user; the latter is a joint activity with the engineers. The product is a set of high level requirements reflecting the user's requirements which can be used by the engineers to develop systems design requirements.

Because requirements evolve over the course of a project, especially a long one, a designer is needed until the system is accepted by the user: the designer ensures that all changes and interpretations made during the course of development do not compromise the user's viewpoint.

Cost/benefit analyses

designers are generalists. They are not expected to be experts in any one technology but are expected to be knowledgeable of many technologies and able to judge their applicability to specific situations. They also apply their knowledge to practical situations, but evaluate the cost/benefits of various solutions using different technologies, for example, hardware versus software versus manual, and assure that the system as a whole performs according to the user's expectations.

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. In some cases, the designer can already assemble the end system unaided. 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 designers (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. An effective systems design team must have access to specialists in critical specialities as needed.

Large automation systems also require a designer and much engineering talent. If the engineered system is large and complex enough, the systems designer may defer to a hardware designer and a software designer for parts of the job, although they all may be members of a joint design team.

The designer should sub-allocate the system requirements to major components or subsystems that are within the scope of a single hardware or software engineer, or engineering manager and team. But the designer must never be viewed as an engineering supervisor. (If the item is sufficiently large and/or complex, the chief designer will sub-allocate portions to more specialized designers.) 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. It is only necessary to know the constraints under which the subsystem will be expected to operate.

A good designer ensures that the system, however complex, is built upon relatively simple and "clean" concepts for each (sub)system or layer and is easily understandable by everyone, especially the user, without special training. The designer 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. As user 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 lots of "fine print."

Layering the design is important for keeping the design 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 designer. It is the chief means by which the program lead will prove to the user that the system is as originally planned and that all involved designers and engineers have met their objectives.

Communications with users and engineers

An automation systems (or software or hardware) designer should use sketches, models, and prototypes to discuss different solutions and results with users, engineers, and other designers. An early, draft version of the user's 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 user requirements should be captured in a preliminary user 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.[1]

In the UK the architects registration board excludes the usage of architect (when used in context of software and IT) from its restricted usage. [2]

See also

References

  1. ↑ The term "architect" is a professional title protected by law and restricted, in most of the world's jurisdictions, to those who are trained in the planning, design and supervision of the construction of buildings. In these jurisdictions, anyone who is not a licensed architect is prohibited from using this title in any way. In the State of New York, and in other US states, the unauthorized use of the title "architect" is a crime and is subject to criminal proceedings."Architecture: What's Legal, What's Not" (PDF). AIA New York State. Retrieved 9 July 2012. "NYS Architecture:Laws, Rules & Regulations:Article 147 Architecture". Retrieved 9 July 2012.
  2. ↑ "What we do to regulate use of the title 'architect'". Architects Registration Board. Retrieved 1 December 2015.

Further reading

  • Donald Firesmith et al.: The Method Framework for Engineering System Architectures, (2008)
  • Mark W. Maier and Rechtin, Eberhardt, The Art of Systems Architecting, Third Edition (2009)
  • Gerrit Muller, "Systems architecting: A business perspective," CRC Press, (2012).
  • Eberhardt Rechtin, Systems Architecting: Creating & Building Complex Systems, 1991.
  • J. H. Saltzer, M. F. Kaashoek, Principles of Computer System Design: An Introduction, Morgan Kaufmann, 2009.
  • Rob Williams, Computer Systems Architecture: a Networking Approach, Second Edition (December 2006).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.