Search

The purpose of this paper is to report on a new system-theoretic based methodology and corresponding model for Enterprise Architecture development. This model captures the essence of the strategic, conceptual, doctrinal layer of the organization. Reusable Quality Technical Architectures (RQ-Tech) graphically reveals a comprehensive array of enterprise decision alternatives in easily understandable views; all while maintaining the hyperlinks to its provenance in strategic authoritative documentation. The RQ-Tech method has combined the practice of Enterprise Architectures with a modern perspective grounded in Systems Theory and the theory regarding the computer science-oriented Semantic Web. This recombination results in a distinctive methodology for developing models. This new methodology supports the conclusion that system-specific solutions produce islands of technology and can be prevented by employing better enterprise change planning. A review of the literature in three major areas illustrates the ov...

As problems have evolved from simple systems to complex systems, so too must the methods we use to address them. However, machine age problems, consisting of simple systems, have traditionally been viewed from a largely technical perspective. In systems age complex problems, a predominantly technical perspective continues to be used at the expense of other complementary perspectives. Complex problems have been viewed, and hence, addressed, with a single predominant lens which has often been unsuccessful in solving many ill-structured, wicked, or messy problems. The development of multiple perspectives requires those faced with solving complex problems to include additional perspectives in order to achieve understanding. This includes the integration of hard and soft perspectives to ensure that, in addition to the technical perspective, the equally important organizational, political and human perspectives have been included. The application of multiple perspectives offers a more inclusive framework through which complex problems may be viewed. The integration of technical, organizational, political and human perspectives widens the aperture through which a problem is analyzed, which then increases the probability of correctly addressing ill-structured, wicked, and messy problems. Embracing these complementary perspectives, guidance is given on how to begin to decompose our mess into a number of discrete problems for analysis.

Modeling is a necessary mechanism for understanding complex phenomena such as the messes this book is designed to help with. This chapter compares methods available for complex systems modeling. A method is then recommended for use in addressing messes. A framework for the development and use of such a model and an accompanying simulation is then presented. This framework is demonstrated on an example problem, with an eye toward using this approach to first think about, then act on, and finally observe our mess systemically.

By now we all know that our mess is composed of multiple problems which all interact in some capacity. This mess can be thought of in terms of its actual state and its desired state. We also know that if the desired and actual states are the same, we have no decision to make as we do not have a problem. If, however, there is a delta between the two, we need to invoke a decision process in an attempt to bridge the gap. This involves creating a model of our mess utilizing the actual state of our system as best we know (as we have done in Chaps. 6– 12). This modeled state, along with a desired state, feeds into a decision process. The output of this decision process is a decision or set of decisions which provide feedback through action (and the result of our action) to our mess and its constituent problems. This set of relationships is shown in Fig. 13.1. This chapter aims to elaborate on the decision process element in Fig. 13.1. We first begin with discussing some basics of decision analysis and decision science. We then proceed to discuss the decision process and how we can execute it. This leads to a framework for action in our mess.

Traditional systems engineering (SE) has been successful in developing requirements that are objective, verifiable, and definitive. These requirements are chiefly related to technical or technological issues necessary to achieve a desired level of system performance. In contrast, System of Systems Engineering (SoSE) engages a more complex and holistic problem space, including organizational, managerial, policy, human/social, and political dimensions that exist in conditions of emergence, ambiguity, and uncertainty; therefore, the traditional SE requirements paradigm must be called into question. At present, the SoSE requirements paradigm has not reached the level of maturity or sophistication experienced by traditional SE. It is a miscalculation to expect successful approaches for SE requirements development to enjoy the same level of success when applied directly to the SoSE problem domain. The purpose of this article is to explore the nature of requirements from an SoSE perspective. First, the ...

The design of systems and components during the design stage of the systems life cycle requires specific purposeful actions to ensure effective designs and viable systems. Designers are faced with a number of design concerns that they must embed into the design in every instance of thinking and documentation. Four of these concerns are addressed by the non-functional requirements for conciseness, modularity, simplicity, and traceability. Formal understanding of each of these non-functional requirements requires definitions, terms, and equations, as well as the ability to understand how to control their effect and measure their outcomes during system design endeavors.

The design of systems and components during the design stage of the systems life cycle requires specific purposeful actions to ensure effective designs and viable systems. Designers are faced with a number of adaptation concerns that they must embed into the design in every instance of thinking and documentation. The ability for a system to adapt is essential to its continued survival and ability to provide requisite functions for its stakeholders. Adaptation concerns includes the non-functional requirements for extensibility, portability, reusability, and self-descriptiveness. Purposeful design requires an understanding of each of these requirements and how to measure and evaluate each as part of an integrated systems design.

