The following article appeared in the Lucent Bell Labs ``Multiuse Express'' magazine, Vol. 4, No. 6, December, 1996.
Developers in certain well-traveled domains have successfully applied OO techniques and tools for years. For instance, the Microsoft MFC GUI framework and OCX components are de facto industry standards for creating graphical business applications on PC platforms. Although these tools have their limitations, they demonstrate the productivity benefits of reusing common frameworks and components.
Software developers in more complex domains like telecom have traditionally lacked standard off-the-shelf middleware components. As a result, telecom developers largely build, validate, and maintain software systems from scratch. In an era of deregulation and stiff global competition, this in-house development process is becoming prohibitively costly and time consuming. Across the industry, this situation has produced a ``distributed software crisis,'' where computing hardware and networks get smaller, faster, and cheaper; yet telecom software gets larger, slower, and more expensive to develop and maintain.
The challenges of building distributed software stem from inherent and accidental complexities [Brooks:87] associated with telecom systems:
While developing high quality reusable software is hard enough, developing high quality extensible and reusable telecom software is even harder. Not surprisingly, many companies attempting to build reusable middleware fail -- often with enormous loss of money, time, and marketshare. Those companies that do succeed, however, reap the benefits resulting from their ability to develop and deploy complex applications rapidly, rather than wrestling endlessly with infrastructure problems. Unfortunately, the skills required to successfully produce telecom middleware remain something of a "black art," often locked in the heads of expert developers.
Many political, economical, organizational, and psychological factors can impede successful reuse in telecom companies. I've found that reuse-in-the-large works best when (1) the marketplace is competitive (i.e., time-to-market is crucial, so leveraging existing software substantially reduces development effort), (2) the application domain is non-trivial (i.e., repeatedly developing complete solutions from scratch is too costly), and (3) the corporate culture is supportive of an effective reuse process (e.g., developers are rewarded for taking the time to build robust reusable components). When these prerequisites don't apply, I've found that developers often fall victim to the "not-invented-here" syndrome and rebuild everything from scratch.
Expanding on the corporate culture theme, I've observed that it's crucial for software managers to openly support the fact that good components, frameworks, and software architectures take time to craft and hone. For reuse to succeed in-the-large, management must have the vision and resolve to support the incremental evolution of reusable software. In general, an 80% solution that can be evolved is often preferable to trying to achieve a 100% solution that never ships. Fred Brook's observation that ``Plan to throw the first one away, you will anyway'' [Brooks:75] applies as much today as it did 20 years ago.
Truly useful components and frameworks are derived from solving real problems, e.g., telecommunications, medical imaging, avionics, OLTP, etc. Therefore, a time honored way of producing reusable components is to generalize from working systems and applications. In particular, resist the temptation to create ``component teams'' that build reusable frameworks in isolation from application teams. I've learned the hard way that without intimate feedback from application developers, the software artifacts produced by a component team won't solve real problems and will not be reused.
Expecting emerging industry standards (like CORBA or TINA) to eliminate telecom software complexity today is very risky. For instance, although some CORBA ORB implementations are suited for certain telecom tasks (such as managing network elements), the semantics of higher level OMG services (such as the Common Object Services) are still too vague, under-specified, and non -interoperable. Although CORBA isn't yet suited to address certain demanding real-time performance and reliability requirements in the telecom domain, over the next 2 years we'll see CORBA-based products emerge that support such features [Schmidt:96].
Apply simple solutions to complex problems that sound too good to be true typically are... For example, translating code entirely from high-level specifications or using trendy OO design methodologies and programming languages is no guarantee of success. In my experience, there's simply no substitute for skilled software developers, which leads to the following final ``lesson learned.''
Ultimately, reusable components are only as good as the people who build and use them. Developing robust, efficient, and reusable telecom middleware requires teams with a wide range of skills. We need expert analysts and designers who have mastered design patterns, software architectures, and communication protocols to alleviate the inherent and accidental complexities of telecom software. Moreover, we need expert programmers who can implement these patterns, architectures, and protocols in reusable frameworks and components. In my experience, it is exceptionally hard to find high quality software developers. Ironically, many telecom companies treat their developers as interchangeable, "unskilled labor" who can be replaced easily. I suspect that over time, companies who respect and reward their high quality software developers will increasingly outperform those who don't.
On the other hand, the bad news is that (1) existing OO components and frameworks are largely focused on only a few areas (e.g., GUIs) and (2) existing industry standards still lack the semantics, features, and interoperability to be truly effective throughout the telecom software domain. Too often, vendors use industry standards to sell proprietary software under the guise of open systems. Therefore, it's essential for telecom companies to work with standards organizations and middleware vendors to ensure the emerging specifications support true interoperability and define features that meet telecom software needs.
Finally, to support the standardization effort, it's crucial for us to capture and document the patterns that underlie the successful telecom software components and frameworks that do exist. Likewise, we need to reify these patterns to guide the creation of standard frameworks and components for the telecom domain. I'm optimistic that the next generation of OO frameworks and components will be a substantial improvement over those we've worked with in the past.
For more information on building reusable OO communication software frameworks with CORBA and ACE, see the following WWW URLs:
http://www.cs.wustl.edu/~schmidt/corba.html
http://www.cs.wustl.edu/~schmidt/ACE.html.
[Brooks:75] Frederick P. Brooks, "The Mythical Man-Month," Addison-Wesley, Reading, MA, 1975.
[Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer, Volume 20, Number 4, April 1987, 10-19.
[Gosling:96] The Java Programming Language, Addison-Wesley, Reading, MA, 1996.
[Lewis:95], Ted Lewis et al., "Object Oriented Application Frameworks," IEEE Computer Society Press, 1995.
[OMG:95] Object Management Group, The Common Object Request Broker: Architecture and Specification 2.0, July, 1995.
[Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for Application-Level Gateways," Theory and Practice of Object Systems, Wiley and Sons, 1996.
[Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and Guru Parulkar, "Towards Real-time CORBA," IEEE Communications Magazine, Volume 14, Number 2, February 1997.
[Stroustrup:91] Bjarne Stroustrup, The C++ Programming Language, 2nd Edition, Addison-Wesley, Reading, MA, 1991.
Back to
ACE home page.
Back to ACE Documentation Home.