Selasa, 16 November 2010

IT Corporate Integration (Part 2)



The Decision to Replace the Customer Service Center System The hardware for the PC-based Customer Service Center system was an early IBM PC with the 8086 chip, plus a 10-megabyte hard disk. Although the system had been enhanced over the years and was working well, by 1990 Batesville Casket had reached the limit of what could be done with this 1stgeneration hardware, and there were a number of things that the logistics people wanted to do in the near future to improve Customer Service Center operations. But the major problem was that the equipment was so old and obsolete that some maintenance contractors were not willing to continue to service some of the components of the hardware. It was clear that the hardware was on its last legs.
One obvious alternative was to merely replace the old hardware with new hardware and continue to use the existing software.
The functionality of the system would remain the same,but the hardware would be maintainable, and sufficient additional capacity would be available to support future enhancements of the system. Unfortunately, the Knowledge-Man software that the system was based upon had gone through several releases, and the version that Batesville Casket was using was no longer supported by the vendor. Even if Batesville Casket continued to use the existing software, they would have to change it to conform to the current version of Knowledge-Man, which would involve a substantial reprogramming effort.
In 1990 Jan Holm, a senior systems analyst, and Jerry W.Munchel, an MIS program manager, spent several months working with the logistics area to explore expectations concerning logistics developments over the next five years. “We looked at their goals and objectives, how they expected Batesville Casket’s manufacturing and distribution systems to evolve, and projects they were anticipating that might impact the needs of
the system,” Holm reports.
One idea under consideration was to identify each casket by bar coding its model number and serial number so that the casket could be automatically tracked through the production and distribution system. Logistics managers expected to place a hand-held bar code reader on the loading dock at each Customer Service Center and connect it to the Customer Service Center PC through a radio-frequency link. Then they
could automatically enter the identification of each casket into the computer as it was received into or sent out of the Customer Service Center. In order to further reduce cycle times, they wanted to send orders to the factory several times
a day rather than sending them all at night. Furthermore, they wanted to replace the routing software package that was part of the system with a more powerful version.
Batesville Casket’s increased emphasis on total customer satisfaction was also leading the logistics staff to plan significant additions to the system to enable them to capture data on service quality and improve customer service. For example, many funeral directors order by description rather than model number, so a Customer Service Center manager sometimes misunderstood and sent the wrong casket to the funeral home.
Therefore, logistics would like to have a system that maintained a history of orders and allowed for improved identification of the models being ordered.



