March, 2019

In a recent CMsights post we looked back at the history of configuration management software to help understand the impact of PLM solutions when delivered as an open platform of interoperating applications. That is, instead of a single mammoth enterprise solution from a sole provider that attempts to perform every function for every user across every industry. In this Part 2 we’ll explore the emerging strategy of “PLM Platforms” where functional services like CM are delivered over a federated architecture comprised of rapidly-deployable industry-specific best-in-class applications.

Implementing PLM as a platform, with CM as an integral part of that platform, offers to be an inherently more affordable, robust, and sustainable architecture that can last into the future without constantly ripping out and replacing entire multi-tier stacks of tightly-bound proprietary software. We’ll conclude by summarizing what this new strategy option means to the decision making of A&D program directors, project managers, and product engineers such that the much-discussed digital thread does not end up becoming a digital knot.

Recap of the State of Enterprise PLM

Over recent years there has been growing fatigue with the cost, complexity, and fragility of implementing enterprise PLM. It’s not uncommon that a road map for deploying PLM is measured in years of calendar time and millions of budget dollars. This is not surprising as the span of PLM-enabling solutions has grown to now include innovation management, requirements planning, portfolio management, computer-aided design, simulation, digital manufacturing, configuration management, cost management, additive manufacturing, model-based systems engineering, process automation, project management and then, of course, the integration of data and processes between all these functions.

Unfortunately, along the lengthy winding deployment road of “Big” PLM, user requirements change, product lines disappear, software evolves, vendors merge, managers leave, funding fluctuates, executive priorities shift, customizations devour budgets, system integrators profit, and then finally users lose patience. Must-have capabilities which were used to justify a PLM program at the onset – such as change control and configuration management across the entire product lifecycle and supply chain – are last, late, or lost in the implementation.

As a consequence, the many substantial benefits of PLM are never fully realized by some enterprises. It’s not quite fair to blame legacy PLM solution providers who came of age with client-server architectures and supersize RDBMS promising to break down silos, create one version of the truth, and transform product development. They simply had to pursue enlarging their product portfolios and increasing their footprint to meet the expectations of their investors. And after all, additional complexity often generated new revenue streams.

Emergence of PLM as a Platform of Applications and Services

While the concept of a platform is well known to consumers of social media, ride hailing, and cloud services, it is a relatively new term when applied to technical domains like PLM. Market analysts and consulting firms such as Gartner, IDC, and CIMdata first began talking about the “Platformization of PLM” and the “Product Innovation Platform” in 2014. Each firm offered their own nuanced definitions like these which you can find by searching across the Internet.

The widely-respected market research and advisory firm Gartner provides a description of the different types of platforms: “A platform is a product that serves or enables other products or services. Platforms (in the context of digital business) exist at many levels. They range from high-level platforms that enable a platform business model to low-level platforms that provide a collection of business and/or technology capabilities that other products or services consume to deliver their own business capabilities. Platforms that enable a platform business model have associated business ecosystems. They typically expose their capabilities to members of those ecosystems via APIs. Internal platforms also typically expose their capabilities via APIs. But they may offer other mechanisms, such as direct data access, as required by the products that consume them.”

The well-known global I.T. market intelligence firm IDC adds PLM in the following: “The product innovation platform, with PLM as its core, essentially ties together all enterprise applications, data, and tools used to design, develop, manufacture, and service products in one system. This includes extension into the front end of innovation to sense demand and manage intellectual property, the value chain of knowledge inside and outside the company for new product ideas, the supply chain for collaboration and rapid time to market, and manufacturing for rapid production, accuracy, and quality.”

CIMdata’s Product Innovation Platform Illustration

The PLM-focused research and industry consultancy firm CIMdata goes on further to say: “A product innovation platform is a set of evolving functional domains—process, lifecycle stage, and technical domains such as system ideation, profitability management, and quality and compliance. They are orchestrated by the platform with a “system of systems” approach that, in essence, makes a product innovation platform the enabler of the next generation of PLM-enabling solutions.”

