Architecture Overview
An overall Service Lifecycle Management solution has many functions to be performed. It starts with the authoring source of the service content, publishing and transformation tasks to prepare the content, delivering the content to the wider consumer base, and finally methods to receive consumer feedback and integrate with eCommerce applications. The following diagram illustrates these functional needs and how they relate to each other:
This diagram is comprised of the following elements:
• Service Information Management and other enterprise source data: This system is the source for providing as-supported views of the products. It manages product technical information such as;
◦ Disassembly and assembly procedures
◦ Test and adjust procedures
◦ Service bulletins
◦ Spare parts information
◦ Service effectivity
• Data Processing – service information is extracted from the source and transformed to fit in the content delivery system.
• Data Loading – the final task to move the service information into the content delivery system.
• Content Delivery – service content is made available to the user base. Integrations with eCommerce solutions are established. User’s feedback is received.
From a deployment perspective, the Service Lifecycle Management environment should have the following systems, as is depicted in the following diagram.
For simplicity, each system is represented here as one server. However each can consist of multiple hardware resources, depending on its design, performance, and scale requirements.
This diagram is comprised of the following elements:
• Windchill SIM/SP or other SIM source of content – Solutions that contain the service information content. In a production setting, this is typically regarded as an internal or ‘back office’ system.
• Windchill Publishing Engine or other Extraction resource – an engine used to extract service content as product bundles for submission to the content delivery system. In a production setting, this is typically regarded as an internal or ‘back office’ system.
• Publisher – the Publisher receives the service information bundle and executes transformation, aggregation, and loading tasks to move the service content into the content delivery system. In a production setting, this is typically regarded as an internal or ‘back office’ system.
• Viewer – Provides user base with access to the service content. In a production setting, this is typically regarded as an external or ‘customer facing’ system. It can be hosted on-premise, externally by a third party, or within the cloud.
