Open PLM Standards versus proprietary projects solutions

Open PLM Standards versus proprietary projects solutions Real life experiences from integration projects Mirko Theiß mirko.theiss@prostep.com Matthias Grau Matthias.grau@prostep.com Karsten Theis karsten.theis@prostep.com © PROSTEP AG 2010

Agenda • Process and Information Standard related Experiences • PLM Services: A Standard based on Standards • Standards-based PDM integration project • Approaches for a PDM integration platform • SW Development Standard related Experiences • Information system for innovation-management • Cost management tool for complex products • Space System Reference Model (SSRM) • Conclusions © PROSTEP AG 2010

PLM ServicesA Standard based on Standards Platform-independent Specification of Data & Behavior / Standardized platform-specific Models OMG PLM Services Presentation Languages OMG UML W3C XML W3C WSDL Platform Independent Spec. OMG MDA STEP AP214 STEP PDM Schema PDTnet PDM Enablers Content (Data/Behavior) © PROSTEP AG 2010

Part Identification Part Structure Document and File Management Shape Definition and Transformation Classification Properties Alias Identification Authorization Configuration Management Change and Work Management Process Planning Multi Language Support PDM Schemaas Basis PLM ServicesScope of OMG PLM Services 2.0 © PROSTEP AG 2010

Standards-based PDM integration project ERP-System TDM-System PDM-System • Context • Automotive sector • Introduction of a new PDM system • Currently many 1:1 interfaces in established solution • Different transport protocols and (proprietary) data models • Goals • Service-oriented architecture • Standard transport protocols and standard data model • Business driven design (Business should understand interface contracts) • Business driven interface design • Well-defined Service-contract: • Understandable by the business, • self-contained and • in principle more than one service consumer • Business-vision governs technology usage • Web-Services technology stack provides best interoperability • PLM Services 2.0 standard data model provides interoperability and understanding on a business level ERP-Adapter TDM-Adapter PDM-Adapter Service Bus ServiceRepository PDM-Adapter PDM-System © PROSTEP AG 2010

Standards-based PDM integration project • Business aspects: • repeated value over time exceeds the initial investment • Integration of three consumers • with one service provider • by usage of one well-defined contract. • Increased business agility due to • no distributed business-logic anymore • no more 1:1 integrations • Extensible solution • Technical aspects: • Business driven PLMServices 2 data model guarantees understanding on business and IT side and improves human communication • Service-bus provides logging & monitoring (domain-wide debugger) • Open Web-Service technology stack guarantees system interoperability • High customer acceptance of the build solution  SOA + PLM-Services success story © PROSTEP AG 2010

Approaches for a PDM integration platformA common problem - but many solutions Process ? PDM System A Trigger PDM System B Trigger Data User A User B Available standards: Information: PLM Services (OMG) Process: BPEL (OASIS) (and many others) © PROSTEP AG 2010

Approaches for a PDM integration platformSolution 1: With full use of standards Workflow Engine (ESB) Process Definition Specific Procedures / Rules PLM-Services XML PDM System A Trigger PDM System B Trigger PLM Services WebServices Connector A Integration Tool Connector B Data Data User A User B • Pros: (in theory) • Reusable processes • Well defined data model • Simpler mappings • Easy to understand • Cons: (in reality) • Performance Issues • Standard data model doesn't fit to all use cases • Two mappings needed: A->Standard->B • Users don’t know the standard but the native data models • Some use cases are hard or even impossible to implement based on BPEL and PLM-Services • Higher infrastructure costs © PROSTEP AG 2010

Approaches for a PDM integration platformSolution 2: Direct Mapping / Direct Implementation  Proprietary solution success story REST-Services Integration Tool JMS Queue PDM System A Trigger PDM System B Trigger Java Connector A Connector B Data Data User A User B • Implementation • Native PDM data models are used (represented as XML) • Mappings are defined A->B • Process is implemented in Java • Transaction save processing by use of JMS • Pros • Better performance • Easier to understand / lower complexity: • fewer mappings • native data model • users understand the mapping and the data models • All special use cases can be implemented in Java • Lower infrastructure costs © PROSTEP AG 2010

