The seed for COM was planted in 1988, when several different teams at Microsoft began to build object-oriented infrastructures that provided reuse based on components. When a group of engineers was assembled from various other teams to help out on the OLE2 project, the group decided they needed to draft a few high-level requirements for the new architecture they would be building.
These Microsoft engineers came up with four high-level requirements for their new component architecture. First, the architecture had to be component-based because maintaining and enhancing code in large, monolithic applications is difficult. Systems based on binary components are much easier to assemble, maintain, and extend.
Second, the architecture had to be based on the object-oriented paradigm. Most of the binary reuse in Windows had been based on traditional DLLs, which don't commonly include object-oriented extensions. This type of binary reuse can't benefit from the encapsulation that can be achieved with a class-based design.
Third, the architecture had to be language independent. It would be far more powerful if each component author could select a language independently of other component authors. Every programming language requires programmers to make trade-offs in productivity, flexibility, and performance. The ability to choose a language on a component-by-component basis offers many advantages over having to use a single language for an entire application.
Finally, the architecture had to address interprocess communication. It was essential to compose systems of clients and objects that ran on different machines so that the architecture could be a foundation for distributed technologies. The engineers also knew that if they could hide the details of interprocess communication from the majority of programmers, their architecture would foster much higher productivity.
The efforts of these engineers debuted in production code with Microsoft's second major release of Object Linking and Embedding (OLE), a technology that allows users to embed or link documents produced in one type of application in a document of another application. Anyone familiar with Microsoft Windows and Microsoft Office has seen an example of a Microsoft Excel spreadsheet or chart embedded in a Microsoft Word document. OLE allowed Microsoft to promote a document-centric approach to computing rather than the application-centric approach that was most common in business software.
OLE requires interprocess communication among applications. The original version of OLE was based on an interprocess mechanism called Dynamic Data Exchange (DDE). This initial release was plagued with resource and performance problems, which resulted in limited acceptance within the industry. Microsoft knew that OLE's features were valuable conceptually but also that making this technology usable in a production environment would mean optimizing the underlying infrastructure. In essence, OLE needed a whole new plumbing system to be viable.
OLE2 shipped with the first generation of COM in 1993. OLE and COM are distinct entities: OLE is a technology for linking and embedding documents, while COM is an architecture for building component-based systems. Unfortunately, the two are often assumed to be one and the same. Because COM was an essential piece of the OLE2 project, many people use the term OLE when they mean COM. Just remember that OLE and COM are very different conceptually. And be prepared to deal with the confusion.