PLM: Hug Your Data or Federate?

Last year I had chance to blog about why PLM Is Too Complex To Mashup? Thinking about Enterprise PLM implementations, I’m always coming to the following conclusion about the way PLM is managing data – PLM system strategically trying to define, own and manage the complete product data cycle and every aspect related to this data inside and outside of the enterprise. Now, in my view, by doing so, PLM put their effort as a very confronted to the other enterprise systems. This behavior is not typical for PLM- other “enterprise animals” are also trying to keep data closely to their core databases and vaults.

Data Hugging

So, I can call this behavior “data hugging”. Is it good and beneficial? From the certain perspective, you can think about this as a good option to centralize data management and control the situation in your organization related to Product Data or any other topic managed in the context of Product Data. However, the reality is different. Such data hugging can create a situation where get full information is quite complicated.

Federation

What are the alternatives? Data Federation is another alternative. Connect data in your system to the data in another system using so called Proxy objects. The idea of the federation has a potential, since it doesn’t require movement of data around between applications on logical and sometime even on the physical level. However, data federation can be quite complicated for implementation and requires explicit connections between systems.

Other options

If you understand the problem of “data hugging” and don’t think a federation can work out with your environment. DW (Data Warehousing) and MDM (Master Data Management) are two related directions and technologies, that can give you a different perspective in federating data across your company.

What is my conclusion today? Companies are struggling between two possible options – to give extreme power to business and enterprise application to hug data inside or to allow data federation inside organization. The first option is promising for the first look. The hidden portion of the “single system” message is the need to move data from everyplace in your organization to this system. This is not a simple decision in my view. Different flavors of the federation can be perceived as a more complex option upfront, however, can provide a more balanced data management solution for the long term. New disruptive solutions coming from outside of enterprise (mashups are one of them) can provide an interesting alternative for tomorrow’s enterprise data management. What the route PLM systems and implementation should take? What is your opinion?

Best, Oleg

About these ads

