Principles of System Architecture

Principle of Emergence (12) As the entities of a system are brought together, their interaction will cause function, behavior, performance, and other intrinsic properties to emerge.

Principle of Holism (20) Every system operates as a part of one large system or several larger systems, and each is itself composed of smaller systems.

Principle of Focus (22) The number of identifiable issues that will influence a system at any point is beyond one’s ­ability to understand. One must identify the most critical and consequential issues, and focus on them.

Principle of Dualism (78) All built systems inherently and simultaneously exist in the physical domain and the ­informational domain.

Principle of Benefit Delivery (91) Good architectures deliver benefit, first and foremost, built on the primary externally delivered function of the systems by focusing on the emergence of functions, and their delivery across the system boundary at an interface.

Principle of Value and Architecture (111) Value is benefit at cost. Architecture is function enabled by form. There is a very close relationship between these two statements, because benefit is delivered by function, and form is associated with cost.

Principle of Solution-Neutral Function (139) Poor system specifications frequently contain clues about an intended solution, function, or form, and these clues may lead the architect to a narrower set of potential options.

Principle of the Role of the Architect (180) The role of the architect is to resolve ambiguity, focus creativity, and simplify complexity.

Principle of Ambiguity (182) The early phase of a system design is characterized by great ambiguity. The architect must resolve this ambiguity to produce (and continuously update) goals for the architect’s team.

Principle of the Stress of Modern Practice (192) Modern product development process, with concurrency, distributed teams, and supplier engagement, places even more emphasis on having a good architecture.

Principle of Architectural Decisions (197) Separate architectural decisions from other decisions, and take the time to carefully decide them up front, because they will be very expensive to change later on.

Principle of Reuse of Legacy Elements (214) Understand the legacy system and its emergent properties thoroughly, and include the necessary elements in the new architecture.

Principle of Product Evolution (216) Systems will evolve or lose competitive advantage. When architecting, define the interfaces as the more stable parts of the system so that the elements can evolve.

Principle of the Beginning (229) The list of stakeholders (internal and external to the enterprise) that are included in the early stages of product definition will have an outsized impact on the architecture.

Principle of Balance (244) Many factors influence and act on the conception, design, implementation, and operation of a system. One must find a balance among the factors that satisfies the most important stakeholders.

Principle of the System Problem Statement (247) The statement of the problem defines the high-level goal and establishes the boundaries of the system. Challenge and refine the statement until you are satisfied that it is correct.

Principle of Ambiguity and Goals (252) The architect must resolve this ambiguity to produce (and continuously update) a small set of representative, complete and consistent, challenging yet attainable, and humanly solvable goals.

Principle of Creativity (267) Creativity in architecture is the process of resolving tensions in the pursuit of good architecture.

Principle of Apparent Complexity (289) Create decomposition, abstraction, and hierarchy to keep the apparent complexity within the range of human understanding.

Principle of Essential Complexity (292) Functionality drives essential complexity. Describe the required functionality carefully, and then choose a concept that produces low complexity.

Principle of the 2nd Law (295) The actual complexity of the system always exceeds the essential complexity. Try to keep the actual complexity close to the essential complexity.

Principle of Decomposition (296) Decomposition is an active choice made by the architect. The decomposition affects how performance is measured, how the organization should be set up, and the potential for supplier value capture.

Principle of “2 Down, 1 Up” (298) The goodness of a decomposition at Level 1 cannot be evaluated until the next level down has been populated and the relationships identified (Level 2).

Principle of Elegance (300) Elegance is appreciated internally by the architect when a system has a concept with low essential complexity and a decomposition that aligns many of the planes of decomposition simultaneously.

Principle of Robustness of Architectures (349) Good architectures can respond to change by being robust (capable of dealing with variations in the environment) or by being adaptable (able to adapt to changes in the environment).

Principle of Coupling and Organization of Architectural Decisions (354) The sequence of architectural decisions can be chosen by considering the sensitivity of the metrics to the decisions and the degree of connectivity of decisions.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.143.245.212