You can perform your own research starting with CIMdata’s essential reading list on platformization found in their 3-part position paper series on “The Next Step in PLM’s Evolution” and in this dossier.

Industry observers Oleg Shilovitsky at Beyond PLM and Jos Voskuil’s PLM Weblog have also written about the platform movement on their websites where you can search for the term platform to find deeper analysis and conversation.

The Advantages and Challenges of PLM as a Platform

In reviewing dozens of blog posts, websites, white papers, and articles the following elements are being promoted as the advantages of PLM when delivered as a platform of apps and services instead of a monolithic solution.

  • PLM deployments can be more elastic and right-sized for the user’s environment
  • Affordability of budgeting a modular as-needed plug-play-pay approach
  • Less risky to implement in a staged modular fashion that organizations can digest at their pace
  • Use of best-in-class industry-focused solutions are even more viable and attractive than before
  • Acknowledges that no one solution provider can deliver all that is needed by industry
  • Reduced dependency on the fate and fortunes of a single enterprise provider
  • Configurability of functionality based on building blocks avoids customization of software
  • Cross-discipline collaboration and multi-disciplinary functionality using a toolkit approach
  • Offers a better way to support systems-of-systems product development complexity
  • Adaptability and flexibility as requirements change or user needs mature
  • Respects and leverages silos of expertise and centers of excellence without destroying them
  • Exploits SaaS and SOA for the extraction and liberation of data out of these silos
  • Hard boundaries between PLM and other enterprise solutions begin to dissolve
  • Extensibility and openness to adopt new technologies as they appear or mature
  • Readily more accommodating to cloud-based delivery platforms
  • Maintainability, upgradeability and sustainability that avoids obsolescence or constant ripping out of huge solutions

This is a long list which deserves a critical eye. Yet, what we at CMstat and our customers like is more fundamental. PLM as a platform is an approach based on incremental change and continuous improvement at a modest pace controlled by the user. It avoids a risky big-bang deployment of PLM from becoming a big-buck whimper. It offers a staged evolution that accommodates technology changes on the user’s terms, dampening the effects of a chaotic industry that profits from perpetual upgrades, replacements, obsolescence, and upheavals.

After all, what product engineer, project manager, or business director really wants to be disrupted, transformed, or revolutionized due to someone else’s business goals, instead of their own?

To be fair, the challenges of “platformization” are also numerous. A few of the most notable ones cited include:

  • Interoperability of component apps, modules and systems can still be tough
  • Integration technologies using next-generation APIs, middleware, and micro-services
  • Federation of data using new DM standards, distributed ledgers, blockchain, etc.
  • Automation and optimization of cross-disciplinary processes is now expected as the norm
  • Requires the migration to a true systems-of-systems approach to product development
  • Replacing a proprietary closed-stack pyramid with an heterogeneous open n-tier ring of apps
  • Not all applications and vendors will willingly support an open platform architecture
  • Resistance of existing providers, their system integrators, and internal supporters

These challenges, while fewer in number, are still substantial. Nevertheless, the net opinion of most market analysts and industry experts is that the platformization of PLM, with a more open federation of applications and data, provides a more resilient architecture into the future where complexity and change can overwhelm even the best-managed businesses. It is a strategy that industrial companies should consider as they look at upgrading or replacing existing applications, whether they be departmental software or enterprise-wide solution stacks.

What this Means for the Future of CM Software

As discussed in previous CMsights posts there have been at least six different strategies developed over the years for industry to attain CM capabilities, in addition to doing nothing and hoping for the best. They are:

1. Use of rudimentary spreadsheets, templates, document version control, and simple databases
2. Custom CM software tools developed in-house by resident CM experts
3. First generation commercial-off-the-shelf (COTS) or Out-of-the-Box (OOTB) software products for generic CM applications
4. Customizing engineering-centric PDM software by extending their change control capabilities
5. Employing industry-specific CM software products like CMstat’s PDMPlus CM for A&D
6. Implementing enterprise PLM solutions with CM functionality somewhere in the deployment road map

