One of the most delightful parts of my job is to travel the world, sharing the Object Management Group's vision of integrated, interoperable systems with varying sizes of audience from as few as 10 people to as many as 10,000 in every corner of the planet.
While the travel can sometimes be grueling, it's worth it when I get a question or two after a speech that shows that someone has experienced the epiphany I myself had in 1989, when I realized that no business can be automated by software systems until the individual applications that automate individual processes are integrated.
There are a few favorite questions that I ask at these events in order to evoke audience participation. My favorite by far is, "What's the definition of a legacy system?" Unfortunately audiences are getting smarter or perhaps they've just heard me speak before! But until recently most of the answers were in the set:
I certainly understand those last two. I once had to work with a million-line FORTRAN program, the source code for which had been lost and the programmers of which had passed away! My own definition, however, is much simpler: a legacy system is a system that runs.
- "Something written in COBOL (or Jovial or PL/I)"
- "Something that runs on an IBM 370 (or IBM 360 or Burroughs machine)"
- "Something that nobody knows how to use anymore"
- "Something for which the source code has been lost"
- "Something written by programmers long dead and forgotten"
Whether it was written in IBM Assembler F in 1963 and is currently being run in a 1401 emulator on a 360 emulator on a 370 emulator on a Hitachi mainframe or written yesterday morning in Java, if it is deployed now, it is a legacy system. Any future software development that we must do in the enterprise must either integrate with that legacy, or replace it and we all know that software doesn't die, so we are left with only one choice: integration.
I don't think anybody is surprised so far certainly, as the chairman of a consortium focused entirely on standards for integrating systems, I am not surprised. Instead, the continuing surprise for me is the way our industry responds to this legacy integration conundrum. That response has been, historically, and apparently will continue to be in the future, the continuous and uninterrupted introduction of silver bullets designed to slay vampires (complex application integration problems).
Since the OMG was founded, these bullets have included C++, Java, Enterprise JavaBeans, OLE/ActiveX/COM/DCOM/COM+/DNA and now XML. (I have bad news for you: XML isn't the universal data interchange format; it's yet another universal data interchange format.) Each of these previous silver bullets has been another legacy to deal with when the next bullet whizzed by, and this will continue to be true.
Oh yes, another technology touted as universal, a source of homogeneity to cast out the heterogeneity of the world is....CORBA, from the Object Management Group. What makes us any different?
The difference is that CORBA is not itself homogeneous. The OMG has always focused on bridging diverse systems and CORBA has changed in dramatic ways over the years to fulfill that vision. CORBA now includes specifications to integrate directly with such dissimilar languages as C, C++, Java, COBOL, Ada, Smalltalk and Lisp; to integrate seamlessly with Microsoft COM and the Java Platform; and to seamlessly compose components with Enterprise JavaBeans and Microsoft MTS components.
Furthermore, as the industry has moved to more structured development techniques and practices, OMG has moved with it. The OMG's Unified Modeling Language is a universally supported metamodel and notation that has unified the industry around a single standard, a standard that includes (among other things) support for metadata repositories, XML-based repository integration, common data warehouse standards for database integration, and mappings to CORBA and other technologies. Again, this allows integration based on the legacy of not only programming artifacts (code), but even abstract designs.
Furthermore, the OMG has moved rapidly in the past three years to build on these infrastructure successes and the open, neutral OMG consensus process by publishing standards in medical systems interoperability, standardized workflow processing, product data management integration, telecommunications systems convergence and many other areas. Did you know that OMG has published standards for air traffic control? How about for human genome research?
All of this activity is structured around the unceasing need for integration. The current spate of enterprise application integration solutions another new magic bullet finds us in the same situation when Company A (which had used EAI tool X) merges with Company B (which had used EAI tool Y). Suddenly it's the integration tools themselves that need integrating!
The search for silver bullets in our industry will never cease. Perhaps it shouldn't maybe someday we'll really find one. In the meantime, after the silver bullet hits a brick wall, somebody has to pick it up and integrate it with the other legacies. Eight hundred companies now achieve that necessary interoperability through the open, neutral OMG process we'd love to have you participate!
Richard Soley is chairman and CEO of the Object Management Group.