18 Responses to PLM: Hug Your Data or Federate?

  1. Cam Bickel says:

    Oleg – this is a big issue. There are certain cases were an analysis tool may work but workers whose primary tool is PLM need certain information at their fingertips. For example, cost and usage information – putting this information in PLM would be helpful to facilitate design to cost and re-use of active parts. This information in naturally maintained in the manufacturing system. Integration is possible and even a batch mode update would be useful for this type of data. However, you find that there is a one to many relationship between PLM and manufacturing sites/systems not to mention currency issues. If becomes complex and cumbersome pretty quickly.

  2. Cam, Thanks for your comment and examples. I agree with them and I indeed think, that this is a big issue for PLM. However, I think, federation or mashups will be more appropriated answer to resolve it rather than try to grab all data under “PLM enterprise data bank”. The examples like “daily sync” works and I had chance to see many similar solutions. This is a reasonable workaround for many manufactures today. Best, Oleg

  3. Menk Slot says:

    Oleg – Some of my customers use a simple solution. If a PLM user needs information from another system (e.g. Cost, stock from ERP) he doesn’t want to open the ERP application. The best way is to copy it as read only data into PLM and update it daily, weekly .. Depending on how often the data is updated in the ERP System. I finished a project where the PLM user can ask for Assy Orders, Purchase orders etc from SAP and after some seconds he can see this info within the PLM System. He only needs this information within an ECO Process to make some decisions.

  4. Menk, Thanks for your comment. Yes, I agree, the solution you explained is somewhat I’d call – the best compromise. However, in today’s dynamic environment it becomes more and more complicated, in my view. Best, Oleg

  5. Brian says:

    I think that the biggest issue with a single system which owns all of the data is the uncertainty of the future. What “new” systems will come online with new data which doesn’t really fit with the “single system”? Because of that a form of federation must be the best answer. New data sources will be developed as users determine a need and these must be available throughout the enterprise in a cost effective manner.
    Finding a way to quickly and cheaply make this data available is the real key.
    Idealy the connections to the data sources and the form design to allow display of the federated data should be codeless.

  6. YXZ says:

    my understanding is, PLM should just focus on design department and give some design information for other departments.

    for federation, there are 2-3 kinds of federation, you can get data and copy data from other applications or you just refer data from other application.

  7. TWeninger says:

    Oleg, you touched a difficult topic here. In fact I think daily synchronization is only acceptable for international distribution due to the cost of high speed WAN connection. If you need access to data at the same campus it should be current. Saying this, I was involved in a project using federated data which is to my knonwledge still unresolved. Hope there will be a systematic way to let various systems communicate to each other….

  8. Chandrajit says:

    I think this is awkward issue. I think “data hugging” depends on type of data, case to case in PLM Implementation.
    In present picture, there are lots of Systems/Applications available to manage various processes in manufacturing/Design, hence very complex/time-consuming to integrate it PLM System/s.
    I would divide it into two – Real-time & Event-Based (or time based) data. Real-time data would be the data which will be required in PLM & changes very frequently. Event-based data would be the data which may be supportive in nature & not frequently updated.
    I think, it should be like respective systems owns their data & PLM system will only display the data as required or can have a unified user interface where we can display the data as required. This will make it less complex & take lesser time to implement.

  9. Brian, Excellent observation. This is so called “change management”. In today’s business environment, to have a system flexible for change becomes “the must” requirement for IT. Federated flexible systems have a chance to leave. Big enterprise behemoths have a very high potential to die. Thanks for your comment! Also take a look on this one – http://plmtwine.com/2009/12/20/large-monolithic-plm-implementations-are-a-thing-of-the-past/. Best, Oleg

  10. YXZ, Yes, initially PLM started from the design department, since this is the place where product knowledge, data, etc is created. However, in today’s business, the need to exchange/access of data between other apps is very important, in my view. So, for most of the cases “copy” data is the way it works. Better federation is when you can access data without actually moving it between apps. Thanks for your comments! Best, Oleg

  11. Thomas, I agree with you. This topic is difficult. Complexity of the corp. infrastructures, multiple locations, etc ., However, I do believe it comes more and more as a need. I see multiple technological ways to resolve it. Some of them, in my view, related to advanced usage of cloud technologies. More data will be moved on cloud and federation (or integration) will become easy… What do you think about that? Best, Oleg

  12. Chandrajit, I think you pointed our an important thing related to how possible to optimize federation depends on processes and nature of tasks. I agree – devil in details, and you need to figure out specifically how to tune your system to federate data. Thanks for your comment! Best, Oleg

  13. Shekhar B says:

    Oleg, I think this is a very fundamental topic and to date an unsolved problem and reason for several failed PLM implementations. The first approach of data residing in one system only is impossible in any organization. PLM and ERP are still fighting for who owns the BOM. PLM or any other systems are tailored to meet the specific requirements/business needs. If data were to reside in one system several application logics have to be written on this single system and it will become an application behemoth impossible to manage. The needs of BI/Reporting are quite different from needs of PDM. Hence from my perspective the current solution is to have federated systems coupled with well defined processes for authoring and change management based on SOA solutions.

  14. Shekhar, Thanks for commenting. Agree, federation, SOA or any other “lean integration” will serve better vs. “one single system solves all problem” approach. Also, fights between enterprise systems are endless… Best, Oleg

  15. Joe Fowler says:

    To federate or not to federate that is the question. I led the F-35 JSF PLM Implementation and we made the decision not to federate the data. We had a single instance of meta data and replicated the data models to local sites to reduce response time read up. Each time someone perform a task, the application would read the central meta data file and read the data from the closest site. Replication was performed on line and real time, so just as soon as you vaulted the data it was available to end users no matter where they were located in the world.

    Many implementations use a federated approach because the PLM tool that was selected is not scalable and does not have a data transfer mechanism. So a lot of companies had to figure out how to federate the data using existing unsophisticated data transfer mechanisms (XML files transferred nightly, weekly, etc., zip files, FTPs). Enough said about that!

    Either approach will work given enough discipline and effort, however a federated approach causes some additional tasks that are not necessay in a single system.

    Each company should measure the risk that one of your partners or vendors is working on an obsolete design that is within lead time.

  16. Joe, To be or not to be :)… Thanks for your comment and sharing of your views and experience. I agree, the decision about federation (especially in the big implementation and organization) can be very specific and depends on many factors. However, my point was- don’t hug your data, federate it! Whatever mechanisms is appropriated. Another angle of this problem is a question of a single data model/storage/location for product data, but this is a different story, in my view. Best, Oleg

  17. Joe Fowler says:

    Reading the comments is kind of interesting but it is hard to put them in context without understanding what experience each of you has as an implementer.
    I led the PLM implementation on the F-35 JSF aircraft program for Lockheed Martin Aeronautics, arguably one of the largest, most complex, and one of the most successful implementations of PLM/PDM in the world. This implementation was international in scope, involving more than 14 partners, 35 design suppliers and 400 + build-to-print suppliers world wide.

    And it is in a single instance (NOT FEDERATED).

    Why?

    – Mostly so that we would have one source for configuration management of product data.
    – Engineering design and manufacturing planning BOMs are authored inside the PLM tool.
    – Auto update of manufacturing planning BOM into ERP solution.
    – We capture as built BOM and load it back into PLM so that waivers and deviations can be captured in a single source.
    – We track the as maintained BOM inside PLM also even though the individual transactions adding and deleting parts are performed in the field.

    All of our partners use the same system as we do.

    I think the primary reason most companies use a federated approach is it is the easy way out…
    It may cost more from an IT standpoint but you don’t have to address the cultural issues inside your company or the issues in dealing with your subcontractor base.

  18. Joe, Thanks! I think this is an excellent explanation how today’s PLM systems is doing their business. With today configuration management capabilities and change management, sounds like to bring all to the one system is the only one workable way. I believe, we can find few more similar implementations in the world. However, do you think, similar architecture can be implemented in mainstream? Very big amount of companies will be interested in PLM implementation if the proposed scale and complexity of PLM implementation will be lower and need to get ALL data under single PLM silo will be less needed… Don’t you think so? Best, Oleg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 253 other followers

%d bloggers like this: