Component-Oriented Software Pitfalls and Opportunities by Jack Krupansky Objects are being pitched as the miracle cure for all software ailments. Beyond the hype of object technology (OT) are a lot of hard-core opportunities for entrepreneurs to make both a lot of money and serious contributions to improving the state of the art of software development. The term component oriented software (COS) describes the shift from monolithic custom software to modular software built from reusable objects. In this two-part article we will explore a number of interesting aspects of this shift. Along the way we will identify numerous business opportunities. What Is It? Object technology is based on the core concepts of object-oriented programming (OOP) as popularized by the Smalltalk and C++ languages. Component oriented software is an attempt to take the OOP concepts that are used within an application and use them across applications. For example, a Visual Basic custom control extension (VBX) is a chunk of shared code which can be used in multiple applications (including those developed in C/C++) without even re-linking the application. The boundaries between traditional software modules tend to be poorly- defined and the resulting software systems are expensive, not very reliable, and difficult to maintain. Each new project tends to start from scratch. COS focuses on sharing code using a more robust architecture based on well- defined components in much the same way as hardware is designed. OOP proponents talk about the benefits of "reuse" of objects. COS actively promotes and facilitates that reuse across applications. A COS developer assembles components to construct a complete software system. Components may themselves be constructed from other components and so on down to the level of pre-built components or old-fashioned code written in a language such as C, assembler, or COBOL. Visual tools or actual code can be used to "glue" components together. Although it is practical to do simple applications using only "visual glue" (e.g., by "wiring" components together as in NEXTSTEP or Digitalk's Smalltalk PARTS or IBM's VisualAge), at some level somebody will be writing function calls and expressions that sequence control and data flow between components.) For entrepreneurs there will be business opportunities in both the components and the glue. Most OT is under the hood and shouldn't be visible to end users. The impact to users will come from faster product development cycles, increased flexibility, and improved customization features. COS will allow independently developed applications will to work together and to do so more efficiently and with less development effort. Summary of Issues Although the underlying ideas of COS have been around for some time we need to build up an infrastructure that fully supports COS. Critical issues for success of COS are: * Dealing with Hyper-Hype and Oversell * Commercial evolution of OT * Common object model * Application Frameworks * Compatibility and multiple sources * Specifications * Data books * Component management * Licensing models that facilitate reuse and profit * Evaluation versus production use * Discipline for producing truly robust software * Intellectual property * Distribution models * Model-View-Controller Paradigm * Training * Consulting * Testing * Tools * Disincentives for Reuse As these issues are addressed we will see increasing effectiveness of OT. Dangling issues will lead to intense thrashing and anxiety, skyrocketing costs, and slow progress. But since we entrepreneurs live by dangling issues, they are opportunities to apply our energy and talent in ways that impress the heck out of mere mortals and induce them to pay lots of money to gain access to our solutions. Dealing with Hyper-Hype and Oversell As OT hype becomes accepted, then the real problems begin. Everyone is saying that OT is here today and so easy to use. You'll be five to ten times as productive. New projects can reuse existing code. You can even reuse "legacy" code. Training is a snap. Maintenance costs will go way down. All the tools you'll ever need are here today. The mark of a good engineer is their ability to quickly sift through irrelevant and misleading drivel and determine what details really matter. Don't let all the vender hype convince you that you're no longer needed. And don't give up on OT just because you find the hype offensive. Sift though the crap and identify real gaps and then work on real solutions. Commercial Evolution of OT Some of the big players in the commercial OT field are Microsoft, Taligent, NeXT, HP, IBM, Apple, Digitalk, and ParcPlace. Each has their own approach to OT and it is not very clear whose approach will win over the long run (other than Microsoft.) In a recent interview in Software Magazine Steve Jobs of NeXT said that it's in Microsoft's best interest if NeXT becomes successful because they'll give him something to copy for the rest of this decade. Even if Microsoft wins there will still be lots of opportunity to capitalize on the gaps. One opportunity is for system tuning and optimization. Nobody has ever accused Microsoft of producing the most optimal and flexible system software. The real beauty of OT is the ease with which objects can be pulled out and replaced. Of course, this has really been true all along even in DOS where you can plug in device drivers. Novell and Stac are great examples of how to succeed with low-level system software even when you don't control the operating system. With objects it is very difficult to understand the flow of control just by looking at a diagram or even actual source code. With polymorphism (applying the same function name to different types of object) a single function call can go to different places based on the actual object value. Some careful analysis and lots of "legwork" walking through all code paths can tell you most of the places that message might go (although with Smalltalk it could go anywhere), but a diagram of that level of flow will be quite a jumble of spaghetti. On the other hand, when the software is actually being run by a specific user the flow may be to a much smaller number of places or even exactly one place or maybe the code never even gets executed. I can imagine all sorts of neat tracing and logging and optimization tools to help developers and system administrators maintain their sanity. Microsoft is pitching OLE (object linking and embedding) as the way to go for object-oriented software. It is very complicated and there is a significant impedance mismatch between it and OOP languages. What a mess. And what an opportunity for consultants and tool builders! OT needs to evolve away from dependence on specific architectural features. For example, Microsoft's Visual Basic custom controls have a 16-bit architecture that is being redesigned for 32-bit machines. Microsoft has a new technology called OCX based on OLE. All you have to do is convert your code. Whadaya mean your vender doesn't have an OCX version of that whizbang fax control for Windows NT running on the IBM PowerPC yet?!? The bottom line is that although the basic concepts of OT and COS are fairly simple there will be a great deal of evolution for at least the next ten years. The only thing we'll be able to count on is change. But that's all us entrepreneurs care about anyway. Common Object Model All objects are not created equal. Even factoring out syntax differences, Smalltalk, C++, and OLE objects are significantly different. C++ gives you maximal compiled efficiency for object operations. Smalltalk gives you maximal interpretive flexibility for inter-object operations. IBM's System Object Model (SOM) attempts to provide language-independent object support. The Object Management Group (OMG) has defined the Common Object Request Broker (CORBA) to support OT services at the system level. And I have my own language, Liana, which has Smalltalk's flexibility using C++ syntax. Object FORTRAN and object COBOL are just around the corner! There are also differences between small objects and system level objects. C++ and Smalltalk have good support for small objects equivalent to C structures and Pascal records. OLE, VBX, SOM, and CORBA are oriented towards big, system level (and network level) objects. Each technology has its own quirks and performance characteristics and it is not easy to move between the worlds of small objects and big objects. If you want to do a medium-size object then you have to force it to be small or big. We need to evolve towards a better match of features. There is a lot of commonality in objects such as an object being defined by a class and each class consisting of data and code and support for data abstraction, polymorphism, inheritance, and late binding. But then there are lots of fringe areas where differences become very significant and prevent true interoperability. Data abstraction allows a class to control what features of the object are accessible from other objects. Whereas Smalltalk strictly prevents other objects from directly accessing an object's features (called instance variables), C++ gives the programmer the ability to individually specify the access to the object features (called data members) to be as strict as Smalltalk (private) or as unlimited as C (public) with some other variations in keeping with the spirit of C. Unfortunately, with so many variations and choices it's hard to develop a component that will be usable across the entire software community. Of course, that does provide an excellent opportunity for consultants to do things like convert slow Smalltalk code into efficient C++ or messy C++ code into flexible Smalltalk. Or to recommend to the MIS director that he fund simultaneous, competitive teams to implement the same pilot project in both Smalltalk and C++ and see for himself how each can fit into his organization and business requirements. I expect that a vender-neutral common object model will evolve with translators that can convert to and from each of the language-specific object models. Each language would then evolve to support the common object model. Some of us will make some money from this translation business. Application Frameworks The basic idea behind an Application Framework (AF) is that a lot of the work is already done for you. An AF is the skeleton of an application and you just fill it out. But today the term is casually misused to refer to any class library. Technically an AF is a coordinated collection of classes which are designed to work together towards solving some problem. The real issue is not whether some classes are an AF, but how functional, complete, and consistent it is. While today's AFs are generic tools to be applied to many problems, the crying need will be for what I call domain-specific class libraries. These will be AFs that are already well filled in for specific types of applications. There will be less drag-and-drop and more fill in the blank. Not that all applications will reduce to this model, but people will be willing to pay lots of money for carefully thought out AFs that eliminate much of the tedium of programming. There is also an area between discrete components and full-blown AFs: subassemblies. Just as in hardware, there is significant value to the customer when a carefully constructed assembly of components can be bought off the shelf. Sure you could construct the subassembly yourself, but if the price is right why bother. Lacking decent terminology, a subassembly will also be called an AF. Examples are a class library for dealing with communications ports, functions for data encryption, class support for MIDI devices, pattern matching functions, a spelling checker, etc. These would all be components, but somehow we need to differentiate between simple, discrete components, elaborate subsystems, and full-blown application frameworks. Of course, the real distinction will be in pricing and if you want to make bigger bucks then just do more for the customer. Both NeXT and Microsoft have started efforts in this area, but since there are so many different applications and many of them are very niche oriented, there will be lots of room for us little guys to stake our claim. Compatibility and Multiple Sources As in hardware, there are many benefits of having compatible components available from multiple venders. Competition keeps prices reasonable and encourages enhancements. Risk is reduced be avoiding dependence on a single vender. COS will not really flourish if most components have a single source. Compatibility will require some agreement on specification for components. Even with compatibility there is still opportunity for feature differentiation. Performance, size, cost, and licensing terms may vary. The spec says what features the component must meet. It won't prevent a vender from offering more features. Components should have a compatibility mode which forces the component to restrict its behavior only to the features in the specification. With that mode you won't have to worry about building your software around one vender's component and then later realize that you can't simply replace it with a "compatible" component due to use of an extra feature. There will be plenty of opportunities for seasoned, disciplined engineers to define and enforce standards, to design standards for compatibility, and to guide component venders in producing compatible components. Specifications COS will require better techniques for developing and distributing specifications. Graphical diagrams are useful and there are many graphical CASE (Computer Aided Software Engineering) methodologies. Concise prose, pseudo-code, and simple two-dimensional tables (such as decision tables) are equally important. And sometimes a carefully annotated C header file can end up being a lot more useful than a notebook full of CASE diagrams. Components from different venders cannot be easily compared unless similar specification techniques are used. COS needs standards for specifications. One of the benefits of UNIX was its de facto standards. There is a common language (C), a common runtime library, common string handling and memory management, common tools, and an elegant way of connecting tools together. And UNIX provided lots of examples of good code. The original developers worked out all the kinks before any of us mere mortals came into the picture. But for COS we are all starting out almost from scratch and we don't even have standards for things as simple as strings or memory management let alone any large examples of COS. We also need better terminology for discussing objects. Each CASE methodology has its own jargon and symbols. I suspect that everything we really need is already out there in some form and we just need somebody to pick though it and engrave just the right combination in stone. Standards are more effective when enforced by tools that embody those standards. Lots of opportunities here for standards, tools, templates, and style guides. Data Books COS needs really good data books analogous to those of the hardware guys. We need a good taxonomy for cataloging software components. We need good specifications for components. Venders of compatible components need to use common terminology and formats so developers can easily do objective comparisons. The ObjectWare catalog from NeXT is a nice try, but even it is rather minimal. What exactly does a COS data book look like? Is it a CD-ROM with Microsoft Windows Help files? Is it on-line? How is it be indexed? How often is it be updated? By whom? Can we get hard copy? Will the information be stored in easily accessible text and graphics file so we can write neat little macros to do custom searching and custom formatting? More opportunities for entrepreneurs! Are you interested enough to take a shot? To Be Continued... In a future article we will examine additional technical and business issues. OT and COS will be truly fertile ground for the entrepreneurs among us. ------ Jack Krupansky runs a one person software business, Base Technology, which develops and markets the Liana object-oriented programming language and offers Windows software development consulting. He may be reached at 800-786-9505, email at jack@basetechnology.com or on the web at http://www.basetechnology.com.