### Lessons Learned Building Reusable OO Telecommunication Software Frameworks

Douglas C. Schmidt
Department of Computer Science
Washington University, St. Louis
http://www.dre.vanderbilt.edu/~schmidt/
d.schmidt@vanderbilt.edu

The following article appeared in the Lucent Bell Labs ``Multiuse Express'' magazine, Vol. 4, No. 6, December, 1996.

### The Distributed Software Crisis

Developing complex software systems is expensive and error-prone. Object-oriented (OO) programming languages [Stroustrup:91,Gosling:96], components [Box:97], and frameworks [Lewis:95] are heavily touted technologies for reducing software cost and improving software quality. When stripped of their hype, the primary benefits of OO stem from the emphasis on modularity and extensibility, which encapsulate volatile implementation details behind stable interfaces and enhance software reuse.

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:

- Inherent complexity stems from the fundamental challenges of developing telecom software. Chief among these is detecting and recovering from network and host failures, minimizing the impact of communication latency, and determining an optimal partitioning of service components and workload onto processing elements throughout a network.

- Accidental complexity stems from limitations with tools and techniques used to develop telecom software. A common source of accidental complexity is the widespread use of algorithmic decomposition, which results in non-extensible and non-reusable software designs and implementations.

The lack of extensibility and reuse in-the-large is particularly problematic for complex distributed telecom software. Extensibility is essential to ensure timely modification and enhancement of services and features. Reuse is essential to leverage the domain knowledge of expert developers to avoid re-developing and re-validating common solutions to recurring requirements and software challenges.

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.

### Lessons Learned Building Reusable OO Communication Software Frameworks

Over the past decade, I've worked with many companies (including Motorola Iridium, Ericsson, Siemens, Bellcore, Kodak, and McDonnell Douglas) building reusable OO communication software [Schmidt:96]. In these projects, we've applied a range of OO middleware tools including OMG CORBA (an emerging industry standard for distributed object computing) and the ACE framework (a widely used C++ framework that implements many strategic and tactical design patterns for concurrent communication software). The following are lessons learned from developing and deploying reusable OO communication software components and frameworks in practice:

- Successful reuse-in-the-large requires non-technical prerequisites --

  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.

- Iteration and incremental growth is essential --

  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.

- Integrate infrastructure developers with application developers --

  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.

- Industry ``standards'' are not panaceas --

  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].

- Beware of simple(-minded) solutions to complex software problems --

  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.''

- Respect and reward quality developers --

  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.

### Concluding Remarks

Developing reusable OO middleware components and frameworks is not a silver bullet. Software is inherently abstract, which makes it hard to engineer its quality and to manage its production. The good news, however, is that OO component and framework technologies are becoming mainstream. Developers and users are increasingly adopting and succeeding with object-oriented design and programming.

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.dre.vanderbilt.edu/~schmidt/corba.html

http://www.dre.vanderbilt.edu/~schmidt/ACE.html.

### References

[Box:97] Don Box, "Understanding COM," Addison-Wesley, Reading, MA, 1997.

[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.