Previous | Table of Contents | Next |
Systems integrators must select from a large range of products and unite their selections into a system that solves the problem at hand for the user. The challenge for the systems integrator is knowing which criteria should be used in selecting the software for each application and ensuring that all the choices work together in a smoothly running system. At a minimum, software choices must be made for the graphical user interface (GUI), the database, interprocess and intraprocess communication, and the programming languages.
Generally, however, senior management, technology committees, or infrastructure specialists in the individual shops make the software choices and give the development team one or two options from each software category. In this case, team members should assess the qualities of the software tools under consideration: particularly, how the qualities affect the end result and how the tools will interact with each other.
The key to integration of open systems for both the experienced analyst as well as the novice developer is to completely understand the goals of the application. All members of the development team have to understand how the users business works and the users desired goal for the system. This point cannot be stressed enough. Users often have a specific approach to the way they do business. Whether this approach is based on habit or on business constraints, members of the development team must pay attention to it. New approaches and ideas should be considered, but ultimately, the way the system approaches the business is always up to the user.
The third important component of a successful integration process is a solid development team. The mainframe environment allowed a single developer to successfully create an integrated system because the components were already integrated by the mainframe provider. When a technology shop was set up on an IBM mainframe, IBM Corp. also provided the software. There was certainly systems software, which was centralized, and other database software products like SQL/DS, dBase 2, or FOCUS and procedural languages like REXX installed and stabilized in a central location. There was one text editor available. The mainframe manufacturer usually supported only one copy of utilities and operating systems, so much of the software choices were already made, installed, and known to work together. The only thing the programmer/analyst was ultimately responsible for was the function of the system for the user. In addition, the mainframe architecture rendered it often more convenient for one person or a very limited number of people to work on a single integrated system.
At the opposite extreme, client/server systems are built on hardware platforms like workstations or PC LANs platforms that give systems analysts and developers much more freedom and flexibility in tool selection, design, and implementation. Because so much more flexibility and processing alternatives can be built into an integrated system, a team of two or more analysts and developers, as well as component specialists, is required to create an integrated, open system.
The sum total of knowledge of the development team must encompass two disciplines: technology and the users business. Within the technology discipline, the team must include members with strengths in database software, GUI software, communications software, and applications software. Analysts and software developers are often experienced in more than one of these areas. Similarly, specialists in the hardware technology in use should be part of the team effort. They can advise on interprocess and interplatform communication and performance, as well as on programming for them.
The technologists knowledge of the users business is at least as important as experience with computer technology. Understanding the users requirements determines how the applications software will function; hardware accommodation will ultimately determine the systems performance.
Interpersonal communication and creation of an effective personal rapport between members of the development team and the users are essential to the integration process. The building of working relationships significantly improves the effectiveness of the completed system. When productive working relationships exist between the users and the development team, developers are less intimidated about what they do not know and ask many more questions. Instead of glossing over issues in the fear of appearing naive, developers are more apt to explore them with users.
Conversely, users need to feel comfortable too. Many business people are still very much intimidated by computers. When unfamiliar terminology and technology is suddenly flung at successful people who are used to being in control, they feel uncomfortable, and uncomfortable users do not easily or willingly discuss the system with the development team. Barriers between the users and the developers degrade the quality of the systems integration process. Forging a solid, interpersonal working relationship between users and the development team is therefore integral to the process of systems integration.
The first technical step in the integration process is gathering specifications for the system. There are several ways to do this. Naturally, the best source is the user. Discussions and interviews with the main user or user liaison and his or her peers are essential, as is careful and organized note taking by members of the development team. Ideally, part or all of the development team should sit with the user for as long as possible, or at least for a minimum of several business days.
Other sources for gathering specifications include other companies, professional associations, and books and articles on the subject. Information from these sources often adds depth and perspective to the goals specified by the user.
Following each session with users, the development team should discuss the information given to it and how it relates to what the team already knows. This exercise helps team members refocus on the goal of the integrated system and to share their own experiences and development ideas. At the end of the systems specification process, the members of the development team should comprehend the users business on an intuitive level.
Previous | Table of Contents | Next |