Integration is an important topic in PLM. Few days ago, I was reading Aras’ blog – Understanding of integration and federation with Aras. This blog caught my attention by review of different PLM integration patterns – integration and federation. Despite the fact, it is a very self-promotional message, I found the following passage in the post interesting -
As an open architecture, Aras has a number of obvious advantages… open APIs, a published data dictionary, an openly available data model… but that’s really only half the story. From a technological perspective we’re using a more modern approach, a pure Web services approach, that’s designed from the ground up with technology agnostic interoperability in mind. Aras can be “connected to”, “integrated with” and “wrapped around” anything you’ve got whether its based on IBM, Oracle, SAP, Linux, Unix, Microsoft or even Progress… or “all of the above”. We even include a Web services wizard in our Solution Studio out-of-the-box. We understand that global companies need to combine data from numerous existing systems in order to manage products across the lifecycle, and we recognize that a highly robust, scalable and secure Federated approach is the right way to do this; both from a technical and a business perspective.
PLM and Integration
Aras blog made me think about various aspects of PLM integrations. Integration is an important topic in every manufacturing organization. It is almost obvious. You have multiple departments, organizations, subcontractors, offshore manufacturing, supply chain and many other things. In order to run your product development and business processes, companies are implementing multiple systems – engineering, manufacturing, supply chain, etc. I believe, the time when people believe to satisfy everybody’s need with a single system is over. It is costly and not efficient. So, you have CAD, PDM, PLM, ERP, SCM, CRM and zillions of other applications in your company that need to work together somehow.
Historically, Product Lifecycle management story is tightly related to integration. PLM system sort of “sits in the middle”. Regardless on what PLM vendor you plan to rely, the question of how to integrate you PLM system (aka data in PLM system and processes) with the rest of the world in your organization will come. The priority might be different – supply chain system, design subcontractors or ERP/MRP integration. Nevertheless, no matter what – you will have to solve your “integration problems”.
Integration Maturity Levels
Integration in PLM has a long history of development, started from highly tailored solutions to various attempts to deliver integration solutions relied on different types of integration infrastructure / middleware.
Level 1: Data Exchange
At this level, the focus of integration is to deliver a solution that can take data from one system and place it in another system. The typical example is batch data exchange between PDM and ERP systems. The scenario, which is probably most widely implemented is to transfer bill of material from PDM to ERP. There are few more scenarios in this area. In my view, the majority of integrations in the industry today are focused on the delivery of data exchange. Vendors are offering some standard capabilities. However, most of the solutions are customized and tailored to a need of a specific customer. The main advantage of this type of integration is simplicity (import/export). The disadvantage of this type of integration is related to the limitation of processes beyond importing and exporting data.
Level 2: Application Integration
I can define two major types of application integration – point-to-point and middleware based integration. Companies started to approach this level of integration in order to deliver an additional logic into integration rather than just import / export data. Technological foundation for integration is delivered by the level of API available for each system. API can vary and depends on application and system architecture. During the past few years, I can clearly see a tendency to converge towards various flavors of web technologies. Point-to-point solutions are focusing on creating an integration logic between two applications. Middleware-based integration was focusing on leveraging integration platforms (i.e. BizTalk, WebSphere, etc.) to connect applications. The cost of middleware integration is higher, but eliminates the complexity of multiple application integration. Today, most of the application integration can be delivered by service providers and IT departments of big customers.
Level 3: Data Federation
One of the biggest problems in application integration is high level of dependencies on the actual systems, system architecture and versions. The tight link between application and data is not allowing to re-use data beyond application version, increase the complexity to establish cross application and cross-department processes. In my view, data federation is the level of integration maturity where data will become self-descriptive and potentially encapsulated from application logic and application versions. This is where the future will take us. I will elaborate on this later in my blog.
What is my conclusion? I think, integration will become even more important soon. There are two main reasons for that. 1- companies are looking how to deliver business solutions faster. To create three years integration project is not an option anymore. Information availability for decision making or cross-department optimization becomes a top priority for IT. 2- cloud. Many companies are checking how to deliver hybrid on-premise/cloud solutions. To take data exchange to cloud won’t an option any more. Future data federation will introduce new web technologies to PLM integration space. Just my thoughts…
Best, Oleg
Image by Salvatore Vuono / FreeDigitalPhotos.net
Pingback: Which Way Is The Integration Pendulum Swinging? « realtimerick