Correspondence; 1958-1989; Bulk
Total Page:16
File Type:pdf, Size:1020Kb
Honeywell Interoffice Correspondence Date: 19 79 January 19 RECEIVED To: L. W. Beers JAN 2 2 1979 From: R. W. Bemer l. W. (ROY) BEERS Location: Subject: Introducing a New Major Operating System 1. Around 1966, Univac introduced EXEC8 to supplant EXEC2. It was a superior design, fabricated by better software production methods than are currently in use here at Phoenix. Customers went 4 full years more with EXEC 2 before EXEC8 was sufficiently workable to be accepted. 2. GCOS 66 has been talked for several years. Many actions were deferred on the assumption of its availability. It is still not released for general test. 3. The design of GCOS 66 is superior to that of GCOS 3, just as EXEC8 was a better design than EXEC2. But customers for the first few years of its life will be unable to discern any substantial superiority over GCOS 3. Therefore, they will stay with the familiar, which in many cases contains their own modifications, and avoid the retraining problem. My conclusion: There is no safe way to sidestep continuous upgrading of GCOS 3 for competitive position in the field. 25 (4-78 ) !! RECEIVED [ Honeywell Interoffice Correspondence <711 NOV 3 Ib/e phr&' L W. (ROY) BEERS 41^ Date: November 1, 1978 cc: ^L. W. Beers C. Clingen To: E. R. Vance R. A. Forzani I H*- e, W. P. Frink From: R. R. Douglas G. A. Gillette S. G. Jerritts Location: LISD S. Klee J5 D. F. Manzer yn'"^3i J. Ring Subject: A Basic Software Operating PhilosophyPfiilosbnhv ' ' P. N. Stoughton I. M. Wyman Having had an opportunity to spend a considerable amount of time on reviewing our Software Development organization, I would like to now describe my thoughts about what needs to be done from an organization and operating standpoint within LISD's software groups. Ideally, I would like to be able to preserve the marketing benefits of three focused operating systems, but it is patently clear to me that we do not have sufficient resources to support three major operating systems on an independent basis. We are not generating sufficient revenues and bottom line results to permit us to enjoy this luxury unless we can become more effective in our development activity. We already see ourselves under terrific pressure across all fronts to provide greater levels of function ality and use which frustrate us in terms of maintaining a state- of-the-art situation for any of our systems. Correspondingly, working closely with Roy Beers and Dewey Manzer's organization, I want you to put the following into operation immediately: 1. You must focus the development of our three operating system functionalities (GCOS, Multics, and CP-6) on very specific market targets. I do not see the neces sity of having Multics look like GCOS, GCOS look like CP-6 and CP-6 look like Multics. Each of the three systems has its own design points with unique strengths and weaknesses. Your approach should be to focus future developments of these three operating systems on market targets which exploit the strengths that we have in each of the systems. For example, the market thrust for GCOS might be in the batch, database, and transaction processing world with multi-dimensional capabilities in timesharing and remote batch. We should exploit Multics' strength in interactive terminal management, security, integrated communication services, relational database capability and its good user interface. We should not only look upon CP-6 as a migration vehicle for the Sigma base to a Level 66 hardware base, but also look at it from the standpoint of its applicability as a high-performance timesharing product offering, employing the same underlying CF 25 (4-78) f HONEYWELL INTEROFFICE CORRESPONDENCE E. R. Vance November 1, 1978 Page two set of engines as GCOS. In all cases, market targets should be selected which hopefully will reduce market ing costs as an objective. We cannot afford to go in and do too many hard conversions. We need to be very selective in the choice of market targets such as time sharing, publications management, the universal front-end, etc., and attempt to minimize the amount of marketing investment to secure new-name accounts. I would like you to immediately convene a group of your people, along with Marketing, Systems Engineering and Product Planning, to address this area. I am going to look for a resolution of this matter by December 1, 1978, so I can present it to the management group on December 11, 1978. It may not be final by that point in time, but sufficient work should be done such that we have a direction. 2. Recognizing the fact that we have three operating systems, it is incumbent upon us to cut down the overall costs associated with the development, maintenance and support of three operating systems. This implies a strategy whereby we develop dependent components in a high level language and rehost them under our three operating systems. I recognize that this is not easy, but it has to be done if we are going to keep going in the direc tion we are proceeding. Unfortunately, we tend to be locked in based on past marketing strategies and programs, and we need to evolve our whole long-term software stra tegy in a more evolutionary fashion. The implication of this strategy implies that you develop single centers of expertise. To my way of thinking, the benefits that we would derive from this are the best use of our resources at the lowest overall cost, the development of high levels of expertise in dependent component areas, a uniformity of user interface, reduced documentation costs within LISD, Marketing and FED, reduced cost in Marketing Support and FED as a result of reduced training requirements and sup port requirements, and a singular support of a DSE strategy. The implications of this are many. It does not imply, how ever, that it all needs to be done in Phoenix. This concept has implications in the area of the control of file systems, language compilers, a job control language, a database management system, an end-user facility, utilities, and our overall networking strategies. I would like a recom mendation from you by November 15 on the form this would take from an organizational standpoint so that we can get on with it. I recognize that it isn't going to be easy to do, but it has to be done to support the three operating systems strategy. If we are unable to make this organization CF 25-1 " HONEYWELL INTEROFFICE CORRESPONDENCE E. R. Vance November 1, 1978 Page three and development strategy work, then most likely we are going to be faced with the reality of having to cancel a major operating system. My thought process runs along the lines that we need a COBOL 79 center of expertise, a file system center of expertise, a FORTRAN center of expertise, a database management system center of expertise, an end-user facility center of expertise, etc. Last, but not least, you need to develop a programming standards and methodology function that will improve portability and productivity. 3. I think that you should adopt a subcontract strategy of a magnitude of 5 to 10% of our total outlay. This will give us a ride-over capability in case we encounter an economic downturn which would force some reduction in expense levels in R&D. I would prefer to take the reduction in outside contracting rather than do it against permanent staff. Further, if you are clever, the contracting can be done on completion dates on six-month intervals so that you have the capacity to adjust in a current year given sufficient lead time. 9. As a major subset of number 2, I think we need to develop a file processing strategy. We need to determine what is it, how are we going to do it, and what is involved in making it happen. One of our problems in the entire Engineering and Product Planning structure within LISD is that we endlessly debate doing things, and hence, nothing seems to get done. This is a critical area that I want to follow-up on with you shortly after you've had an opportunity to do some work on it. 5. You need to develop a common remote maintenance strategy with Product Planning and Systems Engineering, whose objective is to provide increased availability and respon siveness while removing FED costs. This is a high impact program, and it is one that must be accomplished quickly. I think your organization has been far too passive on this. 6. Along with Product Planning and Marketing, you need to give very serious consideration to what options we have and what programs we need to put in place to improve our ability to convert from foreign systems. This has too long been neglected in software development. CF 25-1 HONEYWELL INTEROFFICE CORRESPONDENCE E. R. Vance November 1, 1978 Page four 7. I feel very strongly that your organization, if con structed in the fashion above, needs to speak to the competitiveness of the products which are being developed in it. I want your COBOL people to be able to tell me why the COBOL they have is the best in the business. For the market target selected, I want the operating system people to be able to tell me why it's the best operating system around. The same applies to all of the dependent components that we produce. This has to be forced into your organization, and I intend to follow-up with key managers on very specific dates in the future to determine their understanding of how competitive their product really is in the marketplace.