Mohan96 |
PublicReengineering Wiki |
|
A report on the reengineering of Consilium's WorkStream? product. WorkStream? is a manufacturing execution system for the semiconductor and pharmaceutical industries. It monitors, controls and optimises manufacturing processes. It consists of many modules from which customers can choose. Original system is monolithic with around 4 mloc and runs of VAX/VMS, with a CODASYL database and implemented in COBOL. It consists of one large on-line executable with some small executables for batch runs which produce reports. WorkStream? is transaction based and accepts about 4000 such transactions. The close coupling of components meant that every new piece of functionality required extensive system changes and testing. In the 1990s, sales prospect wanted open systems with relational databases and GUIs. Initially the system was ported to UNIX using a relational DB in place of CODASYL. This improved market acceptance and provided an opportunity for developers to learn about RDBs and UNIX. This move helped the developers gain new skills which would prove useful in subsequent work. However, the transition did not address issues such as: - The cost of maintenance, down times for upgrades and the initial outlay for hardware. - Quality - bug fixes had a ripple effect throughout the system and testing became onerous, particularly for any customers who may have done some customisation. - Customer service - it took a long time for request from customers to be implimeneted. The market was demanding client/server architecture and Consilium decided to develop a fully distributed system. However, existing customers didn't want excessive down times to avoid interrupting production. They did want to see the next generation of system but wanted confidence that their was a safe migration path. New prospects, however, wanted the new system soon. Interestingly, Mohan states that most additional business comes from the installed customer base and there is limited expansion potential. As such, it is important to satisfy existing customers. The also wanted to get the most out of the existing systems strengths and make best use of existing in-house skills. They needed to manage the change and provide the highest value to their customers early. They also recognised that they had to develop their people by introducing them to new technology. Mohan recognised that the big-bang approach was too expsneive, would take too long and was too risky. Therefore, an incremental migration strategy was adopted and distinctions were made between phasing-out (ie replacing components) and phasing-in (ie providing new functions). The phases-in features offered the greatest benefits to the customer and were some of the first aspects addressed. However, the first step was to provide an infrastructure for distribution. Relaibale distributed Objects (RDO) from ISIS distributed systems was chosen as a message bus. Buying a COTS system allowed Consilium to focus on their core competencies and not have to maintain a communication machnisms. RDO provided acceptable fault tolerance and load balancing capabilities. It also allows them to migrate to and take advantage of new technology standards, such as CORBA, in the future. The chose smalltalk and C++ as their application languages and set about training a small team in these. As the project progressed, other developers were trained and phased into the project. OO experts were also brought in to mentor the team. As a result, they have conserved domain experts by giving them career development, but they did loose staff who's new skills made them in demand elsewhere. They found testing distributed systems more difficult, time consuming and costly than for the monolithic legacy due to a high number of possible failure scenarios. She sees the benefits of incremental over big-bang as: - seeing true costs early and refining estimates throughout. - early delivery of benefits to help encourage customer support. - more likely to meet user demands. - developers get motivated by seeing success earlier. Good problem statement: "How can you deliver a client-server implimentation of an existing monolithic mainframe legacy to an installed cutomer base with minimal disruption and risk".
Related pages: Bibliography |
| This page last edited on 29 October 1999 |