business intelligence resources
Print
Email
ADVERTISEMENT
Business Intelligence Resources
Common Decision Support System Architectural Patterns
Listen Podcast
(To subscribe to receive audio articles, click here for the audio article feed.)
Published: June 5, 2008
It is likely that historical decision support system architectural patterns will persist with service-oriented and message-based implementations of decision support systems.

Information technology continues to evolve and improve, but major architectural patterns recur in the development of computerized decision support systems (DSSs). New systems seem to imitate or adopt prior patterns by incorporating updated hardware and networking technologies. It is likely that historical DSS architectural patterns will persist with service-oriented and message-based implementations of decision support systems (cf., Natis, 2003; Whetten, 2001).

Advocates of a unified modeling approach to building systems perceive that design patterns or common architectural styles exist for classes of systems with similar purposes (cf., Booch, Rumbaugh and Jacobson, 1999; Eeles, 2006; Gamma, Helm, Johnson and Vlissides, 1995). Inadequate attention has been given to defining these patterns or styles for computerized DSSs, but some material has been written on the topic.

An architecture for a computerized decision support system documents the plan for deploying the components of the envisioned DSS, or it describes how the components were actually deployed in an implemented decision support application. In general, DSS architecture specifications focus on the dialog/user interface, model base and database components and how they are interconnected. According to the IEEE standard, "architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution" (IEEE 1471-2000).

Sprague and Carlson (1982) defined the components of the DSS technology framework as dialogue management, database management, model base management, and DSS network architecture. They argued the DSS architecture describes the mechanism and structure for the integration of the dialogue, database and model management components. They identified four architectures: the DSS Network, the DSS Bridge, the DSS Sandwich, and the DSS Tower. The DSS Network has multiple dialogue, modeling and database components that are interconnected and can share data through a component interface. The Bridge has a standard interface with local dialogue and modeling components that link to remote modeling and database components. A Sandwich architecture has a single dialogue and database component, but multiple model components are linked by the architecture. The dialogue and database components are the "bread" and the model components provide the "meat" for the application. Finally, the Tower includes more vertical components or tiers with data extraction tools integrating diverse database components. The rest of the Tower architecture is similar to a Network structure.

Power and Kaparthi (1998) identified six DSS architectures: distributed dialogue, remote dialogue, distributed model, distributed data, remote data and stand-alone. The distributed dialogue is basically a thin-client web architecture with the dialogue presented on the client and with models and data accessed from one or more servers using a network connection. The remote dialog is a more traditional thick-client application with the entire dialogue interface on the client and the model and database components on one or more servers. In the distributed model, the application software on the client expands, and model capabilities are distributed for more efficient processing. The distributed data architecture requires accessing data across the network for processing. With a remote data architecture, some data is downloaded to the client for faster processing. Finally, a stand-alone architecture has the entire DSS application on a stand-alone computer with no provision for network access to server based components.

In a similar framework, Schay (1992) of the Gartner Group defined five different styles of client/server computing. The difference in these styles was the portion of the computing process that is "distributed" to another computer over the network. The five styles are defined in relation to the three main processes in a computerized application: (1) presentation (user interface), (2) process (application logic) and (3) data storage (data management). The five styles are called: 1) distributed presentation, 2) remote presentation, 3) distributed logic, 4) remote data management, and 5) distributed database. The descriptive names capture the architectural differences.

Most architectural patterns or styles are very general. According to Eeles (2006), "An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. Thus, an important consideration is to ensure that you document the decisions that have led to this architecture and the rationale for those decisions." Potentially generic architecture patterns can lead to a better understanding of how to build computerized decision support systems. DSSs of all types, communications-driven, data-driven, document-driven, knowledge-driven and model-driven, are increasingly integrated with other information systems and a given DSS may have multiple decision support subsystems of different types. The architectures of data-driven DSSs emphasize database performance and scalability. Most model-driven DSS architectures store the model software on a server and distribute the user interface software to clients. Networking issues create challenges for many types of DSSs but especially for a geographically distributed, communications-driven DSSs. Much more needs to be done to model the increasingly complex patterns in DSSs.

