Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

Enterprise Integration and Interoperability 86.4 Applications and Future Trends 1535

applications across an extended organization with

transactional integrity. It is capable of being adopted

for any general-purpose integration project and can

scale beyond the limits of a hub-and-spoke EAI bro-

ker. Datatransformation isthe abilityto apply XSLT

(extended style sheet transformation) (or XML style

sheets) to XML messages to reformat messages dur-

ing transport depending on the type of receivers

that will consume the messages (for instance, the

ZIP code is a separate information datum for one

application while it is part of a customer address

for another one). Intelligent or rule-based routing

is the ability to use message properties to route

message delivery to different queues according to

message content. Database services simplify access

to database systems using SQL (structured query

language) and Java database connectivity (JDBC)or

object database connectivity (ODBC). Useful enter-

prise integration patterns to be used in messaging

applications can be found in the book by Hohpe

and Woolf [86.4], who have thoroughly analyzed

and described those that are most commonly used

in practice.

6. BPM: Business process management consists of

reviewing, reengineering, and automating business

processes of the organization. Among the process

steps are services offered by IT systems. Once auto-

mated, these processes take the form of workﬂows.

Two languages can be used to model business pro-

cesses, one at the business user level and one at the

workﬂow system level. These are:

– BPMN: The business process modeling notation

is a diagrammatic and semistructured notation

that provides businesses with the capability to

represent their internal business procedures in

a graphical language. It gives organizations the

ability to depict and communicate these proce-

dures in a standard manner. Furthermore, the

graphical notation facilitates the understand-

ing of the performance of collaborations and

business transactions between the organizations.

This ensures that business participants will un-

derstand each other and that participants in the

business will enable organizations to adjust to

new internal and B2B business circumstances

quickly [86.22].

– BPEL: The business process execution language

is an XML-based language designed to enable

task sharing for a distributed computing envi-

ronment – even across multiple organizations –

using a combination of web services (BPEL is

also sometimes called BPEL4WS or BPELWS).

It has been written by developers from BEA

Systems, IBM, and Microsoft. BPEL speciﬁes

the business process logic that deﬁnes choreog-

raphy of interactions between a number of web

services. The BPEL standard deﬁnes the struc-

ture, tags, and attributes of an XML document

that corresponds to a valid BPEL speciﬁca-

tion [86.23]. Conversion mechanisms exist to

translate BPMN models into BPEL speciﬁca-

tions.

86.4 Applications and Future Trends

Enterprise integration has been around in terms of

applications since the beginning of the 1990s, espe-

cially in the domain of manufacturing integration but

also enterprise information integration (EII), enterprise

resources planning (ERP), customer relationship man-

agement (CRM), and then supply chains. The advent of

CORBA, workﬂow engines, and BPM techniques has

given birth to a range of commercial products, known

as enterprise application integration (EAI) platforms.

Many vendors have proposed solutions, including Iona,

Sopra, Vitria, Tibco, Microsoft BizTalk, HP, IBM, Ora-

cle, and BEA Systems, as well open-source solutions.

Today, nearly all industrial sectors are facing in-

tegration and interoperability problems, ranging from

manufacturing supply chains to banking, the insurance

sector, medical services, and public organizations. The

focus ison XML-based messagingcommunications and

loosely coupled interactions thanks to XML/HTTP and

MOM/ESB techniques. One area that has emerged with

EI and is rapidly growing is electronic commerce (web-

based shopping, B2B commerce, e-Procurement, elec-

tronic payment, EDI, etc.). Major initiatives launched

to sustain this area include ebXML (electronic busi-

ness XML)forXML/EDI (electronic data interchange)

(UN/CEFACT (United Nations Centre for Trade Facil-

itation and Electronic Business) and OASIS (Organi-

zation for the Advancement of Structured Information

Standards)), RosettaNet (www.rosettanet.org)inthe

area of standard electronic data exchange for sup-

ply chains, and Bolero.net (www.bolero.net) proposing

Part I 86.4

1536 Part I Home, Ofﬁce, and Enterprise Automation

a data and document exchange infrastructure for in-

ternational commerce involving SWIFT (Society for

WorldwideInterbank Financial Telecommunication)for

