grading the re-use of a component functionality across multiple business processes; and easier modification of functions and processes to support rapid introduction of new services. Chapter 8 - Next-Generation OSS Introduction of a new service would now entail addition of new components into the OSS, integration of these components and modification of the business process components. Some key characteristics of a component-based architecture are as follows: 3.5.1 Well-Defined Interfaces Each component provides a standard well-defined interface through which business function services can be accessed. The interface definition is also based on an underlying data model. The interface is characterised by a communication method such as CORBA, Java RMI, EJB or Message Queue and a data format such as fielded structure or XML. Further, the interfaces can be synchronous, asynchronous or batch in nature. A component interface is a "contract" between that component and other components. Other components access services from this component using the methods defined via the interface. An interface-based mechanism to obtain/instantiate services provided by the component allows the component to participate in the context of multiple business processes - whether that be a provisioning, inventory or fault management process. The services provided by the component and the components itself are "re-usable" and provide time-to-market benefits. 3.5.2 Common Data Model Typically while developing an OSS system using multiple components, a common standardized data model is used to allow easier integration and plug- and-play. For example, a common data model will provide standardized definitions of a network element, a circuit, a path, QOS, customer, fault and the relationships among these entities. When different suppliers provide components, it is hard to adhere to a common data model. In this case, the transformation and adaptation is performed in the integration layer. 3.5.3 Externalised Workflow The traditional OSS systems - often r