Different by Design. Different for What Comes Next.

After nearly 30 years in the product lifecycle management industry, I have learned that PLM never really stands still.

I spent 15 years at Siemens, 10 years at PTC, and have now been with Aras for two years. During that time, I have watched PLM evolve through several distinct eras. Each era was shaped by new business demands, new product complexity, and the technologies available at the time.

What began largely as a way to manage engineering files has become a critical foundation for how companies design, build, maintain, and continuously improve increasingly complex products.

The industry has made enormous progress. It has also accumulated complexity. Many manufacturers now operate with fragmented product information, highly customized systems, disconnected processes, and decades of valuable engineering knowledge distributed across multiple systems and applications.

Today, artificial intelligence is creating another major inflection point.

The real consideration extends beyond adding AI features to PLM. Long-term value depends on whether the underlying PLM environment provides the connected context, adaptability, and governance that AI requires. That is why I believe being different matters.

PLM began by solving an immediate engineering problem

The origins of modern PLM can be traced to a practical need: companies adopting CAD tools needed a reliable way to store, control, and manage engineering files.

As digital design became more prevalent, manufacturers needed to know which drawing was current, who had changed it, and which version had been released. Product data management emerged to bring discipline to this rapidly growing volume of digital engineering information.

From there, the scope expanded.

Organizations began managing bills of material, product structures, documents, revisions, approvals, and engineering changes. PLM moved beyond file storage and became a system for controlling the definition of the product.

That was an important advancement, but the systems created during this era were naturally shaped by the problems and technology constraints of their time.

They were frequently centered on engineering departments, CAD environments, and highly structured product data. They were often deployed as large, monolithic implementations designed to standardize processes and maintain tight control.

For the challenges of that era, this approach made sense.

PLM expanded across the enterprise

As products and organizations became more complex, companies expected PLM to do more.

Engineering teams were no longer working within one location or one discipline. Companies needed to collaborate across global development centers, business units, suppliers, manufacturing facilities, and service organizations.

PLM expanded to support broader processes, including requirements management, quality, manufacturing planning, supplier collaboration, configuration management, systems engineering, and service.

The relationship between PLM and other enterprise systems also became increasingly important. Product development could no longer operate independently from ERP, MES, supply chain, quality, and other operational systems.

Companies wanted to design anywhere and build anywhere. They needed federated environments capable of supporting globally distributed teams while maintaining control over product configurations and changes.

The idea of a product lifecycle was becoming much broader than the engineering department.

But as PLM expanded, implementations frequently became more complicated. Systems were customized to support highly specific processes. Integrations multiplied. Upgrades became difficult. In some cases, organizations spent so much effort preserving the system they had implemented that adapting it to new business requirements became a major undertaking.

The system intended to manage change was not always easy to change itself.

SaaS changed the delivery model—but getting there has been difficult

The next major industry transition was toward cloud and SaaS.

The value proposition was clear. Companies could reduce infrastructure responsibilities, simplify operations, improve accessibility, and adopt new capabilities more regularly. For many organizations, SaaS represented the future of enterprise software.

But the journey from traditional on-premises PLM to SaaS has been far more challenging than the destination itself.

Many established PLM environments were built over years or even decades. They included extensive customizations, integrations, data structures, and processes that reflected how each company designed and delivered its products. Moving those environments to SaaS was rarely as simple as transferring the existing installation to the cloud.

In many cases, vendors had to substantially re-architect their offerings for SaaS. Customers were then faced with what could amount to a new implementation: migrating data, rebuilding integrations, redesigning processes, retraining users, and deciding which years of customization could, or should, be carried forward.

The benefits of SaaS may be compelling, but the cost, disruption, and organizational effort required to reach them can be significant.

This exposed an important issue within the traditional PLM model. A company could see the strategic value of moving to SaaS while still being constrained by the complexity of its existing environment. The technology had advanced, but the customer could not necessarily take advantage of it without effectively starting over.