Approaches for a PDM integration platform Conclusions • Experiences over 10 years and more than 100 OpenPDM based implementation projects show • Customers often do not accept additional costs caused by the extra effort of a more complex solution • Customers often have the expectation to technically understand the solution but do not want to invest in know how rg. standards • Business often asks explicitly for a standards based solution, but the IT wants a solution for the smallest possible costs • PROSTEP’s OpenPDM Integration Platform supports standards-based solutions but: Balancing the pros and cons of using standards is a must in each and every OpenPDM project © PROSTEP AG 2010

MDA formal process MDA project process Domain-Knowledge /Information-Objects CIM manual modeling PIM Tool-Export model transformation apply XSLT XML Schema apply JavaCode-Generator PSM XMI Artefacts:Value Objects, Validator-Pattern, Memento-Pattern Information system for innovation management  MDA success story • Project context • Team size: 12 • 5 sub-projects and development teams • Domain-knowledge was subject to change frequently during development • Quality of shared Java artefacts over all interfaces/sub-projects is crucial • Used MDA components • CIM (Domain-model as requirements specification) • PIM (UML)(Platform independent view of domain model, meta model, no technical details) • Platform specific view generated from PIM by applying mappings and code-generators (XML Schema, Java impl., XSLT) • Conclusion • High productive use of MDA • Applying a formal process to create critical code is essential • Applying MDA is an iterative process • Initial effort to setup the tool chain is quickly amortized, because changes can be handled fast and easy • Quality of automated software creation from meta models increases with quality of available tools © PROSTEP AG 2010 CIM = Computational Independent Model PIM = Platform Independent Model  PSM = Platform Specific Model

Cost management tool for complex products  • Project context • Team size: 5 • Complex enterprise environment with many constraints and restrictions • Many change requests caused methodology changes for code generation • Used MDA components • Describe functional aspects of model for business tier and integration tier as UML stereo types • Self made code generator • DAOs, DTOs and DTA • Generator creates • Persistence • navigation and • loading strategies • Conclusion • Restricted productivity gain of MDA • Changes caused too much effort(because of logical changes) • Don’t change the generator AND the PIM in the same project MDA lesson learned © PROSTEP AG 2010

System Engineering Data Verification Matrix Requirement Assembly & Verification Integration Functional Operational Allocation Design Physical Architecture SOA MDA J2EE BPEL ECSS ETM-10-23 Accomondation System Allocation Functional Architectural Physical Design Design Design Space System Reference Model (SSRM) • Project context • Team size: 5 • DBMS to store user/admin information in a tool-independent syntax and semantics • Network-distributed environment as the basis for tool adoption • Platform independent integration architecture • Workflows to control exchange and communication processes from the user perspective • Used MDA and SOA components • W3C web services to transport data via XML and define operations • Servlet technology to implement server • JDBC/SQL Database to persist data • BPEL to drive workflow • OMG PLM Services • Conclusion • Intensive use of standardized technologies • Enables the usage of both commercial and open source software • Technical Proof of Concept fulfilled the customer needs and is continued in several pilots  a joint project with: MDA and PLM Services success story © PROSTEP AG 2010

Conclusion • Proprietary solutions … • are often more efficient in the scope of a single project • reduce the complexity • can solve problems, where standards don’t fit BUT: often do not scale or adopt to similar adjacent areas THEREFORE: need a clear decision to serve exactly only the specific project task • Standards-based solutions … • improve stability and productivity • improve the reusability of the tool chain BUT: require high skill level at developer and customer side THEREFORE: need an project lead with sufficient management support • Standards require a strategic approach, because • standards typically don’t fit a single specific project task • one project often can’t fund a true standards based implementation approach • successful application of standards requires upfront investment in skills, infrastructure, IT governance, … – i.e. a management level IT strategy © PROSTEP AG 2010

Open PLM Standards versus proprietary projects solutions