secured payment.

In terms of current trends that can be observed

there is a shift from the pure business process paradigm

that prevailed through the 1990s to the service-

orientation paradigm. This puts more emphasis on

services interoperability than on IT systems inter-

operability or enterprise application integration than

before [86.25].

Among the future trends, we can mention the

emergence of composite services, i. e., services made

of services. This will rapidly grow both in business

(to combine competencies and capabilities of several

partners into common services) and in government

organizations (for instance, pan-European services of-

Service

Theories, models, languages

and tools

Research challengesDomains

Collaborative

networked

organizations (CNO)

Enterprise modeling

and reference

models

Enterprise and

process

interoperability

Validation and

verification of

enterprise models

Enterprise

application

integration

Enterprise model

repositories

• Hub of integrated e-Services

• Unified enterprise modeling language (UEML)

• Reference,

ontologies, and

functional models

• CNOs reference models

• Theories of collaboration

• Formal methods and tools

• Empirical studies

• UEML for business

applications interoperability

• Ontology for networked

enterprise interoperability

• Semantic interoperability

• Interoperability architectures

• Interoperability process

classification frameworks

• Model repository classification

scheme

• Process definition, execution,

and tracking

• Process analysis, evaluation,

monitoring and optimization

• Process data mining and

visualization

• Collaboration

and bio-inspired

models and tools

Project life cycle

Fig. 86.3 The scope of emerging challenges in enterprise integration and interoperability (after [86.24])

fered to EU citizens where a service offered to citizens

through a common portal will in fact be a combination

of local services running in member states in national

languages, e.g., application for the blue card or Euro-

pean identity card).

At the technical level, integration and interoper-

ability are still evolving and will continue to evolve

with technology (faster communication networks, au-

thentication mechanisms, security issues, electronic

signature, multilingual issues, etc.).

At the semantic level, many researchers agree that

one of the major challenges for integration and interop-

erability remains the semantic uniﬁcation of concepts.

There are simply too many ontologies around and no

common way of representingthese ontologies, although

OWL-S is a de facto standard. Microtheories have to

emerge to provide sound foundations for the ﬁeld, and

Part I 86.4

Enterprise Integration and Interoperability References 1537

(XML-based) standards for ontology representation are

needed.

At the organizational level, many techniques and

languages exist to capture and represent business pro-

cesses and services in a satisfactory way for business

users. The research trends should focus on developing

interoperability maturity models with associated met-

rics to assess the level of integration or interoperability

and propose methodologies for improving enterprise in-

tegration or interoperability.

Anyway, for the years to come, the driving forces

imposing the new trends will continue to come from

market globalization and new business conditions: need

for more joint ventures, increased communication, fu-

sion and acquisition, knowledge sharing, or use of

common skills and competencies.

86.5 Conclusion

Thanks to advances in Internet computing and service

orientation, enterprise integration and systems interop-

erability have become a reality that largely contributes

to make enterprises more agile, more collaborative, and

more interoperable. The reader should also see Chap.88

on Collaborative e-Work, e-Business, and e-Service and

Chap.90 on Business Process Automation: CRM, SCM

and ERP for related content.

Enterprise integration and systems interoperability

are fairly mature at the technical level, and will con-

tinue to evolve with new IT technologies, but are not

yet completelyaddressed atthe organizational andmore

speciﬁcally at the semantic level.

There are however some other issues (out of the

scope of this chapter) that should be considered. They

concern legal issues, conﬁdentiality issues, or linguistic

aspects, to name a few, especially in the case of in-

ternational contexts (multinational ﬁrms, international

organizations or unions of member states). They can

have a political dimension and be even harder to solve

than pure technical or organizational issues mentioned

in this chapter.

References

86.1 F.B. Vernadat: Enterprise Modeling and Integra-

tion: Principles and Applications (Chapman Hall,

London 1996)

86.2 F.B. Vernadat: Interoperable enterprise systems:

principles, concepts, and methods, Annu. Rev.

Control 31(1), 137–145 (2007)

86.3 B. Gold-Bernstein, W. Ruh: Enterprise Integra-

tion: The Essential Guide to Integration Solutions

(Addison-Wesley, Boston 2005)