Moving software to the cloud did not automatically solve every limitation associated with traditional PLM.

A rigid system delivered through SaaS is still a rigid system. A standardized application may be easier to operate, but it may also force companies to conform to processes that do not reflect how they create differentiated products or serve their customers.

The central question, therefore, became more important than where the software was hosted:

How can an organization modernize its PLM environment without abandoning the product knowledge, processes, integrations, and business value it has spent years creating?

This is particularly important because product development never stops changing. Acquisitions happen. Regulations evolve. New engineering disciplines become involved. Products gain more software and electronics. Supply chains shift. New business models emerge.

Manufacturers should not have to undertake another costly reimplementation every time enterprise technology enters a new era.

We have entered the AI era

Today, the industry is navigating another significant transition.

Artificial intelligence has the potential to transform how engineers find information, evaluate alternatives, identify risks, complete repetitive tasks, and make decisions throughout the product lifecycle.

But AI cannot create trusted outcomes from disconnected and poorly governed information.

An AI system may be able to generate a technically plausible response. In an industrial environment, plausibility is not enough. Engineers need to know which product configuration the answer applies to, whether the underlying information is current, who approved it, what requirements govern it, and how a proposed action could affect manufacturing, quality, compliance, cost, or service.

Industrial AI needs context.

That context comes from the relationships among requirements, parts, documents, software, simulations, changes, suppliers, manufacturing plans, quality records, and physical assets.

In other words, AI needs the digital thread.

This is why I do not see the AI era as simply another opportunity to add functionality to PLM. It is a test of whether the PLM foundation can connect information, preserve governance, support changing processes, and make product knowledge accessible to people and intelligent systems.

Why Aras is different by design

What attracted me to Aras was not simply another set of PLM applications. It was a different design philosophy.

Aras was built around the assumption that business requirements would continue to change.

Its model-based architecture allows organizations to evolve data models, workflows, relationships, and applications without treating every change as a traditional software customization. Its open approach allows companies to connect information across the broader enterprise environment. Its upgrade philosophy is intended to help customers preserve what they have built while continuing to adopt new platform capabilities.

These are not merely technical differences.

They affect whether a company can respond to a new regulation without beginning a multiyear replacement program. They affect whether an acquired business can be brought into a common digital thread. They affect whether engineering, manufacturing, quality, suppliers, and service teams can work from a connected product context.

And increasingly, they affect whether AI can be integrated into real product lifecycle processes rather than operating as a disconnected experiment.

Aras does not require every piece of product information to be copied into a single repository. It can connect and govern information across existing systems while providing the relationships and context required to understand the product across its lifecycle.

That approach is particularly important in the fragmented enterprise environments that exist today.

Different should create differentiated value

Being different is not valuable by itself.

The value comes from what that difference allows customers to do.

It allows them to modernize without repeatedly starting over.

It allows them to extend PLM into new business processes as needs emerge.

It allows them to connect existing systems and information rather than assuming that every application can be replaced.

It allows them to preserve decades of engineering knowledge while adopting new technology.

And it allows them to prepare for AI by establishing the connected, governed product context that intelligent systems require.

This is what “different by design” means to me. It is not simply a statement about software architecture. It is a commitment to helping customers continue evolving.

AI will not be the final era

AI is the defining technology wave of this moment, but it will not be the last.

New technologies, operating models, regulations, and forms of product complexity will continue to emerge. Ten years from now, manufacturers will face requirements that we cannot fully predict today.

The most important capability may therefore not be the ability to anticipate every future need.

It may be the ability to adapt when that future arrives.

PLM began by managing CAD data. It expanded to manage product structures and enterprise processes. It evolved to support global collaboration, connected ecosystems, digital threads, and now AI.

The next era will bring another set of demands.

Companies should not have to abandon the product knowledge, processes, and digital foundations they have spent decades building every time the industry enters a new phase.

They need a platform designed to evolve with them.

That is why I believe Aras is different by design.

Different and built to adapt to what comes next.