The systems architect is an information and communications technology professional. Systems architects define the architecture 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 its design and implementation.
The systems architect's work should seek to avoid implementation issues and readily permit unanticipated extensions/modifications in future stages. Because of the extensive experience required for this, the systems architect is typically a very senior technologist with substantial, but general, knowledge of hardware, software, and similar (user) systems. Above all, the systems architect must be reasonably knowledgeable of the users' domain of experience. For example, the architect 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.
The title of systems architect connotes higher-level design responsibilities than a systems engineer, software engineer or programmer, though day-to-day activities may overlap.
Overview
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. The output of such work sets the core properties of the system and those that are hardest to change later.
In small systems the architecture is typically defined directly by the developers. However, in larger systems, a systems architect should be appointed to outline the overall system, and to interface between the users, sponsors, and other stakeholders on one side and the engineers on the other. Very large, highly complex systems may include multiple architects, in which case the architects work together to integrate their subsystems or aspects, and respond to a chief architect responsible for the entire system. In general, the role of the architect is to act as a mediator between the users and the engineers, reconciling the users' needs and requirements with what the engineers have determined to be doable within the given (engineering) constraints.
In systems design, the architects (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 users' needs and other constraints.
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 users 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 architect.
Interfacing with the design and implementation engineers and architects, so that any problems arising during design or implementation can be resolved in accordance with the fundamental design concepts, and users' needs and constraints.
Ensuring that a maximally robust and extensible design is developed.
Generating a set of acceptance test requirements, together with the designers, test engineers, and the users, 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 users and the engineers constantly up to date and in agreement on the system to be provided as it is evolving.
Ensuring that all architectural products and products with architectural input are maintained in the most current state and never allowed to seriously lag or become obsolete.
Systems architect: topics
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 to very 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 architect. A complete layer at one level will be shown as a functional 'component' of a higher layer (and may disappear altogether at the highest layers).
Users and sponsors
Architects are expected to understand human needs and develop humanly functional and aesthetically-pleasing products. A good architect is also the principal keeper of the users' vision of the end product, and of the process of deriving requirements from and implementing that vision.
Architects do not follow exact procedures. They communicate with users/sponsors in a highly interactive, relatively informal way— together they extract the true requirements necessary for the designed (end) system. The architect must remain constantly in communication with the end users and with the (principal) systems engineers. Therefore, the architect must be intimately familiar with the users' 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 users and architect: the users bring their needs and wish list, the architect brings knowledge of what is likely to prove doable within the cost, time and other constraints. When the users 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 users will be absolutely clear about what they are 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 architect and engineer. 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. The provision of needed services to the users 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 have been found to be insufficient— the application of more general principles of systems, hardware, and software architecture to the design of (sub)systems is seen to be needed. 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. It is also used to ensure that the parts fit together and relate in the desired way.
It is necessary to distinguish between the architecture of the users' world and the engineered systems architecture. 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 architect, there is an unfortunate tendency to confuse the two architectures. 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. A systems architect is expected to combine knowledge of both the architecture of the users' world and of (all potentially useful) engineering systems architectures. The former is a joint activity with the users; the latter is a joint activity with the engineers. The product is a set of high-level requirements reflecting the users' 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, an architect is needed until the system is accepted by the user: the architect ensures that all changes and interpretations made during the course of development do not compromise the users' viewpoint.
Cost/benefit analyses
Architects 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 users' 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 architect can already assemble the end system (almost) 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 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. An effective systems architectural team must have access to specialists in critical specialties as needed.
Partitioning and layering
An architect planning a building works on the overall design, making sure it will be pleasing and useful to its inhabitants. While a single architect by himself may be enough to build a single-family house, many engineers may be needed, in addition, to solve the detailed problems that arise when a novel high-rise building is designed. If the job is large and complex enough, parts of the architecture may be designed as independent components. That is, if we are building a housing complex, we may have one architect for the complex, and one for each type of building, as part of an architectural team.
Large automation systems also require an architect and much engineering talent. If the engineered system is large and complex enough, the systems architect may defer to a hardware architect and/or a software architect for parts of the job, although they all may be members of a joint architectural team.
The architect 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 architect must never be viewed as an engineering supervisor. (If the item is sufficiently large and/or complex, the chief architect will sub-allocate portions to more specialized architects.) 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 architect 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 users, without special training. 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. 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.[1]
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. [2]
An embedded system is a specialized computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electronic system. It is embedded as part of a complete device often including electrical or electronic hardware and mechanical parts. Because an embedded system typically controls physical operations of the machine that it is embedded within, it often has real-time computing constraints. Embedded systems control many devices in common use. In 2009, it was estimated that ninety-eight percent of all microprocessors manufactured were used in embedded systems.
Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.
In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.
In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.
In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.
A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
Reliability engineering is a sub-discipline of systems engineering that emphasizes the ability of equipment to function without failure. Reliability is defined as the probability that a product, system, or service will perform its intended function adequately for a specified period of time, OR will operate in a defined environment without failure. Reliability is closely related to availability, which is typically described as the ability of a component or system to function at a specified moment or interval of time.
Computer-aided production engineering (CAPE) is a relatively new and significant branch of engineering. Global manufacturing has changed the environment in which goods are produced. Meanwhile, the rapid development of electronics and communication technologies has required design and manufacturing to keep pace.
A systems integrator is a person or company that specializes in bringing together component subsystems into a whole and ensuring that those subsystems function together, a practice known as system integration. They also solve problems of automation. Systems integrators may work in many fields but the term is generally used in the information technology (IT) field such as computer networking, the defense industry, the mass media, enterprise application integration, business process management or manual computer programming. Data quality issues are an important part of the work of systems integrators.
A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.
A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.
(In the automation and engineering environments, the hardware engineer or architect encompasses the electronics engineering and electrical engineering fields, with subspecialities in analog, digital, or electromechanical systems.)
In engineering, hardware architecture refers to the identification of a system's physical components and their interrelationships. This description, often called a hardware design model, allows hardware designers to understand how their components fit into a system architecture and provides to software component designers important information needed for software development and integration. Clear definition of a hardware architecture allows the various traditional engineering disciplines to work more effectively together to develop and manufacture new machines, devices and components.
System integration testing (SIT) involves the overall testing of a complete system of many subsystem components or elements. The system under test may be composed of electromechanical or computer hardware, or software, or hardware with embedded software, or hardware/software with human-in-the-loop testing. SIT is typically performed on a larger integrated system of components and subassemblies that have previously undergone subsystem testing.
An interface control document (ICD) in systems engineering and software engineering, provides a record of all interface information generated for a project. The underlying interface documents provide the details and describe the interface or interfaces between subsystems or to a system or subsystem.
Software security assurance is a process that helps design and implement software that protects the data and resources contained in and controlled by that software. Software is itself a resource and thus must be afforded appropriate security.
A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.
ARCADIA is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.
References
↑ 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.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
