Pragmatic Architectures for PLM Future

I think, we’ve faced many changes during past few years related to how enterprise software is going to be implemented. Shifts in business models, new social and cloud technologies, demand for free software and many others. Thinking about all these challenges and changes, I want to discuss what is potential outcome and impact on Product Lifecycle Management architecture and implementations.

In my view, we came to the point when PLM is adopted as a business methodology and business strategy. However, I think we still have a huge gap between understanding of business practice and technologies and implementations we have in the field. So, proposed principles are my ideas about to define a pragmatic PLM architecture for the next 5-7 years. I’m taking this time span, as something that allows us to change fundamental architectures of the systems and not only make cosmetics tweaks.

1. Individuals Interaction and Process Tools. What should be an approach to design process tools? It looks to me, the key capabilities should be in the way a specific user (individual if you will) can impact overall process design and process management in the organization. Process tools need to move from space where people are divided into “process planners” and “process execution”. No more “build vs. run”. The individuals in an organization will need to define right processes and be able to improve as business change in the organization.

2. Customers Collaboration. I think, we move to the space where a customer will decide how to assemble PLM system from a flexible set of PLM services. Those services will be developed and providers by PLM suppliers. However final system configuration will be defined by customer and answer to the specific needs of business and organization.

3. Permanent Change as a key factor to improve software. Changes become a key factor in PLM architecture adoption. Today’s systems are very expensive in case you want to make a change in their configuration, data model, implementation practices. This is something we need to work on the future. Cost of change will be key driver to successful PLM implementation. Change is on going procedure. Together with future SaaS models it will finally remove the need in planning precise PLM implementation phases from year to year.

4. Working Software over Methodologies and Documentation. This is last, but very important. No more documentation. Architectures need to allow people to learn how PLM system works, systems will become self explained and self documented. In the same way, you can discover software code, you will be able to discover PLM implementations. This will be a future role of PLM architects in the organization.

This is, of course, not a recipe how to build new PLM system. However, I do so sense in these principles to think how to change enterprise PLM software in the future.

Just my thoughts. As usual, your comments are welcome!

Best, Oleg