86.4 G. Hohpe, B. Woolf: Enterprise Integration Pat-

terns: Designing, Building, and Deploying Messag-

ing Solutions (Addison-Wesley, Reading 2004)

86.5 AMICE: CIMOSA: CIM Open System Architecture,2nd

edn. (Springer, Berlin, Heidelberg 1993)

86.6 H. Li, T.J. Williams: A vision of enterprise inte-

gration considerations: a holistic perspective as

shown by the Purdue enterprise reference archi-

tecture, Proc. 4th Int. Conf. Enterp. Integr. Model.

Technol. (ICEIMT’04) (Toronto 2004)

86.7 D. Chen, F. Vernadat: Standards on enterprise in-

tegration and engineering – a state of the art, Int.

J. Comput. Integr. Manuf. 17(3), 235–253 (2004)

86.8 ATHENA: Advanced Technologies for Interoperabil-

ity of Heterogeneous Enterprise Networks and their

Applications, FP6-507312-IST1 Integrated Project

(2005) www.ist-athena.org

86.9 D.S. Lithicum: Enterprise Application Integration

(Addison Wesley, Boston 2000)

86.10 OMG: Common object request broker architec-

ture (CORBA), (Object Management Group 1994)

www.omg.org

86.11 P. Herzum: Web Services and Service-Oriented

Architecture, Executive Rep. 4, No. 10 (Cutter Dis-

tributed Enterprise Architecture Advisory Service,

2002)

86.12 R. Khalaf, F. Curbera, W. Nagy, N. Mukhi, S. Tai,

M. Duftler: Understanding web services. In: Prac-

tical Handbook of Internet Computing,ed.by

M. Singh (CRC, Boca Raton 2004), Chap. 27

86.13 IDAbc: European Interoperability Framework for

Pan-European e-Government Services (European

Commission, Brussels 2003),

www.europa.eu/idabc/

86.14 C4ISR: C4ISR Architecture Framework, V. 2.0, Archi-

tecture Working Group (AWG), (US Department of

Defense (DoD), 1998)

86.15 T.R. Gruber: Toward principles for the design of

ontologies used for knowledge sharing, Int. J.

Human-Comput. Stud. 43, 907–928 (1995)

86.16 World Wide Web Consortium (W3C), OWL-S:

Semantic markup for web services (2004),

www.w3.org/2004/OWL

86.17 World Wide Web Consortium (W3C): XML: eXtensible

mark-up language (2000), www.w3.org/xml

86.18 H. Kreger: Web Services Conceptual Architecture

(WSCA 1.0) (IBM Software Group, Somers 2001)

Part I 86

1538 Part I Home, Ofﬁce, and Enterprise Automation

86.19 World Wide Web Consortium (W3C): WSDL: Web ser-

vice description language (2001),

www.w3.org/TR/wsdl

86.20 World Wide Web Consortium (W3C), SOAP: Sim-

ple object access protocol (2002), www.w3.org/TR/

SOAP

86.21 D.A. Chappell: Enterprise Service Bus (O’Reilly, Se-

bastopol 2004)

86.22 Business Process Management Initiative (BPMI):

Business Process Modeling Notation (2005),

ww.bpmn.org/

86.23 IBM: Business Process Execution Language for Web

Services (BPEL4WS) (2003),

www.ibm.com/developersworks/library/ws-bpel/

86.24 S.Y. Nof, F.G. Filip, A. Molina, L. Monostori,

C.E. Pereira: Advances in e-Manufacturing, e-

Logistics, and e-Service Systems, Proc. IFAC Congr.

(Seoul Korea 2008)

86.25 A. Molina, H. Panetto, D. Chen, L. Whitman, V. Cha-

purlat, F. Vernadat: Enterprise integration and

networking: challenges and trends, Stud. Inform.

Control 16(4), 353–368 (2007)

Part I 86

1539

Decision Supp

87. Decision Support Systems

Daniel J. Power, Ramesh Sharda

This chapter places decision automation in

a broader context of using information tech-

nologies in decision making. Key deﬁnitions

and a brief history of computerized deci-

sion support create important boundaries.

Then a description and explanation of char-

acteristics of computerized decision support

