Ch. 6
Understanding DSS Architecture, Networking and Security Issues

Having a well-defined and well-communicated Decision Support System architecture provides an organization with significant benefits. An architecture helps developers work together, improves planning, increases the development teams ability to communicate system concepts to management, increases the team's ability to communicate needs to potential vendors, and increases the ability of other groups to implement systems that must work with the DSS. Technical benefits of a DSS architecture include the ability to plan systems in an effective and coordinated fashion and to evaluate technology options within a context of how they will work rather than abstractly. A DSS vision and an architecture helps communicate the future and provides a consistent goal for making individual design decisions. Achieving all these benefits requires that both information system professionals and prospective DSS users must cooperate closely in developing the architecture.

An architecture drawing provides the grand scheme of a large-scale DSS project. The overall architecture of a DSS should be diagrammed and understood before specific decisions are made. The nature of the architecture depends on the DSS. Small-scale DSS developed by individuals for their own use do not justify a major architectural planning effort, although the overall information system architecture of the organization may constrain the capabilities of desktop DSS. Enterprise-wide DSS do require careful architecture planning if they are to succeed. Figure 6.2 shows a very high-level enterprise-wide data delivery architecture. In general, much more detail about the hardware, networks, and software is needed in specifying the architecture than is shown in Figure 6.2.

According to Mallach (1994), a DSS architecture should define and specify the following components:

1. Database or databases, including any existing databases, internal or external to the organization and any databases that are created specifically for DSS use. The architecture schematic should identify who is responsible for different types of databases, including their accuracy, currency, and security.

2. Model or models, including information about their sources of data, processing, the organizational unit responsibility for maintaining them, and limits on access to them.

3. Software tools for users to access the database and the models, and software tools which system administrators can use to manage the database and the models.

4. Hardware and operating system platforms on which the databases and models reside, on which the programs run, and through which users access the DSS. Any constraints, such as a policy to standardize on products of a particular vendor or products that use a particular operating system, should be stated.

5. Networking and communication capabilities needed to connect the hardware platforms. These capabilities must support needs to connect to one or more servers and databases, needs of work group members to communicate within the group, and enterprise needs to link work groups to each other or to shared data. In many DSS situations the corporate network is used. In this case the network must be examined to make sure it meets present and future Decision Support traffic needs.

Mallach also claims potential users should be specified when a DSS architecture is designed. The specifications should state any assumptions about users’ locations, jobs, levels of education, and any other factor that may affect their use of a specific Decision Support System. This information can be part of the business process map.

Bob Lambert in a paper titled "Data Warehousing Fundamentals" has a similar list of architectural issues that need to be addressed. Lambert argues "An architecture is a design completed early in a project that encompasses (but does not necessarily detail) all aspects of the finished product."

According to Lambert, a completely specified DSS architecture addresses seven major topic areas:

• A description of the problem the DSS is designed to address;
• The objectives, constraints and critical success factors for the DSS;
• Project participants and the role of each participant;
• Major system components and the interfaces, connections or communication paths among the components;
• Anticipated system enhancements, migration paths and modifications;
• An overall development and maintenance schedule and staffing plan; and
• The skills, tools and other support required to develop the Decision Support System on schedule and maintain it over the long term.

Lambert notes, "all project participants should understand and accept the architecture. The architectural design should set a common level of understanding among technical, non-technical and management participants."

Stefferud, Farber, and Dement (1982) stated that the design of a general computing architecture consists of four elements – processors, networks, services, and standards. Nolan (1983) divides an IS/IT architecture into data, applications, and communication components. Also, the capabilities of executive workstations should be determined as part of the discussion of the DSS architecture (cf., Power, 1985).