PLM: Assessing the industrial relevance
303
An implementation methodology of SOA based PLM system TaeJae Lee*, JongGyun Lim*, JunHo Shin*, SeHyun Myung*, MiYoung Choi*, SeungSik Baek*, JuIk Kim*, JaeWook Oh*, DongSuk Lee**, YongDuk Han** * Samsung Electronics, R&D IT Infra Group, Technology Strategy Office, Corporate Technology Operations ** Samsung SDS, Electronics PLM Development Team 31st Fl. Digital R&D Center, 416 Maetan-3Dong, Yeongtong-Gu, Suwon-City, Gyeonggi-Do, Republic of Korea 443-742 +82-31-277-6946(Tel.), +82-31-277-7731(Fax.)
[email protected] (Corresponding author: SeHyun Myung) Abstract: The range of IT systems and engineering solutions that fall under the terminology PLM system has been growing with constant introduction of new IT technologies and latest engineering needs. Consequently, a typical PLM system in a large manufacturing company is no longer represented by a single homogeneous IT system but a collection of several commercial packages as well as home grown applications. This paper describes a methodology to implement a PLM system by integrating hybrid legacy IT assets within serviceoriented architecture using our best of breed service integration policy. Keywords: PLM, SOA, Web Service, ESB, BPM, Enterprise Portal
1
Introduction
Large manufacturing companies today have gone through several phases of R&D innovation and advanced their R&D environments and practices significantly from what they used to be in early 1990’s when a PDM (Product Data Management) system was first introduced. For example, in 1994 when Samsung Electronics Co. (“SEC”, henceforth) embarked on its first corporate PDM system implementation, the focus was on secure on-line management of 2D CAD drawings and related engineering data. Today, however, there is no more 2D CAD drawings managed by the SEC PDM system (“SPDM”, henceforth) – they are generated on the fly from a 3D CAD file. In fact, mechanical CAD work itself is becoming relatively minor task of R&D engineers at SEC as the amount of software source codes and corresponding number of software engineers grow at record high rate. The current version of SPDM has not yet caught up with that particular rate of change, and thus much of the software development activities and data at SEC are not fully managed by the SPDM system. The problem is that there are growing number of other reasons – business wise and IT wise – that require speedy and perpetual change of PDM systems. Business wise, globalization is the number one reason why PDM systems have to change fast. DAMA
Copyright © 2007 Inderscience Enterprises Ltd.
304
T.J. Lee et al.
(Design Anywhere, Manufacture Anywhere) is no longer a fancy catch phrase of a PLM vendor but a mission critical practice of most large manufacturing companies. The second reason is the digitalization trend of consumer products. Software and SoC (System on Chip) engineering activities account for the major portions of product development time and resources. Legacy PDM systems that are architectured to support 2D drawings or PCB circuit design activities have to change fast to support the new requirements. Then there are several other reasons associated with corporate cultural and organizational change. R&D outsourcing, departmental spin-offs, and M&A (Mergers & Acquisitions) of completely new business are common these days. Consequently, there are constant new requirements for improved business processes as well as infrastructure for better communication, information sharing, and data migration. IT wise, the reason why a legacy system like SPDM suffers from the lack of usability and performance to end-users is, ironically, the constant increase of the computing power and introduction of new IT technologies. In 2003, SEC had to upgrade its SPDM system to SPDMv6 by replacing its proprietary client/server architecture to a standard web based architecture because web technologies caused end users to demand better user interface and improved usability. Now SPDMv6 needs to be upgraded once again because current State-of-the-art IT technologies can make it a more flexible system that can easily implement fast changing processes and accommodate integration/interface requirements with other enterprise systems like ERP, APS, CRM and SRM. Faced with above mentioned reasons, SEC is in the course of reviewing several possibilities to migrate current SPDMv6 into a new system. Tentatively we call it a SEC PLM system. This paper describes our research about the implementation methodology of SOA (Service Oriented Architecture) based PLM system at SEC. We define our definition of a PLM system, describe features of SOA that facilitate implementation of our PLM system, and summarize the result of our initial effort to pilot a SOA based PLM system at SEC.
2
Requirements
In order to define the right PLM system at SEC, we took a survey of 17 business units within SEC and compiled the voice of managers and engineers. Prior to the individual interviews we provided them with a list of questions prompting them about the issues and suggestions regarding our present and future R&D processes and systems. Figure 1 is the summary of responses gathered. Traditional requirements from managers – quality, cost and delivery efficiency – are still on the top of the list. However, very different kind of requirements prevails from R&D engineers as well as from some managers – flexibility. Engineers want flexibility from the legacy PDM system because it takes unacceptably long time for the system to reflect the latest change in their engineer practices. Managers want flexibility because the new rules and regulations they want to enforce are only on some papers or booklets and by the time they are implemented in a system it is typically too late since they are already obsolete. Additionally, both managers and engineers want to find more global best practices and intellectual properties. Currently each business unit has its own PDM system, and therefore it is not easy to share information even among the business units. Ideally, both local and global best practices and knowledge should be discovered, accumulated and shared corporate-wide.
An implementation methodology of SOA based PLM system Figure 1
305
Voice of Customers
Executives and Directors Maximize R&D productivity and efficiency Make it flexible to adapt to the fast changing customer needs Continually discover innovative product development methodologies Globalize corporate processes and systems Manage and propagate R&D knowledge and best practices
R&D Engineers Minimize paper works – including various managerial input to PDM systems Prompt upgrade of applications such as change in regulations and processes are reflected to their systems Extend the coverage of the PDM system so that specialized engineering data and activities can be managed as well Allow engineers to use the tool of their choice Provide more best practices
3
Product Lifecycle Management
SEC began implementation of its first corporate PDM system as early as 1994. By 1996, the first fully functional version of SPDM was deployed at the AV division. Ten years later, SPDM is being used throughout the company both domestically and globally. So, yes SEC has a global PDM system. The difficult question to answer is “does SEC have a PLM system?” The primary reason is because the definition of PLM is overloaded. Industries, academia, and vendors seem to have different scope and concept of PLM. Pahl and Beitz [1] assert that a lifecycle of a product covered by a PLM may include phases of “Market / Need / Problem”, “Product Planning / Task Setting”, “Design / Development”, “Production / Assembly / Test”, “Marketing / Consulting / Sales”, “Use / Consumption / Maintenance”, “Recycling” and “Disposal.” According to them, a PLM system should cover all those phases of a product lifecycle as well as the data that are traditionally managed by a PDM system. According to Prof. Michael Grieves [2] and PLM Consortium at Michigan University, PLM is “an integrated, information driven approach to all aspects of a product’s life from its design inception, through its manufacture, deployment and maintenance, and culminating in its removal from service and final disposal.” CIMdata [3] defines PLM as “a strategic business approach that applies a consistent set of business solutions that support the collaborative creation, management, dissemination, and use of product definition information.” On the other hand, various solution vendors [4, 5, 6] are more down to earth and limit the scope of a PLM system to cover some combination of their PDM system with CAD, CAM, CAE, or digital manufacturing systems. We have reviewed those and several other definitions of PLM and adopted the following to be our working definition – “a solution and a strategic approach to manage human resource, process, business system, information across the product lifecycle from the business planning stage to disposal” With the agreed upon definition of PLM at SEC, we have scrutinized our legacy SPDM system and concluded that there are four axis of fundamental re-engineering directions needed to transform SPDM into a PLM system – Coverage, Connectivity, Competency, and Flexibility. We believe that the first three can be achieved by adding new best-of-breed engineering solutions available in the market with proper integration
T.J. Lee et al.
306
with the in-house applications. However, in order to achieve the fourth goal of flexibility, we had to consider new architecture for our new PLM system that can not only accommodate continuous introduction of new best-of-breed applications but also leverage SPDM and tens of other legacy assets already deployed throughout the company. In the remaining sections of this paper, we describe how we have studied and adopted SOA (Service Oriented Architecture) to satisfy that fourth requirement, the open and flexible architecture for SEC PLM system.
4
Service Oriented Architecture
SOA is an architecture that combines proven advantages of object-oriented modeling and component-based design. Services within a SOA are loosely coupled constituents each of which encapsulate a meaningful business objective or enterprise data and may communicate with each other using some standard protocols. SOA is neither a technology nor commercial solution. Instead it is a form of technology architecture that adheres to the principles of service-orientation and standards of web services [7]. SOA is not a new concept, but we believe it is a right concept at the right time. For many companies that undergo business transformation and find their IT systems too heavy and complex to be promptly transformed, SOA could be regarded as a solution for integrating and simplifying their IT systems [8]. Gartner predicts that by 2008, SOA will provide the basis for 80 percent of development projects [9]. This chapter summarizes aspects of SOA-based system as we understand them – services, ESB (Enterprise Service Bus), BPM (Business Process Management) and EP (Enterprise Portal).
4.1 Services First, a service within a SOA can be defined as following: z A service is an implementation independent interface with explicit definition. z A service is loosely coupled, location-transparent and called by interoperable communication protocol. z A service encapsulates re-usable business functions At SEC we differentiate three kinds of services in SOA; basic, composite, and process services. A basic service is an atomic service which can serve some meaningful business function. A composite service consists of combination of one or more basic services. A process service consists of one or more basic services and composite services and forms a business process. Figure 2 illustrates a basic service in SOA which consists of an interface and a service implementation and composite and process services. Although not mandatory, we opted for a standard web service implementation whenever possible. Figure 2
Services in SOA
An implementation methodology of SOA based PLM system
307
4.2 Enterprise Service Bus ESB is a new kind of application integration middleware. Gartner Group defines ESB as “a web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled business components.” IBM describes ESB as providing a set of infrastructure capabilities, implemented by middleware technology, that enable the integration of services in an SOA. Although, the implementation methodology is different from one vendor to another, the main functionalities of an ESB are the same – a middleware and a bus for communication among services in SOA. Figure 3 is an illustration of an enterprise service bus by IBM [10]. Figure 3
Enterprise Service Bus [10].
4.3 Business Process Management BPM became a hot IT issue after introduction of BPR (Business Process Re-engineering) in 1990s’, and is regarded as business innovation method that supports integration of enterprise processes. BPMS (Business Process Management System) is a management system that optimizes business processes through ‘define’, ‘design’, ‘execute’ and ‘analyze’ cycles. A business process is choreography of operations executed by the system or human. The definition and design of the process is important in BPM. The main functions of BPMS are ‘process definition’, ‘process execution’, ‘process measurement / analysis’ and ‘process improvement’. The integration of scattered systems throughout the company is a primary purpose of using BPMS. SOA proposes the idea of smooth integration for BPMS because SOA is an architecture that defines business processes as a collection of business services.
4.4 Enterprise Portal Enterprise Portal is an information gateway to employee, customers and business partners. A portal is in charge of the presentation layer of a SOA system. It integrates system with data and provides single access point to users. When a user interacts with an IT system, s/he only sees the presentation layer. Therefore, portal is often the most important aspect of a web-based IT system and the importance of usability of page layout and content presentation can never be over-emphasized. In our pilot project, we had to update the portal constantly during the various phases of the project.
T.J. Lee et al.
308
5
SOA Based PLM System
The mission of our project is to design and implement a pilot system that represents a legitimate fraction of our next generation PLM system that is based on an open and flexible architecture, while satisfying the engineering functional requirements as shown in Figure 4. Figure 4
Two Facet Requirements for SEC PLM System
Open & Flexible Architecture
Engineering Functionalities
Extensibility & Interoperability
Heterogeneous CAD Data Management
Robustness & Function
PDM Common Service
Process Management
Requirement Management
Technology Platform
Customer & Supplier Management
Easy Development & Maintenance
5.1 SOA Based PLM System Architecture Initially, we surveyed the market for a commercial off-the-shelf package solution that would satisfy our requirements. As a result we found the following two schools of solutions: 1. Middleware solutions to implement a SOA based IT systems 2. PLM solutions rooted on a PDM or a drawing management system No single unified solution was found that could satisfy the two requirements simultaneously. So our next best method was to select the most open and standard middleware solution to implement a basement for our PLM system and then employ a ‘best of breed’ strategy to ‘plug-in’ any number of engineering functionalities from commercial or legacy systems. The resulting SOA based PLM system architecture consists of web services technologies for the application services, ESB technology for message processing of services, BPM technology for business process management, and enterprise portal for UI integration. Figure 5 shows the conceptual architecture of SOAbased PLM system. Each component technology of the referenced SOA is as defined in section 4. It can be noticed in the illustration that SOA based PLM architecture requires services from legacy systems. These services can be accessed through ESB and supplied to the users through integrated UI in portal.
5.2 SOA Based PLM System Implementation Depending on how to count it, there are more than fifty legacy systems in SEC for the management of R&D processes. In order to minimize the risk while maintaining the meaningful size of the pilot project, we defined the scope of our pilot project to cover twelve systems and sub systems. Our implementation goal was to transform those twelve legacy systems into a SOA based PLM system. For the bases of open and flexible SOA architecture, we installed commercial middleware solutions from a couple of selected vendors. With some customization effort to connect to SEC enterprise SSO (Single Sign On) and LDAP (Lightweight Directory Access Protocol), we managed to establish the basics of presentation, BPM, and ESB layers of our SOA based PLM system. The difficult part was transforming legacy systems into services. There was no right answer
An implementation methodology of SOA based PLM system
309
when it comes to deciding the size of a basic service. We took the advice from IBM and used the three-fold approach in identifying services; top-down, goal-driven, and bottomup. Top-down approach is to start from a business process and compile a list of services that are required to run that process. Goal-driven approach is to start from an enterprise KPI (Key Performance Indicator) and derive the business functions needed to achieve the KPI. Bottom-up approach is to analyze existing functions and operations in the legacy system and build up to a meaningful unit of business object. After a number of trials and errors, we identified 20 basic services from the twelve systems. Those are the enterprise services that can be published and shared throughout the company. Using the UDDI (Universal Description, Discovery, and Integration) publication tool from acquired commercial package, we have also registered and published those services within SEC. In addition to the basic services, we implemented nine composite services and three process services to demonstrate the benefits of the new architecture. In particular, the process services are implemented using the standard BPEL (Business Process Execution Language) and executed on top of the BPM engine that we installed as shown in Figure 6. The flexibility of the process design and the visibility of BPMS, draw positive feedbacks from the process owners and designers alike. Figure 5
PLM Architecture
Figure 6
Business process lifecycle for BPMS
310
6
T.J. Lee et al.
Conclusion
Although the coverage is limited to a fraction of the work done in R&D systems at SEC, the implementation of the pilot SOA based PLM system introduced in this paper is the first of its kind that attempts to apply complete four layers of SOA to a PLM system – presentation, BPM, ESB, and service layers. So far, the result is promising. We expect to see quick implementation of new business processes which in turn will promote faster change of processes and thus make SEC a more agile company. Before moving into our next phase of full blown PLM system implementation, however, we still need to solve the granularity issue. Bigger sized services are easier to implement but less modular and thus less useful. Smaller sized services are more difficult to implement and maintain but service re-usability and flexibility will increase. Also, services in SOA are new IT constructs that require continuous maintenance. Thus we need to define governance rules and assign responsible organization for maintaining services throughout their lifecycle.
References 1 2 3 4 5 6 7 8 9 10
Pahl, G., Beitz, W. (1996) Engineering Design: A systematic Approach (2nd ed.), SpringerVerlag, Figure 1.2 in p.3. Grieves, M. (2006) Product Lifecycle Management: Driving the Next Generation of Lean Thinking, New York, McGraw-Hill, p.33. CIMdata, Inc. (2002) Product Lifecycle Management, A CIMdata Report, pp.5-8. Dassault Systemes, http://www.3ds.com. UGS, http://www.ugs.com PTC, http://www.ptc.com. Erl, T. (2005) Service-Oriented Architecture, Concepts, Technology, and Design, Prentice Hall, p.54. Asuka M., ‘Introduction to SOA’ (Japanese), IBM Japan, http://www-6.ibm.com/jp/ software/websphere/developer/soa/. Cearley, D. W., Fenn, J., Plummer, D.C. (2005) Gartner's Positions on the Five Hottest IT Topics and Trends in 2005, Gartner Report, p.4. Keen, M., Bishop, S., et al. (2004) Patterns: Implementing an SOA using an ESB, IBM Redbook, p.77.