systems (DSS)clariﬁesthisapplicationdo-

main. After reviewing management information

needs, a modern taxonomy of decision sup-

port systems is brieﬂy summarized. Issues

associated with building DSS and various ar-

chitectures are reviewed before concluding the

overview.

87.1 Characteristics of DSS ............................1540

87.1.1 Management Information Needs....1540

87.1.2 Communications-Driven

and Group DSS .............................1542

87.1.3 Data-Driven DSS...........................1542

87.1.4 Document-Driven DSS...................1542

87.1.5 Knowledge-Driven DSS .................1543

87.1.6 Model-Driven DSS ........................1543

87.1.7 Secondary Dimensions ..................1543

87.2 Building Decision Support Systems .........1544

87.3 DSS Architecture ...................................1546

87.4 Conclusions..........................................1547

87.5 Further Reading ...................................1547

References ..................................................1548

Decision support systems (DSS) are deﬁned broadly as

interactive computer-based systems thathelp people use

computer communications, data, documents, knowl-

edge, and models to solve problems and make decisions

(see DSSResources.com). DSS are ancillary or auxil-

iary systems; they are not intended to replace skilled

decision-makers. DSS are not automating decision-

making.

In pursuing the goal of improving decision-making,

many different types of computerized DSS have been

built to help decision teams and individual decision-

makers. Some systems provide structured information

directly to managers. Other systems help managers and

staff specialists analyze situations using various types

of quantitative models. Some DSS store knowledge and

make it available to managers. Some systems support

decision-making by small and large groups. Companies

even develop DSS to support the decision-making of

their customers and suppliers.

Table 87.1 identiﬁes some major developments in

the history ofdecision support systems.For more details

see Power [87.1,2].

The history of decision support systems (based

on [87.2]) is relatively brief and the concepts and

Table 87.1 Evolution of DSS concepts

Years Representative DSS Research

1960s Scott Morton’s management decision

support project

Interactive systems research organization

Decision-making theory development

1970s BrandAid research

Alter’s ﬁeld study

Holsapple research

1980s Key DSS books

Group DSS prototypes

Executive information systems (EIS)

PC expert systems

1990s Business intelligence/OLAP

Data warehousing

Web-based systems/portals

Data mining

Part I 87

1540 Part I Home, Ofﬁce, and Enterprise Automation

technologies are still evolving. Today, a number of

academic disciplines provide the substantive founda-

tions for decision support systems development and

research. Database research has contributed tools and

research on managing data and documents. Manage-

ment science and operations research have developed

mathematical models for use in building model-driven

DSS and provided evidence on the advantages of mod-

eling in problem solving. Cognitive science, especially

behavioral decision-making research, has provided de-

scriptive and empirical information that has assisted in

DSS design and has generated hypotheses for decision

support research. Some other important ﬁelds related

to DSS include artiﬁcial intelligence, human–computer

interaction, software engineering, and telecommunica-

tions. In general, the Internet and web have sped up

developments in decision support and have made it hard

to keep up with the rapid changes in DSS capabilities.

In the 1960s, pioneering workin building interactive

systems at the Massachusetts Institute of Technology,

theory development by Simon and colleagues, and Mor-

ton’s [87.3] research created a foundation for building

innovative DSS.

In the early 1970s, BrandAid [87.4] and reports of

Morton’s [87.3] management decision system (MDS)

research demonstrated the feasibility of DSS.Bythe

late 1970s, a number of companies had developed

interactive information systems that used data and mod-

els to help managers analyze semistructured problems.

These diverse systems were all called decision sup-

port systems. Key concept books included those by

Alter [87.5], Sprague and Carlson [87.6], and Bonczek

et al. [87.7].

From those early days, it was recognized that

DSS could be designed to support decision-makers

at any level in an organization. DSS could sup-

port operations, ﬁnancial management, and strategic

decision-making. Over the years many of the more

interesting DSS have been targeted at middle and

senior managers. DSS are also often designed for spe-

ciﬁc types of organizations such as hospitals, banks

or insurance companies. These specialized systems are

sometimes referred to as vertical-market or industry-

speciﬁc DSS.

Today, decision support systems are both off-

the-shelf, packaged applications and custom-designed

