Strategies for object-oriented technology transfer (panel)

Strategies for Object-Oriented Technology Transfer (PANEL) Dennis de Champeaux, Fuure Inc. & Onto00 (moderator) Andrew J. Baer, American Munagement Systems, Inc. Brian Bernsen, McDonnell Douglas Aerospace East Alan R. Korncoff, The Boeing Company Tim Korson, COMSOFT & Clemson University Daniel S. Tkach, IBM International Technical Support Center 1 Background Improving SW development processes is getting increased attention. Hence we can ask for the circumstances under which it is preferable to stick to an existing (structured) paradigm and strive to improve development discipline or alternatively when it is warranted to do an 00 paradigm shift,. Can we formulate a rule of thumb of the form: An organization should improve its SE1 maturity level to X before considering a paradigm shift to OO? If not, why not. If yes, what is a recommended value for X? Software 00 has won the battle, but the war is not yet over. Success stories have been reported. Reuse has been observed in practice. Work is progressing to deal with a full lifecycle and to tackle mega systems. While the tra.nsition to 00 ma.y or may not be obvious for an individual, it is a complex affair? if not a nightmare, for large organizations. Programmers in divisions are often eager to go 00, their managers are often hesitant. A recurring question is how to deal with the large body of existing software that must keep running while at the same time it becomes more and more of a lia.bility. Corporate software research may be “miles ahead” of what goes on in divisions, but it is not obvious how to transfer these insights and practices into divisional trenches. VVe can rephrase these topics into the following groups of questions: Maturity Systems Folkore has it that the legacy problem can be attacked by wrapping an existing system inside an object and that one subsequently objectifies the inside layer-by-layer or subsystem-by-subsystem. This is minimal advice. Can we expand it? Legacy 2 There is a wide arsenal for impacting software work practices. These include training, using internal or external expertise; development of a.dva.nced prototypes in a corporate lab which a.re transferred to divisions; a,nd temporary transfer of people from a corporate think-tank to divisions and/or the other way around. What a,ctions yield the best pay off and what are optimal circumstances for their application? Technology Process Andrew Baer Transfer While many organizations have small pockets of object technology development, very few have moved to la.rge scale development of mission critical business systems. Using object technology to design, develop, a,nd deploy these types of systems requires more than learning a new language, and more than just learning how to fully take adva.ntage of an object development environment. Using object technology on this scale requires understand- 437 ing how objects impa.ct every development life cycle. Transitioning Technology fa,cet of the system the Organization ha.nds-on experience with the technology. This includes some limited hands-on training for designers and managers. Second, create a central object support team to initially champion object technology, to seed new project teams, and ultimately manage the corThe central object support porate reuse library. group member working on an object project has the responsibility to make sure that the project is aware of the designs and objects available in the corporate reuse library, is responsible for helping the project t,ea.m to utilize these reusable objects? is responsible for helping the team to develop new objects (or extensions to existing corporate reusable objects) in a way tha.t is consistent with the esisting library, and is responsible for incorporat,ing to Object Large organizations transitioning to object technology must choose between an evolutiona,ry approa.ch and a revolutiona.ry approach. The revolutionary approach suggests that it is best to “warp” directly to building large complex object systems, learning what you need to learn through the school of “hard knocks”. The evolutionary approach recognizes that people and organizations will learn and adapt more efficiently through a phased transition to object technology. I suggest that while the revolutionary approach may work for a very few organizations, that the evolutionary approach will be best for the large majority of those organizations responsible for developing large-scale mission critical business systems. these new objects (or extensions) into the corporate reuse libra.ry. Without this central staff, it will be difficult to make reuse an effective corporate practice. Third, develop a reuse plan and a vision of the basic architecture of your object technology a,pplications. It is more likely that you will crea.te reusable objects during your early projects if the designers and developers working on those projects have a vision of the objects that are most reuseful As part. of your reuse plan, for your orga.nization. develop a strategy for building your reuse libra,ry, and a strategy for fostering reuse. Daniel Tkach suggests that the phases for an evolutionary change t,o object technology are awareness, exploration, transition, and habit. In developing a strategy to effect this change, an orga.nization must a.ssess where they are along this spectrum. In doing so, the organization must also recognize that the move to object technology does not usually occur in isolation. It is normally accompanied by a move to other technologies such as client/server, GUI, and distributed data. Therefore, to develop a.n effective transition strategy, an organization must assess where individuals or groups are in rela.tion to the phases of evolutionary change for each of the new technologies being introduced. Of the many activities that are undertaken as part of transitioning to object technology, I would like to focus on four key activities. First, make sure to plan for ext.ensive training and mentoring. Learning object technology is not simply learning the syntax of a new la.nguage. It requires the designer and developer to extend their model of the software development process. Make sure that ev- Finally, understand the methods and techniques you will use to make object technology a repeatable and defined process. Object technology impacts the system development life-cycle. It doesn’t require us to “un-learn” what we already kno\v? but it does require us to adopt new practices and procedures. At AMS our research found that while many object technology experts have put forward ideas notatious on object design, and have developed for documenting object models, no one has documented a complete analysis, design, and development methodology for large scale business systems. To provide this full system life-cycle support, we chose to select portions of several object methodologies and combine them in way that works for eryone the types of projects working on object technology projects gets 438 we undertake. SE1 Maturity 3 Level Technology It is not necessary to achieve a specific level of software engineering ma.turity prior to transitioning to object technology. However, I believe an organization will want to move towards an SE1 level of at least 3 to maximize the benefits of reuse. Maximum reuse will occur when the elements (both designs and code) adhere to a format and standards used across an organization. Having a repeatable and defined software engineering process will foster reuse. Legacy Brian Bernsen Transfer Software technology transfer is perhaps more difficult than other types of technology transfer due to the abstract (and creative) nature of the design process. Likewise, it is more difficult to justify (in a capital budgeting sense) the investment in technology and technology transfer. However, there are a number of components to successful 00 technology transfer? many of which apply to all kinds of technology transfer. Management sponsorship and commitment is a key ingredient in 00 technology transfer. Management must understand the costs and benefits of technology since they provide the budget source for training and tools. Cost-benefit analysis and technical overviews should be prepared and presented to management to elicit their support. Organizational support should be provided by a technology center which selects and develops 00 technologies for in-house use a.nd applies these technologies to pilot programs. As technology is transferred to production projects, the technology personnel can move with it. They can serve as chief methodologists and act as a resource to other software engineers? or they can serve as chief software architects laying 00 frameworks for others to refine. (This is an effective way to “spread the fait”, but does not obviate the need for formal training of all software engineers.) Organizational and/or work breakdown structures should reflect object hierarchies vs. functional to facilitate the technology transfer. Training is the most important means of 00 Systems While some object zealots would like to believe that we ca.n just ignore legacy systems, the ma,jority of professionals in our industry understand that no technology is appropriate in all cases. In the short term, our ability to identify successful strategies for working with these legacy systems may determine the pace at which large organizations can move to object technology. In looking at the functionality of legacy systems it is important to categorize them by their operational characteristics. On one end of the spectrum, some legacy systems are massive data handlers and require very little user interaction (e.g., large billing systems like those found in the telecommunications industry or mailing list processors). At t.he other end are those systems that are highly interactive (e.g., customer support systems). While there are certainly exceptions to any guideline, it has been our experience that a.n organization receives the most benefit from migrating those systems at the highly interactive end of the spectrum first. These systems can benefit from the advanced user interface capabilities available on distributed hardware! and can benefit from the response time improvements of distributing the work load across a range of CPUs. The organizational benefits include bett.er customer support, reduced training of customer support personnel, and reduced mainframe costs. technology transfer. Everyone involved in the software development process should be trained including project managers, system engineers, softand (in many cases) the ware quality assurance, customer, with the training tailored for the target group. Alliances with academia can provide both training and trained individuals (for an expanding workforce). Re-training of an established workforce is more difficult since old met,hods must be “unlearned”? and there may be substantial iner- 439 tia. to overcome in an organiza.tion that has developed (and may be supporting) applications developed with other methods. This re-training is best accomplished in hands-on workshops. Classroom training and the distribution of manuals and texts is not sufficient. The use of 00 languages and tools can accelerate the training process and help to enforce the methods. 00 software design should be ta.ught in the context of the software engineering principles on which it is based (e.g. modularity and a,bstraction). quantitative justification for an organiza.tion level. Any informal, grass roots movement would likely not be possible. 00 technology and processes will be refined and developed on the first “real” project to which it is applied. A flexible schedule a.llowing for this learning curve is crucia.1. In general, schedules and development plans providing for prototypes, re-design, a.nd re-code are indicated since a. quality 00 design is difficult (if not impossible) to achieve in a single iterat,ion. Before considering the question of “how” to transform a legacy system to 00, it is essential to ask the question “why ?“. The conversion of any legacy system to an 00 system must be examined from a It may not be cost effective business perspective. or advisable to transform an existing system which has been tested and is in a maintenance phase to an 00 one. Perhaps the legacy problem is simply acknowledging that there will always be systems which are not. 00 and should not be converted. It may be the case that 00 is only cost effective on new or extensively modified systems. SE1 Maturity at this to 00 In short, there is not a minimum SE1 level below which a shift to 00 is not prudent, however organizations at level 1 should consider the transition to 00 concurrently with increasing the SE1 level. Legacy Level There is some relationship between the SE1 level and the feasability/ease of a transition to 00 methods. The SE1 level can certainly influence the ease and duration of a transition to an 00 method. The transition can only be as orderly as the SE1 level. According to the Capability Maturity Model (CMM) for Software (Version 1.1, Software Engineering Institute, February 1993), the software process in an organization at level 1 is “constantly changed” as the work progresses, thus a transition to 00 would be difficult to effect or measure. This Systems Converting an existing system piecemeal may also aggravate the legacy problem since there is no clean sheet to start from. For academic purposes, might creating objects “subsyst,em by subsystem” be difficult due to the fra.gmentation of the properties associated with each subsystem. It may not be possible to make a clean cut into an existing system to extract a subsystem and the logic associated with it. Furthermore, at any point in the conversion, you have an inconsistent system. A conversion makes more sense and “layer-by-layer” provides consistency within ea,ch la,yer converted, but again, it may not be possible to extract these layers without substantial re-work of code in other layers not yet extracted. would not necessarily mitigate the effects of training, an essential part of the transition. In fact, the shift to 00 and higher SE1 levels might well be concurrent. On the other hand, while the transition to 00 might be more orderly in orga,nizations at levels 3-5, it might also be more difficult in the sense that existing processes are (as described in the CMM) “practiced, documented, enforced, trained, (and) measured”, which may imply some inertia to change. Organizations at level 5 are “continuously improving”, but a shift to 00 would likely require For several reasons then, the “conversion” of a.n existing system to 00 may not be advised. If an 00 system is desired, a clean break with the old system should be established to foster a clean sheet 00 design, with the old system viewed as a black box from which performance requirements can be established. 440 4 Alan Technology Korncoff system; t,he resistance to change will impede Do pick a problem where technical progress. the domain readily supports and suggests the identification of objects by other than the development team, i.e. the end users and responsible management. Transfer It’s a good news-ba,d news situation: The good news is: if you are already successful in technology transfer of software projects, the skills that you have developed are directly applicable. 00 technology transfer is not much different than the transfer of other software technology. The bad news is: if you haven’t figured out how to do software technology transfer, transferring 00 technology is just an a,dded burden. Keys to successful technology transfer include the following. 1. Establish internad 4. Plan for impacts expertise. 5. Concentrate A central staff should do the initial development assisted and supported by the team who will eventually undertake system maintenance. The project plan (cost a.nd schedule) should allow for the added time to perform this technology tra.nsfer. The team should also involve end users. to establish on selling management. Emphasize that using 00 technology, enables the solution to be provided, “BFC” (Better? Leverage the capability Faster, Cheaper). of rapid prototyping as an enhancement to gathering end user requirements and permitting higher end user involvement in the deis also velopment process. Rapid prototyping an effective management communication tool; show a working version of the system rather than a requirements document. Indicate the value of reuse in the development of other applications as part of the long term business case. Do not refer to the work as a paradigm shift; this holds a negative connotation to many managers. staff but involve sust,aining 3. Choose a small problem success. and policies. The use of 00 technology may not be accounted for in the e,xisting software developAreas most often imment infrastructure. pacted are quality assurance, especially validation and verification; software certification; documentation; software standards; and proMany of the policies and gram scheduling. procedures developed for traditional software development methodologies will have to be modified or extended to be applicable to 00 work. Team with those responsible for these standards and policies to perform the necessary adjustments. Either hire it or train the internal staff. Use of external consultants is, at best, a short term, stopgap. It ma.y be possible to provide internal training cost effectively: e.g. at Boeing the majority of Smalltalk programmers were self taught using a tutorial included with the software. Supplemental training can be purchased on an as needed ba.sis from various vendors and consultants. 2. Leverage a central support st.aff. to standards an initial 6. Plan for object Size selection should be based on the ability to produce a production system with measurable return on investment within 1 to 2 years. Requirement,s of a longer time period risk losing management, support. Do not pick a mission critical applica.tion; the visibility of a failure incurs unnecessary risk. Do not pick a legacy reuse. Though a powerful capability afforded by 00, reuse does not just happen. Reuse does not just mean developing specifications for objects Provisions with intent of facilitating reuse. have to be made for a variety of infrastructure issues including reuse library definition 441 and maintenance; legalities for developing and reusing in reuse; incentives objects. maturity. For these 00 just seems like a very natural way of modeling their problems and the visual programming environments are a major productivity boost in reducing the learning curve. The individuals for whom the shift appears most painful are those well schooled in classical, top-down structured development. This group have to “unlearn” an analysis methodology and a way of viewing a problem solution. It is almost as if their maturity gets in the way. Large scale reuse (i.e. company-wide or at least outside of the development group who origina,lly created the objects) requires appreciable sophistication in a variety of issues beyond just object definition and development. There are few companies capable of effectively levera,ging reuse for traditional software modules. Maturity in managing these traditional software reuse issues is a. pre-requisite for undertaking large scale 00 reuse. Acceptance. Activities that we as 00 professionals can do to speed the acceptance of our technology: 1. Devise a set of 00 rics. software development met- Management is well aware (or at least believes that it is well aware) of the estimated productivity of programmers using traditional development means. It is possible to estimate how many programmers of a, given level maturity can cut x number of lines of code in y days. Such metrics afford a level of comfort to management that appropriate levels of control and tracking are provided for in a development project. We need to develop such metrics for 00 work. Legacy 2. Develop language standa.rds. For example, the ANSI Technical X3J20 for Smalltalk. System Common characteristics relevant here include: Committee Mainframe 3. Amass a library of success stories. of legacy systems code Fra,gility with respect Provide tha.t are hosting. Layers of patch functionalit,y. Identify projects whose success was made possible or at least enhanced by the use of 00 technology. We need to be able to show return on investments. The successes should be in a variety of domains. Maturity Objectification mission critical obfuscating essential to cha.nge. services. In light of this, recommendations technology include: for applying 00 Level 1. Legacy There are really two separate issues here: (1) Use of the technology for application development and (2) Large scale 00 Reuse. My position on the first has been: The shift to 00 does not seem directly related to maturity is software engineering. Two disparate groups have been shown most capable in leveraging the technology. First are the Hackers. These are individuals who are always the first to tryout a new technology independent of what it is. The second group is the Domain Experts with little software development databases should be left intact. 2. Layering may not be a good fit. The pa,stiche of patches is unlikely to support objectification of successive layers; the patches are rarely so accommodatingly arranged. Further, there is no guarantee that. an arbitrary legacy system would benefit from objectification. We all know that 00 is not a panacea. One approach is to 3. Consider an 00 client. create an 00 based client process running on 442 a worksta,tion providing access to legacy functionality accessed as a server. The 00 client process would be configured with an appropriate GUI. Successive functionality could be selectively migrated from the server legacy system and incorporated into the client process. Advantages of the approach include: (a) the migration process would be transparent to the end user; (b) minimad impact on existing, often mission critical functions; (c) the computing power originally only available from mainframe systems is now likely more cost effectively provided by the workstation; (d) minima,1 or at lea,st well defined impa.ct on the fragile system. 5 Tim Korson High Leverage tivities Technology Transfer Ac- Technology transfer activities depend on the stage Daniel Tkach has deof technology adoption. Exploration, scribed the stages as: Awareness! Transition, a.nd Habit. I would like to focus my remarks on the transition stage. There are many appropriate activities for this stage tl1a.t have been extensively explored in the literature. Most of them are not unique to OOT and therefore not as interesting to explore as those activities that are more directly related to OOT. My experience is that the creation of 00 domain specific libraries and frameworks is one of the highest leverage activities appropriate to the transition stage. These libraries and frameworks can serve as a focal point for many of t,he other more traditional For example, the 00 traintransition activities. ing curriculum could now include courses on these frameworks. In a.ddition 00 apprenticeship programs can be structured around the continued development and maintenance of the libraries. Most importa*ntly, development teams will now staat to use these libraries and frameworks, which will automatically propagate the use of OOT. Another very high leverage activity is the creation of a corporate object center whose sole mission is to fa.cilita,te the transfer to OOT. This center is charged with activities such as: 1. Coordinating other corpora,te bodies such a.s the process group, measurements group, testing group? training department, R&D group, etc. to make sure that they underst.and OOT and it’s impact on them; 2. Producing handbooks and guidelines for the support of development teams; 3. Maintaining a staff of 00 experts to serve a,s project ment,ors; a.nd 4. Lobbying propriate upper level management policy and organizational for the apchanges. Even when an organization has an existing technology insertion group, the temporary creation of an object center staffed with 00-specific change agents is a good idea. Many companies are doing this. For example, IBM has a generic technology insertion group, but has recently also created an object technology center. SE1 Maturity Level I do not see any need for an organization to be at a certain level of maturity before moving to OOT. In fa.ct t,he more ma.ture a. soft,ware development, organization, the more likely it is that the organzation will be reluctant, to move to OOT because of the immature state of the process infrastructure for 00 software development. Most organizations support a variety of development efforts. Consider a health care organization that develops billing, payroll and other standard DP systems, but also develops labora,tory analysis software and other patient care systems that deal with on-line retrieval of s-rays, EKGs etc. The DP systems are probably based on a stable technology with a reasonably mature development process. The advanced multimedia and embedded systems are the more likely candidates for OOT precisely beca.use the development organization does not yet have a mature technology and process for these systems. 443 Legacy Systems port, Q&As, electronic flashes, and participation in conferences and meetings (SHARE, GUIDE etc), are vehicles for technology transfer. The idea of wrappers is often presented as a solution to the problem of making legacy systems “look” 00. However, why should legacy systems have to “look” OO? Most corporations already have a mix of software technologies. OOT is one more technology to add to the mix. It is a mistake to assume that all legacy systems should be converted at some level to OOT. It is true that 00 systems will need to be able to interface with some legacy systems, and that some legacy systems should be migrated to OOT, but there are numerous ways to accomplish this. Wrappers are often indicated when the new 00 systems are written in a pure OOPL like Smalltalk and the legacy systems are in a language like COBOL. However, most commercial systems are written in a hybrid language. When the legacy code is written in the base language of the 00 hybrid, one could choose to recompile the old code with the hybrid compiler. In addition lightweight interface procedures are often indicated. 6 Daniel Technology cumstances Transfer - Actions and Cir- The process of transferring a new technology to an organization is not linear: the needs of the target organization vary during the process, depending on the phase of the transfer the organization is involved in. Four transfer phases can be identified from the point of view of the target organization: The target organization should know about the existence of the new technology and understand the advantages and risks involved in embracing it. Awareness. Exploration. prototype The target organization sets up projects using the new technology. The target organization has decided to embrace the new technology, and the existing technology base is being converted t.o the new one. Transition. Tkach The new technology has become “business as usual” in the target organization. A mature stage of t,his phase would be characterized by the presence of process control? quality standards, and productivity measurements. Habit. The position presented in this panel draws from my experience as the consultant responsible for the transfer of technology projects in the field of object-oriented technology at the IBM International Technical Support Organization (ITSO), which is a worldwide “transfer of technology” institution. The ITS0 has centers close to the main IBM hardware a.nd software laboratories around the world. The objective of those centers is to transfer technology from where it is created - the labs - to where it is needed in the organization - marketing, consulting, and services staff - and also to IBM customers. The technologies are transferred via publications (known as redbooks), workshops taught worldwide, and residencies in which international field support specialists (and eventually customers and lab developers) participate to produce the workshops and redbooks mentioned The awareness phase is key to achieve an effective transfer of technology. This phase is particularly crucial for object-oriented technology, since many economic and cultural decisions have to be made. The recipients of the transfer in this phase are both managers and programmers. Managers and programmers have to be aware of the advantages of object-oriented technology and the requirements for capitalizing on these advantages. The bottom line message is that productivity and quality in object-oriented software development are achieved through reuse, but then the meaning and nature of reuse have to be un- earlier. derstood, In addition. 3rd level direct technical sup- 444 as well as the organizational changes it cesses, control, and metrics, which usually have to be imported. A source of exchange of sophisticated questions and solutions has to be established, such as e-mail conferences and forums. In the habit phase, the quest is for refining the technology, improving existing processes, and exploring the next steps. This level justifies the existence of a.n in-house staff of high level specialists which determine where and what aspect of the technology should be transferred. Although awareness - exploration - transition habit is a na.tural sequence, it is by no means a necessary one. The following are three counterexamples describing ca,ses where this sequence will not hold (and many more can be found): entails. Technical decision issues such as the choice of language and methodology have to be explained, but should not become the focus at this point. It is more important to deal with the “not invented here” syndrome, and with legitimate concerns such as incentives, performance evaluations, and training opportunities. The main objective of the transfer of technology in the awa.reness pha.se is that the technology should not be perceived as threatening by anyone but as a growth opportunity for everyone. Short courses (from 1 t,o 5 days) that include technology fundamentals, advantages, technical and organizational considerations, success stories (both internal and external), and marketplace trends and directions, are effective transfer means in this phase. Those courses should be delivered in-house and there should be several opportunities to attend them on different dates; a teach-the-teachers by company experts or external consultants may be a convenient way t.o sta,rt the process. A list of recommended conferences and trade shows may be a useful tool for stirring the interest of key people in the target organization. 1. A company take-over or merger where the new owner has already developed object-oriented systems. 2. A multi-national company that imposes the new technology on its world-wide branches. 3. A start-up developing technology. The exploration phase is characterized by the existence of “points of light” or “negative entropy pockets”, that is small nuclei of developers that test the new technology, many times with manager consent during normal working hours, but often after hours. Enthusiasts of the new technology appear, probably with some background from the university, from readings, or from previous jobs. The transfer of technology in this phase requires the definition of a specific development environment, the availability of such an environment and the training of selected people in its use for concrete pilot projects. Users groups, where the practitioners of the new technology and interested people meet, say, once per month, to discuss topics, present their projects and even invite external speakers, have proved to be a successful transfer of technology instrument in this stage. company that decides to start the systems with object-oriented The described sequence is: however, a typical cess for any organizational paradigm shift. SE1 Maturity Level and Paradigm pro- Shift If the report that says that about 80% of t,he US MIS shops are at level 1 is correct: and we accept “Thou shalt not perform Yourdon’s admonition: paradigm shifts at low SE1 maturity levels”: the application development world would never go to 00. My position here is that a paradigm shift does not depend OII the maturity of the whole organization but on the characteristics of projects and of the group that will implement them. In addit,ion, transfer of 00 technology does not have to start with programming in the large, but with smaller teams where the process management constraints can be relaxed, and therefore not require a particular SE1 maturity level, even for that team. We should not lose the perspective on the prob- In the transition phase, the key issue is productivity. The technology required now, in addition to the continuous training efforts, relates to pro- lem: in any case, the para.digm 445 shift has to start at some level of maturity, based on some technology. Probably, if we wait long enough, there will be another paradigm shift within the next 10 years for which we will not be prepared either, so . . . And since achieving a SE1 maturity level requires establishing formal methodologies and process definitions of some kind, there does not seem to be an a,pparent adva.nta,ge for an organization to rea,ch to a level 3 maturity with a process based on structural analysis instead of object-oriented modeling, and then make the transition to object-orientation. Legacy quired, probably due to technological reasons, such as a change in the data store and retrieval access methods. Another approach is not to wrap the legacy systems directly, but to use them as servers to the new object-oriented applications, leaving them in their own environment. For instance, the legacy code could probably be left to execute in a server machine connected to the true object oriented application via, a network operating system (NOS) providing location transparency, and have a wrapper or proxy object at the client’s end providing the required interface to the NOS (i.e. wrapping the NOS instead of wrapping the legacy code). This approach is particularly useful when the server (native legacy) environment is quite different from the object-oriented client environment, as is usually the case with mainframe legacy systems. Systems If legacy code can be re-engineered through existing tools, there may be an opportunity for objectifying without the use of wrapping techniques, by transforming the resulting models into object models. These transformations will at this stage have to be performed “by hand”, by carving, as Eric Herness advocates, the E-R models that the re-engineering process may produce. The present level of the technology does not allow for productive direct object-model re-engineering, although the use of techniques derived from the field of artificial intelligence, seems to be promising. Current code-slicing techniques are not adequate for objectoriented layering, since they are usually functionoriented. Statistical tools that could find clusters of accessed data would enhance the productivity of the re-engineering process, but their commercial availability is not widespread. 7 Biographies Andy Baer is currently a Vice President at American Management Systems and Director of Object Technology in the AMS Center for Advanced Technologies. His responsibilities include managing the creation of a reuseable software infrastructure for developing large business applications, evaluating emerging object technology products and trends, helping transition AMS’s staff to using objects, and being the primary focal point at AMS for marketing object technology. Brian Bernsen is a Unit Chief in the Center for Software Engineering at McDonnell Douglas Aerospace East (MDAE), where he investigates CASE tools and software development methods. Prior to joining the Center for Software Engineering, he held various software development positions on the F/,4-18, AV-8B, and A-12 projects? where he wrote the Software Standards and Procedures Manual. He has taught several in-house classes on Ada and Software Engineering and is methods currently developing a “Best Practices” Legacy relational databases should be used “asis”. There is no apparent justification for a massive conversion to an OODBMS, especially in a business environment. Wrappers could be used as a technique for objectifying both legacy code and objects. But a deep series of layers of wra.ppers would be hard to specify and maintain. In addition, wrappers [also known as “ada.pters”) could be used for materializing objects from legacy data stores such a,s flat files. When wrapping legacy systems, legacy data stores should be wrapped separately, because they may be the first things for which a change may be re- manual for Ada software development, Alan Korncoff is Senior Principal the Research 446 and Technology Division at MDAE. Scientist in of the Boe- ing Company. Present assignment is Principal Invest,igator, Object-oriented Technology for Manufacturing Automation. In this capacity, he developed a.nd lead the deployment of the Exception Processor (patent pending), the first application of 00 on the factory floor in Boeing. He is currently Program Ma.nager, Project Ma.nager, Principal Investigator for four 00 projects. Tim Korson ha.s two affiliations: He is Executive Director, The Consortium for the Management of Emerging Software Technologies (COMSOFT) and he is also a R.esearch Associate at Clemson Vniversity. Daniel Tkach is a Senior Information Technology Consultant for Object-Oriented Technology. He works for the IBM International Technical Support Center in San Jose, California, where he is responsible for the IBM worldwide transfer of technology projects in object-orientation. His recent book on the topic, “Object-Oriented Technology in the Application Development Environment” is in the process of being published by The Benjamin/Cummings Publishing Company. 447