We compared the pros and cons of few of these strategies in this 3-part series on “Why not use PDM for all CM requirements”. We can now add and recommend a seventh option for evaluation:

7. Implement rapidly-deployable industry-specific best-in-class CM software applications as part of a larger PLM platform strategy.

The most important impact of this new option is that CM users within a PLM platform approach will no longer have to settle for generic engineering change control functionality masquerading as full-lifecycle configuration management to fully support the five fundamental tenets of CM which are: configuration planning, configuration identification, configuration status accounting, configuration change control, and configuration traceability and audit.

Freed from the constrictions of enterprise PLM, more capable CM software applications can be evaluated and selected to meet the specific needs of industries, programs and products. As a result, there will be greater competition between software providers which will accelerate innovation with improved affordability. We can already see this happening in other types of business where the concept of platform apps and services has now become the norm.

As example, the development and use of CM tools and processes dedicated to meeting the exact needs of users and processes in specific industries will be accelerated. Users of CM software and consumers of configuration data far downstream of engineering in the supply and service chains will not be encumbered with having to use underpowered engineering PDM or overweight enterprise PLM.

Finally, the evolution away from massive monolithic closed PLM solutions – promising everything for everyone – offers the timely opportunity to prevent the increasingly important “digital thread” from becoming a “digital knot” at its core for those already struggling with increasing product requirements and system configuration complexity. The reason to be concerned is that the more industry invests in digitalization, including digital threads and digital twins, the more apparent the limitations will become of a single system from one vendor using one sacred master database to handle it all. Industrial customers and their processes will no longer be held captive to what a single PLM solution can do. Instead, a PLM platform strategy will liberate the customer to be more agile as requirements change and capabilities mature, thus democratizing the distribution of product configuration data for non-expert users.

Recommendations for the A&D Industry

The move to viewing PLM as a platform has substantial implications for the A&D industry where programs and products can last over decades of continuous technological change. The program office, project leads, and product engineers should not consign the evaluation of PLM strategy options to others such as the I.T. department, system integrators, or solution providers. Decisions made about all of the other critical components of PLM (e.g. PDM, DMfg, CAD, EIM, PPM, CAE, etc.), and the strategy for managing the digital thread flowing thru these applications, will directly impact what creators and consumers of configuration data will and will not be able to ever accomplish. If you are one of these managers, it’s a strategy decision you should insist on participating in as stakeholders who will ultimately absorb the cost of deployments or pay the price of failure when it impacts your project.

Users should also be involved up front as your subject matter expert advisors. Regardless of the overall PLM strategy, business culture and technical processes will change and users should be part of it from the beginning. The process of strategy formulation should not be entered into believing the new PLM workflows should be configured to work just like the processes in place now or confined to whatever the new software will allow. To-be processes and tools should be flexible enough to accommodate constantly changing requirements of the business, project, and product portfolio. That can best be accomplished through the use of agile software apps in a robust architecture that is not a prisoner of an overly-rigid strategy which presumes few changes in requirements, technologies, processes, software, and providers will ever occur. That strategy of deploying enterprise PLM as a single solution is simply no longer resilient nor sustainable over the long-term. Nor is it likely to provide the capacity to support the rapidly-escalating complexity of configuration management requirements for specific industries like A&D.

What Do You Think?

What questions or issues do you think our industry should address going forward in considering CM tools as part of a larger PLM platform strategy? Let us know with a comment below and we will summarize these in a future CMsights post which you can sign up to receive at the top right of this page.

If you need help in facilitating an in-house discussion with your management team and colleagues on the different options for deploying CM as part of your overall PLM strategy, or to learn how CMstat’s PDMPlus can fit in a PLM platform, call in the CM experts at CMstat with an email to information@cmstat.com or phone to +001-503-537-1959.