Therefore, in early 1991 the MIS department set up a team to investigate alternatives and recommend what should be done. Munchel headed the team, and the other members
were Holm, Kenneth D. Fairchild, director of Technical Support, and Delbert Rippeltoe, manager of Database Administration. Munchel and Holm had been instrumental in the development of the old system, and Fairchild was responsible for the communications between the office and the Customer Service Centers.
Deciding What Technology to Use The logistics study convinced the team that they needed to significantly revise the software in addition to replacing the hardware,
and it also provided the basis for a number of critical decisions relating to the future technological platform. “Once we decided to replace the hardware, we had to determine how big and how fast the computers should be and what operating system to use,” Fairchild explains, “and when we decided to redo the software, we had to determine what database manager and development environment to use.”
The hardware and operating system decisions were relatively straightforward. The plan to place bar code readers at the loading dock and enter data from them directly into the computer determined that the new computers must be multitasking.
Otherwise, the Customer Service Center manager would have to interrupt his work with the computer whenever the bar code reader was used. Another reason for multitasking was that logistics managers wanted to be able to transmit orders to Batesville during the day without interrupting computer support of normal Customer Service Center operations.
They concluded that an IBM-compatible 386-based computer would have all the processing power that the Customer Service Centers were likely to need during the next few years,and they wanted computers that could be upgraded if needs expanded even more than they planned. They chose an IBM PS/2 Model A16 with 4 megabytes of memory, a math coprocessor,a color monitor, a mouse, and a 160-megabyte hard
disk. They chose a Hayes 9600 Ultra external modem for communications with Batesville and an Epson LQ1170 printer. In order to minimize error and downtime problems, they decided to install an uninterruptible power supply at each site. The total
hardware cost for each site was over $8,000.
The operating system had to support multitasking, and they only considered IBM’s OS/2 and UNIX. Windows was not considered because its DOS base was not considered robust
enough for the Customer Service Center operations. They chose OS/2 primarily because they were concerned that there would be a shortage of business software packages that operated under UNIX. In particular, they knew of no routing packages that would run under UNIX.
The database manager and development environment were related decisions, for the development environment had to support the chosen database manager. One critical issue that strongly influenced their decisions at this point was the choice of a user interface. Intuitively they felt that the new system should be based on a graphical user interface, where system functions would be controlled by using a mouse to select
options by pointing and clicking on icons, buttons, decision bars, and pull-down menus. The Apple Macintosh, Microsoft Windows, and OS/2 Presentation Manager employ graphical user interfaces.
“We did not know how the Customer Service Center managers would react to using a mouse,” Holm explains, “but when we looked at the interactive software packages that were becoming available, they were mouse-driven, windowing, graphical. The upgrade to our router package that logistics was considering has a mouse-driven, windowing user interface. We knew that the managers were going to have to learn how to interact with those packages anyway, so we decided that we needed to be graphical as well.”
As an example of such a graphical interface, the order update screen from the new system (shown in Exhibit 3)allows a Customer Service Center manager to update an existing order. This order is from the ABC FUNERAL HOME for product number 7878. A casket, serial number WA7915, has been allocated to this order, and other information on this order is shown on the screen. The buttons along the right show the things a manager can do to this order by using the mouse to point to the button and click. The top two buttons allow him to navigate to the next and prior orders. Other buttons allow him to change data on the order, cancel the order, allocate or unallocate
a specific casket to the order, assign it to a route for delivery, remove it from an assigned route, change the route, or quit the order update process.
Once they decided to use a graphical interface, the development environment had to support the easy creation (or “painting”) of graphical screens. This led them to consider Object/1, a tool that Holm knew supported object-oriented programming and that claimed to allow a developer to paint dozens of graphical screens in a day. Object/1 was a product of MDBS, Inc., a small software house located in Lafayette,
Indiana, which furnished the Knowledge-Man system that had been used to support the original Customer Service Center system.
Because Batesville Casket had a long and favorable experience with MDBS, it was natural for the team to take a hard look at Object/1. They did not know much about object-oriented programming at the time, but they were aware that it was creating a lot of excitement in the industry. Software industry gurus such as William H. Gates, Microsoft’s chairman, Philippe Kahn, president of Borland International, and Steven P. Jobs, who founded Apple Computer and NeXT, were predicting that object-oriented technology would have a revolutionary impact on the future use of computers.
Object-oriented programming was extolled as a way to increase development productivity by creating programs composed of completely independent components (code modules).
These building blocks are freely interchangeable among different programs, so as an organization builds up more and more such modules, new systems require the creation of less and less new code. Also, maintenance is much easier because functions are isolated in modules and thus are easy to locate, and once a module is corrected in one system, it can easily be corrected in all the other systems that use that module.
The team did not do an extensive search of development environments. “We did not have a lot of time to search,”Fairchild reports, “so we looked at the products that we had in house that we had used before, and we looked at objectoriented programming and made the decision.”
They chose Object/1 for a number of reasons in addition to its reputed development and maintenance efficiency. First, it would provide outstanding support for the graphical user interface approach that they wanted to use, and it could access a
database manager that provided the backup and recovery capability that they needed with multitasking. Second, industry seemed to be heading that way, and keeping near the leading edge was important to them. Finally, as Holm notes, “We could have used one of our familiar tools, but there would have been no learning experience for the department, and we enjoy the challenge!”
“The team wanted to do something new and exciting, and I knew that they would dedicate themselves to making it a success,” Kuisel explains. “Since we knew exactly what the system was to do, and the old system was working well in the short run, there was little risk other than the new technology. Objectoriented programming looked like it might be very important to us as we use PC platforms more extensively, so this was an investment in the future.”

