Though Oracle Agile Product Lifecycle Management (PLM) was a trailblazer for the industry when it was first introduced, users quickly realized that many of their business needs weren’t being met with the out-of-the-box system.
In response, Oracle Agile PLM introduced Process Extensions (PX). These extensions, fundamental to customizing the system, have played a pivotal role in tailoring the software to the unique requirements of each customer.
In the early 2000s, Oracle Agile PLM was a self-contained product with minimal built-in extensibility. As Agile's customer base matured and their needs grew more intricate, the need for customization became apparent. Process Extensions were designed to bridge this gap.
PX utilizes a full-code approach, requiring the development of Java classes or web services that activate based on specific events or through user interface menus.
Over the years, this has spawned a cottage industry of sorts to sell PXs to Agile customers. Many Agile customers have also built custom PXs in-house and/or leveraged PXs from consulting companies such as Domain Systems.
While PX effectively addressed the need for customization, its reliance on traditional coding presented inherent challenges. These challenges will be explored in detail later, but a significant pain point lies in the difficulty of replacing PX functionality when migrating away from Agile PLM.
Fast forward to the present, and the landscape of enterprise application development has been revolutionized by low-code/no-code tools. This innovative approach empowers users to extend functionalities without the need for extensive coding expertise.
A prime example of this modern approach, Propel Software offers a user-friendly interface that allows for customization through clicks, not code. This series will delve into the specific ways Propel PLM handles functionalities traditionally addressed through PX in Agile, showcasing the advantages of a low-code/no-code approach.
What are some uses of Process Extensions?
Historically, organizations have grappled with the limitations of out-of-the-box solutions, necessitating custom integrations and modifications. This need for adaptability led to the advent of Process Extensions (PX), Agile’s extensibility framework. Process Extensions are points within a product where new functionalities can be introduced without altering the core architecture.
Agile PLM customers have used PX to extend their system by:
- Generating Reports: Agile supported a few out-of-the-box reports but this was insufficient for most customers. PXs were implemented to generate custom reports like Change Status or BOM compliance.
- Push Discovery: This is a popular PX that supports sharing Items and sub-assemblies securely with suppliers and contract manufacturers.
- Auto-Assigning Criteria-Based Approvers: Another popular PX that uses an Approval Matrix featuring a list of Approvers and Observers for Change Orders defined in a spreadsheet to automate this task.
- Auto Incorporate/Un-incorporate Items Upon Change Release
- Clone Engineering Change Request to ECO
- Print to PDF, Batch Printing
- Field Validation Prior to Workflow Phase Change
- And many many more.
As Domain Systems explains: “Process Extensions nodes are built into Agile PLM, allowing you to initiate (manually or automatically) any action you need to perform within the system. PXs are developed by a third party, but they can be developed in-house by someone familiar enough with the system.”
At the heart of Process Extensions is a full-code approach. This method requires developers to write extensive custom code, typically Java, to create functionalities that the original software does not provide.
A full-code customization approach poses significant challenges, including:
- Losing critical knowledge over time as original developers move on
- Paying expensive fees for third-party code development
- Making upgrades increasingly complex and error-prone
- Risking your IP security with weakened points of connection
- Difficulty migrating to another system
Extensibility in the Cloud Era
As the software landscape evolved, these challenges highlighted the limitations of the full code approach, particularly in terms of scalability, maintenance, and upgrade compatibility.
The introduction of low code/no code platforms marked a significant shift, offering a more sustainable solution to software extensibility. These platforms enable non-developers to create or modify processes through a user-friendly interface, reducing reliance on custom code and simplifying both development and maintenance.
Propel Software’s PLM solution is built on top of an industry-leading low-code/no-code platform, Salesforce. Propel leverages the Salesforce platform to offer unparalleled extensibility using clicks, not code. Propel’s customization options extend way beyond just Process Extensions. It supports extensibility at the following layers:
- Data model: Propel objects can be extended through custom fields of various data types. Customers can also define new Objects through a no-code interface (Object Manager) and connect these new objects to Propel objects via Related Lists and Lookups.
- Process: Using the powerful Flow Builder, customers can tailor Propel to their needs.
- User Interface: Lightning App Builder allows customers to tailor the UI to their needs. Some customizations include:some text
- Buttons and Actions: adding, removing, rearranging, relabeling, etc.
- Tabs: adding and removing, or showing and hiding based on user role. Including top-level tabs.
- Lightning Components: Augmenting the out-of-the-box UI to provide the right information to the end user.
- And many more.
- Integration: Propel supports different integration patterns to move data in and out of Propel. Eg: using REST and SOAP APIs, streaming APIs, event-based full-code, or SFTP file-based integration.
Replace Process Extensions Using Clicks, Not Code
As seen in the previous section, Propel offers extensibility at various levels. In this section, let’s zoom in on a specific aspect of this extensibility — how are Agile’s popular Process Extensions handled in Propel? Is there equivalent functionality and a migration path?
Propel uses a multi-pronged approach:
1. Built-in Functionalities that benefit from our leadership team (including myself) having worked on Agile and therefore knowing its shortcomings and opportunities.
2. Low-code/no-code Tools such as Flow and App Builder within the Salesforce platform to build complex extensions without writing code.
3. Full-code but upgrade-friendly approach (when needed). This is less common because most needs are met with options 1 and 2 above.
Unlike Process Extensions in Agile, Propel customizations are upgrade-friendly. In fact, Propel provides updates to its software six times a year and most customer upgrades can be completed in less than an hour. This compared to Agile PLM upgrades that typically take months to complete.
Here's a list of popular Agile PLM PXs and the equivalent approach in Propel:
The above list is just a partial list of PXs.
As you can see from the above list, Propel has already built a number of features in the product that were supported through PX in Agile. This is thanks to the combined decades of experience in Agile PLM and seeing firsthand what worked and what did not work in Agile over the years.
Of course, every business is unique—and there are an infinite amount of potential customizations to meet these unique needs. For these instances, Propel users can leverage the power of the no-code/low-code platform to support them.
Up Next …
As we move forward, traditional Agile Process Extensions aren’t likely to outlast the dead-end that is Agile 9.3.6. The good news you’re in safe hands with Propel as you look to migrate from Agile PLM.
It’s only a matter of time before more flexible and user-centric solutions like Propel completely redefine the landscape of product lifecycle management, and force legacy users to step into the future.
Coming up in this series, we will dive deeper into the specifics of a few Process Extensions and the equivalent feature or customization in Propel. We’ll take a closer look at how these popular Process Extensions are handled in Propel:
1. Push Discovery
2. Approval Matrix
