We think that not only third-party software vendors but also large internal development organizations will go the way of the automobile industry. Today, the largest vendors, such as SAP, among others, are vertically integrated, as was Ford Motor Company in its early years. Ford had its own taconite mines in Minnesota to produce iron ore that was made into iron and then steel by its own mills. It had ranches in Montana to raise sheep for the wool used to make mohair upholstery fabric. It had its own sand mines in New Mexico to manufacture of automobile glass. Many large European manufacturers of hard goods still have such vertical organizational structures, but today Ford Motor Company is one of the most horizontally organized manufacturers in the world. A multitude of small independent engineering and manufacturing firms in Michigan, Wisconsin, and Ontario make components for Ford automobiles. Most firms that make automobile parts do not sell automobiles. Instead, they sell components to firms that sell subassemblies that sell larger subassemblies to firms that assemble and sell automobiles. The supply chain is short and flat but is controlled by quality engineering and manufacturing standards along with sophisticated computer supply chain controls. The earliest advocates of software standards and componentization argued that this industrial model would one day be possible if software design and engineering followed the path of hardware design and engineering. It is simply a recursive evocation of Henry Ford's specialization of labor applied to larger and larger components. The migration of Ford from a highly vertically integrated manufacturer to a highly horizontally integrated one was a consequence of this principle applied over time as automobiles became more complex. As the modularity characteristics of software components and their design and development become more similar to hardware components, we think the assembly of information bits into useful software "machines" will follow the pattern of the assembly of physical atoms (actually, molecules) into useful hardware machines. The fruition of early software component advocates' dream in today's increasing use of object-oriented design and development technology is already an increasing trend. The development of the CORBA standard and its subscription by all of the software firms in the world save one has allowed small, highly specialized firms such as Iona in Ireland and Trax in Poland to develop and market sophisticated, high-quality software components (called middleware) all over the world. Indian firms are rapidly entering this market as well, having gained a great deal of experience as outsource developers during the Y2K turnover. Small software vendors in the United States are already buying components from smaller firms in India and selling or licensing their products to larger software vendors in the U.S. and Europe. As in the case of hardware component design and development, we may expect to see automation technology enter the picture as well. In fact, it already has, and in three different dimensions: object frameworks, specification-based design and development, and application generators. Object frameworks were covered in the section "Object-Oriented Analysis, Design, and Programming." The SanFrancisco™ product was large and sophisticated, supported by nearly 3,000 IBM Partners in Development and ultimately decommitted by IBM. It demonstrated the technical feasibility and economic promise of framework technology. The software vendor ranks contain other examples, such as JD Edwards OneWorld™, as do numerous proprietary internal development frameworks. At least one firm has specialized in helping internal software development groups design and establish proprietary frameworks. It is truly a shame that SanFrancisco™ did not survive its patron's (CEO Gerstner) departure from IBM. Curiously, many of its components survived individually to become parts of other IBM software developments. Framework technology is intrinsically large-scale in its scope, but it doesn't have to be as large-scale and function-inclusive as SanFrancisco™ attempted to be. There were too many cooks in the kitchen, and their demands caused the scope and scale of the middleware product set to increase until the complexity was more than they could deal with in training and use. The learning curve became too steep for most of the many small firms (IBM Partners) that had themselves multiplied the product's functionality during the specification stage. Still, although this product was too early and perhaps beyond the scope of software automation at the time, the technology it employed will surface again as the scale of software development and the need for its development automation increases so that not only third-party software vendors but also large internal development organizations will use it. Specification-based design and development of enterprise business application software has long been the Holy Grail of software development. The concept is simple enough, but its realization has been very elusive. You would like an application domain specialist (accountant, supply chain expert, clinical patient records manager, cost accountant, value engineer) to write an unambiguous specification of a functional component that will meet your computational and/or record-keeping requirements when finally committed to software. Of course, this must always be done, regardless of the implementation technology employed, but the most desirable course would now be to feed the specification language-defined application or component into a "supercompiler" that would create a working computer program that meets the domain expert's needs and expectations. The software vendor further along in developing this technology is Lawson Software, with its Landmark™ development system. Landmark™ promises to usher in a whole new technology in which domain experts become high-level programmers and former application programmers become metaprogrammers developing the supercompiler metasoftware middleware that enables and supports the new application development technology. Application generation is not new; it began with Betty Holberton's sort-merge generator in the early 1950s. It has seen a resurgence more recently with Analysts International's Corvet™ application generator, Lawson Software's proprietary 4GL for UNIX and Bismarck for the AS 400, Univac's MAPPER™ for the 1100/2200 series, and Burroughs LINC™. The latter two application generators have been merged for the common product line resulting from the merger of the two firms into Unisys. Today LINC is still the largest-scale application generator available. It lets the developer create complete application systems totally in LINC. You can think of application generators as application-specific specification-based development systems. LINC has few limitations and may be, like Lawson's forthcoming Landmark™, a truly generic "find" in the search for the Holy Grail of application computer programming. A new paradigm for productivity enhancement is coming from WesCorp, a software automation start-up firm in St. Paul, Minnesota. Eric Inman, the founder of WesCorp, has compared the conceptual apparatus of mathematics to that of programming. He believes today's programming languages and tools are fundamentally flawed in terms of their power of expression. Even the high-level specification languages and application generators, while providing limited gains, generally worsen long-term prospects. Instead of inventing just another set of incremental improvements, Inman has formulated a mathematically complete solution for making any programming language, or any other formal language, complete in terms of its expressive power. A complete language cannot be improved by any application generator. WesCorp's introduction of complete languages into the marketplace will revolutionize the art of programming, because these languages will impose no limits on the concepts and ideas that can be represented. |