systems. DSS may support a manager using a single

personal computer or a largegroup of managers in a net-

worked client–server environment. These latter systems

are often called enterprise-wide DSS.

87.1 Characteristics of DSS

Although the term decision support system has many

connotations, based upon Alter’s [87.5] pioneering

research we can identify the following three major char-

acteristics:

1. DSS are designed speciﬁcally to facilitate decision

processes.

2. DSS should support rather than automate decision-

making.

3. DSS should be able to respond quicklyto the chang-

ing needs of decision-makers.

Many terms are used for speciﬁc types of DSS,

including business intelligence, collaborative systems,

data warehousing, model-based systems, knowledge

management, and online analytical processing. Soft-

ware vendors use these more specialized terms for

both descriptive and marketing purposes. What term

we use for a system or software package is a sec-

ondary concern. Our primary concern should be ﬁnding

software and systems that meet a manager’s decision

support needs and provide appropriate management

information.

87.1.1 Management Information Needs

Managers and their support staffs need to consider what

information and analyses are actually needed to sup-

port their management and business activities. Some

managers need both detailed transaction data and sum-

marized transaction data. Most managers only want

summaries of transactions. Managers usually want lots

of charts and graphs; a few only want tables of numbers.

Many managers want information provided routinely

or periodically and some want information available

online and on demand. Managers usually want ﬁnan-

cial analyses and some managers want primarily soft,

nonﬁnancial or qualitative information. Managers have

different needs and wants depending upon personal

preferences, task needs, and information technology

experiences.

Part I 87.1

Decision Support Systems 87.1 Characteristics of DSS 1541

In general, a computerized information system

can provide business transaction summary informa-

tion and can help managers understand many business

operations and performance issues; for example, a com-

puterized system can help managers understand the

status of operations, monitor business results, review

customer preference data, and investigate competi-

tor actions. In all of these situations, management

information and analyses should have a number of char-

acteristics. Information must be both timely and current.

These characteristics mean the information is up to date

and available when managers want it. Also, information

must be accurate, relevant, and complete. Finally, man-

agers want information presented in a formatthat assists

them in making decisions. In general, management in-

formation should be summarized and concise and any

support system should have an option for managers to

obtain more detailed information.

So the subcategory known as decision support sys-

tems needs to provide current, timely information that is

accurate, relevant, and complete. A speciﬁc DSS must

present information in an appropriate format that is easy

to understand and manipulate. The information pre-

sented by a DSS may result from analysis of transaction

data or it may be the result of a decision model or it

may have been gatheredfrom externalsources. DSS can

present internal and external facts, informed opinions,

and forecasts to managers. As many others have noted,

managers want the right information, at the right time,

in the right format, and at the right cost. These sys-

tem requirements seem simple and straightforward, but

meeting them remains a challenge.

Technology is creating new decision support capa-

bilities, but much learningand discussionneeds tooccur

to successfully exploit the technological possibilities.

Decision support systems differ in many ways from op-

erating systems that process business transactions. For

example, a popular system that has been widely imple-

mented is called enterprise resource planning (ERP).

ERP is not a decision support system even though the

term suggests thatdecision-making and planningwill be

improved. In general, enterprise resource planning is an

integrated transaction processing system that facilitates

the ﬂow of information between all of the functional ar-

eas of a business. Recently, DSS have been built that

help managers analyze the data from ERP systems, and

ERP systems make it easier to create a wide variety

of DSS.

Decision automation refers to using informa-

tion technologies to make decisions and imple-

ment programmed decision processes. Typically de-

cision automation is considered most appropriate

for well-structured, clearly deﬁned, routine or pro-

grammed [87.8] decision situations. Decision support

systems are intended to help human decision-makers

while decision automation systems make a decision and

reduce the need for immediate human involvement in

the decision. People still write rules and review results

for decision automation, but software makes the routine

decisions.

A major difference between transaction processing

systems, decision automation, and decision support sys-

tems is the general purpose of each type of system.

Transaction processing systems (TPS) are designed to

expedite and automate transaction processing, record

keeping, and simple business reporting of transactions.

Decision automation uses software to make decisions.

Decision support systems are intended to assist in

decision-making and decision implementation. Trans-

