Previous Table of Contents Next


Chapter 70
Open Systems Integration: Issues in Design and Implementation

Leora Frocht

Open systems integration in today’s client/server environment challenges project managers to incorporate issues of performance, communication, and compatibility in what is often a new development arena. This chapter presents seven rules of integration that help managers and project teams produce an open system that is fluid, sensible, and intuitively usable.

PROBLEMS ADDRESSED

Applications development in the open systems environment involves numerous and varied integration issues. As previously unusable ideas are translated into entirely new client/server systems, open systems tools make possible the development of applications that could not be developed on mainframes or on pre-windows PCs. Designing and implementing open systems therefore presents new and often daunting challenges.

Development team members generally do not have much experience in the open systems environment. The technology is relatively new, and the tools are not mature in the sense that they have not been used commercially for at least ten years. There is no foolproof methodology, and many choices regarding software must be made amid a plethora of conflicting opinions. Experienced developers, who are generally familiar with mainframe or pre-windows tools, must change their entire pattern of thought to adapt to open systems and the client/server approach.

This chapter is based on the experiences of one project manager in integrating legacy systems into a new open systems environment. The seven rules of integration developed from that experience address the many components of integration in the open systems environment and should help managers anticipate and thus mitigate potential problem areas.

ISSUES IN OPEN SYSTEMS INTEGRATION

Integrated systems development involves issues of performance, communication, and compatibility. Integrating legacy systems into an open environment focused on seven major factors that are generally applicable to systems integration projects:

  User specifications.
  Business alignment.
  Communications.
  Data accuracy.
  Resource contention.
  Ergonomics.
  Legacy systems.

Managers involved in such projects are challenged to manage these components and integrate them into a fluid, sensible, and intuitively usable system.

User Specifications

A reasonable understanding of user requirements makes the integration of the other six components much easier. Accurate interpretation of user specifications depends on the manager’s ability to bring together project team members with the appropriate training and experience level.

Alignment to Business Objectives

A thorough understanding of the business objective also helps derive the end user’s requirements, needs, and goals and ensures system performance. No decisions, whether software- or hardware-related, can be made without a thorough understanding of how the business is conducted.

Many development choices depend on what the business requires. The system must be flexible enough so that users are able to do more than they expected or initially thought of. To the extent permissible by today’s technology, the system should be portable so that an application can be moved from one platform to another, from one version of an operating system to its next generation, or from a PC to a workstation. It should be able to support current data needs as well as anticipated future needs.

Performance Performance, both in accuracy and speed, should reflect the end user’s identified business needs. It is hardware- and software-related. Appropriate hardware must be selected. For example, if high-volume communication is an aspect of the system, communications hardware, such as wide area network and local area network (LAN) routers and cables, must be selected and implemented to handle higher volumes. Volume is generally identified by users because they are the ones who generate transaction activity. Server machines must be designed to handle large volumes of data or applications software, or at least be scalable and configurable to do so.

Communications

Communications software must also be robust enough to send out and receive large volumes of data. Market data services, which provide information like stock prices in the Dow Jones industrial average, generally address these issues; they transmit hundreds of thousands if not millions of messages a day. Applications software designed to accept high volumes of messages must not only receive the messages but also interpret and process them efficiently. The source code must be able to receive each individual record, determine what to do with it (e.g., based on information in header data), and send it off to the designated recipient. The recipient could be a database, a flat file, or a window panel. All of these transactions must be completed in a reasonable time frame.

Accuracy

Accuracy is a critical issue in systems development. Appropriate business decisions are made only if data is correct all the time. Because accuracy is sometimes overlooked in the development of an integrated open system, project team members must be vigilant in resisting the temptation to do so.

Resource Contention

Applications developers must consider how data is used because in an integrated system two users should contend for resources. Resource contention frequently occurs when requests for data are made to the database. Standard procedure dictates that one user’s retrieval of data from a database not restrict other users’ access to the data.

Resource contention can also occur in the area of communications, particularly regarding interprocess communication or data broadcasting to a large group. The application must not require that the broadcasting of one message depend on the successful delivery of another message. Also, the successfully integrated system allows sent messages to be buffered or stored and processed separately from the communications portion of the application. That way, messages can continue to be received instead of being backed up because the communication protocol is still processing the previous message.


Previous Table of Contents Next

Copyright © CRC Press LLC