This book will help readers gain a solid understanding of non-functional requirements inherent in systems design endeavors. It contains essential information for those who design, use, and maintain complex engineered systems, including experienced designers, teachers of design, system stakeholders, and practicing engineers. Coverage approaches non-functional requirements in a novel way by presenting a framework of four systems concerns into which the 27 major non-functional requirements fall: sustainment, design, adaptation, and viability. Within this model, the text proceeds to define each non-functional requirement, to specify how each is treated as an element of the system design process, and to develop an associated metric for their evaluation. Systems are designed to meet specific functional needs. Because non-functional requirements are not directly related to tasks that satisfy these proposed needs, designers and stakeholders often fail to recognize the importance of such attributes as availability, survivability, and robustness. This book gives readers the tools and knowledge they need to both recognize the importance of these non-functional requirements and incorporate them in the design process

The design of systems and components during the design stage of the systems life cycle requires specific purposeful actions to ensure effective designs and viable systems. Designers are faced with a number of design concerns that they must embed into the design in every instance of thinking and documentation. Three of these concerns are addressed by the non-functional requirements for compatibility, consistency, and interoperability. Formal understanding of each of these non-functional requirements requires definitions, terms, and equations, as well as the ability to understand how to control their effect and measure their outcomes during system design endeavors.

Effective sustainment of systems and components during the operation and maintenance stages of the system life cycle require specific purposeful actions during the design stages of the system life cycle. The reliability and maintainability of the system and its constituent components are established as part of the system design process. Reliability and maintainability are non-functional requirements that exists at both the component- and system-level and are intertwined and interrelated. Improper reliability and maintainability designs in any level of the system’s hierarchy may have far reaching affects. The ability to understand how reliability and maintainability are treated in the design process and formal metrics and measurement processes for each non-functional requirements are essential during all system design endeavors.

Engineering Systems, the man-made systems that provide important functions in modern societies, are designed by engineers. The design of engineering systems is a formal process which invokes both technical and human elements to provide the blueprint for systems which simultaneously provide for the needs of a system’s stakeholders while not harming the environment or living beings. Engineering design is the term used for the formal processes and methodologies used to create and maintain man-made systems in a life cycle that runs from inception through retirement and disposal .

Effective sustainment of systems and components during the operation and maintenance stages of the system life cycle require specific purposeful actions during the design stages of the system life cycle. The availability and testability of the system and its constituent components are essential to ensure that the systems continues to provide the required functions to its stakeholders. Availability and testability are non-functional requirements that exists at both the component- and system-level and are intertwined and interrelated. Inattention to testability concerns may lead to decreased availability having far reaching affects that include the systems own viability. The ability to understand how availability and testability are implemented in the design process and formal metrics and measurement processes for each non-functional requirements ensure that they are adequately addressed during all system design endeavors.

The design of systems and components during the design stage of the systems life cycle requires specific purposeful actions to ensure effective designs and viable systems. Designers are faced with a number of adaptation concerns that they must embed into the design in every instance of thinking and documentation. The ability for a systems to change is essential to its continued survival and ability to provide requisite functions for its stakeholders. Changeability includes the non-functional requirements for adaptability, flexibility, modifiability and robustness. Purposeful design requires an understanding of each of these requirements and how to measure and evaluate each as part of an integrated systems design.

The design of systems and components during the design stage of the systems life cycle requires specific purposeful actions to ensure effective designs and viable systems. Designers are faced with a number of other viability concerns that they must embed into the design to ensure the system remains viable. The ability for a system to remain viable is critical if it is to continue to provide required functionality for its stakeholders. Other viability concerns includes the non-functional requirements for accuracy, correctness, efficiency, and integrity. Purposeful design requires an understanding of each of these requirements and how to measure and evaluate each as part of an integrated systems design.

One of the most easily understood tasks during any systems design endeavor is to define the systems functional requirements. The functional requirements are a direct extension of the stakeholder’s purpose for the systems and the goals and objectives that satisfy them. Less easily understood are a systems non-functional requirements, or the constraints under which the entire system must operate. Identification of non-functional requirements should happen early in the conceptual design stage of the systems life cycle, for the same reason that functional requirements are defined up-front—that is, costs sky-rocket when new requirements are added late in a systems design sequence. Approaches for addressing non-functional requirements are rarely addressed in texts on systems design. In order to provide a logical and repeatable technique for addressing over 200 existing non-functional requirements, they must be reduced parsimoniously to a manageable number. Over 200 non-functional requirements are reduced, using results reported in eight models from the extant literature. The 27 resultant non-functional requirements have been organized in a taxonomy that categorizes the 27 major non-functional requirements within four distinct categories. Utilization of this taxonomy provides a framework for addressing non-functional requirements during the early system design stages.