action processing is however related to the design of

DSS because transaction databases often provide data

for decision-oriented reporting systems and data ware-

houses. Decision automation often interacts with TPS,

and the results of automated decisions often impact on

TPS.

Transaction processing systems usually provide

standard reports on a periodic basis and support the op-

erations of a company. DSS are used on demand when

they are needed to support decision-making. A man-

ager typically initiates each instance of decision support

system use, either by using the DSS herself or by ask-

ing a staff intermediary to use a DSS. Some managers

and especially clerical employees use transaction pro-

cessing systems to support operations. Line managers

and support staff are the primary users of DSS. TPS

record current information and maintain a database of

transaction information. DSS generally use historical

internal and external data for analysis. DSS may focus

on quantitative analysisand modeling current and future

scenarios. TPS emphasize data integrity and consis-

tency, and although both of these qualities are important

in every system, the primary emphasis for a DSS is

on ﬂexibility and on conducting analyses and retrieving

decision-relevant information and knowledge. Decision

automation routinizes a speciﬁc decision 24h a day,

7days a week.

One of the long-standing conclusions from reading

DSS case studies is that DSS can take on many different

forms and can be used in many different ways [87.5].

Decision support systems certainly vary in many ways.

Some DSS focus on accessing data, some on manipulat-

ing models, and some on facilitating communications.

Part I 87.1

1542 Part I Home, Ofﬁce, and Enterprise Automation

DSS also differ in scope; some DSS are intended for

one primary user and are used stand-alone for analy-

sis, whereas others are intended for many users in an

organization. Also, DSS differ in terms of who uses

a speciﬁc system; for example, some DSS are used by

actual decision-makers and some are used by interme-

diaries such as marketing analysts or ﬁnancial analysts.

If a computerized system is not a transaction processing

system and if a manager uses it, many observers will be

tempted to call the system a DSS.

Some examples show the wide variety of DSS ap-

plications. Major airlines have DSS used by analysts

for many tasks including pricing and route selection.

Many companies have DSS that aid in corporate plan-

ning and forecasting. Specialists often use these DSS

that focus on ﬁnancial and simulation models. DSS can

help monitor costs and revenues and track departmental

budgets. Also, investment evaluation and support sys-

tems are increasingly common. Frito-Lay has a DSS

that aids in pricing, advertising, and promotion. Route

salesmen use handheld computers to support decision-

making activities.

Many manufacturing companies use manufactur-

ing resources planning (MRP) software. This spe-

ciﬁc operational-level DSS supports master production

scheduling, purchasing, and materials requirements

planning. More recent MRP systems support what-

if analysis and simulation capabilities. DSS support

quality improvement and control decisions. Monsanto,

FedEx, and most transportation companies use DSS

for scheduling trucks, airplanes, and ships. The Coast

Guard uses a DSS for procurement decisions. Com-

panies such as Wal-Mart have large data warehouses

and usedata-mining software. Businessintelligence and

knowledge management systems are increasingly com-

mon. On the World Wide Web one can ﬁnd DSS that

help track and manage stock portfolios, choose stocks,

plan trips, and suggest gifts. DSS support distributed

decision activities using groupware and a corporate in-

tranet.

The following expanded DSS framework helps cat-

egorize the most common DSS currently in use [87.1,

9, 10]. Some DSS are integrated or hybrid systems

with more than one major DSS subsystem. The frame-

work focuses on one major capability dimension with

ﬁve categories and three secondary dimensions. The

term driver is used as a common or shared descrip-

tive adjective in the expanded framework. Driver refers

to the capability, tool or component that is providing

the dominant functionality in the DSS. The ﬁve cat-

egories explained below are communications-driven,

data-driven, document-driven, knowledge-driven, and

model-driven.

87.1.2 Communications-Driven

and Group DSS

Group decision support systems (GDSS) and group-

ware were investigated in the mid-1980s, but now

a broader category of communications-driven DSS can

be identiﬁed. This type of decision support system

includes communication, collaboration, and decision

support. A group DSS is an interactive computer-based

system intended to facilitate the solution of prob-

lems by decision-makers working together as a group;

such systems often derive functionality from a model

more than from supporting collaboration and hence

