Architecture Overview
This section provides an overview of architecture considerations for Servigistics InService implementations.
Choosing a deployment architecture can become complicated by many factors:
• The location of source content (authored and non-authored) compared to the location of the Servigistics InService solution:
• The consumer base that will access the content
• The location and requirements for live integration of the Servigistics InService solution and other Information Systems providing such services as Parts Ordering and Feedback tickets.
• The methods used to provide the published content to the user base.
This section will provide typical examples of architectures that can achieve most requirements, anywhere from simple Servigistics InService implementations for Development and QA phases, to large production architectures that are supporting thousands of concurrent users.
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. 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.
• Other CMS/ERP and Extraction Engine — If data from a third-party CMS/ERP system is to be loaded into Servigistics InService, then a custom extraction engine must be written to extract the data out of the third-party system and convert that data into the CSV format expected by Servigistics InService. For more information, see Servigistics InService Publishing and Loading Guide.
• 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-premises, externally by a third party, or within the cloud.
