ACE/docs/ACE-lessons.html

   1 <HTML>
   2
   3 <!--  -->
   4 <HEAD>
   5 <TITLE>Lessons Learned Building Reusable OO Telecommunication Software</TITLE>
   6 </HEAD>
   7
   8 <BODY text = "#000000"
   9 link="#000fff"
  10 vlink="#ff0f0f"
  11 bgcolor="#ffffff">
  12
  13 <HR>
  14 <H3>Lessons Learned Building Reusable OO Telecommunication Software Frameworks</H3>
  15
  16 <DT>Douglas C. Schmidt
  17 <DT>Department of Computer Science
  18 <DT>Washington University, St. Louis
  19 <DT><A HREF="http://www.dre.vanderbilt.edu/~schmidt/">http://www.dre.vanderbilt.edu/~schmidt/</A>
  20 <DT><A HREF="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</A>
  21
  22 <P>The following article appeared in the Lucent Bell Labs ``Multiuse
  23 Express'' magazine, Vol. 4, No. 6, December, 1996. <P>
  24
  25 <P><HR><P>
  26
  27 <H3>The Distributed Software Crisis</H3>
  28
  29 Developing complex software systems is expensive and error-prone.
  30 Object-oriented (OO) programming languages [Stroustrup:91,Gosling:96],
  31 components [Box:97], and frameworks [Lewis:95] are heavily touted
  32 technologies for reducing software cost and improving software
  33 quality.  When stripped of their hype, the primary benefits of OO stem
  34 from the emphasis on <EM>modularity</EM> and <EM>extensibility</EM>,
  35 which encapsulate volatile implementation details behind stable
  36 interfaces and enhance software reuse. <P>
  37
  38 Developers in certain well-traveled domains have successfully applied
  39 OO techniques and tools for years.  For instance, the Microsoft MFC
  40 GUI framework and OCX components are <EM>de facto</EM> industry
  41 standards for creating graphical business applications on PC
  42 platforms.  Although these tools have their limitations, they
  43 demonstrate the productivity benefits of reusing common frameworks and
  44 components.<P>
  45
  46 Software developers in more complex domains like telecom have
  47 traditionally lacked standard off-the-shelf middleware components.  As
  48 a result, telecom developers largely build, validate, and maintain
  49 software systems from scratch.  In an era of deregulation and stiff
  50 global competition, this in-house development process is becoming
  51 prohibitively costly and time consuming.  Across the industry, this
  52 situation has produced a ``distributed software crisis,'' where
  53 computing hardware and networks get smaller, faster, and cheaper; yet
  54 telecom software gets larger, slower, and more expensive to develop
  55 and maintain. <P>
  56
  57 The challenges of building distributed software stem from
  58 <EM>inherent</EM> and <EM>accidental</EM> complexities [Brooks:87]
  59 associated with telecom systems: <P>
  60
  61 <UL>
  62 <LI> Inherent complexity stems from the fundamental challenges of
  63   developing telecom software.  Chief among these is detecting and
  64   recovering from network and host failures, minimizing the impact of
  65   communication latency, and determining an optimal partitioning of
  66   service components and workload onto processing elements throughout
  67   a network. <P>
  68
  69 <LI> Accidental complexity stems from limitations with tools and
  70   techniques used to develop telecom software.  A common source of
  71   accidental complexity is the widespread use of algorithmic
  72   decomposition, which results in non-extensible and non-reusable
  73   software designs and implementations. <P>
  74 </UL>
  75
  76 The lack of extensibility and reuse in-the-large is particularly
  77 problematic for complex distributed telecom software.  Extensibility
  78 is essential to ensure timely modification and enhancement of services
  79 and features.  Reuse is essential to leverage the domain knowledge of
  80 expert developers to avoid re-developing and re-validating common
  81 solutions to recurring requirements and software challenges. <P>
  82
  83 While developing high quality reusable software is hard enough,
  84 developing high quality extensible and reusable telecom software is
  85 even harder.  Not surprisingly, many companies attempting to build
  86 reusable middleware fail -- often with enormous loss of money, time,
  87 and marketshare.  Those companies that do succeed, however, reap the
  88 benefits resulting from their ability to develop and deploy complex
  89 applications rapidly, rather than wrestling endlessly with
  90 infrastructure problems.  Unfortunately, the skills required to
  91 successfully produce telecom middleware remain something of a "black
  92 art," often locked in the heads of expert developers. <P>
  93
  94 <P><HR><P>
  95
  96 <H3>Lessons Learned Building Reusable OO Communication Software Frameworks</H3>
  97
  98 Over the past decade, I've worked with many companies (including
  99 Motorola Iridium, Ericsson, Siemens, Bellcore, Kodak, and McDonnell
 100 Douglas) building reusable OO communication software [Schmidt:96].  In
 101 these projects, we've applied a range of OO middleware tools including
 102 OMG <A HREF="http://www.dre.vanderbilt.edu/~schmidt/corba.html">CORBA</A>
 103 (an emerging industry standard for distributed object computing) and
 104 the <A HREF="http://www.dre.vanderbilt.edu/~schmidt/ACE.html">ACE</A>
 105 framework (a widely used C++ framework that implements many strategic
 106 and tactical design patterns for concurrent communication software).
 107 The following are lessons learned from developing and deploying
 108 reusable OO communication software components and frameworks in
 109 practice: <P>
 110
 111 <UL>
 112 <LI> <B><EM> Successful reuse-in-the-large requires non-technical
 113 prerequisites -- </EM></B><P>
 114
 115   Many political, economical, organizational, and psychological
 116   factors can impede successful reuse in telecom companies.  I've
 117   found that reuse-in-the-large works best when (1) the marketplace is
 118   competitive (i.e., time-to-market is crucial, so leveraging existing
 119   software substantially reduces development effort), (2) the
 120   application domain is non-trivial (i.e., repeatedly developing
 121   complete solutions from scratch is too costly), and (3) the
 122   corporate culture is supportive of an effective reuse process (e.g.,
 123   developers are rewarded for taking the time to build robust reusable
 124   components).  When these prerequisites <EM>don't</EM> apply, I've
 125   found that developers often fall victim to the "not-invented-here"
 126   syndrome and rebuild everything from scratch. <P>
 127
 128 <LI> <B><EM> Iteration and incremental growth is essential </EM></B> -- <P>
 129
 130   Expanding on the corporate culture theme, I've observed that it's
 131   crucial for software managers to openly support the fact that good
 132   components, frameworks, and software architectures take time to
 133   craft and hone.  For reuse to succeed in-the-large, management must
 134   have the vision and resolve to support the incremental evolution of
 135   reusable software.  In general, an 80% solution that can be evolved
 136   is often preferable to trying to achieve a 100% solution that never
 137   ships.  Fred Brook's observation that ``Plan to throw the first one
 138   away, you will anyway'' [Brooks:75] applies as much today as it did
 139   20 years ago. <P>
 140
 141 <LI> <B><EM> Integrate infrastructure developers with application developers
 142 </EM></B> -- <P>
 143
 144   Truly useful components and frameworks are derived from solving real
 145   problems, e.g., telecommunications, medical imaging, avionics, OLTP,
 146   etc.  Therefore, a time honored way of producing reusable components
 147   is to generalize from working systems and applications.  In
 148   particular, resist the temptation to create ``component teams'' that
 149   build reusable frameworks in isolation from application teams.  I've
 150   learned the hard way that without intimate feedback from application
 151   developers, the software artifacts produced by a component team
 152   won't solve real problems and will not be reused. <P>
 153
 154 <LI> <B><EM> Industry ``standards'' are not panaceas -- </EM></B> <P>
 155
 156   Expecting emerging industry standards (like CORBA or TINA) to
 157   eliminate telecom software complexity today is very risky.  For
 158   instance, although some CORBA ORB implementations are suited for
 159   certain telecom tasks (such as managing network elements), the
 160   semantics of higher level OMG services (such as the Common Object
 161   Services) are still too vague, under-specified, and non</EM></B>
 162   -interoperable.  Although CORBA isn't yet suited to address certain
 163   demanding real-time performance and reliability requirements in the
 164   telecom domain, over the next 2 years we'll see CORBA-based products
 165   emerge that support such features [Schmidt:96].<P>
 166
 167 <LI> <B><EM> Beware of simple(-minded) solutions to complex software problems
 168 -- </EM></B> <P>
 169
 170   Apply simple solutions to complex problems that sound too good to be
 171   true typically are...  For example, translating code entirely from
 172   high-level specifications or using trendy OO design methodologies
 173   and programming languages is no guarantee of success.  In my
 174   experience, there's simply no substitute for skilled software
 175   developers, which leads to the following final ``lesson learned.''
 176 <P>
 177
 178 <LI> <B><EM> Respect and reward quality developers </EM></B> -- <P>
 179
 180   Ultimately, reusable components are only as good as the people who
 181   build and use them.  Developing robust, efficient, and reusable
 182   telecom middleware requires teams with a wide range of skills.  We
 183   need expert analysts and designers who have mastered design
 184   patterns, software architectures, and communication protocols to
 185   alleviate the inherent and accidental complexities of telecom
 186   software.  Moreover, we need expert programmers who can implement
 187   these patterns, architectures, and protocols in reusable frameworks
 188   and components.  In my experience, it is exceptionally hard to find
 189   high quality software developers.  Ironically, many telecom
 190   companies treat their developers as interchangeable, "unskilled
 191   labor" who can be replaced easily.  I suspect that over time,
 192   companies who respect and reward their high quality software
 193   developers will increasingly outperform those who don't. <P>
 194 </UL>
 195
 196 <P><HR><P>
 197 <H3>Concluding Remarks</H3>
 198
 199 Developing reusable OO middleware components and frameworks is not a
 200 silver bullet.  Software is inherently abstract, which makes it hard
 201 to engineer its quality and to manage its production.  The good news,
 202 however, is that OO component and framework technologies are becoming
 203 mainstream.  Developers and users are increasingly adopting and
 204 succeeding with object-oriented design and programming.<P>
 205
 206 On the other hand, the bad news is that (1) existing OO components and
 207 frameworks are largely focused on only a few areas (e.g., GUIs) and
 208 (2) existing industry standards still lack the semantics, features,
 209 and interoperability to be truly effective throughout the telecom
 210 software domain.  Too often, vendors use industry standards to sell
 211 proprietary software under the guise of open systems.  Therefore, it's
 212 essential for telecom companies to work with standards organizations
 213 and middleware vendors to ensure the emerging specifications support
 214 true interoperability and define features that meet telecom software
 215 needs.<P>
 216
 217 Finally, to support the standardization effort, it's crucial for us to
 218 capture and document the patterns that underlie the successful telecom
 219 software components and frameworks that do exist.  Likewise, we need
 220 to reify these patterns to guide the creation of standard frameworks
 221 and components for the telecom domain.  I'm optimistic that the next
 222 generation of OO frameworks and components will be a substantial
 223 improvement over those we've worked with in the past.<P>
 224
 225 For more information on building reusable OO communication software
 226 frameworks with CORBA and ACE, see the following WWW URLs:<P>
 227
 228 <A HREF="http://www.dre.vanderbilt.edu/~schmidt/corba.html">http://www.dre.vanderbilt.edu/~schmidt/corba.html</A><p>
 229 <A HREF="http://www.dre.vanderbilt.edu/~schmidt/ACE.html">http://www.dre.vanderbilt.edu/~schmidt/ACE.html.</A>
 230
 231 <P><HR><P>
 232 <H3>References</H3>
 233
 234 [Box:97] Don Box, "Understanding COM," Addison-Wesley,
 235      Reading, MA, 1997.<P>
 236
 237 [Brooks:75] Frederick P. Brooks, "The Mythical Man-Month,"
 238      Addison-Wesley, Reading, MA, 1975.<P>
 239
 240 [Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and
 241      Accidents of Software Engineering," IEEE Computer, Volume
 242      20, Number 4, April 1987, 10-19.<P>
 243
 244 [Gosling:96] The Java Programming Language, Addison-Wesley,
 245      Reading, MA, 1996.<P>
 246
 247 [Lewis:95], Ted Lewis et al., "Object Oriented Application
 248      Frameworks," IEEE Computer Society Press, 1995.<P>
 249
 250 [OMG:95] Object Management Group, The Common Object Request Broker:
 251      Architecture and Specification 2.0, July, 1995.<P>
 252
 253 [Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for
 254      Application-Level Gateways," Theory and Practice of Object
 255      Systems, Wiley and Sons, 1996.<P>
 256
 257 [Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and
 258      Guru Parulkar, "Towards Real-time CORBA," IEEE Communications
 259      Magazine, Volume 14, Number 2, February 1997.<P>
 260
 261 [Stroustrup:91] Bjarne Stroustrup, The C++ Programming Language, 2nd
 262      Edition, Addison-Wesley, Reading, MA, 1991.<P>
 263
 264 <P><HR><P>
 265 Back to <A HREF="http://www.dre.vanderbilt.edu/~schmidt/ACE.html">
 266 ACE</A> home page.<BR>
 267 Back to <A HREF="index.html">ACE Documentation Home</A>.
 268 <!--#include virtual="/~schmidt/cgi-sig.html" -->
 269 </BODY>
 270 </HTML>