are model-driven DSS. Groupware supports electronic

communication, scheduling, document sharing, and

other group productivity and decision support enhanc-

ing activities. A number of technologies and capabilities

are included in this category in the framework: some

collaborative group DSS, two-way interactive video,

white boards, bulletin boards, chat, and email systems.

87.1.3 Data-Driven DSS

Data-driven DSS emphasize analysis of data. These

systems include ﬁle drawer and management reporting

systems, data warehousing and analysis systems, exec-

utive information systems (EIS), and data-driven spatial

decision support systems (SDSS). EIS are targeted at

senior managers and SDSS display spatial data for de-

cision support. Business intelligence (BI) systems are

also examples of data-driven DSS. A data-driven DSS

provides access to and manipulation of large databases

of structured data and especially a time series of in-

ternal company data and external data. Simple ﬁle

systems accessed by query and retrieval tools provide

the most elementary level of functionality. Data ware-

house systems that allow the manipulation of data by

computerized tools tailored to a speciﬁc task and set-

ting or by more general tools and operators provide

additional functionality. Data-driven DSS with online

analytical processing (OLAP) provide the highest level

of functionality and decision support that is linked to

analysis of large collections of historical data [87.11].

87.1.4 Document-Driven DSS

A new type of DSS,adocument-driven DSS,isevolv-

ing to help managers retrieve and manage unstructured

Part I 87.1

Decision Support Systems 87.1 Characteristics of DSS 1543

documents and web pages. A document-driven DSS in-

tegratesa variety of storage and processing technologies

to provide complete document retrieval and analysis.

The web provides access to large document databases

including databases of hypertext documents, images,

sounds, and video. Examples of documents that would

be accessed by a document-driven DSS are policies

and procedures, product speciﬁcations, catalogs, and

corporate historical documents, including minutes of

meetings, corporate records, and important correspon-

dence. A search engine is a powerful decision-aiding

tool associated with a document-driven DSS. Some au-

thors call this type of system a knowledge management

system.

87.1.5 Knowledge-Driven DSS

The terminology for this fourth category of DSS is

still evolving. Currently, the best term seems to be

knowledge-driven DSS. Sometimes it seems equally ap-

propriate to use Alter’s [87.5] term suggestion DSS

or the narrower term management expert system.

Knowledge-driven DSS suggest or recommend actions

to managers. These DSS have specialized problem-

solving expertise. The expertise consists of knowledge

about a particular domain, understanding of problems

within that domain, and skill at solving some of these

problems.

87.1.6 Model-Driven DSS

A ﬁfth category, model-driven DSS, includes systems

that use accounting and ﬁnancial models, representa-

tional models, and optimization models. Model-driven

DSS emphasize access to and manipulation of a quan-

titative model. Simple statistical and analytical tools

provide the most elementary level of functionality.

Some OLAP systems that allow complex analysis of

data may be classiﬁed as hybrid DSS systems providing

modeling, data retrieval, and data summarization func-

tionality. Model-driven DSS use data and parameters

provided by decision-makers to aid them in analyzing

a situation, but they are not usually data intensive. Very

large databases are usually not needed for model-driven

DSS, but data for a speciﬁc analysis may need to be

extracted from a large database.

87.1.7 Secondary Dimensions

The secondary dimensions used to describe DSS

include purpose, targeted users, and the enabling tech-

nology. A relatively new category of DSS made

possible by new technologies and the rapid growth

of the public Internet is interorganizational DSS.

These DSS target a company’s customers or suppli-

ers. The public Internet is creating communication

links for many types of interorganizational systems,

including DSS. An interorganizational DSS provides

external stakeholders with access to a company’s in-

tranet and authority or privileges to use speciﬁc DSS

capabilities. Companies can make a data-driven DSS

available to suppliers or a model-driven DSS avail-

able to customers to design a product or choose

a product. Most DSS are intra-organizational DSS

that are designed for use by managers in a company

as stand-alone DSS or for use by a group of man-

agers in a company as a group or enterprise-wide

DSS.

Many DSS are designed to support speciﬁc busi-

ness functions or types of businesses and industries.

These are broad- or narrow-purpose DSS.SuchDSS