Learning to Use Object-Oriented Programming

Object-oriented programming appears to be simple because there are only a few basic terms to learn: object, method, class, inheritance, and encapsulation. But it is also a new paradigm, or way of thinking about programs, and it is not easy to explain. An object can represent anything of interest—a number, a date, a screen, a casket, a customer—anything that involves data. An object includes both the data describing the object and all of the methods that can operate on that object. Each method, then, is a code module that does something to or with the data of the object. Encapsulation refers to the binding together of the data and the methods that operate on the
object; the only way that an object can be operated on is by means of its methods. Thus, the object is protected from actions performed by other parts of the program, or from actions of other programs that may use that object. Objects are the building blocks from which all programs are built, and because of encapsulation the same objects can be used by many different programs. Once the methods of an object are
correct, they are correct everywhere that object is used. When one changes a method, it is changed everywhere that object is used.
“A mortgage is an example of an object,” Holm explains. “There are things that you want to do against a mortgage. You might want to calculate a present value, or determine the return on investment. The mortgage has some data associated with it—interest rate, payment amount, amount owed, etc. Then there are routines that you perform against that mortgage when you ask questions about current balance or the effect on payment amount of a change in interest rate. In object-oriented
terminology, these routines are called methods, and they are encapsulated in the object. So when you ask a question of an object, you don’t know or care how it gets the answer. If there are ten other systems that need to ask that question, they all
ask that same object. And if you decide that you want to change how you calculate the answer, you change the method in the one object and it is changed in all the systems.”
The concept of a class is closely related to the concept of an object. A class is an abstract object that includes the characteristics (both data and methods) that are common to the objects that comprise it. For example, automobiles might be a class,
and Ford Mustang and Buick Skylark might be the objects of that class. Classes are hierarchical—if vehicles were a class, then automobiles would be a subclass and trucks might be another subclass. What makes this concept powerful is inheritance.
If one creates a new object in a class, it automatically inherits all of the properties of that class, and it is only necessary to add the data and methods that are unique to the new object.
“For example,” explains Fairchild, “data might be a class, with alphanumeric data being one subclass and numeric data being another subclass. Then an integer might be a subsubclass within that subclass of numeric data, and a decimal number might be another sub-subclass and a binary number might be another sub-subclass. Integers and decimal numbers and binary numbers would all inherit certain methods from the
numeric data subclass, which would also inherit common methods from the data class.”
One very powerful aspect of Object/1 is that it comes with some 300 classes and 3,000 methods already defined and ready for use. Whenever you create new objects or classes, they become available for use in all subsequent programs.
As has been previously noted, Object/1 already includes the objects necessary to create graphical screens, so they may be painted with no traditional programming. The screen painting utility displays a blank screen (called a canvas) along with a
set of symbols denoting the various things that can be placed on a screen—buttons, list boxes, data entry boxes, display boxes, labels, etc. To create the button “Next Ordr” on the screen in Exhibit 3, for example, you would use the mouse to point and click on the symbol for push buttons. Then you use the mouse to point to the position on the screen where you want this button to appear and click again. This brings up a
screen that allows you to enter the name of the push button and the method to be invoked when this button is selected. To create the entry field labeled “Serial,” you would click on the symbol for entry field, point to where it should appear, and click
to bring up a screen that allows you to enter the name of the field, and so forth. If you do not like where you have placed an object, the mouse can be used to “drag” it to another position.
When finished, you give the screen a name, and it becomes an object that inherits all the methods that have been created for the screen class of objects. As an example of object-oriented programming, Exhibit 4 presents the code invoked by clicking on the Change button on the order update screen shown in Exhibit 3. Methods are invoked to operate on objects by the following notation:
MethodName(ObjectName, P1, P2,...)
When a pair of parentheses encloses a list of symbols separated by commas, the left-most symbol is the name of an object, and the other symbols in the list (if any) designate parameters that are used by the method. The name of the method to be applied to the object precedes the left parenthesis.
Consider line 8 of Exhibit 4:
found=returnValueOf(new(OrdrChg, self)); This nested pair of methods would execute from the inside out, so the method new would be applied to the object OrdrChg with the parameter self. But the object OrdrChg is the screen shown in Exhibit 5, which has methods that allow the manager to point to any box and enter or change the data in that box. In this example, we have typed pick comment in the box labeled Pick Comm.
When the manager is through making changes to the data shown on this screen, he or she uses the mouse to click on the Accept button on this screen. This button is an object, and clicking on it invokes a method that completes the change process and returns to the method new, which creates a new version of the object OrdrChg (and completes the actions enclosed within the parentheses in line 8). Then the method
returnValueOf is applied to this new version of the object OrdrChg to store a returned value into the object found. The result of the entire process shown in Exhibit 4 is to display the screen shown in Exhibit 6.
In the above, the object OrdrChg is an instance of a class that comes from Object/1, and the methods new and returnValueOf were inherited from existing objects in Object/1. All of the button objects are instances of the button class from Object/1, and all the screens are instances of a screen class from Object/1. Although these basic concepts may seem relatively straightforward, the team found that it was not easy to learn to use them effectively. “We had a much longer learning curve than
we expected,” Munchel reports. “We had a training problem. When we decided on Object/1, the next vendor training class was scheduled for two months later, and we couldn’t wait that long. So we brought in a consultant to do an abbreviated version
of the training, and we did not get the training we needed.
We ended up working through tutorials while we were trying to get started with coding the system.” This lack of formal training was critical because objectoriented programming is so different from other programming. “Object-oriented programming really is a totally different mindset,” Fairchild notes. “I couldn’t find anything to relate it to in my 25 years of programming experience. In fact, my past experience
often led me astray!”
“We didn’t really understand the terminology,” Holm explains. “It sounded like doubletalk—we laugh now. But once in a while the light would pop on and we’d think we
understood. And then we would go on and find that we did not completely understand that, and we would have to go back to the beginning again. It was a highly repetitive
process.”
Not only did they have to learn the concepts, but they also had to learn how to use the Object/1 tool. Object/1 provides many classes and objects that one can use, but it takes some time to become familiar with what is there. “MDBS, Inc. provides
a big book that contains descriptions of all these classes and methods,” Fairchild explains, “and we had to learn whether to use one of theirs or write one of our own. It took us a long time to figure out what classes we were creating and maintaining.
And we had to teach the other programmers (and ourselves)to look for existing methods before starting to code something new.”
Object/1 supports the programmer by providing an online list of all the available objects and classes. When the programmer selects a class or object, a list of all the methods that apply to it appears on the screen. When a new object or method is
created, it is automatically added to this online display. Object/1 also includes an online editor that enables a programmer to create code on the screen and edit it to make changes. Thus, Object/1 provides powerful assistance for online programming.