Historically, the focus has been on structural software system components of DSSs, but there is an increasing need to identify patterns in other "views" for particular types of DSSs. "Views" are analogous to the different blueprints created for a complex building by an architect. A DSS architecture can potentially be diagrammed in terms of four layers: the business process map, the systems architecture, the technical architecture, and an output delivery architecture. The business process map shows how decision making tasks are completed. The systems architecture shows the traditional software components. The technical architecture focuses on computing hardware, protocols and networking. The output delivery architecture focuses on the results and representations of the system (cf., Power, 2002). Identifying patterns in process maps and output delivery can also assist DSS architects.

Having a well-defined and well-communicated architecture for a specific DSS provides an organization with significant benefits. An architecture diagram helps developers work together, improves planning, increases the development team's 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 specific DSS. Technical benefits of defining 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 specific DSS vision and an architecture for a new DSS 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 defining the intended architecture. Design patterns can help DSS architects and potential users evaluate and select solutions. Identifying patterns or styles can also assist a DSS architect in preparing early-phase project estimates to make a business case for a proposed decision support system.

Design the envisioned decision support system architecture before you build the system.

References:

Blythe, K. C. "Client/Server Computing: Management Issues." CAUSE/EFFECT, Volume 16, Number 2, Summer 1993.

Booch, G., J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide, Boston: Addison-Wesley, 1999.

Eeles, P. What is a software architecture? IBM, February 15, 2006.

Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Boston: Addison-Wesley, 1995.

IEEE Std 1471-2000, "IEEE Recommended Practice for Architectural Description of Software-Intensive Systems."

Mallach, E. G. Understanding Decision Support and Expert Systems. Burr Ridge, IL: Richard D. Irwin, Inc., 1994.

Natis, Y. V., "Service-Oriented Architecture Scenario," Gartner, April 16, 2003.

Nolan, R. L. "Building the company’s computer architecture strategic plan." Stage by Stage (Nolan, Norton & Company) 2 (Winter): 1983: 1-7.

Power, D. J. “What are common DSS architectural patterns or styles?” DSS News, Vol. 8, No. 20, October 7, 2007.

Power, D. J. and S. Kaparthi. "The Changing Technological Context of Decision Support Systems" in Berkeley, D., G. Widmeyer, P. Brezillion & V. Rajkovic (Eds.). Context-Sensitive Decision Support Systems. London: Chapman and Hall, 1998.

Schay, P. "How Will Traditional Mainframe and Midrange Systems Evolve to Support Client/Server Computing?" in the Proceedings of the Gartner Group Symposium 1992, Scenarios, Vol. 1 (Stamford, Conn.: Gartner Group, 1992), p. 6 of Client/Server section.

Sprague, R.H. and E.D. Carlson. Building Effective Decision Support Systems. Englewood Cliffs, NJ: Prentice-Hall, 1982.

Welsh, M. J., "Enterprise architecture essentials, Part 3: Design and build your enterprise architecture," IBM, September 11, 2007.

Whetten, B. "Message-Based Computing: The Fourth Wave of Integration," 12/23/2001.

If you found this article helpful and would like to receive the latest insights each week from the experts featured on the Business Intelligence Network, please subscribe to the Bill Inmon Newsletter.


Recent articles by Dan Power

Dan Power -

Daniel J. "Dan" Power is a Professor of Information Systems and Management at the College of Business Administration at the University of Northern Iowa and the editor of DSSResources.com, the Web-based knowledge repository about computerized systems that support decision making; the editor of PlanningSkills.com; and the editor of DSS News, a bi-weekly e-newsletter. Dr. Power's research interests include the design and development of decision support systems and how these systems impact individual and organizational decision behavior.

Editor's note: More Dan Power articles, resources, news and events are available in the Business Intelligence Network's Dan Power Channel. Be sure to visit today!

showing all