ABSTRACT
However, there can be significant risks associated with using a general-purpose method for engineering the architecture of a specific system on a specific endeavor by specific organizations for specific stakeholders:
Systems N can vary greatly in terms of: Size (from small embedded applications to ultra-large systems of systems) − Complexity (from simple to incredibly complex) − Criticality (such as business criticality, safety criticality, and security criticality) − Cardinality of purpose (from single-purpose systems to multipurpose systems) − Application domain (such as communications, information processing, transportation, − and weapon systems) Operational dependence on other systems (from stand-alone to part of a highly interop-− erable system of systems) Originality (new “greenfield” systems to updates of existing legacy systems) − Uniqueness (from unique systems to systems within product lines) − Amount of reuse (such as COTS, GOTS, MOTS, and open source) mandated or − incorporated Technologies incorporated (including diversity, volatility, and maturity) − Required functionality, required quality characteristics and attributes, and requirements − volatility
Expendability (from single use to reusable systems) − Automation (from manned to unmanned and from totally autonomous to human − operated)
System development endeavors N can vary greatly in terms of: Type (from individual projects to programs of related projects) − Size (from small to vast endeavors) − Duration (from a few months to many years) − Schedule and funding (from more than adequate to very insufficient) − Contractual relationships (ranging from informal in-house development to formal con-− tracts between acquisition organizations, prime contractors, subcontractors, and vendors) Development and life-cycle scope (from initial development through major modifica-− tion of legacy systems)
Development organizations N can vary greatly in terms of: Engineering culture (from early to late adopters of technology) [Rogers, 1962] − Management culture (including degree of control and risk taking versus risk avoidance) − Staff training, experience, and expertise − Staff localization (from co-located to geographically distributed) −
System stakeholders N can vary in terms of: Type (such as acquirer, user, operator, trainer, maintainer, certifier, and member of the − public) Authority to set system goals and requirements − Numbers (from a single individual to literally tens or hundreds of thousands) − Accessibility to the architecture teams − Willingness to take risks − Preferences in terms of architectures and technologies − Past experiences with similar systems −
Because of these variables, no single system architecture engineering method is likely to be sufficiently general to meet the needs of all endeavors. us, many architecture teams have had to tailor the previously existing method to meet the needs of their new endeavors. Unfortunately, the variability of architecture engineering efforts has been so great that it has often been very difficult to choose the appropriate reusable architecture engineering method and properly tailor it to meet the specific needs of the endeavor. is difficulty is one of many reasons why the intended architecture engineering method and the actual architecture engineering process performed in practice have often differed greatly. It is also a reason why both methods and associated processes have had limited success in effectively and efficiently developing and maintaining optimal system architectures and their associated representations.