Developing the System
The team was scheduled to install the system in December 1991. They planned to train the Customer Service Center managers in December, when they were to be in Batesville for a national meeting, thus saving about $70,000 that it would cost to fly them in at another time. Although the team had decided on Object/1 in early June they did not produce any usable code until early September, because of their long learning curve.
By working 70-hour weeks, Holm, Fairchild, and two additional programmers were able to complete about 80 percent of the functionality of the system—the day-to-day operations necessary to run a Customer Service Center—by the training date in December, so they were able to train the Customer Service Center managers at the scheduled time. But the system was far from ready to install—they still had to complete the remaining 20 percent of the functionality and take care of fundamental
system operations like transaction logging and record locking. They also had to develop a system to convert the data files in the present system to the form the new system required.
They also had to redo the data model of the old system. “Although about 95 percent of the data were there in the old system,” Holm recalls, “the new model does not look like the model we had in the old system. We had to rethink the data in terms of object-oriented concepts.” The final system includes about 40 data objects, such as an order object, a customer object, and a casket object. There are many other objects, such as input and output screen objects.
And they have created about ten “utility” classes, such as the print class that their programmers always use when printing a report. This print class includes methods that take care of the date, positioning column headers, page counts, spacing, accumulating
and printing totals, and all the other things that are necessary to create a printed report.

