Grundsätzlich besteht jede Software-Komponente aus einer oder mehreren ausführbaren Dateien. Dies wird im Objektmodell durch eine entsprechende Assoziation von der Klasse compObjTemplate zu der neuen Klasse capsuleTemplate gekennzeichnet. Laut RM-ODP muß das Capsule Template die zur Instantiierung eines Capsules benötigte Information - die jedoch nicht näher spezifiziert wird - enthalten. Die Instantiierung eines Capsules ist gleichbedeutend mit dem Starten eines Prozesses und gehört zu den Aufgaben des Konfigurationsmanagements. Für die MOC capsuleTemplate werden Attribute eingeführt, die speziell Konfigurationsinformationen enthalten: Das Attribut InstantProcedure gibt Auskunft über Ort (z.B. Pfadangabe) und Name einer ausführbaren Datei. Eine Programmdatei besitzt einen Typ (Type) - binär oder Skript - der ebenfalls Informationen zum Betriebssystem bzw. Prozessor enthält. Über mögliche und sinnvolle Belegungen von Aufrufparametern informiert das Attribut RuntimeParameter; Size gibt die Größe des ausführbaren Programms an. Ferner wird ein Attribut RequiredObjects modelliert, das angibt, welche Objekte zur Ausführung der Datei vorhanden sein müssen. Hierbei kann es sich um Initialisierungs- oder Konfigurationsdateien, um benötigte Bibliotheken oder Systemschnittstellen handeln. Diese Informationen sind nicht zuletzt auch für das Fehlermanagement relevant. Arbeitet ein Systemdienst nicht ordnungsgemäß, kann der Administrator überprüfen, ob die zugehörigen Capsules korrekt gestartet wurden und ob alle erforderlichen Objekte in der Umgebung vorhanden sind.
Bei der Modellierung dieser Klasse besteht die Gefahr, die Information auf mehrere speziellere Attribute aufzuteilen und somit die Allgemeingültigkeit der generischen Klasse aufzugeben, weil man Spezifika eines bestimmten Systems oder einer Maschinenarchitektur zu sehr in den Vordergrund stellt: Beispielsweise kann ein Capsule Template für ein ausführbares Programm auf einem Großrechner unter MVS nicht gleich aussehen wie ein Template für eine Batch-Datei unter MS-DOS. Für unterschiedliche Plattformen muß das Capsule Template daher noch weiter spezialisiert werden. Außerdem ist es in einem erweiterten Modell denkbar, das Attribut RequiredObjects durch Assoziationen («requires») zu anderen MOCs des Engineering Viewpoint zu ersetzen. Nachfolgend ist ein Beispiel für eine Instanz der generischen Klasse capsuleTemplate für den Prozeß ovtrapd angegeben, der für den Empfang und die Verarbeitung von SNMP-Traps in der Managementplattform HP OpenView auf einem HP-UNIX System zuständig ist:
Außerdem enhält die Klasse capsuleTemplate eine Aggregationsbeziehung zur Klasse clusterTemplate. Dies ist die Folgerung aus der Tatsache, daß in RM-ODP ein Capsule aus einem oder mehreren Clusters besteht. Managementinformation für die Klasse clusterTemplate ist analog zu capsuleTemplate definiert, wobei die Attribute Size und RuntimeParameters entfallen. Analog zu obigem Beispiel ist dem Capsule Template ovtrapd eine Instanz eines Cluster Template für eine Bibliothek zugeordnet:
An dieser Stelle muß ein wenig von den Festlegungen des RM-ODP abgewichen werden, da die Strukturierungsregeln für Cluster ( cluster rules) in [#!iso10746-3!#] festlegen, daß ein Cluster lediglich in exakt einem Capsule enthalten sein darf. Das Konzept der dynamischen, gemeinsam genutzten Bibliotheken (dynamic shared libraries), welches in vielen Systemen aus Geschwindigkeitsgründen realisiert ist, verstößt gegen diese Regel. Da wir jedoch das Management heute existierender Systeme betrachten (welche nicht nach den Prinzipien des RM-ODP konstruiert wurden), weichen wir in diesem Fall vom Standard ab.