can be labeled as function-speciﬁc or industry-speciﬁc

purpose DSS.

A function-speciﬁc DSS such as a budgeting sys-

tem may be purchased from a vendor or customized

in-house using a more general-purpose development

package. Vendor developed or off-the-shelf DSS sup-

port functional areas of a business such as marketing

or ﬁnance; some DSS products are designed to sup-

port decision tasks in a speciﬁc industry such as a crew

scheduling DSS for an airline. A function or task-

speciﬁc DSS has an important purpose in solving

a recurring decision task. Function- or task-speciﬁc

DSS can be further classiﬁed and understood in terms

of the dominant DSS component in the DSS.So,

a function-speciﬁc DSS may be model driven, data

driven, document driven or knowledge-driven. These

DSS have capabilities relevant for a decision about

some function that an organization performs (e.g.,

a marketing function or a production function). These

DSS are categorized by purpose: function-speciﬁc DSS

help a person or group accomplish a speciﬁc deci-

sion task; general-purpose DSS software helps support

broad tasks such as business performance monitoring,

businessintelligence, projectmanagement, anddecision

analysis.

All ﬁve broad categories of decision support sys-

tems can be implemented using web technologies.

When the enabling technology used to build a DSS

is the Internet and web is seems appropriate to call

the system a web-based DSS.Aweb-based DSS is

a computerized system that delivers decision support

Part I 87.1

1544 Part I Home, Ofﬁce, and Enterprise Automation

Table 87.2 An expanded DSS framework (after [87.1])

Dominant DSS User groups: Purpose: Enabling

component internal, external general, speciﬁc technology

Communications Internal teams, Conduct a meeting Web or

Communications-driven DSS now expanding Bulletin board client/server

Help users collaborate

Database Managers, staff, Query a data Main frame,

Data-driven DSS now suppliers warehouse client/server,

web

Document base Specialists and Search web pages, Web

Document-driven DSS user group is expanding ﬁnd documents

Knowledge base Internal users, Management advice, Client/server, web

Knowledge-driven DSS now customers choose products

Models Managers and staff, Crew scheduling Stand-alone PC

Model-driven DSS now customers Decision analysis

information or decision support tools to a manager or

business analyst using a thin-client web browser such

as FireFox or Internet Explorer [87.1]. The computer

server that is hosting the DSS application is linked

to the user’s computer by a network with the trans-

mission control protocol/Internet protocol (TCP/IP).

In many companies, a web-based DSS is synony-

mous with an intranet or enterprise-wide DSS.Web

technologies are powerful tools for creating decision

support systems and especially interorganizational DSS

that support the decision-making of customers and

suppliers. Web 2.0 technologies are the leading edge

for building DSS,butsomeDSS will continue to

be built using mainframe and client–server enabling

technologies.

Column one of Table 87.2 lists the ﬁve broad

categories of decision support systems that differ in

terms of the dominant decision support component, in-

cluding communications-driven DSS, data-driven DSS,

document-driven DSS, knowledge-driven DSS,and

model-driven DSS. The table provides examples of

targeted user groups – intra-organizational and interor-

ganizational, purpose, and enabling technologies.

One can use the dominant DSS architecture com-

ponent, targeted user group, purpose, and the enabling

technology to describe a speciﬁc decision support sys-

tem. For example, a manager may want to build

a model-driven, intra-organizational, product design,

web-based DSS to support a speciﬁc business decision

process.

87.2 Building Decision Support Systems

Traditionally, information systems academics and prac-

titioners have discussed building decision support

systems in terms of four major components:

1. The user interface

2. The database

3. The models and analytical tools

4. The DSS architecture and network [87.6].

This traditional list of components remains useful be-

cause it identiﬁes similarities and differences between

categories or types of DSS and it can help managers

and analysts build new decision support systems. The

expanded DSS framework [87.1, 9, 10] is based on the

different emphases placed on DSS components when

a speciﬁc system is actually constructed (Fig.87.1).

Data-driven, document-driven, and knowledge-

driven DSS need specialized database components.

A model-driven DSS may use a simple ﬂat-ﬁle

database with fewer than 1000 records, but the model

component is very important. Experience and some

Part I 87.2