Component-Oriented Software - 2 by Jack Krupansky Hazards and Entrepreneurial Opportunities Abound Component-oriented software (COS) shows great promise for radically improving our ability to deliver sophisticated software solutions. In my previous article we examined a number of issues which will determine the effectiveness of COS at solving real world problems. Let's look at additional technical and business issues and highlight the related entrepreneurial business opportunities. Component Management An aspect of COS that hasn't gotten much attention is management of components on a system or even a network. What if I have a lot of applications that each come with all the components it uses and a subset of components are the same between applications? Do I get (or want) multiple copies of components? And if I do want to have the common components shared then how can I un-install an application without disturbing the other applications? And how are versions of a component identified? And how is compatibility between versions indicated? I presume that we will evolve towards a technology in which components are separate entities such as Windows dynamic link libraries rather than being hard-linked into the application. Hard-linking is an option, but it interferes with user-driven customization. Even if a development organization chooses hard-linking, how do they deal with sharing of components between their development groups? We need to deal with component naming conflicts. You and I can both develop components for different functions but have the same name and a developer wants to use both components in the same application. This naming conflict must be resolved by renaming one of the components. Solutions might be a centralized name prefix registry, a name substitution feature in the linker, or a utility to rename references within a binary component. We need usage analysis tools that will be like looking into a microscope and seeing all the objects buzzing around. You could then filter and analyze and summarize to your heart's content. The boundary between applications will blur and system and network level views will be as important as looking at a single application. In theory, I could run an application over the network and rather than a large executable file being loaded into my machine individual components could migrate to my machine as needed. I rarely use even 15% of the features in an application. This also presents opportunities for network licensing software. And opportunities for new forms of installation software. Traditional network analysis tools focus on systems, processes, and messages. With COS we introduce new levels of traffic complexity. Seeing what processes are sending what messages between what machines won't tell you a lot about what objects are doing what operations. Tomorrow's smart users will be able to mix and match software. They will take a component from one application and use it in another application. Aftermarket add-ons will improve their productivity. No longer under the tyrannical control of the system manager or even the designers of the application! Can you say support nightmare? Can you say job security? We'll need utilities that track down who's sticking what components where they shouldn't. Licensing Models for Reuse and Profit Royalty-free licensing works best for high-volume low-cost products. Per-user and royalty licensing work best for lower volume, high-priced products. There are lots of variations and it is mostly a matter of what the market will bear. But in the coming world of components, things will change. One of the proposed licensing schemes is per-use with some sort of metering. I'm sure others exist and more will follow. My view is that we need simplicity. And a way to assure that component creators are equitably compensated for their creativity and ability to spot market opportunities. One approach would be to think of components in much the same way as books. The author might get an advance and future payments based on sales. Build yourself a reputation as a crack component builder and get bigger advances and more payments from higher sales volume. Or build an occasional high-value component that sells to a niche market for a premium price. Just like some specialty books. Another nasty issue comes from the OOP concept of inheritance. You can develop a component that derives part of its functionality from another component. Or maybe your component is really just a clever assembly of commodity components. Now you need to be able to sub-license those other components. Royalty-free licenses are the most appealing, but you'll have to be careful because some component venders may explicitly disallow distribution in situations where their component features are essentially passed through with minimal added value. This might seem disturbing, but the usual intent will be to deter shady venders from merely repackaging components and then stealing the original venders prospective customers. Imagine taking someone's spreadsheet grid control and merely adding a fancy border or changing some colors. Imagine being on a jury and trying to determine whether the repackaging adds significant value or competes unfairly with the original. On the other hand, if you have a component that is a good candidate for such abuse you might consider marketing it for precisely that use with either royalties or significant fees and just don't sell it as a commodity in the first place. Components must be cheap enough so that after paying for each of the many components used by your software you can still make a profit. Component venders may be tempted to charge significant fees, but I think the trend will be toward a smaller number of big ticket components and vast numbers of cheap or royalty-free commodity components. Evaluation Versus Production Use Although I might be willing to pay a lot of money to use a special purpose component in my product, I am not willing to pay that price without being able to first evaluate its suitability. Some venders will be willing to let you test drive the real thing for a limited period of time. Some will have stripped-down evaluation kits. The bottom line is that convenient, flexible evaluation is essential for a thriving component-based software industry. Discipline Needed for Robust Software COS will be a big boon for hard-core, disciplined engineers. Applications, subroutine libraries, and simple components such as VBX controls can be thrown together by almost anyone. Development of truly robust, high performance, and compatible components will take real engineering discipline. Armies of over-funded, mediocre talent armed with fancy tools simply can't compete with lone, disciplined engineers who methodically work through the COS issues. Hardware engineers intrigued by software but offended by the lack of discipline of today's software practitioners will see component development as an attractive opportunity. Intellectual Property A future article will explore the intellectual property issues relating to components, ownership of standards and de facto standards. But I will say that these issues are critical to the acceptance of COS and its viability as a business model for component producers. The most difficult step will be getting to the point where specs for compatible components are not owned by a component creator although the component creator may by de facto control changes to the spec. Examples are Hayes modem commands, PostScript, and Visual Basic compatible macro languages. Distribution Models Within a few years even a modest software effort will involve hundreds if not thousands of components. Ordering all those components from lots of venders will just not be tolerable. Just imagine all the floppies and paperwork. Encrypted CD-ROM and on-line libraries are likely solutions. Thousands of components can fit on a single CD- ROM. Larger firms will license entire collections of components and us little guys will license components as we need them. There will be shareware opportunities. And opportunities for niche entrepreneurs to compose specialized libraries with selected and matched components to simplify development of vertical applications. I can imagine individual component creators joining component co-ops so that customers don't end up having to purchase individual components. Big ticket, large scale components could still be distributed separately. Plenty of opportunity to partner with fellow component creators or get your great invention bundled with some big ticket package. Model-View-Controller Paradigm Many Windows applications will be built using GUI (Graphical User Interface) tools that let you develop an application without writing any code. But for other than trivial applications you will need to develop some logic (either as code, a flowchart, or by wiring components together.) The visual tools make it easy to just insert that logic where its needed. Unfortunately, for sophisticated applications that's the worst thing you can do. Tying the application logic tightly with the user interface restricts your flexibility to change one without affecting the other. It makes more sense to have a well-defined fire wall separating the user interface from the application logic. The Xerox PARC researchers called this the Model-View- Controller (MVC) paradigm. The model is the application logic which expresses how the problem solution is modeled within the computer. The user interface is a combination of a view and a controller which are roughly analogous to the display and input. Although a typical GUI has discrete events for keyboard and mouse input and painting of the display, the interaction between the two is less well understood and a cause of programming problems. Techniques and tools for mapping the mouse position to a modeled application object and optimizing partial redisplay of the changing model is a challenging aspect of sophisticated applications such as CAD or desktop publishing. The MVC paradigm can be applied to non-GUI situations as well. Few programmers really understand this paradigm, so there is plenty of opportunity for consultants and component developers to exploit it. Focusing your engineering talent on modeling and views will allow you to create long-lasting value. Customers will appreciate that their investment in your technology will retain its value over time regardless of whose GUI is in favor this week. Training Lots of money will be spent (and made) on training for COS. Most of it will go to the larger, established training firms. But there will still be plenty of narrow or specialized niches for entrepreneurs to exploit that are too small or too bizarre for the big training organizations to go after. If you have years of experience in a niche your expertise and interest (and modest rates) will look much more attractive to the client. The real opportunity is that you can show the client exactly how to apply COS to their specific problem. And, for a modest fee, you can even get them started and be there when they need assistance. Consulting Where there's complexity there's a need for consulting services. It's really easy for a company to send their developers to object technology school for a week and think the next project will be a cakewalk. That's where you come in. Cleaning up someone's mess isn't as bad as it sounds. There may be schedule pressure, but management can be so relieved just to realize that the project is getting back under control that they don't mind paying your outrageous (but reasonable) rates. In fact, I think I'd rather come into a project late in the game and become the hero than have started a project under unreasonable expectations. Keep in mind that the early consultants get the fat worms. As a technology becomes old hat the client realizes that anyone can do it and there is no reason to pay high rates. Windows programming used to pay extremely well. Some of the emerging COS technologies that are ripe for exploitation are Microsoft's OLE, IBM's SOM, object request brokers, and implementation details and nuances of the various object models. Mixing and matching of technologies will become important and a great opportunity. Testing Testing is critical for software components. We need tools for testing the non-interactive aspects of components. Interactions between components must be tested. Components must be tested to make sure they work together. One of the keys to good testing is a comprehensive test plan. Few software people really understand how to do this and lack the discipline to carry it out. A good test plan requires solid specifications for the components. I can see companies paying a lot to bring someone in to do a quick review of their components and propose the outline for a test plan. Good testers are hard to find and hard to keep and the situation will only get worse as the COS industry matures. Even with a good test plan it takes a lot of talent to ensure that the test cases really test the software properly. And as components get more sophisticated the problem gets worse (or better for the entrepreneur.) Tools Microsoft's strategy seems to be to divide the software industry into two camps: component builders and solution providers who glue components together into complete solutions. They envision components in C/C++ and solutions in BASIC and Microsoft provides the tools for both. This clean division sounds great for now, but it doesn't address the long-term growth in the use of objects in all aspects of system design. After all, with COS, one person's solution is supposed to be someone else's component. Between and beyond the two poles there will be many gaps to be filled by entrepreneurial tool venders. Disincentives for Reuse The maintenance cost of shared code can be higher since the code may have to do more to satisfy more users. You must do a better job of documenting and testing shared code. On the other hand, by generalizing the code and focus attention on any weak spots you can make it more robust and less in need of traditional bug fix maintenance. Once you start sharing code you also take on the burden of compatibility. Within a project it is easy to see how a component is used and to judge the impact of a change to the component. The process becomes more tedious when other projects or companies share a component. It can become the kind of nasty straitjacket that creative types try to avoid. At least a few consultants will make a lot of money helping companies share components. The additional levels of support for code reuse will have to come out of someone's budget. In most companies it just isn't practical for a manager to take on additional costs just to reduce the costs for another manager. It's always possible for two groups to share code without management even knowing about it. It works best if you in fact exchange code so everybody wins at nobody's expense. And, it's always possible that some entrepreneurial consultant may decide to focus their energies on helping organizations deal with the non-technical reuse issues. There will be a great management backlash against object technology when they find out that startup costs and maintenance costs are higher than they expected. Gurus may have helped to get the system up and then turned maintenance over to average developers. The only solution is to keep the design as simple and clean as possible. Object technology gives you tools to do great design, but can't turn mediocre designers into great designers. Conclusions Additional issues will arise as we progress further into the world of software components. Let's welcome the problems and pitfalls because each will spawn even more entrepreneurial business opportunities. In fact, every "solution" will create even further opportunities! Objects are here to stay and the next ten years will give us ample opportunities to display our entrepreneurial skills. I must strongly emphasize that COS is evolving and you must be careful when placing large bets on specific technologies or markets which have not yet converged. But don't wait too long before deciding to pursue your ideas. My real hope is that COS will restore the sense of craftsmanship that we lost when productivity began to be measured in terms of KLOC (thousands of lines of code) per month. Components should be more like a gems and less like cancerous tumors. A good metric for the maturity of COS will be the degree to which portions of end-user applications can themselves be used as components for other applications. And finally, software development should be satisfying, stimulating, and even fun. There should be a sense of pride in the result. COS can help us achieve that goal. And we can make COS possible. ------------------ 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, e-mail at jack@basetechnology.com, or on the web at http://www.basetechnology.com.