System development using domain specific software architecture (DSSA) design approaches address many software engineering concerns. This research demonstrates how a DSSA style (viz. Switchboard) augments the design process and integrates essential missing factors. The DSSA style improves the design process and facilitates the utilization of nontechnical constraint sets by software architecture designers. The Switchboard style was embedded in a tool suite (ArckBuilder), to aid in more effectively mapping the non-traditional factors to the DSSA. This embedded style encourages a specific design process derived from the field study data. ArckBuilder was designed and developed to guide stakeholder articulation of the domain specific, non-traditional, crosscutting effects, and constraint sets. The resulting architectural representations use object reflection and interfaces to express relationships more formally than generic box and arrow software architecture artifacts acquired during the data collection. In addition, documentation can be generated to link architectural representations with constraints.

Application domains focus the attention of software engineers on a particular case or set of solution-constraining factors. This domain focus facilitates the effective generation of software system specifications for that instance. The application domain design construct differs from domain constructs describing complex entities bound by less formal relationships. These informal domain constructs encompass factors which are not directly related to software design, but which may nevertheless contribute to system failures. In mission-critical domains, entity interaction introduces various domain-specific software configurations and behavior. This “variety” is interrelated by factors that are broader than typically associated with application development. The electric power industry exhibits such "broader" factors, which are of keen interest to a diverse set of stakeholders. These factors are directly associated with various types of constraint sets emerging from the domain. Constraints express causal, spatial, or temporal relationships between domain specific social, technical, or socio-technical entities. A field study was conducted at an electric power utility to investigate how software systems were evolved in response to some complex factors such as those arising from deregulation. Software system designers must consider these crosscutting effects to achieve successful system implementation. They expressed concern and frustration regarding the influence of these crosscutting effects on their design processes. Data indicates there exists two types of unacceptable conclusions if software engineers do not consider these types of factors. The first failure is a complete or full stop in the process resulting in the discontinuation or abandonment of implementation efforts. The second type of failure is the incorrect integration of the crosscutting effects into a completed implementation. In the latter case, the system executes as envisioned by the stakeholders. Nevertheless, the overarching functional objectives or higher-level requirements are not met and the system is in fact a failure. Software system designers in the electric power industry already utilize certain forms of software architecture representations to offset domain complexity. However, they have difficulty integrating semi- or non-technical factors into their processes and the resulting architectural representations. Such factors are difficult to quantify in any meaningful way for software system architects. It is evident that technical constraint sets associated with software architectures can be used in a reciprocal and iterative validation process with the traditional requirements engineering process. However, it is less obvious how one can utilize nontechnical constraints to discover crosscutting effects.

The Switchboard style is sufficient to represent all known domain states because it meets two conditions. First, the style reflects the domain data, which was cross-referenced from the two field sites. There exists an ongoing reflective validation between the data and style that is verified from emerging events in the industry. The reflective validation was iterative modified using behavioral models appropriate for the given level of abstraction (e.g. social). The second sufficient representational condition is exhibited in the use of the style. Information about domain variety is created as the architect explicates crosscutting effects using this architectural framework. The architect is able to manage complexity more effectively by leveraging an idealized resource model incorporated into the Switchboard style. The interdependencies commonly associated with architectural domain resources are sufficiently captured and juxtaposed using categorical constraints with stylistic constraints derived from the data.