Converting to the New System
Rather than the team going to each Customer Service Center to assist them in converting to the new system, the team devoted about two man-months to the creation of an elaborate conversion system to guide the Customer Service Center manager
through the 40-odd steps necessary to install the new OS/2 operating system, load the new software on the hard disk, and convert the files from the old to the new system. It took between 6 and 12 hours to complete the conversion process at each Customer Service Center. And since there had been such a long time between the training in December and the actual installation of the system in April, the team also prepared
and sent out a training version of the system in March so that the Customer Service Center managers could practice installing the system and play with it to refamiliarize themselves with the operation of the new system.
In mid-March 1992, they tested the system in the Customer Service Center in Indianapolis, and they began to convert to the new system in the rest of the Customer Service Centers in early April. When they converted the first four Customer Service
Centers, they encountered a mysterious bug that set them back for a while. On rare occasions the system would mysteriously lock up, and they would have to shut it down and reload the software. With new hardware, a new operating system, the Object/1 development system, and the new application system, they were in totally unfamiliar territory and had to call in experts from IBM and the software vendor MDBS to help them diagnose and correct the problem, which turned out to be a bug in OS/2. As of June 1992, the system was successfully installed in all the Customer Service Centers.
Batesville Casket had purchased 15 of the new computers in late 1990 and installed them in Customer Service Centers early in 1991, running the old software on them. The system really flew! But the new system operates slower on the new hardware than the old system does, and the Customer Service Center managers that had used the old system on the new hardware have noticed this slowdown. The new system is slower because Object/1 programs are interpreted rather than compiled in this first generation version of the software.

Evaluation of This Experience
Although the team learned a tremendous amount about the object-oriented approach, they realize that they still have more to learn. “We need to change our approach to design as well as to writing code,” Holm asserts. “We think we are in pretty good
shape in object-oriented analysis, but we need to go back and work more on system and program design.” Fairchild recalls that: “As part of the tool they say that a method should probably not exceed 15 to 20 lines of code, but we have some with a couple of hundred. We need to go back with what we have learned and rethink some of the things we have done.”
They obviously did not meet the original December 1991 deadline for installing the system. After getting through the long learning curve, it took them about five months to code the system. “We did a lot of work in a short amount of time, even including the learning curve,” Fairchild notes. “Without the Object/1 tool, I do not know how we could have produced a system with the graphical interface that we now have.”
“The first system you develop using object-oriented programming may take about the same amount of time that it would using traditional approaches,” Fairchild continues. “But where you are really going to make hay is on the next and succeeding systems. You don’t have to go back and rewrite any of the things that you have already done. You can use the objects and methods that you have created, and they will port right
into any new system. For example, we can use our print class in any new system, and there are many objects like that.”
Holm notes that there are even wider implications. “One inventory control system, no matter what the industry, is much like any other. The object-oriented approach allows us to take advantage of that commonality. I would be comfortable taking this system to any company that is running a distribution warehouse, and it could be easily modified to suit its needs. “Tools like Object/1 will eventually have an inventory control set of classes and methods that will allow any organization to easily put together an inventory control system to suit its needs. You will be able to make changes to reflect the uniqueness of your organization, while still taking advantage of all the commonality. You will be able to quickly create a working system from common objects, try it, and quickly modify it to suit your special needs.”
Kuisel evaluates the project as follows: “It has taken longer than we planned, and a late project is always a disappointment. But the new system appears to be just what we wanted, and there is a lot of excitement about using it. The old system was getting to be a little shaky, but I’m confident that the new one is a solid foundation for what we want to do in the future. “Moreover,” Kuisel continues, “we have learned a lot about the object-oriented approach and how to use it. After this is over, we will evaluate this and other tools available in the marketplace and see what fits our needs best. I suspect that the object-oriented approach is going to come out ahead, but our development people will make that decision. They are the
ones that must go through the very difficult learning curve to adapt to the object-oriented approach, so they must make their own commitment if we are to adopt this new technology for widespread use.”

Tidak ada komentar:

Posting Komentar