Designing and Developing IODSSs

 < Day Day Up > 

IODSSs should be built using a decision-oriented diagnosis approach (cf., Stabell, 1983). Simply making an existing DSS accessible using a Web browser or accessible to customers or other external stakeholders will usually lead to unsatisfactory results. Once a diagnosis of decision support needs is complete, a feasibility analysis is definitely required for building such a potentially large- scale DSS. A systematic development approach must then be explicitly chosen, and managers must be involved in the development process.

Developing the user interface, models, and data store for IODSSs remain major tasks. A user interface is important in a Web development environment, and it probably becomes more important because so many stakeholders of various levels of sophistication can potentially access some or all IODSS capabilities. The charting, “what if?”, drill-down, and other decision support capabilities available to designers of Web-based IODSSs are comparable to those for stand- alone, PC-based DSSs, but the number of available decision support operations expands enormously with the additions of hyperlinks and the availability of external data and document sources.

Source: Modified from Power and Kaparthi (2002).

The actual architecture implemented for IODSSs is usually simple. Most Webbased IODSSs are built using a three- or four-tier architecture and are designed to allow any authorized user, with a Web browser and an Internet connection, to interact with them. The application code usually resides on a remote server, and the user interface is presented at the client’s Web browser. A person in a stakeholder organization, using a Web browser, sends a hypertext transfer protocol (HTTP request) to a Web server provided by a focal organization or its subcontractor (application service provider, ASP) (see Figure 2). The Web server processes the request. This typically includes server-side scripts like VBScript, JavaScript, or ColdFusion Markup Language (Kaparthi & Kaparthi, 2001). In addition, the server-side processing may include execution of Java Servelets or other native executables. The script may implement or link to a model, process a database request, or format a document. The server may access other database servers, Web servers, or directory servers in a multitier architecture. The results are returned to the user’s Web browser for display as an HTTP response. The client receives the response that is formatted using the hypertext markup language (HTML) or other markup languages like the extensible markup language (XML). In addition, client-side processing may include scripting using JavaScript or VBScript, Java applets, ActiveX components, or other proprietary formats like Macromedia flash or Adobe Portable Document Format (PDF).

click to expand
Figure 2: Web-based IODSS architecture

When a company embarks on building Web-based IODSSs, some problems can be anticipated and minimized. First, Web-based DSS applications will probably encounter some peak load problems. During the business day, many managers will want to access the corporate intranet, and so a “high-performance” hardware architecture that can expand to serve a large number of concurrent users is needed. This load problem is associated with the “scalability” of the hardware and software and the planning of the developers. Quality of service (QoS) will be a major issue when using the Web for IODSSs. Virus and denial of service attacks can further impact IODSS reliability.

Second, the Web is a “stateless” environment that does not automatically keep track of configuration settings, transaction information, or any other data for the next page request. To avoid requiring users to reenter information such as user name and password, Web-based DSS applications must keep state information from one Web page to another. This creates new security issues for companies wishing to make sensitive, internal data accessible to users. User authorization and authentication are challenging in the Web environment because of the large number of potential users.

Third, Web technologies continue to evolve and mature. The technology uncertainty forces organizations and managers to monitor the changes and fund frequent upgrades. The cost of deploying IODSSs is decreasing, and there is a continuing danger that competitors will implement systems that “leapfrog” existing IODSSs. Despite these problems and challenges, the Web is and should be the platform of choice for new IODSSs.

 < Day Day Up > 

Inter-Organizational Information Systems in the Internet Age
Inter-Organizational Information Systems in the Internet Age
ISBN: 1591403189
EAN: 2147483647
Year: 2006
Pages: 148 © 2008-2017.
If you may any questions please contact us: